Amazon DynamoDB Accelerator コンソールのウォークスルー – パート 2

Amazon DynamoDB は、応答時間が 1 桁のミリ秒単位で測定されるスケーラビリティとパフォーマンスを提供します。マイクロ秒単位の応答時間が必要なユースケースでは、DynamoDB Accelerator (DAX) がその実現に役立ちます。DAX は DynamoDB と互換性がある API マネージドキャッシュで、リアルタイムのゲーム、入札、気象分析、取引など、要求の厳しいアプリケーションに高速のインメモリパフォーマンスを提供します。DAX を使用すると、読み取り容量単位を効率的にプロビジョニングすることでコストを削減し、最終的に一貫した読み取りワークロードの応答時間がマイクロ秒に短縮されるため、スループットが向上します。

このブログ記事では、ウェブベースの DynamoDB コンソールを使用して、数回クリックするだけで DAX を有効にすることに焦点を当てています。このウォークスルーの過程で、クラスター、ノード、サブネットグループ、パラメータグループ、イベントなどの DAX 主要コンポーネントについて理解を深めることができます。

DynamoDB コンソール DynamoDB Accelerator セクションの詳細ウォークスルー

DynamoDB の設定については、このブログ記事のパート 1 を参照してください。このウォークスルーは、DynamoDB コンソールに 1 回以上アクセスしたことを前提としています。コンソールの DynamoDB DAX セクションで利用可能なすべての機能と、そこからアクセスする方法についてステップバイステップのウォークスルーに沿って説明します。

DynamoDB DAX コンソールに初めてアクセスした後は、常にコンソールの [ダッシュボード] ページから始めます。ダッシュボードには、Amazon CloudWatch アラームによってトリガーされた最近のアラート、DAX サービスヘルス、DynamoDB Accelerator に関するその他の情報に関する DAX コンポーネントの詳細が表示されます。

上のスクリーンショットで番号付けされているように、ダッシュボードのセクションは以下のとおりです。

#	セクション	説明
1	クラスターの作成	ダッシュボードから直接、DAX クラスターを作成することができます。
2	リソース	次の DAX コンポーネントのリストと数を提供します – クラスター – クラスターサブネットグループ – クラスターパラメータグループ – クラスターイベント
3	アラーム	CloudWatch アラームに基づいてアラートのリストを表示します。アラートは、DAX クラスターやノードのパフォーマンスをモニタリングするのに役立ちます。
4	サービスヘルス	リージョン内の DynamoDB Accelerator 関連の停止について通知します。あるいは、サービスヘルスダッシュボードに直接移動することもできます。
5	関連情報	最近の起動およびその他の関連機能、サービス、DAX 情報に関する情報へのリンクを提供します。

クラスター

DAX は Amazon VPC 内で実行され、特に指定がない限り、DAX クラスターはデフォルト VPC 内で実行されます。つまり、インターネット経由では DAX クラスターにアクセスできません。

高レベルでは、DAX クラスターは 1 つのノードが「プライマリ」として機能し、追加のノード (存在する場合) がクラスターのリードレプリカとして機能する 1 つ以上のノードで構成されます。DAX クラスターは、クラスターあたり最大 10 個のノード (プライマリノードと最大 9 個のリードレプリカ) をサポートできます。

実行時に、DAX クライアントがアプリケーションのすべての DynamoDB API リクエストを DAX クラスターに送信します。 Lambda のような VPC でアクセスできるさまざまなコンピューティングプラットフォームでアプリケーションと DAX クライアントを設定できます。ただし、この例では Amazon EC2 インスタンスが VPC に起動され、次に (DAX クライアントを含む) アプリケーションが EC2 インスタンスにデプロイされます。アプリケーションは DAX クラスターのエンドポイントを指定して DAX にアクセスします。DAX クライアントはクラスターエンドポイントと連携してインテリジェントなロードバランシングとルーティングを実行するため、着信リクエストがクラスター内のすべてのノードに均等に分散されます。したがって、1 つのエンドポイントですべてのトラフィックを処理できるため、DAX を実装するのは非常に簡単です。

DAX クライアントで GetItem を使用すると、リクエストが DAX に到達し、DAX がキャッシュを介してこれらの API リクエストの 1 つを直接処理できる場合 (キャッシュヒット)、マイクロ秒以内に処理されます。それ以外の場合、つまりキャッシュ内でアイテムを利用できない場合 (キャッシュミス)、リクエストを DynamoDB に渡します。DynamoDB はリクエストされたアイテムを返し、DAX はそれをアイテムキャッシュに格納します。最後に、DAX クラスターはアイテムをアプリケーションに返します。また、DAX クラスターに複数のノードが含まれている場合、アイテムはクラスター内の他のすべてのノードに複製されます。DAX は、Amazon DynamoDB テーブルにキャッシュを追加するプロセスを簡素化するように特別に設計されたライトスルーキャッシングサービスであるため、このようなことが可能になります。

クラスターの作成

DAX クラスターの作成方法:

DynamoDB コンソールの DAX セクションにあるクラスターページから、[クラスターの作成] を選択します。

DynamoDB Accelerator (DAX) クラスターの作成ページで、クラスター名を入力し、DAX クラスターのノードタイプ、クラスターサイズ、暗号化オプション、IAM ロール、サブネットグループ、およびセキュリティグループを選択します。

このウォークスルーでは、クラスター名に DAX-console と入力し、残りのコンポーネントで次のものを選択します。

ノードタイプ: 私は自分のクラスターのノードタイプとしてデフォルトで選択されている dax.r4.xlarge を使います。クラスター内のすべてのノードは同じノードタイプです。つまり、完全レプリカであり、キャッシュされたデータの単一レプリカを管理します。次の 2 つの方法のいずれかで DAX クラスターをスケールできます。
- クラスターにノードを追加します。これにより、クラスター全体の読み取りスループットが向上します。
- より大きなノードタイプを使用します。ノードタイプが大きいほど容量が大きくなり、スループットが向上します。(新しいノードタイプで新しいクラスターを作成しなければならないことにご注意ください。)
クラスターサイズ: デフォルトで選択されている 3 ノードを使用します。クラスターは、1 つのプライマリノードと最大 9 つのリードレプリカで構成されます。つまり、シングルノードクラスターとマルチノードクラスターのどちらでも構いません。
特に 3 つのノード (1 つのプライマリと 2 つのリードレプリカ) を持つマルチノード DAX クラスターを使用することをお勧めします。各ノードは異なるアベイラビリティーゾーンに配置され、特に高可用性は、いずれかのアベイラビリティーゾーンが停止した場合に保証されます。実行中の DAX クラスターでもノードを追加または削除できます。
暗号化: デフォルトの設定を有効にして暗号化を有効にします。DAX の保管中の暗号化は、基盤となるストレージへの不正アクセスからデータを保護することで、追加のデータ保護レイヤーを提供します。
クラスターが作成された後は、暗号化を有効または無効にすることができません。作成時にクラスターが有効になっていなかった場合は、保存時の暗号化を有効にするためにクラスターを再作成する必要があります。

IAM ロール: DAX クラスターを作成したら、クラスターと対話するユーザーの代わりに DAX クラスターで実行できる DynamoDB アクションを定義する IAM ロールに関連付ける必要があります。つまり、ユーザー/アプリケーションは、DAX クラスターにアクセスするときに、DAX クラスターの IAM ポリシー権限を継承します。[新規作成] を選択して、次の情報を入力します。
- IAM ロール名 – デフォルトの名前 DAXtoDynamoDB を使用します。この名前での新しい IAM ロールが作成され、DAX クラスターが実行時にこのロールを引き受けます。
- IAM ロールポリシー – [読み取り/書き込み] を選択すると、ターゲット DynamoDB テーブルと共に IAM ポリシー名フィールドがポップアップに表示されます。このポリシーにより、DAX クラスターは DynamoDB で読み取りおよび書き込み操作を実行できます。ただし、本稼働環境では、セキュリティが最も低い権限のベストプラクティスについて、IAM ポリシーの範囲を指定する必要があります。
- IAM ポリシー名 – IAM ポリシーのデフォルト名 DAXtoDynamoDBPolicy を使用します。これで、この名前での新しい IAM ポリシーが作成され、IAM ロールにアタッチされます。
- ターゲット DynamoDB テーブル – DynamoDB で作成されたすべてのテーブルを選択するオプションを残します。つまり、DAX クラスターはそのアカウントで作成されたすべての DynamoDB テーブルに対するリクエストをキャッシュします。

サブネットグループ — VPC 内の 1 つ以上のサブネットの集まりです。DAX クラスターを作成すると、ノードがサブネットグループ内のサブネットにデプロイされます。作成した既存のサブネットグループを使用できます。何も無い状態なので、[新規作成] を選択し、次の情報を入力します。
- 名前 – サブネットグループの短い名前として my-subnet-group を入力します。
- 説明 – サブネットグループの説明に DAX サブネットグループを入力します。
- VPC ID – サブネットグループに使用されるデフォルト VPC を選択します。
- サブネット – サブネットグループに 3 つのサブネットを選択します。リストから 1 つ以上のサブネットを選択できます。これらのサブネットは、クラスターを作成した後でも変更できます。
  注意: サブネットは複数のアベイラビリティーゾーンに分散されています。マルチノード DAX クラスター (1 つのプライマリノードと 1 つ以上のリードレプリカ) を作成する予定の場合は、DAX がクラスターノードを複数のアベイラビリティーゾーンにデプロイできるように、複数のサブネット ID を選択することをお勧めします。
セキュリティグループ – デフォルトのセキュリティグループを使用するというオプションはそのままにします。

クラスター設定 – クラスター設定はデフォルト設定を使用のままにします。デフォルト設定は、クラスターを起動する最速の方法です。これらの設定は、今すぐまたは DAX クラスターの作成後に変更できます。DAX クラスター設定を作成した後で、現在使用中のパラメータグループをカスタムグループに置き換えると、DAX クラスター設定を編集できます。

または、DAX クラスターの作成中に DAX クラスター設定をカスタマイズすることを選択した場合は、[デフォルト設定を使用する] の選択を解除する必要があります。その後、次の設定を変更できます。

さまざまなフィールドの意味について簡単に説明します。

クラスターの説明: ここで DAX クラスターの簡単な説明を入力できます
アベイラビリティーゾーン: このフィールドでは、クラスター内の各ノードのアベイラビリティーゾーンを選択することも、クラスター内のノードを使用可能なアベイラビリティーゾーンに均等に分散させる [優先設定なし] を選択することもできます。
耐障害性を最大にするには、リードレプリカを別々のアベイラビリティーゾーンにデプロイする必要があります。この設定により、アベイラビリティーゾーン全体が使用不可になっても、DAX クラスターは機能し続けることができます。
パラメータグループ: パラメータグループは、クラスターに適用できるパラメータの名前付きセットです。これにより、そのクラスター内のすべてのノードでまったく同じ設定が行われることが保証されます。パラメータグループは、DAX クラスター実行時の設定を管理するために使用されます。DAX には、パフォーマンスを最適化するために使用できるいくつかのパラメータ (キャッシュデータの TTL ポリシーの定義など) があります。既存のパラメータグループを選択するか、[新規作成] を選択できます。後者のオプションでは、クラスター内のすべてのノードに適用される次のパラメータを定義できます。
- パラメータグループ名: これは必須フィールドです。
- 説明: パラメータグループの説明を任意で追加できます。
- クエリ TTL: DAX は、クエリ操作とスキャン操作の結果を格納するためのクエリキャッシュを管理します。
- アイテム TTL: DAX は GetItem および BatchGetItem 操作の結果を格納するためにアイテムキャッシュを管理します。
  クエリキャッシュとアイテムキャッシュの両方に、Time-to-Live (TTL) が設定されています。デフォルトでは 5 分または 300 秒になっています。これらのフィールドは任意であり、カスタム TTL の指定を選択できます。空白のままにすると、5 分のデフォルト TTL が使用されます。現在、DAX に指定できる TTL に上限はありません。

更新が即座に表示されるようにするには、AWS コンソールが以下のエラーメッセージをスローするので、クエリ/アイテム TTL を 0 に設定します。つまり、AWS CLI 経由でカスタムパラメータグループを使用して無効にします。この設定の欠点は、DAX が TTL に基づいて値を更新することがなくなり、クエリ/スキャン操作がキャッシュされなくなることです。

メンテナンス期間: すべてのクラスターには、毎週のメンテナンス期間があり、その間にシステムの変更が適用されます。キャッシュクラスターの作成または変更中に優先メンテナンス期間を指定しない場合、DAX は、リージョンごとの 8 時間のブロックからランダムに選択された曜日に 60 分のメンテナンス期間を割り当てます。各リージョンのタイムブロックの詳細については、メンテナンス期間を参照してください。
この例では、日曜日の午前 12:00 UTC にスケジュールされている毎週 60 分のメンテナンス期間を選択しました。
SNS 通知のトピック: 次のオプションから、これらの定期メンテナンスイベントの通知を受け取るかどうかを選択できます。
- 通知を無効にする
- 新しい SNS トピックを作成する
- SNS トピック ARN を追加する
- 既存の SNS トピックを使用する

目的どおりに設定したら、[クラスターの起動] を選択します。
次のスクリーンショットに示すように、作成した dax-console テーブルが、DAX コンソールの [クラスター] ページに表示されます。[作成中] の DAX クラスターが一覧表示されます。
クラスターの作成には数分かかります。クラスターの準備が整うと、ステータスが「利用可能」に変わります。
下のスクリーンショットから確認できるように、DAX クラスターには 3 つのアベイラビリティーゾーンに分散された 3 つのノードタイプ「dax.r4.large」を持つ専用クラスターエンドポイントがあります。

クラスターページの各タブには、テーブルに関する情報があります。DAX クラスター dax-console の概要セクションには、クラスターの名前と説明、ノードタイプ、クラスターサイズ、クエリとアイテムの TTL を含むパラメータグループ、セキュリティグループに登録するサブネットグループ、アベイラビリティーゾーンと VPC、メンテナンス期間、クラスターの可用性と暗号化ステータスなど、以前設定したすべてのパラメータが一覧表示されています。さらに、DAX クラスターの作成時には、DAX クラスターに割り当てられるパラメータがほとんどありません。

クラスターエンドポイント:クラスターエンドポイントは、アプリケーション/DAX クライアントで’使用するように、すべての DAX クラスターに割り当てられます。エンドポイントはクラスター内のノードの追加と削除をマスクします。そのため、アプリケーション/DAX クライアントはクラスター内の個別ノードのホスト名とポート番号を気にする必要がありません。
ここでは、この場合 DAX クラスターが vpc-75bffe11 で作成された DAX クラスターエンドポイントは、VPC 内でのみアクセス可能であり、インターネット経由ではアクセスできないということにご注意ください。
クラスター ARN: クラスター Amazon リソース ID (ARN) は、DAX API アクションのアクセス許可を定義するために、IAM ポリシーで使用できるすべての DAX クラスターに割り当てられます。
IAM サービスロール ARN: 前に作成した IAM サービスロール用の ARN です。ユーザーが DAX クラスター経由でアクセスできる DynamoDB リソースと API アクションを決定します。

クラスターの編集

実行中の DAX クラスターの編集を選択できます。現在、DAX クラスターでの SNS 通知設定のクラスターの説明、パラメータグループ、メンテナンス期間、およびトピックを編集できます。このウォークスルーで作成したサンプルで、DAX クラスターを編集するプロセスを説明します。

変更が必要な DAX クラスターを選択し、コンソールのクラスターページで [アクション] に [編集] を選択します。
ポップアップウィンドウで、変更したい設定を選択して入力するように求められます。
[保存] を選択して、クラスターに必要な変更を追加します。

[クラスター] タブ

それでは、DynamoDB コンソールのクラスターページのタブを見てみましょう。

[概要] タブ

[概要] タブ (前のスクリーンショット参照) には、クラスター名、エンドポイントと ARN、ノード数とノードタイプ、パラメータとサブネットグループ、メンテナンス期間、および DAX クラスターの識別に必要なその他の重要な情報など、DAX クラスター設定の詳細が含まれます。

[ノード] タブ

このセクションでは、ノードを追加、削除、または再起動できます。ブログの投稿で前述したように、ノードは DAX クラスターの最も小さい構成要素です。DAX クラスターは、ノードの追加または削除によってスケールできます。こちらは、手動によるスケーリングを実行できるセクションです。

ノードの再起動: シングルノードクラスターの場合、ノードを再起動すると DAX プロセスが再起動され、ノードが一時的にオフラインになります。ただし、これはキャッシュの内容には影響しません。マルチノードクラスターの場合、ノードを再起動すると、ノードが再起動されてピアの 1 つと再同期されてキャッシュが最新の状態になるまで、ノードは一時的にオフラインになります。

ノードの追加: 既存の DAX クラスターにノードを追加するときに、追加する新しいノードの数、つまりこの例では 1 から 7 まで、それぞれにアベイラビリティーゾーンを選択することができます。これらのノードは、DAX クラスターのリードレプリカとして機能します。

[メトリック] タブ

Amazon CloudWatch を使用して DAX をモニタリングできます。Amazon CloudWatch は、DAX から生データを収集し、読み取り可能なほぼリアルタイムのメトリックとして処理します。これらの統計は 2 週間にわたって記録されます。デフォルトでは、DAX メトリックデータが自動的に CloudWatch に送信されます。DAX の名前空間を使用して CloudWatch コンソールで DAX クラスターのメトリックを表示することもできます。

DAX クラスターを作成すると、DAX クラスターをモニタリングできるようにいくつかのメトリックが作成されます。次は DAX クラスターのパフォーマンスを測定するための主なメトリックの一部です。

CPU 使用率: ノードまたはクラスターの CPU 使用率です。

アイテムキャッシュヒット: プライマリキーに基づいて成功したアイテム検索の数。

アイテムキャッシュミス: プライマリキーに基づいて失敗したアイテム検索の数。

クエリキャッシュヒット: クエリパラメータに基づいて成功したクエリ結果の検索数。

クエリキャッシュミス: クエリパラメータに基づいて失敗したクエリ結果の検索数。

クエリリクエスト数: インスタンスによって処理されたスキャンリクエストの数。

失敗したリクエスト数 (合計): インスタンスによって報告されたエラーの原因となったリクエストの合計数。

エラーリクエスト数 (カスタマーエラー): インスタンスによって報告されたユーザーエラーの原因となったリクエストの合計数。

失敗したリクエスト数 (サービスエラー): インスタンスによって報告された内部エラーの原因となったリクエストの合計数。

合計リクエスト数: クラスターに送信されたリクエストの合計数。

DatabaseSize: オブジェクトを Dax に格納するために割り当てられたストレージの量。

キャッシュミス/CPU 使用率/合計リクエスト数の増加は、クラスターのパフォーマンスに悪影響を及ぼします。このような場合は、CloudWatch メトリックに設定されているしきい値に基づいて DAX クラスターを水平にスケールできます。クラスター全体の読み取りスループットが向上するのに役立ちます。あるいは、より大きなノードタイプを使用する新しい DAX クラスターを作成して、クラスターがより多くのデータをメモリに格納できるようにし、キャッシュミスを減らしてアプリケーション全体のパフォーマンスを向上させることができます。

[アラーム] タブ

他の CloudWatch メトリックと同様に、アラームの状態が変化したときに Amazon SNS メッセージを送信する DAX 関連メトリック用の Amazon CloudWatch アラームを作成できます。DAX コンソールの [アラーム] タブからアラームを作成、編集、削除することができます。スケーリングアクティビティ中にノードがクラスターに追加またはクラスターから削除された場合や、DAX クラスターに関連する問題がありパフォーマンス、クラスタータイムアウトなどに限定されない場合に、アラートが役に立ちます。

[タグ] タブ

DynamoDB を含むほとんどの AWS サービスは、ユーザーが定義した名前でリソースにラベルを付ける機能としてタグ付けをサポートしています。タグを DAX クラスターに割り当てることで、同じタグを持つすべての AWS リソースをすばやく識別できます。または、割り当てたタグで AWS 請求書を分類するのに役立ちます。

サブネットグループ

DAX コンソールのこのセクションでは、DAX クラスターの作成中にサブネットグループが作成されたときと同様に機能します。

サブネットグループを実行中の DAX クラスターに接続/置換することはできませんが、コンソールのこのセクションにはサブネットグループを作成するオプションがあります。DAX クラスターの作成中に、既存のサブネットグループを使用することを選択できます。

サブネットグループの [編集] または [削除] を使用して、実行中の DAX クラスターにある既存のサブネットグループを変更することができます。ただし、DAX クラスターのノードがまだサブネットグループのいずれかのサブネットに関連付けられているというエラーメッセージが表示されます。また、サブネットグループが DAX クラスターに関連付けられている場合、そのサブネットグループを削除することはできません。

パラメータグループ

DAX コンソールのこのセクションでは、DAX クラスターの作成中にパラメータグループが作成されたときと同様に機能します。

実行中の DAX クラスターに接続/交換できるコンソールのこのセクションには、パラメータグループを作成するオプションがあります。DAX クラスターの作成中に既存のパラメータグループを使用することも、実行中の DAX クラスターで使用することもできます。キャッシングのニーズに基づいてアイテム/クエリ TTL 値を使用する DAX クラスターが複数ある場合は、さまざまなパラメータグループを使用することを選択できます。

パラメータグループの [編集] 操作または [削除] 操作を使用して、パラメータグループの設定、つまり名前、アイテム、クエリ TTL 値を変更することもできます。DAX クラスターに関連付けられているパラメータグループは削除できません。

イベント

DAX は、ノード追加の失敗、ノード追加の成功、セキュリティグループへの変更など、クラスター内の重要なイベントを記録します。重要なイベントをモニタリングすることで、クラスターの現在の状態を把握し、イベントに応じて是正措置を講じることができます。DAX コンソールのイベントセクションを使用して、これらのイベントにアクセスできます。DAX クラスターでイベントが発生したときにすぐにわかるように、通知を特定の Amazon SNS トピックに送信するようにリクエストすることもできます。

クラスターの削除

DAX クラスターを使用しなくなった場合は、未使用のリソースに対して請求されないように、削除する必要があります。このウォークスルーで作成したサンプルを削除して、DAX クラスターを削除するプロセスを説明します。

削除したい DAX クラスターを選択して、コンソールのクラスターページで [アクション] に [削除] を選択します。
ポップアップウィンドウで選択を確認するように求められます。このクラスターのすべての CloudWatch アラームを削除します (デフォルトで選択されています)。
[削除] を選択してクラスターの削除を完了します。

結論

このブログ記事では、DynamoDB コンソールの DynamoDB Accelerator セクションで、サブネット/パラメータグループ、クエリ/アイテムキャッシュ、TTL、DAX スケーリング、CloudWatch モニタリング、アラート、そしてコンソールを使用してこれらを設定する方法など、DAX の主要コンポーネント/機能について説明しました。また、クラスターを作成し、クラスターを編集してから、コンソールからクラスターを削除する方法についても例を挙げました。新規ユーザーは、サービスで DAX を探索する際に AWS コンソールについてより良く理解できます。

このブログ記事を書いている時点で、DAX は現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、米国西部 (北カリフォルニア)、南米 (サンパウロ)、欧州 (アイルランド)、アジアパシフィック (シンガポール)、アジアパシフィック (東京)、アジアパシフィック (シドニー)、およびアジアパシフィック (ムンバイ) の各リージョンでご利用いただけます。

著者について

Ishita の写真 Ishita Mehta-Desai は、AWS のテクニカルアカウントマネージャーです。彼女は顧客に技術的なガイダンスを提供すること、新しい場所を探索することを楽しんでいます。

Amazon Web Services ブログ