翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ZooKeeper から KRaft モードへの移行
<a name="zk-to-kraft-migration"></a>

`UpdateClusterKafkaVersion` API を使用して、既存の ZooKeeper ベースの MSK クラスターを KRaft モードに移行できます。移行はインプレースで実行されます。クラスターはプロセス全体で引き続き使用でき、データは移動されません。Amazon MSK は KRaft コントローラーをプロビジョニングし、クラスターメタデータを ZooKeeper から KRaft クォーラムに移行し、ZooKeeper ノードを自動的に廃止します。

## 前提条件
<a name="zk-kraft-migration-prereqs"></a>

クラスターを ZooKeeper から KRaft モードに移行する前に、以下を確認してください。
+ クラスターが `3.9.x` ZooKeeper モードで Apache Kafka バージョンを実行しています。クラスターが古いバージョンの場合は、`3.9.x`まず標準バージョンのアップグレードプロセスを使用して にアップグレードします。
+ クラスターは `ACTIVE`状態であり、保留中のオペレーションはありません。
+ ZooKeeper への直接アクセスに依存するツール (Cruise Control の古いバージョンやカスタム管理ツールなど) を使用する場合は、ZooKeeper の直接接続ではなく Kafka Admin APIs を使用するように更新します。
+ 標準 (プロビジョニング済み) クラスターの場合: ZooKeeper クライアントアクセスを無効にする必要があります。移行`ZookeeperAccess.Enabled=false`を開始する前に、 `UpdateConnectivity` API を使用して を設定します。Express クラスターでは、このステップは必要ありません。
+ すべてのクライアントアプリケーションは、`--bootstrap-server`接続文字列ではなく、`--zookeeper`接続文字列を使用します。ZooKeeper 接続文字列は、移行後には使用できません。
+ クラスターでは、パブリックアクセスとオープンモニタリングの両方が同時に有効になっていません。
+ クラスターは`kafka.t3.small`ブローカーインスタンスを使用しません。
+ クラスターは動的アドバタイズされたリスナーを使用しません。`advertised.listeners` プロパティがブローカーで動的に設定されているかどうかを確認するには、次のコマンドを実行します。ここで、 `{{$bs}}`はクラスターのブートストラップサーバー接続文字列であり、出力に が含まれていないことを確認します`advertised.listeners`。

  ```
  bin/kafka-configs.sh --bootstrap-server $bs --entity-type brokers --describe
  ```

  動的に設定されたプロパティの詳細については、「」を参照してください[動的 Amazon MSK 設定](msk-configuration-properties.md#msk-dynamic-confinguration)。

## 移行中の動作
<a name="zk-kraft-migration-process"></a>

ZooKeeper-to-KRaftを開始すると、Amazon MSK は次のステップを自動的に実行します。

1. Amazon MSK は、クラスターに KRaft コントローラーノードをプロビジョニングします。これらのコントローラーは追加料金なしで含まれます。

1. データプレーン移行の実行: ブローカーは、クライアントトラフィックの処理を継続しながら、メタデータに KRaft クォーラムを使用するように再設定されます。

1. すべてのブローカーが KRaft クォーラムに登録されると、Amazon MSK は ZooKeeper ノードを廃止します。

1. クラスター管理モードが KRaft に更新されます。

移行は長時間実行されるオペレーションであり、クラスターのサイズによっては数時間かかる場合があります。`DescribeClusterOperation` API を使用してオペレーションステータスをモニタリングできます。

**重要**  
移行を元に戻すことはできません。クラスターを KRaft モードに移行すると、ZooKeeper モードに戻すことはできません。

## を使用して移行する AWS CLI
<a name="zk-kraft-migration-howto"></a>

1. クラスターで使用可能なターゲットバージョンを確認します。

   ```
   aws kafka get-compatible-kafka-versions --cluster-arn {{ClusterArn}}
   ```

   クラスターが移行対象である場合、出力には KRaft `.kraft` ターゲットバージョン (サフィックス付き) が含まれます。

1. KRaft ターゲットバージョンを指定して移行を開始します。

   ```
   aws kafka update-cluster-kafka-version \
       --cluster-arn {{ClusterArn}} \
       --current-version {{Current-Cluster-Version}} \
       --target-kafka-version "3.9.x.kraft"
   ```
**重要**  
クラスターのバージョンは単純な整数ではありません。`DescribeCluster` オペレーションを使用して、クラスターの最新バージョンを検索します。

1. 移行の進行状況をモニタリングします。

   ```
   aws kafka describe-cluster-operation --cluster-operation-arn {{ClusterOperationArn}}
   ```

   オペレーション状態は を介して移行`UPDATE_IN_PROGRESS`し、 で完了します`UPDATE_COMPLETE`。

## 移行後
<a name="zk-kraft-migration-after"></a>

移行が完了した後:
+ クラスターは KRaft モードで動作します。すべてのメタデータは KRaft コントローラーによって管理されます。
+ ZooKeeper ノードは削除されます。ZooKeeper 接続文字列は使用できなくなりました。
+ `--bootstrap-server` 接続文字列を使用する場合、クライアントアプリケーションは変更なしで動作し続けます。
+ オープンモニタリングに必要な場合は、 `ListNodes` API を使用して KRaft コントローラーエンドポイントを表示できます。