Zenn
📝

Amazon DynamoDB Accelerator (DAX)ってなんだろ？

2021/04/24に公開
AWS
DynamoDB
idea

Amazon DynamoDB Accelerator (DAX) について調べてみました。

Amazon DynamoDB Accelerator (DAX) | AWS

概要

  • DynamoDB用に特化したフルマネージド型高可用性インメモリキャッシュ
  • 1 秒あたりのリクエスト数が数百万件になる場合でも、ミリセカンドからマイクロセカンドへの最大 10 倍のパフォーマンス向上を実現
  • マネジメントコンソールやSDKから簡単に有効化できる
  • VPC環境で動作

とりあえず爆速になるっていうのはよく聞きますね。
VPC環境で動作するというのは知りませんでした。
image.png

メリット

  • 卓越したパフォーマンス
    • 読み込みに負荷がかかるワークロードで、1 秒あたり 100 万回単位のリクエストの応答時間をミリ秒にする
  • 高いスケーラビリティ
    • 1 秒あたり 100 万回単位のリクエストを送信する 10 個のノードのクラスターにスケールアウト可能
  • フルマネージド
    • エラー検出、エラーリカバリ、およびソフトウェアの修正などの多くの一般的な管理タスクが自動化
  • 使いやすさ
    • DynamoDB と API の互換性
  • 柔軟性
    • 複数の DynamoDB テーブルに 1 つの DAX クラスター、1 つの DynamoDB テーブルに複数の DAX クラスターなど
  • セキュア
    • IAMによるアクセス制御
    • CloudWatchやCloudTrailによる監視

設定も変更も簡単で高パフォーマンスを提供してくれるとのことです。

In-Memory Acceleration with DynamoDB Accelerator (DAX) - Amazon DynamoDB

概要

  • スケールとパフォーマンスを重視して設計
  • 要求の厳しいアプリケーションのメモリ内パフォーマンスを高速化
  • インメモリキャッシュとして、DAXは結果整合性のある読み取りワークロードの応答時間を1桁のミリ秒からマイクロ秒まで1桁短縮
  • DynamoDBとAPI互換のマネージドサービスを提供することにより、運用とアプリケーションの複雑さを軽減し、既存のアプリケーションで使用するには、最小限の機能変更のみ
  • サーバー側の暗号化をサポートし、ディスクに保持されているデータが暗号化

DynamoDBは基本的に結果整合性の読み取りなのでDAXもそのようです。

ユースケース

  • 読み取りに可能な限り速い応答時間を必要とするアプリケーション
    • リアルタイム入札
    • ソーシャルゲーム
    • 取引アプリケーション
  • 少数のアイテムを他のアイテムよりも頻繁に読み取るアプリケーション
    • 人気のある商品を1日で販売するeコマースシステム
  • 読み取りが集中するが、コストもかかるアプリケーション
    • DynamoDBを使用して、アプリケーションが必要とする1秒あたりの読み取り数をプロビジョニング
    • 読み取りアクティビティが増加した場合、テーブルのプロビジョニングされた読み取りスループットを（追加コストで）増加させる
    • アクティビティをアプリケーションからDAXクラスターにオフロードし、それ以外の場合に購入する必要のある読み取り容量ユニットの数を減らす
  • 大量のデータに対して繰り返し読み取りを必要とするアプリケーション

リアルタイム処理、一時的なアクセス集中への対応などが代表的なようですね。

向いてないケース

  • 強い整合性のある読み取りを必要とする（または結果整合性のある読み取りを許容できない）アプリケーション
  • 読み取りにマイクロ秒の応答時間を必要としないアプリケーション
  • 基になるテーブルから繰り返される読み取りアクティビティをオフロードする必要がないアプリケーション
  • 書き込みが集中するアプリケーション
  • 読み取りアクティビティをあまり実行しないアプリケーション
  • DynamoDBですでに別のキャッシュソリューションを使用していて、そのキャッシュソリューションを操作するために独自のクライアント側ロジックを使用しているアプリケーション

DAXでは結果整合性のみの対応なんですね。

リクエストが強い整合性のある読み込みを指定する場合、DAX はリクエストを DynamoDB に渡します。DynamoDB からの結果は DAX にキャッシュされません。代わりに、それらは単にアプリケーションに返されます。

読み取りのアクセスを高速化するのがユースケースなので、書き込みが多い場合や読み取りが少ない場合は向いてないみたいです。

基本の仕組み

  • VPC環境内で実行するように設計
  • VPCセキュリティグループを使用して、仮想ネットワークでDAXクラスターを起動し、クラスターへのアクセスを制御
  • DAXクラスターを作成するには、AWSマネジメントコンソールを使用
  • アプリケーションを（DAXクライアントを使用して）EC2インスタンスにデプロイ
  • 実行時に、DAXクライアントはアプリケーションのすべてのDynamoDBAPIリクエストをDAXクラスターに送信
  • DAXがこれらのAPIリクエストのいずれかを直接処理できる場合は、処理
  • それ以外の場合は、リクエストをDynamoDBに渡す
  • 最後に、DAXクラスターは結果をアプリケーションに返す

キャッシュ処理するDAXクラスターはセキュリティグループで制御できるようです。
また、DAXを使用するアプリではDAXクライアントを使用してEC2にデプロイすると書かれています。
これによりアプリへのDynamoDBリクエストがDAXクラスターに送信され、クラスターで処理できれば処理し、できなければDynamoDBに渡すという流れができるようです。

DAXがリクエストを処理する方法

読み取り操作

  • DAXクラスターは、1つ以上のノードで構成
  • 各ノードは、DAXキャッシングソフトウェアの独自のインスタンスを実行
  • ノードの1つは、クラスターのプライマリノードとして機能
  • 追加のノード（存在する場合）は、リードレプリカとして機能
  • アプリケーションは、DAXクラスターのエンドポイントを指定することでDAXにアクセス
  • DAXクライアントソフトウェアは、クラスターエンドポイントと連携して、インテリジェントな負荷分散とルーティングを実行
  • DAXは、GetItem、BatchGetItem、Query、ScanのAPI呼び出しに応答
  • リクエストが結果整合性のある読み取り（デフォルトの動作）を指定している場合、DAXからアイテムを読み取ろうとする
  • DAXで利用可能なアイテムがある場合（キャッシュヒット）、DAXはDynamoDBにアクセスせずにアイテムをアプリケーションに返す
  • DAXに使用可能なアイテムがない場合（キャッシュミス）、DAXはリクエストをDynamoDBに渡す
  • DynamoDBから応答を受信すると、DAXは結果をアプリケーションに返します。ただし、結果はプライマリノードのキャッシュにも書き込まれる
  • クラスター内に読み取りレプリカがある場合、DAXはレプリカをプライマリノードと自動的に同期させる

ノード：キャッシュ用インスタンス(実態はEC2なのかな？)
クラスター：ノードの集合体

☆プライマリーとリードレプリカについて
ノードが複数ある場合、1つはプライマリー、その他はリードレプリカになるようです。

☆アプリからのアクセスについて
DAXクラスターにはエンドポイントがあるので、アプリはここにアクセスし、DAXのソフトがリクエストの負荷分散とルーティングもしてくれるようです。
DAXが対応するAPI呼び出しはGetItem、BatchGetItem、Query、Scanの4つです。
結果整合性のあるリクエストが来た場合、まずDAXから読み取ろうとします。

☆キャッシュについて
キャッシュヒットしたら、DAXはDynamoDBではなく、DAXのキャッシュからアイテムを返します。
キャッシュミスしたら、DAXはリクエストをDynamoDBに渡します。
キャッシュミスの際、DynamoDBからDAX経由でアプリに結果が返されると同時に、プライマリノードにもキャッシュされます。

☆リードレプリカについて
レプリカがあれば、DAXはプライマリとレプリカを自動同期します。

書き込み操作

  • BatchWriteItem、UpdateItem、DeleteItem、PutItemのAPI操作は「ライトスルー」と見なされる
  • これらの操作では、データは最初にDynamoDBテーブルに書き込まれ、次にDAXクラスターに書き込まれる
  • この操作は、データがテーブルとDAXの両方に正常に書き込まれた場合にのみ成功

ライトスルーはここではオリジンであるDynamoDBと、キャッシュであるDAXの両方に書き込むということですね。
書き込み順はDynamoDB → DAXであるとのことで、両方成功しないといけないみたいです。

その他の操作

  • テーブルを管理するためのDynamoDB操作（CreateTable、UpdateTableなど）は認識しない
  • アプリケーションがこれらの操作を実行する必要がある場合は、DAXを使用するのではなく、DynamoDBに直接アクセスする必要がある

テーブル管理の操作はキャッシュしないとのことです。

リクエストレート制限

  • DAXに送信される要求の数がノードの容量を超える場合、DAXは、ThrottlingExceptionを返すことにより、追加の要求を受け入れる速度を制限
  • DAXは、CPU使用率を継続的に評価して、正常なクラスター状態を維持しながら処理できる要求の量を決定

要求が過度に多い場合は自動的に処理できる要求の量を制限してくれるようです。

アイテムキャッシュ

  • DAXは維持項目キャッシュから結果を格納する GetItemとBatchGetItem動作を制御
  • キャッシュ内のアイテムは、DynamoDBからの結果整合性のあるデータを表し、主キー値によって保存
  • アプリケーションがGetItemまたはBatchGetItemリクエストを送信すると、DAXは指定されたキー値を使用してアイテムキャッシュからアイテムを直接読み取ろうとする
  • アイテムキャッシュには、存続可能時間（TTL）設定があり、デフォルトは5分
  • アイテムがTTL設定より長くキャッシュに残っていると、アイテムの有効期限が切れる
  • GetItem期限切れのアイテムに対してリクエストを発行すると 、これはキャッシュミスと見なされ、DAXはGetItemリクエストをDynamoDBに送信
  • DAXは、アイテムキャッシュの最も使用頻度の低い（LRU）リストも保持
  • LRUリストは、アイテムが最初にキャッシュに書き込まれたのはいつか、アイテムが最後にキャッシュから読み取られたのはいつかを追跡
  • アイテムのキャッシュがいっぱいになると、DAXは古いアイテムを削除して（まだ有効期限が切れていない場合でも）、新しいアイテム用のスペースを確保
  • LRUアルゴリズムは、アイテムキャッシュに対して常に有効であり、ユーザーが構成することはできない
  • アイテムキャッシュのTTL設定としてゼロを指定した場合、アイテムキャッシュ内のアイテムは、LRUの出差または 「ライトスルー」操作によってのみ更新される

☆キャッシュのTTLについて
デフォルトは5分です。
TTLが切れたアイテムへのリクエストはキャッシュミスになります。

☆LRU方式について
DAXがいっぱいになった時に最初に削除されるのは、一番使用頻度の低いデータです。
この場合TTLが切れていなくてもサヨナラされます。
LRUアルゴリズムの制御はユーザー側では不可能です。

クエリキャッシュ

クエリのキャッシュやLRUについての記述も先述のアイテムキャッシュと似た内容でしたので、詳しくはドキュメントをご覧下さい。

まとめ

今回は**Amazon DynamoDB Accelerator (DAX)**について調べてみました。
以下がポイントでした。

  • DynamoDB用に特化したフルマネージド型高可用性インメモリキャッシュ
  • VPC環境で動作
  • リアルタイム処理、一時的なアクセス集中への対応
  • 書き込みが多い場合や読み取りが少ない場合は向いてない
  • DAXクラスターはセキュリティグループで制御
  • キャッシュがあればクラスターが処理、なければオリジンが処理しキャッシュする

参考になれば幸いです。

Discussion