Amazon DynamoDB
開発者ガイド (API バージョン 2012-08-10)

DAX クラスターコンポーネント

DAX クラスターは、AWS のインフラストラクチャのコンポーネントで構成されます。このセクションでは、これらのコンポーネントと、それらがどのように連携するかについて説明します。

ノード

ノードとは、DAX クラスターにおける最小の構成要素です。各ノードは DAX ソフトウェアのインスタンス 1 つを実行し、キャッシュされたデータのレプリカを 1 つ保持します。

DAX クラスターは 2 とおりの方法のいずれかでスケールできます。

  • クラスターにさらにノードを追加する。これは、クラスター全体の読み込みスループットを増加します。

  • より大きなノードタイプを使用する。ノードタイプが大きくなると、容量が大きくなり、スループットを増やすことができます。(新しいノードタイプで新しいクラスターを作成する必要があることに注意してください。)

クラスター内の各ノードは同じノードタイプであり、同じ DAX キャッシュソフトウェアを実行します。使用可能なノードタイプのリストについては、https://aws.amazon.com/dynamodb/pricing を参照してください。

クラスター

クラスターは、DAX がユニットとして管理する 1 つまたは複数のノードの論理グループです。クラスター内のノードの 1 つがプライマリノードとして指定され、他のノード (ある場合) はリードレプリカです。

プライマリノードは以下を担当します。

  • キャッシュ済みデータに対するアプリケーションリクエストの対応。

  • DynamoDB への書き込みオペレーションの処理。

  • クラスターの削除ポリシーに従った、キャッシュからのデータの削除。

プライマリノードにキャッシュされたデータが変更されると、DAX はその変更をすべてのリードレプリカノードに伝達します。

リードレプリカは以下を担当します。

  • キャッシュ済みデータに対するアプリケーションリクエストの対応。

  • クラスターの削除ポリシーに従った、キャッシュからのデータの削除。

ただし、プライマリノードとは異なり、リードレプリカは DynamoDB には書き込みません。

リードレプリカにはさらに 2 つの目的があります。

  • スケーラビリティ。DAX に同時にアクセスする必要があるアプリケーションクライアントが多数ある場合は、リードレプリカを追加して読み取りをスケーリングできます。DAX はクラスターのすべてのノードにワークロードを均等に分散します。(スループットを増やすもう一つの方法は、より大規模なキャッシュノードタイプを使用することです。)

  • 高可用性。プライマリノード障害時に、DAX は自動的にリードレプリカにフェイルオーバーし、新しいプライマリとして指定します。レプリカノードに障害が発生しても、障害が発生したノードが回復するまで、DAX クラスター内の他のノードがリクエストを処理することができます。耐障害性を最大にするため、リードレプリカを異なるアベイラビリティーゾーンにデプロイする必要があります。この設定により、アベイラビリティーゾーン全体が使用できない場合でも DAX クラスターが機能し続けることができます。

DAX クラスターは、クラスターごとに最大 10 個のノードをサポートできます (プライマリノードと最大 9 個のリードレプリカ)。

重要

本稼働環境での使用においては、少なくとも 3 つのノードをそれぞれ異なるアベイラビリティーゾーンに置いて DAX を使用することを強くお勧めします。DAX クラスターが耐障害性を持つためには 3 つのノードが必要です。

DAX クラスターは、開発またはテストワークロードでは 1 つまたは 2 つのノードでデプロイできます。1 つまたは 2 つのノードクラスターでは耐障害性がないため、本稼働での使用では 3 つ未満のノードはお勧めしません。1 つまたは 2 つのノードクラスターでソフトウェアまたはハードウェアの障害が発生した場合、クラスターが使用できなくなったり、キャッシュ済みデータが失われることがあります。

リージョンとアベイラビリティーゾーン

ある AWS リージョンにある DAX クラスターは、同じリージョンにある DynamoDB テーブルとのみやり取りできます。したがって、適切なリージョンに DAX クラスターを起動することを確認する必要があります。他のリージョンに DynamoDB テーブルがある場合は、そのリージョンにも DAX クラスターを起動する必要があります。

各リージョンは、他のリージョンと完全に分離されるように設計されています。各リージョンには複数のアベイラビリティーゾーンがあります。別のアベイラビリティーゾーンでノードを起動して、最大限の耐障害性を実現できます。

重要

単一アベイラビリティーゾーンにクラスターのすべてのノードを置かないでください。この設定では、アベイラビリティーゾーンの障害時に DAX クラスターが利用できなくなります。

本稼働環境での使用においては、少なくとも 3 つのノードをそれぞれ異なるアベイラビリティーゾーンに置いて DAX を使用することを強くお勧めします。DAX クラスターが耐障害性を持つためには 3 つのノードが必要です。

DAX クラスターは、開発またはテストワークロードでは 1 つまたは 2 つのノードでデプロイできます。1 つまたは 2 つのノードクラスターでは耐障害性がないため、本稼働での使用では 3 つ未満のノードはお勧めしません。1 つまたは 2 つのノードクラスターでソフトウェアまたはハードウェアの障害が発生した場合、クラスターが使用できなくなったり、キャッシュ済みデータが失われることがあります。

パラメータグループ

パラメータグループは DAX クラスターのランタイム設定を管理するために使用されます。DAX には、パフォーマンスを最適化するために使用できるいくつかのパラメータ (キャッシュ済みデータの TTL ポリシーを定義するなど) があります。パラメータグループは、クラスターに適用できる名前付きのパラメータのセットであり、クラスター内のすべてのノードが正確に同じ設定であることを確実にするものです。

セキュリティグループ

DAX クラスターは、AWS アカウントに専用の仮想ネットワークであり他の Amazon VPC からは独立している Amazon VPC 環境で実行されます。セキュリティグループは、VPC の仮想ファイアウォールとして機能し、インバウンドトラフィックとアウトバウンドネットワークトラフィックをコントロールできます。

VPC でクラスターを起動する際に、着信ネットワークトラフィックを許可する進入ルールをセキュリティグループに追加します。進入ルールは、クラスターのプロトコル (TCP) とポート番号 (8111) を指定します。この進入ルールをセキュリティグループに追加すると、VPC 内で実行されるアプリケーションが DAX クラスターにアクセスできます。

クラスター ARN

各 DAX クラスターには Amazon リソース識別子 (ARN) が割り当てられます。ARN 形式は次のとおりです。

arn:aws:dax:region:accountID:cache/clusterName

IAM ポリシー内でクラスター ARN を使用して、DAX API アクションのアクセス権限を定義します。詳細については、「DAX での Identity and Access Management」を参照してください。

クラスターエンドポイント

すべての DAX クラスターは、アプリケーションで使用できるクラスターエンドポイントを提供します。エンドポイントを使用してクラスターにアクセスすることで、アプリケーションでクラスターの個別のノードのホスト名とポート番号を把握する必要がなくなります。アプリケーションは、リードレプリカを追加または削除した場合でも、自動的にクラスターのすべてのノードを「把握」します。

クラスターエンドポイントの例を次に示します。

myDAXcluster.2cmrwl.clustercfg.dax.use1.cache.amazonaws.com:8111

ノードエンドポイント

DAX クラスターのノードそれぞれに独自のホスト名とポート番号があります。ノードエンドポイントの例を次に示します。

myDAXcluster-a.2cmrwl.clustercfg.dax.use1.cache.amazonaws.com:8111

ノードのエンドポイントを使用すると、アプリケーションからノードに直接アクセスできます。しかし、DAX クラスターを単一のユニットとして扱い、代わりにクラスターのエンドポイントを使用してアクセスすることをお勧めします。クラスターエンドポイントを使用することで、アプリケーションでノードのリストを保持し、クラスターでノードが追加または削除されたときにリストを最新の状態に保つ必要がなくなります。

サブネットグループ

DAX クラスターノードへのアクセスは、Amazon Virtual Private Cloud (Amazon VPC) 環境内の Amazon EC2 インスタンスで実行されるアプリケーションのみに制限されます。サブネットグループを使用して、特定のサブネットで実行されている Amazon EC2 インスタンスからのクラスターアクセスを許可できます。サブネットグループは、Amazon Virtual Private Cloud (VPC) 環境で実行しているクラスターに対して指定できるサブネット (通常はプライベート) の集合です。

DAX クラスターを作成する場合、キャッシュサブネットグループを指定する必要があります。DAX はそのサブネットグループを使用して、そのサブネット内でノードに関連付けるサブネットおよび IP アドレスを選択します。

イベント

DAX は、ノードの追加の失敗、ノードの追加の成功、セキュリティグループの変更など、重要なイベントをクラスター内に記録します。主要イベントをモニタリングすることで、クラスターの現在の状態を知り、イベントに基づいて是正措置を取ることができます。AWS マネジメントコンソール、または DAX 管理 API の DescribeEvents アクションを使用して、これらのイベントにアクセスできます。

特定の Amazon SNS トピックに通知を送信するようにリクエストし、DAX クラスターでイベントが発生したときはすぐにわかるようにもできます。

メンテナンスウィンドウ

すべてのクラスターには、週ごとのメンテナンス時間があります。その時間内にシステムの変更が適用されます。キャッシュクラスターの作成または変更時に、必要なメンテナンス時間を指定しない場合、DAX では、ランダムに選択された曜日に対して 60 分のメンテナンス時間を割り当てます。

60 分のメンテナンス時間は、リージョンごとに決められた 8 時間の中でランダムに選択されます。次の表に、デフォルトでメンテナンス時間が割り当てられる各リージョンの時間ブロックを示します。

リージョンコード リージョン名 メンテナンス時間
ap-northeast-1 アジアパシフィック (東京) リージョン 13:00–21:00 UTC
ap-southeast-1 アジアパシフィック (シンガポール) リージョン 14:00–22:00 UTC
ap-southeast-2 アジアパシフィック (シドニー) リージョン 12:00–20:00 UTC
ap-south-1 アジアパシフィック (ムンバイ) リージョン 17:30–1:30 UTC
eu-central-1 欧州 (フランクフルト) リージョン 23:00–07:00 UTC
eu-west-1 欧州 (アイルランド) リージョン 22:00–06:00 UTC
sa-east-1 南米 (サンパウロ) リージョン 01:00–09:00 UTC
us-east-1 米国東部 (バージニア北部) リージョン 03:00–11:00 UTC
us-east-2 米国東部 (オハイオ) リージョン 23:00–07:00 UTC
us-west-1 米国西部 (北カリフォルニア) リージョン 06:00–14:00 UTC
us-west-2 米国西部 (オレゴン) リージョン 06:00–14:00 UTC

メンテナンスウィンドウは使用率の最も低い時間帯に設定する必要があります。このため、場合によっては変更が必要になります。お客様がリクエストしたメンテナンス作業が発生する、時間範囲を最大 24 時間で指定できます。