Apache Kafka のベンチマーク: 価格に対するパフォーマンス

この記事では、Apache Kafka の環境を比較する調査を紹介します。最終的な目標は、最も効果的なセットアップを見つけて、最高の価格性能比を実現することです。

当社のデータ プラットフォームは、大規模なデータ セットの分析プラットフォームを構築するためのマネージド サービスを提供しており、他の市場ソリューションと競合しています。競争力を維持するために、当社は定期的に社内調査を実施して強みを特定し、改善することで、より良い取引を実現しています。この記事では、そのような調査の 1 つを紹介します。現在、当社のプラットフォームは、クラウド プロバイダーとして AWS と GCP をサポートしています。どちらも、複数のコンピューティング世代と 2 つの CPU アーキテクチャ (Intel と AMD の x86、および ARM) を提供しています。さまざまな Java 仮想マシン (JVM) を使用してこれらのセットアップを比較し、新しいプロセッサでの新しいバージョンのパフォーマンスを評価します。

TL;DR を知りたい場合: ARM は素晴らしいです。最新の高価なアーキテクチャが必ずしも「優れている」とは限りません。結果に直接ジャンプするか、方法論とセットアップについてさらに詳しく調べるために進んでください。

方法論

自社のサービスでパフォーマンスをテストすることも考えましたが、まだサポートしていないさまざまな環境で比較したいと考えました。新しい仮想マシン、リージョン、さらには他のクラウド プロバイダーもチェックしたいと考えました。そこで、ベースライン Kafka とさまざまなベース コンテナー イメージを使用するトイ プロジェクトを実装することから始めました。この方法では、特定のハードウェアでベンチマーク ツールを実行し、パフォーマンスを測定できます。

さまざまな構成をテストして、最も興味深い結果を特定することを目指しています。そのために、テスト マトリックスの考え方を使用して、最初の調査結果をフィルターします。perf や eBPF などのツールを使用してこれらの調査結果を詳細に分析し、パフォーマンスをさらに改善します。

テストケース

まず、テストの目的について説明しましょう。私は OpenJDK JVM の経験が豊富です。しかし、現在では Microsoft、Amazon、その他の企業から多くの代替品が提供されています。たとえば、Amazon Correto には AWS に最適化された追加機能とパッチが含まれています。当社のほとんどの顧客が AWS を使用しているため、これらの JVM がそのプラットフォームでどのように動作するかを確認するために、Amazon Correto をテストに含めたいと考えました。

最初の比較では次のバージョンを選択しました。

• OpenJDK 11 (古いものですが、過去の比較用です)
• OpenJDK 17 (現在使用されている JVM)
• Amazon Coretto 11.0.22-amzn (代替の遡及比較)
• Amazon Coretto 17.0.10-amzn (現在のバージョンの代替)
• Amazon Coretto 21.0.2-amzn (より優れた新しい LTS バージョン)

バージョンが定義されたら、 Amazon CorretoとOpenJDKを使用して Kafka イメージを構築するためのスクリプトをいくつか準備しました。

画像設定

ベンチマーク テストでは、特定のパフォーマンス メトリックに焦点を当てるために Kafka 設定を変更しました。 [JVM] x [instance_type] x [architecture] x [cloud_provider]のさまざまな組み合わせをテストしたかったので、ネットワーク接続とディスク パフォーマンスの影響を最小限に抑えることが重要でした。データ ストレージに tmpfs を使用してコンテナーを実行することでこれを実現しました。

 podman run -ti \ --network=host \ --mount type=tmpfs,destination=/tmp \ kfbench:3.6.1-21.0.2-amzn-arm64

当然ながら、このセットアップは本番環境向けではありませんが、CPU とメモリのボトルネックを分離する必要がありました。最善の方法は、テストからネットワークとディスクの影響を取り除くことです。そうしないと、これらの要因によって結果が歪んでしまいます。

最小限のレイテンシと高い再現性を確保するために、同じインスタンスでベンチマーク ツールを使用しました。また、ホスト ネットワーク構成なし、および cgroup 分離仮想ネットワークを使用したテストも試しましたが、これらは不要なレイテンシを追加し、パケット転送の CPU 使用率を増加させるだけでした。

tmpfs はメモリを動的に割り当てるため、断片化や遅延が発生する可能性がありますが、私たちのテストには十分でした。代わりに、メモリを静的に割り当ててこれらの問題を回避できる ramdisk を使用することもできましたが、tmpfs の方が実装が簡単で、求めていた洞察が得られました。私たちの目的にとって、tmpfs は適切なバランスを実現しました。

さらに、メモリからデータをより頻繁に削除するために、いくつかの追加の Kafka 設定を適用しました。

 ############################# Benchmark Options ############################# # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.bytes # Chaged from 1GB to 256MB to rotate files faster log.segment.bytes = 268435456 # https://kafka.apache.org/documentation/#brokerconfigs_log.retention.bytes # Changed from -1 (unlimited) to 1GB evict them because we run in tmpfs log.retention.bytes = 1073741824 # Changed from 5 minutes (300000ms) to delete outdated data faster log.retention.check.interval.ms=1000 # Evict all data after 15 seconds (default is -1 and log.retention.hours=168 which is ~7 days) log.retention.ms=15000 # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.delete.delay.ms # Changed from 60 seconds delay to small value to prevent memory overflows log.segment.delete.delay.ms = 0

変更点の概要は次のとおりです。

• ログの保持時間は、データをより速く削除するために 15 秒に設定され、tmpfs のストレージを管理するためにログの保持サイズは1 GB に制限されています。ログのセグメント サイズも、ファイルをより速くローテーションするために 256 MB に変更されています。
• 保持チェック間隔を1秒に短縮し、古いデータを素早く削除します。
• メモリの問題を防ぐためにセグメント削除遅延は0に設定されます

この構成は本番環境での使用には適していませんが、無関係な要因の影響を軽減するため、ベンチマーク テストには重要です。

インスタンスタイプ

DoubleCloud では、この記事の執筆時点で、次の主要な世代のコンピューティング リソースをサポートしています。

• s1 ファミリー: m5a インスタンス (i1 は Intel プロセッサを搭載した m5 を表します)
• s2 ファミリー: m6a インスタンス (i2 は Intel プロセッサを搭載した m6i を表します)
• sg1 ファミリー: AMD Rome プロセッサを搭載した GCP n2 標準インスタンス

Graviton プロセッサについては、以下をサポートしています。

• g1 ファミリー: m6g インスタンス (Graviton 2)
• g2 ファミリー: m7g インスタンス (Graviton 3)

さらに、Ampere Altra の Graviton の代替として、GCP の t2a インスタンスをテストしました。AWS の地域サポートが限られているため、お客様には提供していませんが、パフォーマンスを比較するためにベンチマークに含めました。「適切な」地域のいずれかにいる場合は、これが良い選択肢になるかもしれません。

ベンチマークツール

ベンチマークのために、 franz-go ライブラリと例に基づいた軽量ツールを開発しました。このツールは、ボトルネックになることなく、Kafka を効率的に飽和させます。

librdkafka は信頼性と人気があることで知られていますが、cgo の潜在的な問題のため、私はこれを避けました。

テスト

Kafka はスケーラビリティに優れていることでよく知られており、トピックを複数のパーティションに分割して、ワークロードをブローカー間で効率的に水平に分散できます。ただし、パフォーマンスと価格の比率に特に焦点を当てているため、私はシングルコアのパフォーマンスの評価に集中しました。

したがって、テストでは、個々のコア機能を最大限に活用するために、単一パーティションのトピックを使用しました。

各テスト ケースには次の 2 つのタイプが含まれます。

• 同期生成: メッセージの確認を待ちます。リアルタイムアプリケーションなど、ミリ秒が重要となる低遅延環境の測定に最適です。
• 非同期プロデュース: メッセージをバッファリングしてバッチで送信します。これは、ほぼリアルタイムのニーズと 10 ～ 100 ミリ秒の許容可能な遅延のバランスをとる Kafka クライアントに典型的です。

トピック パーティション スレッドを完全に飽和させるために、平均的な顧客ケースよりも大きい 8 KB のメッセージを使用しました。

結果

さまざまなアーキテクチャを評価するために合成効率メトリックを使用して、さまざまなテスト ケースを比較する一連のグラフを紹介します。このメトリックは、Kafka ブローカーに取り込むことができる数百万行をパーセントで定量化し、アーキテクチャのコスト効率を簡単に評価できます。

クラウド プロバイダーの追加割引により、実際の結果が異なる場合があることを認識することが重要です。可能な限り、両方のクラウド プロバイダーのテストはフランクフルトで実施されました (インスタンス タイプのオプションが制限されている場合はオランダで実施されました)。

チャート

すべてのチャートで、インスタンスにはプロバイダーが使用するのと同じ慣例の名前を使用します。インスタンスは、最初にクラウド プロバイダー (AWS、次に GCP) 別に並べ替えられ、次に世代別 (古いものから新しいものへ) に並べ替えられます。

完全な結果は、生の形式ではありますが、私の包括的なベンチマーク シートでご覧いただけます。そこには、レイテンシや帯域幅の数値、さまざまな JVM の比較パフォーマンスなど、この記事で紹介した以上のデータが掲載されています。

AWSの調査結果

s1ファミリー: 最も遅いパフォーマンス

2019 年第 3 四半期に遡る AMD EPYC 7571 を搭載した m5a 世代に基づく「第 1 世代」s1 インスタンスは、当社のレガシー オプションです。これらは、フランクフルトのオプションの中で最も効率が低く、最も遅く、オンデマンドで約 0.2080 ユーロ/時間のコストがかかります。約 0.2070 ユーロ/時間の新しい s2 ファミリーに移行すると、基本的に同じ価格で 2 倍の効率が得られます。分析アプリケーションのクエリ時間と取り込み速度を向上させるために、これらのよりコスト効率が高くパフォーマンスの高いオプションに移行することをお客様にお勧めします。

g1ファミリー: s2と同等の効率

g1 ファミリーは Graviton 2 をベースとしており、これまで優れた価値を提供してきましたが、AMD プロセッサを搭載した新しい s2 ファミリーは、Apache Kafka の効率レベルに匹敵するようになりました。帯域幅がわずかに低く、価格面でわずかな優位性があるにもかかわらず、g1 ファミリーは新しいオプションと比較すると時代遅れと見なされています。

g2ファミリー: 優れた効率

Graviton 3 を搭載した g2 ファミリーは、その優れた効率性から、私たちの一番の推奨製品として際立っています。特定のシナリオでは s2 および i2 ファミリーより最大 39% もパフォーマンスが優れており、ほぼすべてのリージョンでコスト効率の高いソリューションを提供するため、ほとんどの Apache Kafka ユースケースに最適です。Kafka の典型的な IO バウンドの性質を考えると、計算効率を最適化することはコスト削減にとって非常に重要です。arm64 アーキテクチャを採用する傾向が高まっており、当社のクラスターのほぼ半数がすでにこの新しいテクノロジーを活用しています。

x86_64 効率トレンド

テストでは、新しい AMD または Intel プロセッサは、全体的なスループットとレイテンシの点ですべて改善していることが示されています。それにもかかわらず、新しい m6 および m7 世代の効率性の向上は頭打ちになっています。m7 世代でさえ、一部の領域ではレイテンシが低くなる可能性がありますが、私たちのテストによると、g2 ファミリーと比較すると効率性は劣っています。

m7aファミリー: 優れたレイテンシー性能

m7a ファミリーは低レイテンシ アプリケーションに優れており、スループットとレイテンシの点で Intel と以前の AMD 世代の両方を上回っています。このアーキテクチャは、どこでも利用できるわけではありませんが、パフォーマンスの向上における AMD の進歩を反映しています。お住まいの地域で利用できる場合は、優れた結果を得るために m7a を検討してください。

GCPの調査結果

AWSとの効率比較

GCP インスタンスは、一般的に AWS のインスタンスに比べて効率性が低くなります。これは私にとって大きな洞察でした。顧客は通常、分析アプリケーションでのコスト効率の良さから GCP を好み、その結果、請求額が低くなるからです。当社の sg1 ファミリーは、AWS s2 ファミリーに匹敵する n2 標準世代を使用しています。ただし、この比較を他のインスタンス タイプに拡張しようとした私の試みは、特に c3 および n2 世代については、リージョンの可用性によって制約を受けました。

Arm Tauプロセッサ：コスト効率

GCP の Tau プロセッサを使用する Arm インスタンスは、Graviton 2 に比べて 5～7% の効率向上を実現しており、お住まいの地域で利用可能な場合は、合理的なコスト削減オプションとなります。GCP による Arm インスタンスのサポートは 4 つのリージョンに限定されていますが、g1 ファミリーと同等のパフォーマンスと効率を提供します。

継続利用割引

Apache Kafka クラスターでは VM が継続的に使用されるため、継続使用割引を利用すると最大 20% の割引が受けられます。これにより、Ampere Altra などの古い計算能力でも、効率の点で Graviton 3 と競合できるようになります。ただし、追加の AWS 割引が適用される場合もあるため、直接比較するのは困難です。

JVMの洞察

ARM アーキテクチャ上の新しい JVM バージョンでは大幅な改善が見られるだろうと思っていました。しかし、openjdk-11 と corretto-11 はすでに ARM 向けに最適化されているようです。Kafka の新しいバージョンには Java 17 以上が必要なので、Java 17 に切り替えたところ、ベンチマークで約 4 ～ 8% のパフォーマンス向上が得られました。

さらに、21.0.2-amzn は有望で、新しいインスタンス タイプでさらに 10 ～ 20% のパフォーマンス向上を実現します。

結論

私は時々、社内調査を行って、生産クラスターに最適なソリューションを見つけ、有用な洞察を集めています。ARM アーキテクチャへの移行は、コストを節約し、エネルギー使用量を削減するため、マネージド サービスにとって有利です。

ARM を利用することで、Apache Kafka 向けマネージド サービスと ClickHouse 向けマネージド サービスの両方のパフォーマンスとコスト効率が向上し、すでにメリットがあることが証明されています。この調査により、テスト マトリックスが改良され、最も効率的な環境とさらなる最適化が必要な領域が特定されました。私たちは常に、内部で微調整と改良を行っており、コミュニティと知識を共有できることを嬉しく思っています。お楽しみに!