TR-4947: NetApp NFSストレージを使用したApache Kafkaワークロード - 機能検証とパフォーマンス
Shantanu Chakole、Karthikeyan Nagalingam、Joe Scott、 NetApp
Kafka は、大量のメッセージ データを受け入れることができる堅牢なキューを備えた分散型のパブリッシュ/サブスクライブ メッセージング システムです。 Kafka を使用すると、アプリケーションはトピックに非常に高速にデータを書き込んだり読み取ったりできます。 Kafka は、そのフォールト トレランスとスケーラビリティにより、多数のデータ ストリームを非常に高速に取り込んで移動する信頼性の高い方法として、ビッグ データ分野でよく使用されます。ユースケースには、ストリーム処理、Web サイト アクティビティの追跡、メトリックの収集と監視、ログの集約、リアルタイム分析などがあります。
NFS 上の通常の Kafka 操作は正常に動作しますが、NFS 上で実行されている Kafka クラスターのサイズ変更または再パーティション化中に、名前変更の問題によりアプリケーションがクラッシュします。負荷分散やメンテナンスの目的で Kafka クラスターのサイズを変更したり、再パーティション化したりする必要があるため、これは重大な問題です。詳細は以下をご覧ください "ここをクリックしてください。"。
このドキュメントでは、次の内容について説明します。
-
馬鹿げた名前変更問題と解決策の検証
-
CPU使用率を減らしてI/O待機時間を短縮する
-
Kafkaブローカーの回復時間の短縮
-
クラウドとオンプレミスでのパフォーマンス
Kafka ワークロードに NFS ストレージを使用する理由は何ですか?
実稼働アプリケーションの Kafka ワークロードは、アプリケーション間で膨大な量のデータをストリーミングできます。このデータは、Kafka クラスター内の Kafka ブローカー ノードに保持され、保存されます。 Kafka は可用性と並列性でも知られており、トピックをパーティションに分割し、それらのパーティションをクラスター全体に複製することでこれを実現します。これは、最終的に、Kafka クラスターを流れる膨大な量のデータのサイズが通常倍増することを意味します。 NFS を使用すると、ブローカーの数の変化に応じてデータの再バランスが非常に迅速かつ簡単に行えます。大規模な環境では、ブローカーの数が変更されたときに DAS 間でデータを再調整するのは非常に時間がかかり、ほとんどの Kafka 環境ではブローカーの数は頻繁に変更されます。
その他の利点は次のとおりです。
-
成熟。 NFS は成熟したプロトコルであり、その実装、セキュリティ保護、および使用のほとんどの側面が十分に理解されていることを意味します。
-
開ける。 NFS はオープン プロトコルであり、その継続的な開発は、無料かつオープンなネットワーク プロトコルとしてインターネット仕様に文書化されています。
-
コスト効率が良い。 NFS は、既存のネットワーク インフラストラクチャを使用するためセットアップが簡単な、低コストのネットワーク ファイル共有ソリューションです。
-
集中管理 NFS を集中管理することで、個々のユーザー システムに追加のソフトウェアやディスク領域が必要になることが減ります。
-
配布済み NFS は分散ファイル システムとして使用できるため、リムーバブル メディア ストレージ デバイスの必要性が軽減されます。
Kafka ワークロードにNetApp を選ぶ理由
NetApp NFS 実装はプロトコルのゴールド スタンダードとみなされており、数え切れないほどのエンタープライズ NAS 環境で使用されています。NetAppの信頼性に加えて、次のような利点もあります。
-
信頼性と効率性
-
スケーラビリティとパフォーマンス
-
高可用性( NetApp ONTAPクラスタの HA パートナー)
-
データ保護
-
*災害復旧 (NetApp SnapMirror)*サイトがダウンした場合、または別のサイトで再開して中断したところから続行する必要がある場合。
-
ストレージ システムの管理性 ( NetApp OnCommandを使用した管理)。
-
*負荷分散*クラスターを使用すると、異なるノードでホストされているデータ LIF から異なるボリュームにアクセスできます。
-
中断のない運用。 LIF またはボリュームの移動は NFS クライアントに対して透過的です。
-