# DAX クラスターコンポーネント
Amazon DynamoDB Accelerator (DAX) クラスターは、AWS のインフラストラクチャのコンポーネントで構成されます。このセクションでは、これらのコンポーネントと、それらがどのように連携するかについて説明します。
**Topics**
+ [ノード](#DAX.concepts.nodes)
+ [クラスター](#DAX.concepts.clusters)
+ [リージョンとアベイラビリティーゾーン](#DAX.concepts.regions-and-azs)
+ [パラメータグループ](#DAX.concepts.parameter-groups)
+ [セキュリティグループ](#DAX.concepts.security-groups)
+ [クラスター ARN](#DAX.concepts.cluster-arn)
+ [クラスターエンドポイント](#DAX.concepts.cluster-endpoint)
+ [ノードエンドポイント](#DAX.concepts.node-endpoints)
+ [[サブネットグループ]](#DAX.concepts.cluster.security)
+ [イベント](#DAX.concepts.events)
+ [メンテナンスウィンドウ](#DAX.concepts.maintenance-window)
## ノード
ノードとは、DAX クラスターにおける最小の構成要素です。各ノードは DAX ソフトウェアのインスタンス 1 つを実行し、キャッシュされたデータのレプリカを 1 つ保持します。
DAX クラスターは 2 通りの方法のいずれかでスケールできます。
+ クラスターにさらにノードを追加する。これは、クラスター全体の読み込みスループットを増加します。
+ より大きなノードタイプを使用する。ノードタイプが大きくなると、容量が大きくなり、スループットを増やすことができます。(新しいノードタイプで新しいクラスターを作成する必要があります。)
クラスター内の各ノードは同じノードタイプであり、同じ DAX キャッシュソフトウェアを実行します。使用可能なノードタイプのリストについては、「[Amazon DynamoDB の料金表](https://aws.amazon.com/dynamodb/pricing)」を参照してください。
## クラスター
クラスターは、DAX がユニットとして管理する 1 つまたは複数のノードの論理グループです。クラスター内のノードの 1 つが*プライマリ*ノードとして指定され、他のノード (ある場合) は*リードレプリカ*です。
プライマリノードは以下を担当します。
+ キャッシュ済みデータに対するアプリケーションリクエストの対応。
+ DynamoDB への書き込みオペレーションの処理。
+ クラスターの削除ポリシーに従った、キャッシュからのデータの削除。
プライマリノードにキャッシュされたデータが変更されると、DAX は、レプリケーションログを使用して、その変更をすべてのリードレプリカノードに伝播します。すべてのリードレプリカから確認を受け取ると、DynamoDB はプライマリノードからレプリケーションログを削除します。
DAX クラスターは、クラスターごとに最大 11 個のノード (プライマリノードと最大 10 個のリードレプリカ) をサポートできます。
リードレプリカは以下を担当します。
+ キャッシュ済みデータに対するアプリケーションリクエストの対応。
+ クラスターの削除ポリシーに従った、キャッシュからのデータの削除。
ただし、プライマリノードとは異なり、リードレプリカは DynamoDB には書き込みません。
リードレプリカにはさらに 2 つの目的があります。
+ **スケーラビリティ**。DAX への同時アクセスを必要とするクライアントが多数ある場合は、レプリカを追加して読み込みをスケーリングできます。DAX は、クラスター内のすべてのノードに均等にロードを分散します。(スループットを増やすもう 1 つの方法は、より大規模なキャッシュノードタイプを使用することです。)
+ **高可用性**。プライマリノード障害時に、DAX は自動的にリードレプリカにフェイルオーバーし、新しいプライマリとして指定します。レプリカノードに障害が発生しても、障害が発生したノードが回復するまで、DAX クラスター内の他のノードがリクエストを処理することができます。耐障害性を最大にするため、リードレプリカを異なるアベイラビリティーゾーンにデプロイする必要があります。この設定により、アベイラビリティーゾーン全体が使用できない場合でも DAX クラスターが機能し続けることができます。
**重要**
本稼働環境での使用においては、少なくとも 3 つのノードをそれぞれ異なるアベイラビリティーゾーンに置いて DAX を使用することを強くお勧めします。DAX クラスターが耐障害性を持つためには 3 つのノードが必要です。
DAX クラスターは、開発またはテストワークロードでは 1 つまたは 2 つのノードでデプロイできます。1 つのノードまたは 2 つのノードクラスターでは耐障害性がないため、本稼働での使用では 3 つ未満のノードはお勧めしません。1 つのノードまたは 2 つのノードクラスターでソフトウェアまたはハードウェアの障害が発生した場合、クラスターが使用できなくなったり、キャッシュ済みデータが失われることがあります。
**重要**
DAX クラスターは、最大 500 の DynamoDB テーブルをサポートします。500 テーブルを超えると、クラスターの可用性とパフォーマンスが低下する可能性があります。
## リージョンとアベイラビリティーゾーン
ある AWS リージョンにある DAX クラスターは、同じリージョンにある DynamoDB テーブルとのみやり取りできます。したがって、適切なリージョンで DAX クラスターを起動することを確認してください。他のリージョンに DynamoDB テーブルがある場合は、そのリージョンにも DAX クラスターを起動する必要があります。
各リージョンは、他のリージョンと完全に分離されるように設計されています。各リージョンには複数のアベイラビリティーゾーンがあります。別のアベイラビリティーゾーンでノードを起動して、最大限の耐障害性を実現できます。
**重要**
単一アベイラビリティーゾーンにクラスターのすべてのノードを置かないでください。この設定では、アベイラビリティーゾーンの障害時に DAX クラスターが利用できなくなります。
本稼働環境での使用においては、少なくとも 3 つのノードをそれぞれ異なるアベイラビリティーゾーンに置いて DAX を使用することを強くお勧めします。DAX クラスターが耐障害性を持つためには 3 つのノードが必要です。
DAX クラスターは、開発またはテストワークロードでは 1 つまたは 2 つのノードでデプロイできます。1 つまたは 2 つのノードクラスターでは耐障害性がないため、本稼働での使用では 3 つ未満のノードはお勧めしません。1 つまたは 2 つのノードクラスターでソフトウェアまたはハードウェアの障害が発生した場合、クラスターが使用できなくなったり、キャッシュ済みデータが失われることがあります。
## パラメータグループ
*パラメータグループ*は、DAX クラスターのランタイム設定を管理するために使用されます。DAX には、パフォーマンスを最適化するために使用できるいくつかのパラメータ (キャッシュ済みデータの TTL ポリシーを定義するなど) があります。パラメータグループはクラスターに適用可能なパラメータの名前付きセットです。これにより、そのクラスター内のすべてのノードがまったく同じ方法で設定されていることを確認できます。
## セキュリティグループ
DAX クラスターは、Amazon Virtual Private Cloud (Amazon VPC) 環境で実行されます。この環境は、AWS アカウント専用の仮想ネットワークであり、他の VPC からは独立しています。*セキュリティグループ*は、VPC の仮想ファイアウォールとして機能し、インバウンドトラフィックとアウトバウンドネットワークトラフィックをコントロールできます。
VPC でクラスターを起動する際に、着信ネットワークトラフィックを許可する*進入*ルールをセキュリティグループに追加します。進入ルールは、クラスターのプロトコル (TCP) とポート番号 (8111) を指定します。このルールをセキュリティグループに追加すると、VPC 内で実行されるアプリケーションが DAX クラスターにアクセスできます。
## クラスター ARN
各 DAX クラスターには Amazon リソースネーム (ARN) が割り当てられます。ARN 形式は次のとおりです。
```
arn:aws:dax:region:accountID:cache/clusterName
```
IAM ポリシー内でクラスター ARN を使用して、DAX API オペレーションのアクセス許可を定義します。詳細については、「[DAX のアクセスコントロール](DAX.access-control.md)」を参照してください。
## クラスターエンドポイント
すべての DAX クラスターは、アプリケーションで使用できるクラスターエンドポイントを提供します。エンドポイントを使用してクラスターにアクセスすることで、アプリケーションでクラスターの個別のノードのホスト名とポート番号を把握する必要がなくなります。アプリケーションは、リードレプリカを追加または削除した場合でも、自動的にクラスターのすべてのノードを「把握」します。
転送中に暗号化を使用するように設定されていない、us-east-1 リージョンのクラスターエンドポイントの例を以下に示します。
`dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com`
転送中に暗号化を使用するように設定されている、同じリージョン内のクラスターエンドポイントの例を以下に示します。
`daxs://my-encrypted-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com`
## ノードエンドポイント
DAX クラスターのノードそれぞれに独自のホスト名とポート番号があります。*ノードエンドポイント*の例を以下に示します。
`myDAXcluster-a.2cmrwl.clustercfg.dax.use1.cache.amazonaws.com:8111 `
アプリケーションは、エンドポイントを使用してノードに直接アクセスできます。しかし、DAX クラスターを単一のユニットとして扱い、代わりにクラスターのエンドポイントを使用してアクセスすることをお勧めします。クラスターエンドポイントを使用することで、アプリケーションでノードのリストを保持し、クラスターでノードが追加または削除されたときにリストを最新の状態に保つ必要がなくなります。
## [サブネットグループ]
DAX クラスターノードへのアクセスは、Amazon VPC 環境内の Amazon EC2 インスタンスで実行されるアプリケーションのみに制限されます。サブネットグループを使用して、特定のサブネットで実行されている Amazon EC2 インスタンスからのクラスターアクセスを許可できます。サブネットグループは、Amazon VPC 環境で実行しているクラスターに対して指定できるサブネット (通常はプライベート) の集合です。
DAX クラスターを作成するときに、サブネットグループを指定する必要があります。DAX はそのキャッシュサブネットグループを使用して、そのサブネット内でノードに関連付けるサブネットおよび IP アドレスを選択します。
## イベント
DAX は、ノードの追加の失敗、ノードの追加の成功、セキュリティグループの変更など、重要なイベントをクラスター内に記録します。主要イベントをモニタリングすることで、クラスターの現在の状態を知り、イベントに基づいて是正措置を取ることができます。AWS マネジメントコンソール、または DAX 管理 API の `DescribeEvents` アクションを使用して、これらのイベントにアクセスできます。
特定の Amazon Simple Notification Service (Amazon SNS) トピックに通知を送信するようにリクエストすることもできます。そうすれば、DAX クラスターでイベントが発生したことがすぐにわかります。
## メンテナンスウィンドウ
システムの変更を適用するため、すべてのクラスターには週ごとのメンテナンスウィンドウがあります。変更が順次適用されるにしたがって、既存のノードが置き換えられ、変更が適用された新しいノードがクラスターに追加されます。この間、アプリケーションでは、一時的なエラーやスロットリングが発生する可能性があります。そのため、使用量が最も少ない時間にメンテナンスウィンドウを設定し、必要に応じてこのスケジュールを定期的に調整することをお勧めします。お客様がリクエストしたメンテナンス作業が発生する時間範囲を最大 24 時間で指定できます。
キャッシュクラスターの作成または変更時に、必要なメンテナンス期間を指定しない場合、DAX では、ランダムに選択された曜日に対して 60 分のメンテナンスウィンドウが割り当てられます。この 60 分間のメンテナンスウィンドウは、各 AWS リージョン の 8 時間の時間ブロックからランダムに選択されます。次の表に、デフォルトでメンテナンス時間が割り当てられる各リージョンの時間ブロックを示します。
****
| リージョンコード | リージョン名 | メンテナンスウィンドウ |
| --- | --- | --- |
| ap-northeast-1 | Asia Pacific (Tokyo) Region | 13:00～21:00 UTC |
| ap-southeast-1 | Asia Pacific (Singapore) Region | 14:00～22:00 UTC |
| ap-southeast-2 | Asia Pacific (Sydney) Region | 12:00～20:00 UTC |
| ap-south-1 | Asia Pacific (Mumbai) Region | 17:30～1:30 UTC |
| cn-northwest-1 | 中国 (寧夏) リージョン | 23:00～07:00 UTC |
| cn-north-1 | 中国 (北京) リージョン | 14:00～22:00 UTC |
| eu-central-1 | Europe (Frankfurt) Region | 23:00～07:00 UTC |
| eu-north-1 | 欧州 (ストックホルム) リージョン | 01:00～09:00 UTC |
| eu-south-2 | 欧州 (スペイン) リージョン | 21:00～05:00 UTC |
| eu-west-1 | 欧州 (アイルランド) リージョン | 22:00～06:00 UTC |
| eu-west-2 | Europe (London) Region | 23:00～07:00 UTC |
| eu-west-3 | 欧州 (パリ) リージョン | 23:00～07:00 UTC |
| sa-east-1 | South America (São Paulo) Region | 01:00～09:00 UTC |
| us-east-1 | 米国東部 (バージニア北部) リージョン | 03:00～11:00 UTC |
| us-east-2 | 米国東部 (オハイオ) リージョン | 23:00～07:00 UTC |
| us-west-1 | US West (N. California) リージョン | 06:00～14:00 UTC |
| us-west-2 | 米国西部 (オレゴン) リージョン | 06:00～14:00 UTC |