# ユースケースに対する DAX の適合性の評価
<a name="evaluate-dax-suitability"></a>

このセクションでは、DAX を使用するタイミングとその理由について説明します。このガイダンスを使用すると、DAX の DynamoDB への統合が、アプリケーションのワークロードパターン、パフォーマンス要件、およびデータ整合性のニーズに効果的かどうかを判断できます。また、書き込み負荷の高いワークロードやアクセス頻度の低いデータなど、DAX が適さないシナリオについても説明します。

**Topics**
+ [DAX を選択するタイミングとその理由](#choose-dax)
+ [DAX の使用が適さない場合](#dax-unsuitable-scenarios)

## DAX を選択するタイミングとその理由
<a name="choose-dax"></a>

いくつかのシナリオで、アプリケーションスタックに DAX を追加することを検討できます。例えば、DAX を使用して DynamoDB に対する読み取りリクエストの全体的なレイテンシーを短縮したり、テーブルからの同じデータの繰り返し読み取りを最小限に抑えたりできます。次のリストは、DAX と DynamoDB の統合を活用できるシナリオの例を示しています。
+ **高パフォーマンス要件**
  + **低レイテンシーの読み取り** – アプリケーションが結果整合性のある読み取りにマイクロ秒単位の応答時間を必要とする場合は、DAX の使用を検討する必要があります。DAX は、頻繁に読み込まれるデータにアクセスするための応答時間を大幅に短縮することもできます。
+ **読み取り負荷の高いワークロード**
  + **読み取り負荷の高いアプリケーション** – 10:1 以上など、書き込みに対する読み取りの比率が高いアプリケーションの場合、DAX はキャッシュヒットを増やし、古いデータを減らします。これにより、テーブルに対する読み取りが減少します。書き込み負荷が高い場合にアプリケーションがキャッシュから古いデータを読み取らないようにするには、キャッシュの [DynamoDB での Time to Live (TTL) の使用](TTL.md) を低く設定します。
  + **一般的なクエリのキャッシュ** – アプリケーションが e コマースプラットフォーム上の一般的な製品など、同じデータを頻繁に読み取る場合、DAX はキャッシュから直接これらのリクエストを処理できます。
+ **バーストトラフィックパターン**
  + **よりスムーズなテーブルのスケーリング** – DAX は、突然のトラフィックスパイクの影響を低減します。DAX には、DynamoDB テーブルのキャパシティを適切にスケールアップするためのバッファが用意されているため、読み取りスロットリングのリスクが軽減されます。
  + **各項目の読み取りスループットの向上** – DynamoDB は、各項目に個々のパーティションを割り当てます。ただし、3,000 [読み取りキャパシティーユニット (RCU)](provisioned-capacity-mode.md#read-write-capacity-units) に達すると、パーティションは項目の読み取りスロットリングを開始します。DAX では、1 つの項目の読み取りを 3,000 RCU 以上にスケーリングできます。
+ **コスト最適化**
  + **DynamoDB コストの削減** – DAX からの読み取りにより、DynamoDB テーブルに送信される読み取りが減少し、コストに直接影響する可能性があります。キャッシュヒットレートが高い場合、テーブルの読み取りコストが DAX クラスターのコストを上回り、総コストの削減につながります。
+ **データ整合性の要件**
  + **結果整合性** — DAX は結果整合性のある読み込みをサポートします。このため、DAX は即時整合性が重要でないユースケースに適しています。
  + **書き込みスルーキャッシュ** — DAX に対して行う書き込みは[書き込みスルー](DAX.consistency.md)です。DAX は、項目が DynamoDB に書き込まれたことを確認すると、その項目バージョンを項目キャッシュに保持します。この書き込みスルーの仕組みは、キャッシュとデータベース間のデータ整合性をより厳密に維持するのに役立ちますが、追加の DAX クラスターリソースを使用します。

## DAX の使用が適さない場合
<a name="dax-unsuitable-scenarios"></a>

DAX は強力な機能ですが、すべてのシナリオに適しているわけではありません。次のリストは、DAX と DynamoDB の統合が適さないシナリオの例を示しています。
+ **書き込み負荷の高いワークロード** – DAX の主な利点は読み取りを高速化することですが、書き込みでは読み取りよりも多くの DAX リソースが使用されます。主に書き込み負荷の高いアプリケーションの場合、DAX の利点が制限される可能性があります。
+ **データの読み取り頻度が低い** – アプリケーションがデータに低頻度でアクセスしたり、再利用頻度の低いデータ (コールドデータ) に広範囲にわたってアクセスしたりすると、[cache hit ratio](pres-guide-monitor-dax.md#cachehitratio) が低くなります。この場合、キャッシュを維持するためのオーバーヘッドは、パフォーマンスの向上を正当化できない可能性があります。
+ **一括読み取りまたは一括書き込み** — アプリケーションが個別の書き込みよりも多くの一括書き込みを実行する場合は、DAX を書き込みアラウンドする必要があります。さらに、一括読み取りの場合は、DynamoDB テーブルに対して完全なテーブルスキャンを直接実行する必要があります。
+ **強力な整合性要件またはトランザクション要件** – DAX は強力な整合性のある読み込みと [TransactGetItems](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactGetItems.html) 呼び出しを DynamoDB テーブルに渡します。クラスターリソースの使用を避けるため、これらの読み取りは DAX クラスターを読み取りアラウンドする必要があります。この方法で読み取られた項目はキャッシュされないため、DAX 経由でこれらの項目をルーティングすることは意味がありません。
+ **パフォーマンス要件の低いシンプルなアプリケーション** – パフォーマンス要件が低く、直接の DynamoDB レイテンシーに対する許容度があるアプリケーションの場合、DAX を追加する複雑さとコストは必要ではない場合があります。DynamoDB は単独で高スループットを処理し、1 桁ミリ秒のパフォーマンスを提供します。
+ **キーと値によるアクセスを超えた複雑なクエリニーズ** – DAX はキーと値によるアクセスパターンに最適化されています。アプリケーションが[クエリ](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Query.html)操作や[スキャン](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Scan.html)操作など、複雑なフィルタリングを伴う複雑なクエリ機能を必要とする場合、DAX キャッシュの利点が制限される可能性があります。

  このような状況では、代わりに [Amazon ElastiCache (Redis OSS)](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) を使用してください。ElastiCache (Redis OSS) は、リスト、セット、ハッシュなどの高度なデータ構造をサポートしています。また、pub/sub、地理空間インデックス、スクリプティングなどの機能も提供します。
+ **コンプライアンス要件** – DAX は現在、DynamoDB と同じコンプライアンス認定を提供していません。例えば、DAX は SOC 認定をまだ取得していません。