翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

キャッシュはディスク I/O の削減につながるため、どのデータベース (DB) にとっても最も重要な機能の 1 つです。最も頻繁にアクセスされるデータはバッファキャッシュと呼ばれるメモリ領域に保存されます。クエリが頻繁に実行される場合、データはディスクではなくキャッシュから直接取得されます。この方が高速で、スケーラビリティとアプリケーションのパフォーマンスも向上します。PostgreSQL のキャッシュサイズを設定するには、shared_buffers のパラメータを使用します。詳細については、「メモリ」(PostgreSQL ドキュメント) を参照してください。

フェイルオーバー後、Amazon Aurora PostgreSQL 互換エディションのクラスターキャッシュ管理 (CCM) は、アプリケーションとデータベース復旧のパフォーマンスが向上するように設計されています。CCM を使用しない一般的なフェイルオーバーの状況では、一時的ながらパフォーマンスが大幅に低下することがあります。これはフェイルオーバー DB インスタンスの起動時に、バッファキャッシュが空になることが原因です。空のキャッシュは、コールドキャッシュとも呼ばれます。DB インスタンスはディスクから読み取る必要があり、キャッシュからの読み取りよりも時間がかかります。

CCM を実装するときは、推奨リーダー DB インスタンスを選択し、CCM はキャッシュメモリをプライマリのキャッシュメモリまたはライター DB インスタンスと継続的に同期させます。フェイルオーバーが発生した場合、推奨リーダー DB インスタンスが新しいライター DB インスタンスに昇格されます。というのも、このインスタンスには、ウォームキャッシュというキャッシュメモリがすでに備わっていて、フェイルオーバーがアプリケーションのパフォーマンスに与える影響を最小限に抑えます。

クラスターキャッシュ管理はどのように機能しますか?

フェイルオーバー DB インスタンスは、プライマリのライター DB インスタンスとは異なるアベイラビリティーゾーンにあります。推奨リーダー DB インスタンスは優先フェイルオーバーターゲットであり、優先フェイルオーバーターゲットは、Tier-0 優先度レベルに割り当てることで指定されます。

CCM は、ライター DB インスタンスのキャッシュを推奨リーダー DB インスタンスと同期します。リーダー DB インスタンスは、現在キャッシュされているバッファアドレスのセットを、ブルームフィルターとしてライター DB インスタンスに送信します。ブルームフィルターは、ある要素がセットのメンバーであるかどうかをテストするために使用される、確率的でメモリ効率の高いデータ構造です。ブルームフィルターを使用すると、リーダー DB インスタンスが同じバッファアドレスをライター DB インスタンスに繰り返し送信するのを防ぐことができます。ライター DB インスタンスはブルームフィルターを受け取ると、バッファキャッシュ内のブロックを比較し、使用頻度の高いバッファをリーダー DB インスタンスに送信します。デフォルトでは、使用回数が 3 回を超えるバッファは頻繁に使用されていると見なされます。

次の図は、CCM がライター DB インスタンスのバッファキャッシュを推奨リーダー DB インスタンスと同期する方法を示しています。

CCM の詳細については、「Aurora PostgreSQL のクラスターキャッシュ管理によるフェイルオーバー後の高速復旧」(Aurora ドキュメント) および「Aurora PostgreSQL クラスターキャッシュ管理の概要」(AWS ブログ記事) を参照してください。CCM の設定方法については、「クラスターキャッシュ管理の設定」(Aurora ドキュメント) を参照してください。

制限事項

CCM の機能には以下の制限があります。

クラスターキャッシュ管理のユースケース

小売、銀行、金融などの一部の業界では、わずか数ミリ秒の遅延がアプリケーションのパフォーマンスに問題を引き起こし、ビジネスに大きな損失をもたらす可能性があります。CCM は、プライマリデータベースインスタンスのバッファキャッシュを推奨バックアップインスタンスに継続的に同期することで、アプリケーションとデータベースのパフォーマンスを回復できるため、フェイルオーバーによるビジネス上の損失を防ぐことができます。