Amazon MSK が Raft モードの Apache Kafka (KRaft) をサポートしました

企業はリアルタイムでデータをキャプチャして分析するために、Apache Kafka と Amazon Managed Streaming for Apache Kafka(Amazon MSK)を採用しています。 Amazon MSK は、Kafka のインフラ管理の専門知識や Apache Kafka を自分で設定して実行することに伴う複雑なオーバーヘッドへの対処なしに、Apache Kafka 上で本番アプリケーションを構築および実行できるよう支援します。リリース当初から、Apache Kafka は Kafka ブローカーとトピックのメタデータを保存および複製するために Apache ZooKeeper に依存してきました。 Apache Kafka バージョン 3.3 から、Kafka コミュニティはメタデータ管理における ZooKeeper への依存性を置き換えるために、コンセンサスプロトコルである KRaft (Kafka on Raft) を採用しました。将来的には、Apache Kafka コミュニティは ZooKeeper モードを完全に削除する計画です。

本日、バージョン 3.7 からの新しいクラスターで、Amazon MSK 上の KRaft のサポートを開始できることをうれしく思います。この投稿では、KRaft モードが ZooKeeper アプローチに比べてどのように役立つかの詳細を説明します。また、KRaft モードで MSK クラスターを作成するプロセスと、KRaft モードの MSK クラスターにアプリケーションを接続する方法もご紹介します。

ZooKeeper から KRaft モードへの置き換えられた理由

従来の Kafka アーキテクチャは、クラスタメタデータの信頼できるソースとして ZooKeeper に依存しています。ZooKeeper のメタデータへの読み書きアクセスは、単一の Kafka コントローラを通じて行われます。パーティション数が多いクラスタの場合、このアーキテクチャは、コントローラが 1 つであることに起因する、ブローカーの突然のシャットダウンやコントローラのフェイルオーバーといったシナリオでボトルネックを引き起こす可能性があります。

KRaft モードは、メタデータを Kafka クラスター自体内で管理することで、これらの制限を解決します。ZooKeeper クラスターに依存する代わりに、KRaft モードはクラスターメタデータを複数の Kafka コントローラーノード全体に保存および複製し、メタデータのクォーラムを形成します。KRaft コントローラーノードは、Kafka メタデータログを管理する Raft クォーラムで構成されます。メタデータ管理の責任を複数のコントローラーノード全体に分散することで、KRaft モードは、ブローカーの制御不能なシャットダウンやコントローラーのフェイルオーバーなどのシナリオでのリカバリー時間を改善します。
KRaft モードとその実装の詳細については、KIP-500: セルフマネージドメタデータクォーラムで ZooKeeper を置き換えるを参照してください。

次の図は、ZooKeeper モードと KRaft モードの 3 ノード MSK クラスター・アーキテクチャを比較したものです。

KRaft モードの Amazon MSK

これまで、Amazon MSK はメタデータ管理に ZooKeeper に依存する Kafka クラスタをサポートしてきました。Amazon MSK の主なメリットの 1 つは、ZooKeeper クラスタの設定と管理の複雑さを追加料金なしで処理してくれることです。多くの組織が、数千のパーティションにトラフィックを分割する必要がある大規模なビジネスクリティカルなストリーミングアプリケーションを実行するために Amazon MSK を利用しています。Kafka クラスタのサイズが大きくなるにつれ、クラスタ内で生成されるメタデータの量は、パーティション数に比例して増加します。

Kafka クラスタがサポートできるパーティション数を決定する重要な 2 つのプロパティがあります。ノードごとのパーティション数制限と、クラスタ全体のパーティション制限です。以前述べたように、ZooKeeper ベースのメタデータ管理システムは、Apache Kafka のクラスタ全体のパーティション制限にボトルネックを課していました。しかし、Amazon MSK にバージョン 3.7 から KRaft モードが導入されたことで、Amazon MSK は現在、ZooKeeper モードのデフォルトクォータの 30 ブローカーに対して、最大 60 ブローカーを持つクラスタの作成を可能にしています。Kafka のスケーラビリティは、基本的にはより多くのノードを追加して全体的な容量を増やすことによってクラスタを拡大することによるものです。結果的に、クラスター全体のパーティション制限は、引き続き Kafka システム内のスケーラビリティの上限であり続けます。パーティション制限が、使用可能な各ノードに分散配置されるパーティションの最大数を決定するためです。
Amazon MSK は、追加費用なしで KRaft コントローラーノードを管理します。

KRaft モードの MSK クラスターの作成とアクセス

KRaft モードで MSK クラスタを設定するには、次のステップを完了します:

Amazon MSK console にてナビゲーションペインから Clusters を選択します。
Create cluster を選択します。
Cluster creation method で Custom create を選択します。
Cluster name に任意の名前を入力します。
Cluster type で Provisioned を選択します。
Apache Kafka version で 3.7.x を選択します。
Metadata mode で KRaft を選択します。　
他の設定はそのままで、 Create cluster を選択します。

クラスターの作成が成功したら、クラスターに移動して　View client information　を選択できます。これにより、クラスターのブートストラップサーバーに関する詳細が提供されます。

KRaft モードの MSK クラスタへのアクセスのためのクライアントアプリケーションとツールの調整

Amazon MSK で KRaft モードが採用されたことにより、ZooKeeper に接続して MSK クラスタと対話するクライアントアプリケーションやツールを使用しているお客様は、アーキテクチャから ZooKeeper が削除されたことを反映するようにこれらを更新する必要があります。バージョン 1.0 から、Kafka は ZooKeeper 接続文字列の代わりにブートストラップサーバー(ブローカー)を入力パラメータとして管理ツールが使用できるようにする機能を導入し、バージョン 2.5 から ZooKeeper 接続文字列の非推奨を開始しました。この変更は、Kafka を ZooKeeper から切り離し、メタデータ管理のために最終的に ZooKeeper を KRaft モードで置き換えるための取り組みの一環でした。 ZooKeeper 接続文字列を指定する代わりに、クライアントは bootstrap.servers設定オプションを使用して、Kafka ブローカーに直接接続する必要があります。次の表は、これらの変更を要約したものです。

.	ZooKeeper 利用時	KRaft 利用時
クライアントとサービス	`bootstrap.servers=broker:<port>` または `zookeeper.connect=zookeeper:2181` (非推奨)	`bootstrap.servers=broker:<port>`
管理ツール	`kafka-topics --zookeeper zookeeper:2181` (非推奨) または `kafka-topics —bootstrap-server broker:<port> … —command-config`	`kafka-topics —bootstrap-server broker:<port> … —command-config`

概要

この投稿では、Amazon MSK がメタデータ管理のための KRaft モードのサポートを開始したことについて説明しました。また、KRaft の動作と ZooKeeper との違いについても説明しました。

Amazon MSK で　KRaft モードを利用するためには、AWS Management Consoleを使用して KRaft モードで新しいクラスターを作成してください。詳細はAmazon MSK デベロッパーガイドを参照してください。

著者について

Kalyan Janaki はアマゾンウェブサービスのシニアビッグデータ&アナリティクススペシャリストです。彼は、お客様が AWS 上で拡張性やパフォーマンスが高く、安全なクラウドベースのソリューションを設計および構築できるよう支援しています。

翻訳はソリューションアーキテクトの小役丸が担当しました。原文はこちらです。

Amazon Web Services ブログ