# クラスターオペレーションの管理
<a name="dax-cluster-operations"></a>

DAX は、クラスターのメンテナンスと状態をお客様に代わって管理します。ただし、使用パターンに合わせてクラスターを水平または垂直にスケーリングするには、運用上の入力を提供する必要があります。このセクションでは、DAX クラスターをスケーリングするための推奨されるプロセスについて説明します。

**Topics**
+ [クラスターの水平スケーリング](#dax-cluster-horizontal-scaling)
+ [クラスターの垂直スケーリング](#dax-cluster-vertical-scaling)

## クラスターの水平スケーリング
<a name="dax-cluster-horizontal-scaling"></a>

DAX クラスターをスケーリングするには、スループットの需要に合わせてキャパシティを調整する必要があります。この調整は、実行中のクラスター内のノード (レプリカ) の数を増減することによって行われます。このプロセスは、[水平スケーリング](DAX.cluster-management.md#DAX.cluster-management.scaling.read-scaling)と呼ばれ、需要が低い場合にワークロードをより多くのノードに分散したり、少数のノードに統合したりするのに役立ちます。

AWS CLI の `decrease-replication-factor` コマンドまたは `increase-replication-factor` コマンドを使用して、DAX クラスターを水平方向にスケールインおよびスケールアウトできます。

**レプリケーション係数を増やす (スケールアウト)**  
DAX クラスターのレプリケーション係数を増やすと、クラスターにノードが追加されます。次の例は、`increase-replication-factor` コマンドの使用方法を示しています。

```
aws dax increase-replication-factor \
    --cluster-name {{yourClusterName}}  \
    --new-replication-factor {{desiredReplicationFactor}}
```
+ このコマンドでは、`cluster-name` 引数はクラスター名を指定します。例えば、{{yourClusterName}} です。
+ `new-replication-factor` 引数は、スケーリング後のクラスター内の合計ノード数を指定します。これには、プライマリノードとレプリカノードが含まれます。例えば、クラスターに現在 3 つのノードがあり、さらに 2 つのノードを追加する場合は、`new-replication-factor` の値を 5 に設定します。

**レプリケーション係数を減らす (スケールイン)**  
DAX クラスターのレプリケーション係数を減らすと、クラスターからノードが削除されます。ノードを削除すると、需要の低い時間帯のコストを削減できます。次の例は、`decrease-replication-factor` コマンドの使用方法を示しています。

```
aws dax decrease-replication-factor \
    --cluster-name {{yourClusterName}}  \
    --new-replication-factor {{desiredReplicationFactor}}
```
+ このコマンドでは、`cluster-name` 引数はクラスター名を指定します。例えば、{{yourClusterName}} です。
+ `new-replication-factor` 引数は、スケーリング後のクラスター内のノード数を指定します。この数は、現在のレプリケーション係数よりも小さく、プライマリノードを含める必要があります。例えば、クラスターに現在 5 つのノードがあり、2 つのノードを削除する場合は、`new-replication-factor` の値を 3 に設定します。

### 水平スケーリングに関する考慮事項
<a name="dax-horizontal-scaling-considerations"></a>

水平スケーリングを計画する場合は、以下の点を考慮します。
+ **プライマリノード** – DAX クラスターにはプライマリノードが含まれます。レプリケーション係数には、プライマリノードが含まれます。例えば、レプリケーション係数 3 は、1 つのプライマリノードと 2 つのレプリカノードを意味します。
+ **可用性** — DAX ノードを追加または削除すると、クラスターの可用性と耐障害性が変わります。ノードが増えると可用性は向上しますが、コストも増加します。
+ **データ移行** – レプリケーション係数を増やすと、DAX は新しいノードセット全体のデータ分散を自動的に処理します。新しいノードがトラフィックの処理を開始する際、そのキャッシュは既にウォームアップされています。ただし、このプロセスは、データ移行中のパフォーマンスに一時的な影響を与える可能性があります。

スケーリングプロセス中およびスケーリングプロセス後に DAX クラスターを注意深くモニタリングし、クラスターが期待どおりに動作していることを確認し、必要に応じて調整を行います。

## クラスターの垂直スケーリング
<a name="dax-cluster-vertical-scaling"></a>

既存のクラスターのノードサイズを垂直方向にスケーリングするには、新しいクラスターを作成し、アプリケーショントラフィックを新しいクラスターに移行する必要があります。異なるノードを持つ新しいクラスターに移行するには、アプリケーションのパフォーマンスと可用性への影響を最小限に抑えながらスムーズに移行できるようにするためのいくつかのステップが必要です。

ノードサイズを垂直方向にスケーリングするための新しいクラスターを作成するには、以下の点を考慮します。
+ **現在のセットアップを確認する** – 現在の DAX クラスターのメトリクスを確認して、必要な新しいノードサイズと数を決定します。この情報を入力として使用して、クラスターサイズを定義します。詳細については、「[クラスターのサイジング](dax-cluster-sizing.md)」を参照してください。
+ **新しい DAX クラスターをセットアップする** – 決定したノードタイプと数で新しい DAX クラスターを作成します。調整が必要な場合を除き、[パラメータグループ](dax-deploy-cluster.md#dax-cluster-parameter-group)の既存の設定を使用できます。
+ **データを同期する** — DAX は DynamoDB のキャッシュレイヤーであるため、データを直接移行する必要はありません。ただし、トラフィックを送信するまで、新しい DAX クラスターにはワーキングデータセットはメモリに存在しません。
+ **アプリケーション設定を更新する** – 新しい [DAX クラスターのエンドポイント](DAX.concepts.cluster.md#DAX.concepts.cluster-endpoint) を指すようにアプリケーションの設定を更新します。アプリケーションの設定によっては、コードの変更や環境変数の更新が必要になる場合があります。

  新しいクラスターに切り替える際の影響を軽減するには、アプリケーションフリートのごく一部から新しいクラスターに Canary トラフィックを送信します。これは、アプリケーションの更新を徐々にロールアウトするか、DAX エンドポイントの前に重みベースのルーティング DNS エントリを使用することで実行できます。
+ **モニタリングと最適化** — 新しい DAX クラスターに切り替えたら、パフォーマンスの[メトリクスとログ](DAX.Monitoring.md)に問題がないか注意深くモニタリングします。更新されたワークロードパターンに基づいてノード数を調整する準備を行います。

  新しいクラスターがワーキングデータセットを適切にキャッシュするまで、キャッシュミス率とレイテンシーは高くなります。
+ **古いクラスターの廃止** – 新しいクラスターが想定どおりに動作していることが確実な場合は、不要なコストが発生しないように、古い DAX クラスターを安全に廃止してください。