DAX クラスターはマネージドクラスターですが、アプリケーションの要件に合わせて設定を調整できます。DynamoDB API オペレーションと緊密に統合されているため、アプリケーションを DAX と統合する際は、以下の点を考慮する必要があります。
このセクションの内容
DAX の料金
クラスターのコストは、プロビジョニングしたノードの数とサイズによって異なります。すべてのノードでは、クラスターで実行される 1 時間ごとに費用が発生します。詳細については、「Amazon DynamoDB 料金
キャッシュヒットによって DynamoDB の費用が発生することはありませんが、DAX クラスターリソースに影響を与えます。キャッシュミスでは DynamoDB の読み取り費用が発生し、DAX リソースが必要です。書き込みでは DynamoDB の書き込み費用が発生し、書き込みをプロキシするための DAX クラスターリソースに影響を与えます。
項目キャッシュとクエリキャッシュ
DAX は項目キャッシュとクエリキャッシュを保持します。これらのキャッシュの違いを理解することは、キャッシュがアプリケーションに与えるパフォーマンスと整合性の特性を判断するのに役立ちます。
| キャッシュの特性 | 項目キャッシュ | クエリキャッシュ |
|---|---|---|
|
目的 |
GetItem および BatchGetItem API オペレーションの結果を保存します。 |
クエリおよびスキャン API オペレーションの結果を保存します。これらのオペレーションは、特定の項目キーではなく、クエリ条件に基づいて複数の項目を返すことができます。 |
|
アクセスタイプ |
キーベースのアクセスを使用します。 アプリケーションが |
パラメータベースのアクセスを使用します。 DAX は、 |
|
キャッシュの無効化 |
DAX は、以下のシナリオで、更新された項目を DAX クラスター内のノードの項目キャッシュに自動的にレプリケートします。
|
クエリキャッシュは、項目キャッシュよりも無効化が困難です。項目の更新は、キャッシュされたクエリやスキャンに直接マッピングされない場合があります。データ整合性を維持するには、クエリキャッシュの TTL を慎重に調整する必要があります。DAX またはベーステーブルを介した書き込みは、TTL が以前にキャッシュされた応答を期限切れにし、DAX が DynamoDB に対して新しいクエリを実行するまで、クエリキャッシュに反映されません。 |
|
グローバルセカンダリインデックス |
GetItem API オペレーションはローカルセカンダリインデックスまたはグローバルセカンダリインデックスではサポートされていないため、項目キャッシュはベーステーブルからの読み取りのみをキャッシュします。 |
クエリキャッシュは、テーブルとインデックスの両方に対してクエリをキャッシュします。 |
キャッシュの TTL 設定の選択
TTL は、データが期限切れになるまでに、キャッシュに保存される期間を決定します。この期間が過ぎると、次のリクエストでデータが自動的に更新されます。DAX キャッシュに適切な TTL 設定を選択する場合は、アプリケーションのパフォーマンスの最適化とデータ整合性のバランスをとる必要があります。すべてのアプリケーションに適した普遍的な TTL 設定はないため、最適な TTL 設定はアプリケーションに固有の特性と要件によって異なります。この規範ガイダンスを使用して、保守的な TTL 設定から始めることをお勧めします。その後、アプリケーションのパフォーマンスデータとインサイトに基づいて、TTL 設定を繰り返し調整します。
DAX は項目キャッシュの LRU (least recently used) リストを保持します。LRU リストは、項目がいつキャッシュに最初に書き込まれたか、またはいつキャッシュから最後に読み取られたかを追跡します。DAX ノードのメモリがいっぱいになると、(期限切れでない場合でも) DAX はより古い項目を削除し、新しい項目のためのメモリを確保します。LRU アルゴリズムは常に有効で、ユーザーが設定することはできません。
アプリケーションに適した TTL 期間を設定するには、以下の点を考慮します。
データアクセスパターンを理解する
-
読み込み負荷の高いワークロード – 読み込み負荷が高く、データ更新の頻度が低いアプリケーションでは、TTL 期間を長く設定してキャッシュミスの数を減らします。TTL 期間を長くすると、基盤となる DynamoDB テーブルにアクセスする必要も少なくなります。
-
書き込み負荷の高いワークロード – DAX を介して書き込まれない更新が頻繁に行われるアプリケーションの場合、キャッシュとデータベースの整合性が保たれるように TTL 期間を短く設定します。TTL 期間を短くすると、古いデータが使用されるリスクも軽減されます。
アプリケーションのパフォーマンス要件を評価する
-
レイテンシー感度 – データの鮮度よりも低レイテンシーがアプリケーションで必要な場合は、TTL 期間を長く設定します。TTL 時間が長くなるとキャッシュヒットが最大化され、平均読み取りレイテンシーが短縮されます。
-
スループットとスケーラビリティ — TTL 時間が長くなると、DynamoDB テーブルの負荷が軽減され、スループットとスケーラビリティが向上します。ただし、スループットやスケーラビリティとデータ鮮度のバランスをとる必要があります。
キャッシュエビクションとメモリ使用量の分析
-
キャッシュメモリの制限 — DAX クラスターのメモリ使用量をモニタリングします。TTL 時間が長くなるとキャッシュにより多くのデータが保存され、メモリ制限に達し、LRU ベースのエビクションが発生する可能性があります。
メトリクスとモニタリングを使用して TTL を調整する
キャッシュヒットとキャッシュミス、CPU およびメモリの使用率などのメトリクスを定期的に確認します。これらのメトリクスに基づいて TTL 設定を調整して、パフォーマンスとデータ鮮度のバランスを最適化します。キャッシュミスが多く、メモリ使用率が低い場合は、TTL 期間を長くしてキャッシュヒットレートを高めます。
ビジネス要件とコンプライアンスを考慮する
データ保持ポリシーによって、機密情報または個人情報に設定できる最大 TTL 期間が変わる場合があります。
TTL をゼロに設定する場合のキャッシュの動作
TTL を 0 に設定すると、項目キャッシュとクエリキャッシュは以下のように動作します。
-
項目キャッシュ – キャッシュ内の項目は、LRU エビクションまたは書き込みスルーオペレーションが発生した場合にのみ更新されます。
-
クエリキャッシュ — クエリレスポンスはキャッシュされません。
DAX クラスターを使用した複数のテーブルのキャッシュ
個別のキャッシュを必要としない複数の小さな DynamoDB テーブルを持つワークロードの場合、単一の DAX クラスターがこれらのテーブルのリクエストをキャッシュします。これにより、特に複数のテーブルにアクセスし、高パフォーマンス読み取りを必要とするアプリケーションでは、DAX をより柔軟かつ効率的に使用できます。
DynamoDB データプレーン API と同様に、DAX リクエストにはテーブル名が必要です。同じ DAX クラスターで複数のテーブルを使用する場合、特定の設定は必要ありません。ただし、クラスターのセキュリティアクセス許可で、キャッシュされたすべてのテーブルへのアクセスが許可されていることを確認する必要があります。
複数のテーブルで DAX を使用する際の考慮事項
複数の DynamoDB テーブルで DAX を使用する場合は、以下の点を考慮する必要があります。
-
メモリ管理 – 複数のテーブルで DAX を使用する場合、ワーキングデータセットの合計サイズを考慮する必要があります。データセット内のすべてのテーブルは、選択したノードタイプと同じメモリ領域を共有します。
-
リソース割り当て — DAX クラスターのリソースは、キャッシュされたすべてのテーブル間で共有されます。ただし、トラフィックの多いテーブルは、隣接する小さなテーブルでのデータエビクションを発生させる可能性があります。
-
規模の経済 — より小さなリソースをより大きな DAX クラスターにグループ化して、より安定したパターンにトラフィックを平均化します。DAX クラスターに必要な読み取りリソースの総数については、3 つ以上のノードを持つことも経済的です。これにより、クラスター内のすべてのキャッシュされたテーブルの可用性も向上します。
DAX および DynamoDB グローバルテーブルのデータレプリケーション
DAX はリージョンベースのサービスであるため、クラスターは自身の AWS リージョン 内のトラフィックのみを認識します。グローバルテーブルは、別のリージョンからデータをレプリケートする際に、キャッシュを書き込みアラウンドします。
TTL 時間が長くなると、古いデータがプライマリリージョンよりもセカンダリリージョンに長く残る可能性があります。これにより、セカンダリリージョンのローカルキャッシュでキャッシュミスが発生する可能性があります。
次の図は、ソースリージョン A のグローバルテーブルレベルで発生するデータレプリケーションを示しています。リージョン B の DAX クラスターは、ソースリージョン A から新しくレプリケートされたデータをすぐには認識しません。
DAX が利用可能なリージョン
DynamoDB テーブルをサポートするすべてのリージョンが DAX クラスターのデプロイをサポートしているわけではありません。アプリケーションで DAX による読み取りレイテンシーが低い場合は、まず DAX をサポートするリージョンのリストを確認します。次に、DynamoDB テーブルのリージョンを選択します。
DAX キャッシュの動作
DAX はメタデータキャッシュおよびネガティブキャッシュを実行します。これらのキャッシュの動作を理解することで、キャッシュされた項目とネガティブキャッシュエントリの属性メタデータを効果的に管理できます。
-
メタデータのキャッシュ - DAX クラスターは、キャッシュされた項目の属性名に関するメタデータを無期限に保持します。このメタデータは、項目の有効期限が切れたり、キャッシュから削除された後も保持されます。
時間の経過とともに、大量の属性名を使用するアプリケーションは、DAX クラスターでメモリ消耗を引き起こすことがあります。この制限は最上位の属性名のみに適用され、ネスト属性名には適用されません。無制限の属性名の例には、タイムスタンプ、UUID や ID があります。タイムスタンプとセッション ID を属性値として使用することはできますが、より短く予測可能な属性名を使用することをお勧めします。
-
ネガティブキャッシュ – キャッシュミスが発生し、DynamoDB テーブルからの読み取りで一致する項目がない場合、DAX は対応する項目キャッシュまたはクエリキャッシュにネガティブキャッシュエントリを追加します。このエントリは、キャッシュの TTL 期間が終了するか、書き込みスルーが発生するまで保持されます。DAX は、将来のリクエストに対して、このネガティブキャッシュエントリを返し続けます。
ネガティブキャッシュの動作がアプリケーションパターンに合わない場合は、DAX が空の結果を返す際に DynamoDB テーブルを直接読み取ります。また、キャッシュ内の空の結果が長期間続くのを防ぎ、テーブルとの整合性を向上させるために、TTL キャッシュ期間を短く設定することをお勧めします。
