ネットアップのNFSがKafkaワークロードに最適な理由
変更を提案
PDF
Kafkaを使用するNFSストレージの問題 名を変更するための解決策 が追加されたので、KafkaワークロードにNetApp ONTAP ストレージを活用する堅牢な環境を構築できます。これにより、運用オーバーヘッドが大幅に削減されるだけでなく、Kafkaクラスタに次のメリットがもたらされます。
-
* KafkaブローカーのCPU利用率を削減*分離されたネットアップONTAP ストレージを使用すると、ディスクI/O処理がブローカーから分離されるため、CPUフットプリントが削減されます。
-
*ブローカーのリカバリ時間が短縮されます。*分離型のNetApp ONTAP ストレージはKafkaブローカーのノード間で共有されるため、データを再構築することなく、従来のKafka環境と比較して、任意の時点で新しいコンピューティングインスタンスを使用して不良ブローカーに置き換えることができます。
-
* Storage Efficiency。*アプリケーションのストレージレイヤがNetApp ONTAP でプロビジョニングされるようになったため、インラインデータ圧縮、重複排除、コンパクションなど、ONTAP に備わっているStorage Efficiencyのメリットをすべて活用できます。
これらの利点は、このセクションで詳しく説明するテストケースでテストおよび検証されました。
KafkaブローカーのCPU使用率の低下
技術仕様は同一だがストレージ技術が異なる2つの精子Kafkaクラスタで同様のワークロードを実行した場合、全体的なCPU利用率がDASに比べて低いことがわかりました。KafkaクラスタがONTAP ストレージを使用している場合、全体的なCPU利用率は低くなるだけでなく、CPU利用率の増加はDASベースのKafkaクラスタよりも緩やかな勾配を示しています。
アーキテクチャのセットアップ
次の表に、CPU利用率の低下を実証するために使用する環境構成を示します。
| プラットフォームコンポーネント | 環境の構成 |
|---|---|
Kafka 3.2.3ベンチマークツール: OpenMessaging |
|
すべてのノード上のオペレーティングシステム |
RHEL 8.7以降 |
NetApp Cloud Volumes ONTAP インスタンス |
シングルノードインスタンス–M5.2xLarge |
ベンチマークツール
このテストケースで使用されているベンチマークツールはです "OpenMessagingの略" フレームワーク：OpenMessagingは、ベンダーに依存せず、言語に依存しません。金融、eコマース、IoT、ビッグデータに関する業界ガイドラインを提供し、異種システムやプラットフォーム間でメッセージングやストリーミングアプリケーションを開発するのに役立ちます。次の図は、OpenMessagingクライアントとKafkaクラスタの相互作用を示しています。
-
コンピューティング。 3ノードのKafkaクラスタを使用し、3ノードのZookeeperアンサンブルを専用サーバ上で実行しました。各ブローカーには、専用のLIFを介してNetApp CVOインスタンス上の単一のボリュームへのNFSv4.1マウントポイントが2つありました。
-
監視。 Prometheus-Grafanaの組み合わせには2つのノードを使用しました。ワークロードの生成については、このKafkaクラスタとの間でデータを生成したり消費したりできる3ノードクラスタを別途用意しています。
-
*ストレージ。*シングルノードのNetApp Cloud Volumes ONTAP インスタンスを使用し、250GB gp2 AWS-EBSボリュームを6個マウントしました。その後、これらのボリュームは、専用のLIFを介して6つのNFSv4.1ボリュームとしてKafkaクラスタに公開されました。
-
*設定。*このテストケースで設定可能な2つの要素は、KafkaブローカーとOpenMessagingワークロードでした。
-
ブローカー設定 Kafkaブローカーには以下の仕様が選択されています。以下に示すように、すべての測定値にレプリケーション係数3を使用しました。
-
-
* OpenMessagingベンチマーク（OMB）のワークロード構成。*次の仕様が提供されました。以下で強調されている目標生産者率を指定しました。
テストの方法論
-
2つの類似したクラスタが作成され、それぞれに独自のベンチマーククラスタ群があります。
-
クラスタ1。 NFSベースのKafkaクラスタ。
-
クラスタ2。 DASベースのKafkaクラスタ。
-
-
OpenMessagingコマンドを使用すると、各クラスタで同様のワークロードがトリガーされます。
sudo bin/benchmark --drivers driver-kafka/kafka-group-all.yaml workloads/1-topic-100-partitions-1kb.yaml
-
プロデュースレートの設定は4回の繰り返しで増加し、CPU使用率はGrafanaで記録されました。生産率は次のレベルに設定されました。
-
1万だ
-
40,000
-
8万だ
-
10万だ
-
観察
KafkaでNetApp NFSストレージを使用する主なメリットは2つあります。
-
* CPU使用率をほぼ3分の1に削減できます。*同様のワークロードでの全体的なCPU使用率は、DAS SSDと比較してNFSでは低く、削減率は低い場合は5%、高い場合は32%です。
-
※プロデュース率が高い場合、CPU使用率のドリフトが3倍に減少※プロデュース率の上昇に伴い、CPU使用率の上昇は予想通り上昇しました。しかし、DASを使用するKafkaブローカーのCPU使用率は、低い生産率では31%から高い生産率では70%に上昇し、39%の増加となりました。一方、NFSストレージバックエンドでは、CPU利用率が26%から38%に上昇し、12%も上昇しました。
また、メッセージ数が100、000の場合、DASのCPU利用率はNFSクラスタよりも高くなります。
ブローカーの迅速なリカバリ
ネットアップの共有NFSストレージを使用すると、Kafkaブローカーのリカバリ時間が短縮されることがわかりました。Kafkaクラスタでブローカーがクラッシュした場合、このブローカーは同じブローカーIDを持つ正常なブローカーに置き換えることができます。このテストケースを実行したところ、DASベースのKafkaクラスタでは、新しく追加された正常なブローカーにデータが再構築されるため、時間がかかることがわかりました。NetApp NFSベースのKafkaクラスタの場合、交換後のブローカーは以前のログディレクトリから引き続きデータを読み取り、はるかに高速にリカバリします。
アーキテクチャのセットアップ
次の表に、NASを使用するKafkaクラスタの環境構成を示します。
| プラットフォームコンポーネント | 環境の構成 |
|---|---|
Kafka 3.2.3. |
|
すべてのノード上のオペレーティングシステム |
RHEL8.7以降 |
NetApp Cloud Volumes ONTAP インスタンス |
シングルノードインスタンス–M5.2xLarge |
次の図は、NASベースのKafkaクラスタのアーキテクチャを示しています。
-
コンピューティング。 3ノードのZookeeperアンサンブルを専用サーバー上で実行する3ノードのKafkaクラスタ。各ブローカーには、専用のLIFを介してNetApp CVOインスタンス上の単一のボリュームへのNFSマウントポイントが2つあります。
-
監視。 PrometheusとGrafanaの組み合わせでは2ノード。ワークロードの生成には、このKafkaクラスタを生成して使用できる3ノードクラスタを別 々 に使用します。
-
*ストレージ。*シングルノードのNetApp Cloud Volumes ONTAP インスタンス。250GB gp2 AWS-EBSボリュームが6個マウントされています。これらのボリュームは、専用のLIFを介して6つのNFSボリュームとしてKafkaクラスタに提供されます。
-
*ブローカーの設定*このテストケースで設定可能な要素の1つはKafkaブローカーです。Kafkaブローカーのために以下の仕様が選択されました。。
replica.lag.time.mx.msは、特定のノードがISRリストから削除される速度を決定するため、高い値に設定されます。不良ノードと正常ノードを切り替える場合、そのブローカーIDがISRリストから除外されないようにします。
テストの方法論
-
同様の2つのクラスタが作成されました。
-
EC2ベースのコンフルエントクラスタ。
-
NetApp NFSベースのコンフルエントクラスタ。
-
-
1つのスタンバイKafkaノードが、元のKafkaクラスタのノードと同じ構成で作成されました。
-
各クラスタでサンプルトピックを作成し、各ブローカーに約110GBのデータが読み込まれました。
-
* EC2ベースのクラスタ。* Kafkaブローカーのデータディレクトリがにマッピングされています
/mnt/data-2（次の図では、cluster1のBroker-1（左側のターミナル））。 -
* NetApp NFSベースのクラスタ。* KafkaブローカーのデータディレクトリがNFSポイントにマウントされている
/mnt/data（次の図では、cluster2のBroker-1（右側の端末））。
-
-
各クラスタで、Broker-1が終了し、ブローカーのリカバリプロセスが失敗しました。
-
ブローカーが終了した後、ブローカーのIPアドレスがセカンダリIPとしてスタンバイブローカーに割り当てられました。これは、Kafkaクラスタ内のブローカーが次のように識別されるために必要でした。
-
* IPアドレス。*障害が発生したブローカーのIPをスタンバイブローカーに再割り当てすることによって割り当てられます。
-
*ブローカーID。*これはスタンバイブローカーで設定されました
server.properties。
-
-
IP割り当て時に、スタンバイブローカーでKafkaサービスが開始されました。
-
しばらくすると、サーバログがプルされ、クラスタ内の交換用ノードでデータを構築するのにかかった時間が確認されました。
観察
Kafkaブローカーの回復はほぼ9倍速くなりました。NetApp NFS共有ストレージを使用すると、KafkaクラスタでDAS SSDを使用する場合と比較して、障害が発生したブローカーノードのリカバリにかかる時間が大幅に短縮されることがわかりました。1TBのトピックデータの場合、DASベースのクラスタのリカバリ時間は48分でしたが、NetApp-NFSベースのKafkaクラスタのリカバリ時間は5分未満でした。
EC2ベースのクラスタで110GBのデータを新しいブローカーノードにリビルドするのに10分かかったのに対し、NFSベースのクラスタでは3分でリカバリが完了しました。また、ログでは、EC2のパーティションのコンシューマオフセットが0であり、NFSクラスタではコンシューマオフセットが前のブローカーから取得されていることがわかりました。
[2022-10-31 09:39:17,747] INFO [LogLoader partition=test-topic-51R3EWs-0000-55, dir=/mnt/kafka-data/broker2] Reloading from producer snapshot and rebuilding producer state from offset 583999 (kafka.log.UnifiedLog$) [2022-10-31 08:55:55,170] INFO [LogLoader partition=test-topic-qbVsEZg-0000-8, dir=/mnt/data-1] Loading producer state till offset 0 with message format version 2 (kafka.log.UnifiedLog$)
DASベースのクラスタ
-
バックアップノードは08：55：53、730に開始されました。
-
データの再構築プロセスは09:05:24,860に終了しました。110GBのデータの処理には約10分かかります。
NFSベースのクラスタ
-
バックアップノードは09：39：17、213に開始されました。開始ログエントリは以下のように強調表示されます。
-
データの再構築プロセスは09:42:29,115に終了しました。110GBのデータの処理には約3分かかります。
このテストを、約1TBのデータを含むブローカーに対して繰り返しました。DASでは約48分、NFSでは約3分かかりました。結果を次のグラフに示します。
ストレージ効率
KafkaクラスタのストレージレイヤはNetApp ONTAP を介してプロビジョニングされていたため、ONTAP のすべてのStorage Efficiency機能を利用できました。このテストでは、Cloud Volumes ONTAP でNFSストレージをプロビジョニングしたKafkaクラスタで大量のデータを生成しました。ONTAP 機能により、スペースが大幅に削減されたことがわかりました。
アーキテクチャのセットアップ
次の表に、NASを使用するKafkaクラスタの環境構成を示します。
| プラットフォームコンポーネント | 環境の構成 |
|---|---|
Kafka 3.2.3. |
|
すべてのノード上のオペレーティングシステム |
RHEL8.7以降 |
NetApp Cloud Volumes ONTAP インスタンス |
シングルノードインスタンス–M5.2xLarge |
次の図は、NASベースのKafkaクラスタのアーキテクチャを示しています。
-
コンピューティング。 3ノードのKafkaクラスタを使用し、3ノードのZookeeperアンサンブルを専用サーバ上で実行しました。各ブローカーには、専用のLIFを介してNetApp CVOインスタンス上の単一のボリュームへのNFSマウントポイントが2つありました。
-
監視。 Prometheus-Grafanaの組み合わせには2つのノードを使用しました。ワークロードの生成には、独立した3ノードクラスタを使用し、このKafkaクラスタを生成して使用しました。
-
*ストレージ。*シングルノードのNetApp Cloud Volumes ONTAP インスタンスを使用し、250GB gp2 AWS-EBSボリュームを6個マウントしました。その後、これらのボリュームは、専用のLIFを介して6つのNFSボリュームとしてKafkaクラスタに公開されました。
-
*構成*このテストケースの構成要素はKafkaブローカーです。
プロデューサー側で圧縮がオフになっているため、プロデューサーは高いスループットを生成できます。Storage Efficiencyは、代わりにコンピューティングレイヤで処理されました。
テストの方法論
-
上記の仕様でKafkaクラスタがプロビジョニングされました。
-
クラスタでは、OpenMessaging Benchmarkingツールを使用して約350GBのデータが生成されました。
-
ワークロードの完了後、ONTAP System ManagerとCLIを使用してStorage Efficiencyの統計を収集しました。
観察
OMBツールを使用して生成したデータでは、ストレージ容量削減比率が1.70：1で約33%削減されました。次の図に示すように、生成されたデータに使用された論理スペースは420.3GB、データの保持に使用された物理スペースは281.7GBです。
