Amazon DynamoDB Accelerator
DynamoDB の前段にインメモリキャッシュを配置し、読み取りレイテンシをミリ秒からマイクロ秒に短縮するフルマネージドキャッシュサービス
概要
Amazon DynamoDB Accelerator (DAX) は、DynamoDB に特化したインメモリキャッシュクラスターです。DynamoDB API と完全互換のため、アプリケーションコードのエンドポイントを DAX クラスターに変更するだけで、読み取りレイテンシをミリ秒単位からマイクロ秒単位に短縮できます。書き込みはライトスルーで DynamoDB に透過的に反映され、キャッシュの整合性が自動的に維持されます。
ElastiCache との選定基準と DAX 固有の制約
DAX と ElastiCache for Redis はどちらもインメモリキャッシュですが、用途が明確に異なります。DAX は DynamoDB 専用で、DynamoDB API をそのまま使えるため、アプリケーションの変更が最小限で済みます。GetItem、BatchGetItem、Query、Scan の結果をアイテムキャッシュとクエリキャッシュの 2 層で自動的にキャッシュし、同じリクエストが来た場合は DynamoDB にアクセスせずに結果を返します。ElastiCache は汎用キャッシュで、DynamoDB 以外のデータソース (RDS、外部 API の結果、セッションデータなど) もキャッシュできます。Redis のデータ構造 (Sorted Set、Hash、List) を活用した複雑なキャッシュロジックも実装可能です。DAX を選ぶべきケースは、DynamoDB の読み取り負荷が高く、同じキーやクエリパターンが繰り返されるワークロードです。DAX の制約として、VPC 内からのみアクセス可能 (Lambda から使う場合は VPC 接続が必要)、強い整合性読み取りはキャッシュをバイパスして DynamoDB に直接アクセスする、テーブルごとにクラスターを分ける必要がある、という点があります。書き込みが多く読み取りが少ないワークロードでは、DAX のコストに見合う効果が得られません。
クラスター設計とキャッシュ戦略
DAX クラスターは最低 3 ノード (マルチ AZ) の構成が本番環境で推奨されます。ノードタイプは dax.r5 系で、キャッシュするデータ量に応じてメモリサイズを選択します。アイテムキャッシュの TTL (デフォルト 5 分) とクエリキャッシュの TTL (デフォルト 5 分) は独立して設定でき、データの更新頻度に応じて調整します。更新頻度が低いマスターデータは TTL を長く (1 時間以上)、頻繁に更新されるデータは TTL を短く (数十秒) 設定します。キャッシュヒット率は CloudWatch の ItemCacheHits / (ItemCacheHits + ItemCacheMisses) で算出でき、80% 以上を目標にします。ヒット率が低い場合は、アクセスパターンがキャッシュに適していない (毎回異なるキーにアクセスしている) 可能性があります。DAX のコストはノード時間課金で、dax.r5.large (3 ノード) の場合は月額約 600 USD です。DynamoDB の読み取りキャパシティユニット (RCU) の削減額と比較して、DAX のコストが見合うかを事前に試算することが重要です。
ゲームのリーダーボードとリアルタイムアプリでの活用
DAX が最も効果を発揮するのは、少数のホットキーに読み取りが集中するワークロードです。ゲームのリーダーボードでは、上位ランキングのクエリが全プレイヤーから繰り返し実行されます。DAX なしでは DynamoDB のパーティションにホットスポットが発生し、スロットリングのリスクがありますが、DAX がクエリ結果をキャッシュすることで DynamoDB への負荷を劇的に削減します。EC サイトの商品カタログも同様で、人気商品の詳細ページは同じ GetItem が大量に発行されるため、DAX のアイテムキャッシュが有効です。リアルタイムの入札システムでは、現在の最高入札額を頻繁に読み取る一方で、更新は入札時のみです。DAX の TTL を数秒に設定すれば、ほぼリアルタイムのデータを返しつつ DynamoDB の読み取り負荷を 90% 以上削減できます。一方、分析クエリのように毎回異なる条件で Scan を実行するワークロードでは、クエリキャッシュのヒット率が低くなるため DAX の効果は限定的です。このようなケースでは、DynamoDB のデータを S3 にエクスポートして Athena で分析する方が適切です。