Azure HDInsight 4.0 では、パフォーマンス、接続性、セキュリティが大幅に強化された最新のオープンソース コンポーネントが提供されています。 このドキュメントでは、HDInsight 3.6 上の Apache Kafka ワークロードを HDInsight 4.0 に移行する方法について説明します。 ワークロードを HDInsight 4.0 に移行した後は、HDInsight 3.6 では使用できない多くの新機能を使用できます。
HDInsight 3.6 Kafka 移行パス
HDInsight 3.6 では、Kafka の 2 つのバージョン (1.0.0 と 1.1.0) がサポートされています。 HDInsight 4.0 では、バージョン 1.1.0 と 2.1.0 がサポートされています。 Kafka のバージョンと実行する HDInsight のバージョンに応じて、複数の移行パスがサポートされます。 これらのパスを以下に説明し、次の図に示します。
- 最新バージョンで Kafka と HDInsight の両方を実行する (推奨):HDInsight 3.6 および Kafka 1.0.0 または 1.1.0 アプリケーションを Kafka 2.1.0 (以下のパス D と E) を使用して HDInsight 4.0 に移行します。
- 最新バージョンで HDInsight を実行しますが、Kafka はより新しいバージョンでのみ実行します。HDInsight 3.6 および Kafka 1.0.0 アプリケーションを Kafka 1.1.0 (以下のパス B) を使用して HDInsight 4.0 に移行します。
- 最新バージョンで HDInsight を実行し、Kafka バージョンを保持する: HDInsight 3.6 および Kafka 1.1.0 アプリケーションを Kafka 1.1.0 (以下のパス C) を使用して HDInsight 4.0 に移行します。
- より新しいバージョンで Kafka を実行し、HDInsight バージョンを保持する: Kafka 1.0.0 アプリケーションを 1.1.0 に移行し、HDInsight 3.6 (以下のパス A) に留めます。 このオプションでは、引き続き新しいクラスターをデプロイする必要があることに注意してください。 既存のクラスターでの Kafka バージョンのアップグレードはサポートされていません。 必要なバージョンのクラスターを作成したら、新しいクラスターを使用するように Kafka クライアントを移行します。
Apache Kafka のバージョン
Kafka 1.1.0
Kafka 1.0.0 から 1.1.0 に移行する場合は、次の新機能を利用できます。
- Kafka コントローラーの機能強化により、制御されたシャットダウンが高速化されるため、ブローカーを再起動して問題から迅速に復旧できます。
- FetchRequests ロジックの機能強化により、クラスター上のパーティション (およびより多くのトピック) を増やせるようにしました。
- Kafka Connect では、トピックの レコード ヘッダー と 正規表現がサポートされています 。
更新プログラムの完全な一覧については、 Apache Kafka 1.1 のリリース ノートを参照してください。
Apache Kafka 2.1.0
Kafka 2.1 に移行する場合は、次の機能を利用できます。
- レプリケーション プロトコルが改善されたため、ブローカーの回復性が向上します。
- KafkaAdminClient API の新機能。
- 構成可能なクォータ管理。
- Zstandard 圧縮のサポート。
更新プログラムの完全な一覧については、 Apache Kafka 2.0 リリース ノート と Apache Kafka 2.1 リリース ノートを参照してください。
Kafka クライアントの互換性
新しい Kafka ブローカーは、古いクライアントをサポートします。
KIP-35 - プロトコル バージョンの取得 により、Kafka ブローカーと KIP-97 の機能を動的に決定するためのメカニズム が導入されました。Kafka クライアント RPC 互換性ポリシーの改善により 、新しい互換性ポリシーと Java クライアントの保証が導入されました。 以前は、Kafka クライアントは、同じバージョンまたは新しいバージョンのブローカーと対話する必要がありました。 これで、新しいバージョンの Java クライアントと、KIP-35 をサポートする他のクライアント ( librdkafka など) は、古い要求の種類にフォールバックしたり、機能が利用できない場合に適切なエラーをスローしたりできます。
クライアントが古いブローカーをサポートしているわけではないことに注意してください。 詳細については、「 互換性マトリックス」を参照してください。
一般的な移行プロセス
次の移行ガイダンスでは、単一の仮想ネットワークで HDInsight 3.6 にデプロイされた Apache Kafka 1.0.0 または 1.1.0 クラスターを想定しています。 既存のブローカーにはいくつかのトピックがあり、プロデューサーとコンシューマーによって積極的に使用されています。
移行を完了するには、次の手順を実行します。
テスト用の新しい HDInsight 4.0 クラスターとクライアントをデプロイします。 新しい HDInsight 4.0 Kafka クラスターをデプロイします。 複数の Kafka クラスター バージョンを選択できる場合は、最新バージョンを選択することをお勧めします。 デプロイ後、必要に応じていくつかのパラメーターを設定し、既存の環境と同じ名前のトピックを作成します。 また、必要に応じて TLS と Bring Your Own-Key (BYOK) 暗号化を設定します。 次に、新しいクラスターで正しく動作するかどうかを確認します。
プロデューサー アプリケーションのクラスターを切り替え、すべてのキュー データが現在のコンシューマーによって使用されるまで待ちます。 新しい HDInsight 4.0 Kafka クラスターの準備ができたら、既存のプロデューサーの宛先を新しいクラスターに切り替えます。 既存のコンシューマー アプリが既存のクラスターからすべてのデータを使用するまで、そのままにしておきます。
コンシューマー アプリケーションでクラスターを切り替えます。 既存のコンシューマー アプリケーションが既存のクラスターのすべてのデータの使用を完了したことを確認したら、接続を新しいクラスターに切り替えます。
必要に応じて、古いクラスターを削除し、アプリケーションをテストします。 スイッチが完了して正常に動作したら、必要に応じて、古い HDInsight 3.6 Kafka クラスターと、テストで使用されているプロデューサーとコンシューマーを削除します。