DAX クラスターの管理

このセクションでは、Amazon DynamoDB Accelerator (DAX) クラスターの一般的な管理タスクの一部を紹介します。

DAX クラスターを管理するための IAM アクセス許可

AWS Management Console または AWS Command Line Interface (AWS CLI)を使用して DAX クラスターを管理する場合は、ユーザーが実行できるアクションの範囲を絞り込むことを強くお勧めします。そうすることで、最小権限の原則に従って、リスクを緩和できます。

次の説明は、DAX 管理 API のアクセスコントロールに焦点を当てます。詳細については、「Amazon DynamoDB API リファレンス」の「Amazon DynamoDB Accelerator」を参照してください。

DAX 管理 API では、特定のリソースへの API アクションを範囲に含めることはできません。Resource 要素は "*" に設定する必要があります。これは GetItem、Query、Scan などの DAX データプレーン API オペレーションとは異なります。データプレーンオペレーションは DAX のクライアントを通じて表示され、これらのオペレーションは特定のリソースを範囲にできます。

例として、次の IAM ポリシードキュメントについて考えます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "dax:*"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01"
            ]
        }
    ]
}

このポリシーの目的は、特定のクラスター DAXCluster01 のみの DAX 管理 API コールを許可することであるとします。

ユーザーが次の AWS CLI コマンドを発行するとします。

aws dax describe-clusters

基盤となる DescribeClusters API コールが特定のクラスターを範囲にできないため、このコマンドは Not Authorized (権限がありません) という例外で失敗します。ポリシーが構文としては有効であっても、このコマンドは Resource 要素が "*" に設定される必要があるため、失敗します。ただし、ユーザーが DAX データプレーンコール (GetItem や Query など) を DAXCluster01 に送信するプログラムを実行する場合は、それらのコールは成功します。これは、DAX データプレーン API が特定のリソース (この場合は DAXCluster01) を範囲にできるためです。

DAX 管理 API と DAX データプレーン API の両方を包括する単一の包括 IAM ポリシーを作成する場合は、ポリシードキュメントに 2 つの異なるステートメントを含めることをお勧めします。これらのステートメントの 1 つが DAX データプレーン API に対応し、もう 1 つのステートメントが DAX 管理 API に対応するようにします。

次のポリシー例で、この方法を示します。DAXDataAPIs ステートメントは DAXCluster01 リソースを範囲とするが、DAXManagementAPIs のリソースは "*" にする必要がある点に注意してください。各ステートメントに示されているアクションは、説明のみを目的としています。アプリの必要に応じて、これらをカスタマイズできます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DAXDataAPIs",
            "Action": [
                "dax:GetItem",
                "dax:BatchGetItem",
                "dax:Query",
                "dax:Scan",
                "dax:PutItem",
                "dax:UpdateItem",
                "dax:DeleteItem",
                "dax:BatchWriteItem"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01"
            ]},
            {
            "Sid": "DAXManagementAPIs",
            "Action": [
                "dax:CreateParameterGroup",
                "dax:CreateSubnetGroup",
                "dax:DecreaseReplicationFactor",
                "dax:DeleteCluster",
                "dax:DeleteParameterGroup",
                "dax:DeleteSubnetGroup",
                "dax:DescribeClusters",
                "dax:DescribeDefaultParameters",
                "dax:DescribeEvents",
                "dax:DescribeParameterGroups",
                "dax:DescribeParameters",
                "dax:DescribeSubnetGroups",
                "dax:IncreaseReplicationFactor",
                "dax:ListTags",
                "dax:RebootNode",
                "dax:TagResource",
                "dax:UntagResource",
                "dax:UpdateCluster",
                "dax:UpdateParameterGroup",
                "dax:UpdateSubnetGroup"
                ],
            "Effect": "Allow",
            "Resource": [
                "*"
            ]
        }
    ]
}

DAX クラスターのスケーリング

DAX クラスターのスケーリングには 2 つのオプションを使用できます。第 1 のオプションは水平スケーリングです。クラスターにリードレプリカを追加します。2 番目のオプションは、垂直スケーリング で、さまざまなノードタイプを選択します。アプリケーションに適切なクラスターサイズとノードタイプの選択方法の詳細については、「DAX クラスターサイジングガイド」を参照してください。

水平スケーリング

水平スケーリングでは、クラスターにリードレプリカを追加することで、読み込みオペレーションのスループットを向上させることができます。1 つの DAX クラスターで最大 10 個のリードレプリカをサポートし、レプリカはクラスターの実行中に追加または削除できます。

新しいノードを追加する際は、ピアノードからキャッシュデータを同期する必要があります。そのため、追加時間はキャッシュサイズとアプリケーションのワークロードによって異なります。ベストプラクティスとして、予想されるトラフィックのピークに合わせてクラスターを事前にスケールすることをお勧めします。適切なサイズ設定のガイドラインとモニタリングの推奨事項については、「DAX クラスターサイジングガイド」を参照してください。

次の AWS CLI の例で、ノードの数を増減する方法を説明します。--new-replication-factor 引数は、クラスター内のノードの合計数を指定します。ノードの 1 つはプライマリノードであり、他のノードはリードレプリカです。

aws dax increase-replication-factor \
    --cluster-name MyNewCluster  \
    --new-replication-factor 5

aws dax decrease-replication-factor \
    --cluster-name MyNewCluster  \
    --new-replication-factor 3

垂直スケーリング

大規模なデータセットがある場合、より大きいノードタイプを使用することでアプリケーションに有益な場合があります。ノードが大きいほど、クラスターがより多くのデータをメモリに保存できるため、キャッシュミスが軽減され、アプリケーション全体のパフォーマンスが向上します。(DAX クラスターのすべてのノードは同じタイプでなければならないことに注意してください。)

DAX クラスターの書き込みオペレーションやキャッシュミスの割合が高い場合は、より大きなノードタイプを使用するとアプリケーションにも利点があります。書き込みオペレーションとキャッシュミスは、クラスターのプライマリノード上のリソースを消費します。したがって、より大きなノードタイプを使用すると、プライマリノードのパフォーマンスが向上し、これらのタイプのオペレーションのスループットが向上します。

実行中の DAX クラスターのノードタイプを変更することはできません。代わりに、目的のノードタイプの新しいクラスターを作成する必要があります。サポートされているノードタイプについては、「ノード」を参照してください。

新しい DAX クラスターを作成するには、AWS Management Console、AWS CloudFormation、AWS CLI、または AWS SDK を使用します。(AWS CLI の場合、--node-type パラメータを使用してノードタイプを指定します。)

DAX クラスターの設定のカスタマイズ

DAX クラスターを作成する場合、次のデフォルト設定が使用されます。

新しいクラスターの場合は、作成時に設定をカスタマイズできます。AWS Management Consoleでこれを行うには、[デフォルト設定の使用] をオフにして以下の設定を変更します。

メンテナンスイベントが発生すると、DAX から Amazon Simple Notification Service (Amazon SNS) を使用して通知が送信されます。通知を設定するには、[SNS 通知のトピック] セレクタからオプションを選択します。新しい Amazon SNS トピックを作成することも、既存のトピックを使用することもできます。

Amazon SNS トピックの設定とサブスクリプションの詳細については、「Amazon Simple Notification Service デベロッパーガイド」の「Amazon SNS の開始方法」を参照してください。

TTL 設定の構成

DAX は、DynamoDB から読み込んだデータを 2 つのキャッシュに保持します。

詳細については、「項目キャッシュ」および「クエリキャッシュ」を参照してください。

これらのキャッシュそれぞれのデフォルトの TTL は 5 分です。異なる TTL 設定を使用する場合は、カスタムパラメータグループを使用した DAX クラスターを起動できます。コンソールでこれを行うには、ナビゲーションペインの [DAX | Parameter groups (DAX | パラメータグループ)] を選択します。

上記のタスクを AWS CLI を使用して実行することもできます。次の例では、カスタムパラメータグループを使用して新しい DAX クラスターを起動する方法を示しています。この例では、項目キャッシュ TTL は 10 分に設定され、クエリキャッシュ TTL は 3 分に設定されます。

このパラメータグループを使用して、新しい DAX クラスターを起動できます。

aws dax create-cluster \
    --cluster-name MyNewCluster \
    --node-type dax.r3.large \
    --replication-factor 3 \
    --iam-role-arn arn:aws:iam::123456789012:role/DAXServiceRole \
    --parameter-group custom-ttl

DAX のタグ付けサポート

DynamoDB を始めとする多くの AWS サービスは、タグ付け (ユーザー定義の名前でリソースにラベル付けする機能) をサポートします。DAX クラスターにタグ付けを割り当てて、同じタグ付けを持つすべての AWS リソースをすばやく識別したり、タグ付け別に AWS の請求書を分類したりできます。

詳細については、「」を参照してくださいDynamoDB でのリソースへのタグとラベルの追加

AWS Management Console の使用

AWS CLI の使用

AWS CLI を使用して DAX クラスタータグを管理している場合は、最初にクラスターの Amazon リソースネーム (ARN) を確認する必要があります。次の例は、MyDAXCluster という名前のクラスターの ARN を確認する方法を示しています。

aws dax describe-clusters \
    --cluster-name MyDAXCluster \
    --query "Clusters[*].ClusterArn"

出力で、ARN は次の例のようになります。arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster

次の例は、クラスターにタグ付けする方法を示しています。

aws dax tag-resource  \
    --resource-name arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster \
    --tags="Key=ClusterUsage,Value=prod"

クラスターのすべてのタグを一覧表示します。

aws dax list-tags \
    --resource-name arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster

タグを削除するには、キーを指定します。

aws dax untag-resource  \
    --resource-name arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster \
    --tag-keys ClusterUsage

AWS CloudTrail の統合

DAX は AWS CloudTrail と統合されているため、DAX クラスターのアクティビティを監査できます。CloudTrail ログを使用して、クラスターレベルで行われたすべての変更を表示できます。ノード、サブネットグループ、パラメータグループなどのクラスターコンポーネントへの変更も確認できます。詳細については、「」を参照してくださいAWS CloudTrail を使用して DynamoDB オペレーションをログに記録する

クラスターを削除する

使用していないリソースに課金されないように、不要になった DAX クラスターを削除する必要があります。

コンソールまたは AWS CLI を使用して、DAX クラスターを削除できます。以下はその例です。

aws dax delete-cluster --cluster-name mydaxcluster