Amazon DynamoDB Accelerator（DAX）

Amazon DynamoDB Accelerator（DAX）は、DynamoDB向けのインメモリキャッシュクラスターです。DynamoDB互換のAPIを提供するため、アプリケーションがDAXクライアント経由で読み書きする構成にすると、DynamoDBの読み取り処理をキャッシュから返せます。キャッシュされているデータへのアクセスでは、DynamoDB単体のミリ秒単位の応答をマイクロ秒単位に近づけられます。

DAXが役立つのは、同じ項目や同じ検索結果が繰り返し読まれるような、読み取りに偏ったワークロードです。たとえば、展示施設のアプリで人気展示の説明や開催時間を多数の利用者が何度も参照する場合、対象データをDAXに保持してDynamoDBへの読み取りを減らせます。一方、頻繁に変わる値や、読み取りごとに必ず最新状態が必要なデータでは、キャッシュによる応答速度の利点とデータ鮮度の要件を比較する必要があります。

読み取りの流れ

DAXは読み取りをキャッシュから返すキャッシュヒットと、DynamoDBへ取りに行くキャッシュミスの両方を処理します。

1. アプリケーションがDAXクライアントを使ってDAXクラスターへ読み取りを送る。
2. DAXのキャッシュに有効な値があれば、その値をアプリケーションへ返す。
3. 値がない、またはキャッシュの有効期限が切れている場合、DAXはDynamoDBテーブルへ読み取りを転送する。
4. DynamoDBから受け取った結果をキャッシュに保存し、アプリケーションへ返す。
5. 同じデータを後続リクエストが読むと、キャッシュが有効な間はDAXから応答できる。

この動きは読み取りスルー（read-through）キャッシュです。アプリケーションはキャッシュミス時にDynamoDBへ直接問い合わせる分岐を実装せずに済みます。キャッシュミスが起きた最初のリクエストではDynamoDBへのアクセスが必要で、その後にキャッシュの効果が現れます。

DAXは GetItem や BatchGetItem の結果を保持するアイテムキャッシュと、Query や Scan の結果を保持するクエリキャッシュを備えています。どちらも読み取り用のキャッシュですが、同じ項目をキーで取得する処理と、条件に合う項目群を取得する処理では、キャッシュされる結果の単位が異なります。項目の読み取りと検索結果の双方が繰り返されるシステムでは、アクセスパターンごとにどのキャッシュが効くかを確認します。

DAXは書き込みを高速化するための一般的なキャッシュではなく、中心となる用途はDynamoDBの読み取り加速です。読み取り要求が少ない、毎回異なるデータを取得する、更新が極端に多いといったワークロードでは、キャッシュヒットが少なく、クラスターの維持費に対して十分な効果が得られない場合があります。

TTLとデータの鮮度

キャッシュ内の値には有効期限（TTL: Time to Live）を設定します。DAXではアイテムキャッシュとクエリキャッシュを別々に扱い、それぞれのTTLを構成できます。既定値はどちらも5分です。アプリケーションの要件に合わせて調整できますが、TTLが長いほどキャッシュの再利用機会が増える一方、変更前の値が残る可能性も長くなります。

TTLが切れると、次にその値への読み取りが発生したときにキャッシュミスとなり、DAXはDynamoDBから新しい結果を取得します。したがって、TTLは「指定時間が経過した瞬間にキャッシュ全体が更新される時刻」ではありません。有効期限切れ後に次のアクセスが来た段階で再取得されます。キャッシュヒット時の応答は、元テーブルの最新値と一致しない可能性があります。

書き込みがDAXを経由する場合、DAXは書き込みをDynamoDBへ転送し、成功した更新をアイテムキャッシュへ反映します。ただし、アプリケーションがDAXを迂回してDynamoDBを直接更新する場合、別のリージョンや別の経路で更新する場合、またはクエリ結果キャッシュに依存する場合は、キャッシュに古い値が残ることがあります。特に、アイテムキャッシュへの書き込み反映と、Query / Scan の結果キャッシュに残る値は同じように考えないでください。データを更新する経路とキャッシュの種類を確認し、TTLをデータ鮮度の要件に合わせて決めます。

強い整合性が必要な読み取り

DAXのキャッシュ読み取りは結果整合性です。強い整合性を指定した読み取りは、DAXのキャッシュから値を返す処理ではなく、DynamoDBテーブルへ転送して実行します。このため、DAXのキャッシュを経由する読み取りと、DynamoDBから強い整合性で読む処理とでは、応答速度と最新性の前提が異なります。

たとえば、展示情報や施設案内のように数分程度の更新遅延を許容できるデータは、キャッシュの候補になります。一方、決済後の残高や在庫引当の確定値のように、直近の書き込みを反映した読み取りが欠かせない処理では、キャッシュの値に依存させずDynamoDBで強い整合性読み取りを行う設計が必要です。DAXを導入したことだけで、すべての読み取りが最新状態を返すわけではありません。

読み取りの要件	DAXの使い方	判断のポイント
キャッシュされた値を低遅延で繰り返し読む	DAXのアイテムキャッシュまたはクエリキャッシュを使う	キャッシュヒット率と許容できる更新遅延を確認する
キャッシュに値がない、またはTTL切れ	DAXからDynamoDBへ読み取りを転送する	初回の取得にはDynamoDBへの読み取りが必要
強い整合性が必要	DynamoDBへ強い整合性読み取りを転送する	キャッシュによるマイクロ秒級応答の対象にはならない
更新が少なく、データが繰り返し読まれる	DAXをキャッシュ層として検討する	読み取り負荷の削減とノード費用を比較する

書き込みとライトスルー

DAX経由の書き込みはライトスルー方式です。アプリケーションから PutItem や UpdateItem などの書き込み要求を受けると、DAXはまずDynamoDBテーブルに書き込みます。DynamoDB側で処理が成功した場合に、DAXは成功した書き込みをアイテムキャッシュへ反映し、クライアントへ成功応答を返します。DAXのキャッシュだけを更新し、元のテーブルへの反映を後回しにする方式ではありません。

したがって、DAX経由の書き込みで正常な成功応答を得たことは、DynamoDBへの書き込みが成功したことを前提とします。DynamoDBへの書き込みが失敗した場合、書き込み成功として応答されることはありません。書き込み後にアイテムキャッシュを使う読み取りでは、成功した更新が反映されることが期待できます。

ただし、ライトスルー書き込みを利用しても、DAXクラスターを通らない更新や、クエリキャッシュに残った検索結果まで常に即時に最新化されると解釈してはいけません。アプリケーション内で更新経路を統一できるか、読み取りパターンにクエリキャッシュが含まれるかを確認します。最新の値が必要な読み取りは、TTLの経過を待つだけでなく、DynamoDBで強い整合性読み取りを選択することも検討します。

DAXを導入する効果と費用

DAXを使うと、キャッシュヒットした読み取りをDynamoDBテーブルまで到達させずに処理できるため、読み取り負荷の軽減と応答時間の短縮につながります。読み込みリクエストが大量に発生し、同じデータが繰り返し読まれる場合、DynamoDBへの読み取りリクエストを減らして費用を抑えられる可能性があります。

一方、DAXクラスターには追加料金がかかります。主な費用はクラスター内の各ノードについて、ノードのインスタンスタイプと稼働時間を基準に発生します。キャッシュヒットが少なくてもノード費用はかかり、キャッシュミスや書き込みに伴うDynamoDB側の料金も残ります。DAX導入で常に総費用が下がるわけではありません。

導入効果を考えるときは、少なくとも次の要素を合わせて見積もります。

• 繰り返し読まれるデータの割合とキャッシュヒット率
• DAX導入によって削減できるDynamoDBの読み取りリクエスト量
• DAXクラスターのノード数、インスタンスタイプ、稼働時間
• キャッシュミス、書き込み、キャッシュされない読み取りに対するDynamoDB側の料金
• キャッシュされた値の古さをどこまで許容できるか

DAXはDynamoDB専用で、DynamoDBのクライアントAPIとの互換性を活かしてキャッシュを追加する選択肢です。複数のデータストアを横断したキャッシュや、アプリケーション独自のキャッシュ操作が必要なら、ElastiCacheなど別のサービスと比較します。サービス名だけで選ぶのではなく、データストアとの互換性、必要なキャッシュ制御、整合性要件、運用費用を基準にします。

試験で押さえるポイント

• DynamoDBの読み取り負荷をマイクロ秒単位に近づける目的で、DynamoDB互換APIを持つ専用キャッシュを使うならDAXを検討する。
• DAXは主に読み取り加速に使い、GetItem / BatchGetItem のアイテムキャッシュと Query / Scan のクエリキャッシュを区別する。
• キャッシュミスではDAXがDynamoDBへ問い合わせ、結果をキャッシュして返す。TTL切れ後は次のアクセスで再取得される。
• TTLの既定値は5分だが、キャッシュされた値が常に元テーブルの最新値だとは限らない。
• DAXのキャッシュ読み取りは結果整合性であり、強い整合性読み取りはDynamoDBへ送られる。
• DAX経由の書き込みはライトスルーで、DynamoDBへの書き込み成功後に成功応答となる。
• DAXにはノード単位の追加料金がある。読み取り削減による費用低減がノード料金を上回るとは限らないため、負荷とヒット率を基に判断する。

AWS公式ドキュメント

• DynamoDB Accelerator（DAX）
• DAXの読み取り操作とキャッシュ
• DAXの書き込み操作
• DynamoDBの読み取り整合性
• Amazon DynamoDBの料金

関連トピック

• Amazon DynamoDBの基本とデータモデル
• Amazon DynamoDBのキャパシティモードと読み書き性能
• DynamoDBの料金と課金項目
• DynamoDBの整合性・ストリーム・グローバルテーブル・バックアップ（SAA）
• ElastiCacheとDAX