翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# クラスターキャッシュ管理
キャッシュは、ディスク I/O の削減に役立つため、データベース (DB) の最も重要な機能の 1 つです。最も頻繁にアクセスされるデータは、*バッファキャッシュと呼ばれるメモリ領域に格納されます*。クエリが頻繁に実行されると、ディスクではなくキャッシュから直接データが取得されます。これはより高速で、スケーラビリティとアプリケーションパフォーマンスが向上します。PostgreSQL のキャッシュサイズは、`shared_buffers`パラメーターを使用して設定します。詳細については、「[メモリ](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-MEMORY) (PostgreSQL ドキュメント)」を参照してください。
フェイルオーバー後、Amazon Aurora PostgreSQL [互換エディションのクラスターキャッシュ管理 (CCM)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.cluster-cache-mgmt.html) は、アプリケーションとデータベースの復旧パフォーマンスを向上させるように設計されています。CCM を使用しない一般的なフェイルオーバーが発生した場合、一時的だがパフォーマンスが大幅に低下することがあります。これは、フェイルオーバー DB インスタンスの起動時にバッファキャッシュが空になることが原因で発生します。空のキャッシュは、*コールドキャッシュ*とも呼ばれます。DB インスタンスはディスクから読み取る必要がありますが、これはキャッシュからの読み取りよりも時間がかかります。
CCM を実装する場合、*優先するリーダー* DB インスタンスを選択すると、CCM はそのキャッシュメモリをプライマリ (*ライター*) DB インスタンスのキャッシュメモリと継続的に同期します。フェイルオーバーが発生すると、優先リーダー DB インスタンスが新しいライター DB インスタンスに昇格します。*ウォームキャッシュと呼ばれるキャッシュメモリが既に搭載されているため*、フェイルオーバーがアプリケーションのパフォーマンスに与える影響を最小限に抑えることができます。
## クラスターキャッシュ管理はどのように機能しますか?
フェイルオーバー DB インスタンスは、プライマリのライター DB インスタンスとは異なるアベイラビリティーゾーンにあります。優先リーダー DB インスタンスは優先フェイルオーバーターゲットで、**Tier-0** の優先度レベルを割り当てることで指定されます。
**注記**
昇格階層の優先度は、Aurora リーダーが失敗後に書き込み DB インスタンスに昇格する順序を指定する値です。有効な値は 0～15 です。ここで、0 は優先度が最も高く、15 が最も低いことを表します。昇格階層の詳細については、「[Aurora DB クラスターの耐障害性](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraHighAvailability.html#Aurora.Managing.FaultTolerance)」を参照してください。昇格階層を変更しても、停止は発生しません。
CCM は、ライター DB インスタンスのキャッシュを優先リーダー DB インスタンスと同期します。リーダー DB インスタンスは、現在キャッシュされているバッファアドレスのセットをブルームフィルターとしてライター DB インスタンスに送信します。*ブルームフィルターは*、要素がセットのメンバーかどうかをテストするために使用される、確率的でメモリ効率の高いデータ構造です。ブルームフィルターを使用すると、リーダー DB インスタンスがライター DB インスタンスに同じバッファアドレスを繰り返し送信することを防ぎます。ライター DB インスタンスはブルームフィルターを受け取ると、バッファーキャッシュ内のブロックを比較し、頻繁に使用されるバッファーをリーダー DB インスタンスに送信します。デフォルトでは、バッファの使用回数が3を超えると、そのバッファは頻繁に使用されると見なされます。
次の図は、CCM がライター DB インスタンスのバッファキャッシュを優先リーダー DB インスタンスと同期する方法を示しています。
![\[異なるアベイラビリティーゾーンの Aurora DB インスタンス間で設定されたクラスターキャッシュ管理。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/ccm-and-qpm-aurora-postgresql/images/ccm.png)
CCM の詳細については、「[Aurora PostgreSQL のクラスターキャッシュ管理によるフェイルオーバー後の高速リカバリ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.cluster-cache-mgmt.html)」(Aurora ドキュメント) と「[Aurora PostgreSQL クラスターキャッシュ管理の概要](https://aws.amazon.com/blogs/database/introduction-to-aurora-postgresql-cluster-cache-management/)」(AWSブログ記事) を参照してください。CCM の設定方法については、「[クラスターキャッシュ管理の設定](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.cluster-cache-mgmt.html#AuroraPostgreSQL.cluster-cache-mgmt.Configure)」(Aurora ドキュメント) を参照してください。
## 制約事項
CCM 機能には次の制約があります。
+ リーダー DB インスタンスは、ライター DB インスタンスと同じ DB インスタンスクラスタイプとサイズ（`r5.2xlarge`またはなど）でなければなりません`db.r5.xlarge`。
+ CCM は、Aurora Global Database の一部である Aurora PostgreSQL DB クラスターではサポートされません。
## クラスターキャッシュ管理のユースケース
小売、銀行、金融などの一部の業界では、わずか数ミリ秒の遅延がアプリケーションのパフォーマンスの問題を引き起こし、ビジネスに大きな損失をもたらす可能性があります。CCM は、プライマリデータベースインスタンスのバッファキャッシュを優先バックアップインスタンスに継続的に同期させることで、アプリケーションとデータベースのパフォーマンスを回復させるのに役立つため、フェイルオーバーによるビジネス損失を防ぐことができます。