次の方法で共有

Apache Kafka のワークロードを Azure HDInsight 5.1 に移行する

Azure HDInsight 5.1 では、パフォーマンス、接続性、セキュリティが大幅に強化された最新のオープンソース コンポーネントが提供されています。 このドキュメントでは、HDInsight 4.0 (Kafka 2.1) から HDInsight 5.1 (Kafka 3.2) に Apache Kafka ワークロードを移行する方法について説明します。

Apache Kafka のバージョン

Apache Kafka 3.2.0

Kafka 3.2.0 (HDI 5.1) に移行する場合は、次の新機能を利用できます。

  • MM 2.0 では、クラスター間での自動コンシューマー オフセット同期をサポートしているため、クラスター KIP-545 間でのコンシューマーの移行やフェールオーバーが容易になります。
  • パーティション リーダーにパーティションを回復するためのヒント: コントローラーが新しく選択したトピック パーティション リーダーと通信し、その状態 KIP-704 を回復する必要があるかどうかを許可する新機能。
  • セキュリティで保護された通信のために、TLS 1.2 が既定でサポートされます。
  • Zookeeper の依存関係の削除: プロデューサーとコンシューマーに zookeeper パラメーターが不要になりました。 CLI コマンド KIP-500 で--zookeeperする代わりに、--bootstrap-server オプションを使用します。
  • Acceptor を作成するための構成可能なバックログ サイズ: ブローカー KIP-764 で TCP のアクセプター ソケットの SYN バックログのサイズを設定できる新しい構成。
  • DescribeLogDirsResponse に追加されるトップレベルのエラーコードフィールド: DescribeLogDirs API を他の API と一貫させ、CLUSTER_AUTHORIZATION_FAILED以外の他のエラーも返すことができる新しいエラーコード KIP-784。

更新プログラムの完全な一覧については、 Apache Kafka 3.2.0 リリース ノートを参照してください。

Kafka クライアントの互換性

新しい Kafka ブローカーは、古いクライアントをサポートします。 KIP-35 - プロトコル バージョンの取得 により、Kafka ブローカーと KIP-97 の機能を動的に決定するためのメカニズム が導入されました。Kafka クライアント RPC 互換性ポリシーの改善により 、新しい互換性ポリシーと Java クライアントの保証が導入されました。 以前は、Kafka クライアントは、同じバージョンまたは新しいバージョンのブローカーと対話する必要がありました。 これで、新しいバージョンの Java クライアントと 、KIP-35 をサポートする他のクライアント ( librdkafka など) は、古い要求の種類にフォールバックしたり、機能が利用できない場合に適切なエラーをスローしたりできます。

Kafka クライアントのアップグレードの互換性を示すスクリーンショット。

注

クラスターのバージョンと同じ kafka クライアント バージョンを使用することをお勧めします。 詳細については、「 互換性マトリックス」を参照してください。

一般的な移行プロセス

次の移行ガイダンスでは、単一の仮想ネットワークで HDInsight 4.0 にデプロイされた Apache Kafka 2.1.1 クラスターを想定しています。 既存のブローカーにはいくつかのトピックがあり、プロデューサーとコンシューマーによって積極的に使用されています。 既存のクラスターでの Kafka バージョンのアップグレードはサポートされていません。 HDI 5.1 でクラスターを作成した後、新しいクラスターを使用するように Kafka クライアントを移行します。

移行を完了するには、次の手順を実行します。

  1. テスト用の新しい HDInsight 5.1 クラスターとクライアントをデプロイします。 新しい HDInsight 5.1 Kafka クラスターをデプロイします。 複数の Kafka クラスター バージョンを選択できる場合は、最新バージョンを選択することをお勧めします。 デプロイ後、必要に応じていくつかのパラメーターを設定し、既存の環境と同じ名前のトピックを作成します。 また、必要に応じて TLS と Bring Your Own-Key (BYOK) 暗号化を設定します。 次に、新しいクラスターで正しく動作するかどうかを確認します。

    スクリーンショットは、新しい HDInsight 5.1 クラスターをデプロイする方法を示しています。

  2. プロデューサー アプリケーションのクラスターを切り替え、すべてのキュー データが現在のコンシューマーによって使用されるまで待ちます。 新しい HDInsight 5.1 Kafka クラスターの準備ができたら、既存のプロデューサーの宛先を新しいクラスターに切り替えます。 既存のコンシューマー アプリが既存のクラスターからすべてのデータを使用するまで、そのままにしておきます。

    スクリーンショットは、プロデューサー アプリのクラスターを切り替える方法を示しています。

  3. コンシューマー アプリケーションでクラスターを切り替えます。 既存のコンシューマー アプリケーションが既存のクラスターのすべてのデータの使用を完了したことを確認したら、接続を新しいクラスターに切り替えます。

    コンシューマー アプリでクラスターを切り替える方法を示すスクリーンショット。

  4. 必要に応じて、古いクラスターを削除し、アプリケーションをテストします。 スイッチが完了して正常に動作したら、必要に応じて、古い HDInsight 4.0 Kafka クラスターと、テストで使用されているプロデューサーとコンシューマーを削除します。

次のステップ