Aurora PostgreSQL のクラスターキャッシュ管理によるフェイルオーバー後の高速リカバリ

フェイルオーバーが発生した場合に Aurora PostgreSQL クラスター内の書き込み DB インスタンスを迅速にリカバリするには、Amazon Aurora PostgreSQL のクラスターキャッシュ管理を使用します。クラスターキャッシュ管理を使用することで、フェイルオーバー発生時でもアプリケーションパフォーマンスを維持することができます。

一般的なフェイルオーバーが発生した場合、フェイルオーバー後に一時的だがパフォーマンスが大幅に低下することがあります。この低下は、フェイルオーバー DB インスタンスの起動時にバッファキャッシュが空になることが原因で発生します。空のキャッシュは、コールドキャッシュとも呼ばれます。コールドキャッシュでは、DB インスタンスは、低速のディスクから読み取る必要があるため、パフォーマンスが低下します。バッファキャッシュに格納されている値は使用されません。

クラスターキャッシュ管理では、特定の読み取り DB インスタンスをフェイルオーバーのターゲットとして設定します。クラスターキャッシュ管理により、指定された読み取りのキャッシュ内のデータは、書き込み DB インスタンスのキャッシュ内のデータと確実に同期されます。事前に入力された値を持つ指定された読み取りのキャッシュは、ウォームキャッシュと呼ばれます。フェイルオーバーが発生すると、指定された読み取りでは、新しい書き込み DB インスタンスに昇格するとすぐにウォームキャッシュ内の値が使用されます。このアプローチでは、アプリケーションで優れたリカバリパフォーマンスを実現することができます。

クラスターキャッシュ管理では、指定されたリーダーインスタンスのインスタンスタイプとサイズ (db.r5.2xlarge または db.r5.xlarge など) が読み取りと同じである必要があります。Aurora PostgreSQL DB クラスターを作成すると、フェイルオーバー中のクラスターの回復が可能になることにご留意ください。インスタンスクラスのタイプとサイズの一覧については、Hardware specifications for DB instance classes for Aurora を参照してください。

クラスターキャッシュ管理の設定

クラスターキャッシュ管理を設定するには、以下のプロセスを順番に実行します。

クラスターキャッシュ管理の有効化

クラスターキャッシュ管理を有効にするには、以下のステップを実行します。

aws rds modify-db-cluster-parameter-group \
    --db-cluster-parameter-group-name my-db-cluster-parameter-group \
    --parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"

aws rds modify-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name my-db-cluster-parameter-group ^
    --parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"

書き込み DB インスタンスの昇格階層の優先度の設定

クラスターキャッシュ管理の場合、Aurora PostgreSQL DB クラスターの書き込み DB インスタンスの昇格階層の優先度が Tier 0 であることを確認します。昇格階層の優先度は、Aurora リーダーが失敗後に書き込み DB インスタンスに昇格する順序を指定する値です。有効な値は 0～15 です。ここで、0 は優先度が最も高く、15 が最も低いことを表します。昇格階層の詳細については、Aurora DB クラスターの耐障害性 を参照してください。

aws rds modify-db-instance \
    --db-instance-identifier writer-db-instance \
    --promotion-tier 0 \
    --apply-immediately

aws rds modify-db-instance ^
    --db-instance-identifier writer-db-instance ^
    ---promotion-tier 0  ^
    --apply-immediately

読み取り DB インスタンスの昇格階層の優先度の設定

クラスターキャッシュ管理用にリーダー DB インスタンスを 1 つだけ設定する必要があります。そのためには、書き込み DB インスタンスと同じインスタンスクラスで同じサイズの Aurora PostgreSQL クラスターから、リーダーを選択します。例えば、読み取りが db.r5.xlarge を使用する場合、この同じインスタンスクラスターのタイプとサイズを使用するリーダーを選択します。その昇格階層の優先度を 0 に設定します。

昇格階層の優先度は、Aurora リーダーが失敗後に書き込み DB インスタンスに昇格する順序を指定する値です。有効な値は 0～15 です。ここで、0 は優先度が最も高く、15 が最も低いことを表します。

aws rds modify-db-instance \
    --db-instance-identifier reader-db-instance \
    --promotion-tier 0 \
    --apply-immediately

aws rds modify-db-instance ^
    --db-instance-identifier reader-db-instance ^
    ---promotion-tier 0  ^
    --apply-immediately

バッファキャッシュのモニタリング

クラスターキャッシュ管理を設定したら、書き込み DB インスタンスのバッファキャッシュと指定された読み取りのウォームバッファキャッシュの間の同期の状態をモニタリングできます。書き込み DB インスタンスと、指定された読み取り DB インスタンスの両方のバッファキャッシュコンテンツを調べるには、PostgreSQL pg_buffercache モジュールを使用します。詳細については、pg_buffercache PostgreSQL ドキュメントを参照してください。

aurora_ccm_status 関数を使用する

また、クラスターキャッシュ管理では、aurora_ccm_status 関数も使用できます。指定された読み取りのキャッシュウォームの進行状況に関する次の情報を取得するには、書き込みの DB インスタンスの aurora_ccm_status 関数を使用します。

次の例は、aurora_ccm_status 関数を使用してその出力の一部をウォームレートとウォームの割合 (%) に変換する方法を示しています。

SELECT buffers_sent_last_minute*8/60 AS warm_rate_kbps, 
   100*(1.0-buffers_sent_last_scan::float/buffers_found_last_scan) AS warm_percent 
   FROM aurora_ccm_status();

CCM 設定のトラブルシューティング

apg_ccm_enabled クラスターパラメータを有効にすると、ライター DB インスタンスのインスタンスレベルでクラスターキャッシュ管理が自動的にオンになり、Aurora PostgreSQL DB クラスターの 1 つのリーダー DB インスタンスで有効になります。ライターインスタンスとリーダーインスタンスは、同じインスタンスクラスタイプとサイズを使用する必要があります。昇格階層の優先度は 0 に設定されます。DB クラスター内の他のリーダーインスタンスにはゼロ以外の昇格階層が必要で、クラスターキャッシュ管理はそれらのインスタンスに対して無効になっています。

設定に問題が発生し、クラスターキャッシュ管理が無効になる理由は次のとおりです。