パフォーマンスおよびリソース使用量テストの結果

複数のパフォーマンスストレステストを実行し、多様なユースケースに対応しての Self-Balancing の効率性、時間およびリソースの使用量が決定されています。Self-Balancing コードが実行されるノードである Kafka コントローラーノードのプロファイルは、こうしたテストによって作成されています。

次のような一般的なユースケースにおけるパフォーマンステストの結果を大まかに要約し、以下に示します。

  • クラスターの拡張
  • クラスターの縮小
  • 新コントローラー(リードブローカー)へのフェイルオーバー

ブローカーの追加よる、パーティションが多数ある小さなクラスターの拡張

5 ブローカーのクラスターで多数のレプリカやパーティションをテストし、クラスターを拡張することで、Self-Balancing で自動的にブローカーをクラスターに追加し、すべてのノードにパーティションを再配分することを検証することが目的です。

テストの説明

このテストでは、"ブローカーの追加" 処理(5 ブローカーのクラスターを段階的に 8 ブローカーに拡張)用のバランス調整計画を生成するときの影響をチェックします。計画が算出され送信されると、Self-Balancing はバッチ処理でパーティションを調整し、再割り当てを行います。このテストでは再割り当てが完了し、8 つすべてのブローカーでワークロードが均等に配分された、バランスのとれたクラスターになったことを確認します。

クラスターの構成

  • 5 ブローカー(AWS でのプログレッシブテストで 8 ブローカーに拡張)
  • 9 万レプリカ(3 万パーティション)
  • t2.2xlarge マシン
  • 5 トピック(6000 パーティション、レプリケーション係数 3)

パフォーマンスの結果

  • Telemetry Reporter のメトリクスの収集では、バランス調整中(ブローカーの追加によるクラスターの拡張)の CPU 使用率が 10% 未満に抑えられています。
  • Self-Balancing では、平均で 1 分余り(78 秒)かけてアルゴリズムを生成し、"ブローカーの追加" 計画を算出します。

多くのパーティションがある大規模クラスターのスケーラビリティテスト

クラスターの拡張と縮小を実行して、ブローカーごとに最大 1000 個のレプリカがある 40 ブローカーのクラスター(ハイエンド)上で、Self-Balancing のスケーラビリティをテストすることが目的です。

テストの説明

このテストでは、クラスターを 39 ブローカーからレプリカが 21,600 の 48 ブローカーに拡張する "ブローカーの追加" 処理に対して、バランス調整計画を生成するときの影響を評価します。

続いてブローカーごとのレプリカを 2250 個(48 ブローカーで 108,000 個)に増やし、クラスターを縮小する "ブローカーの削除" 処理に対する計画の生成の影響をチェックします。

クラスターの構成

  • 39 ブローカー、プログレッシブテストで 48 ブローカーに拡張
  • 最大 10 MB の、ブローカーごとの受信トラフィック
  • "ブローカーの追加" テストでは 39 ブローカーの 21,600 レプリカ、"ブローカーの削除" テストでは 48 ブローカーの 108,000 レプリカ(2250 レプリカごと)で開始
  • r5.xlarge マシン
  • 4 トピック、1800 パーティションとレプリケーション係数 3(21,600 レプリカ)で開始

パフォーマンスの結果

  • "ブローカーの追加" のパフォーマンスの結果は、他のテストの結果と同様であるため、ここでは省略します。
  • "ブローカーの削除" 処理でのメトリクス収集の CPU 使用率は、平均 1 ~ 3% 程度で、多くの処理(レプリカの再割り当てを除く)は 60 秒以内に完了します。
  • Self-Balancing による定期的なメトリクスサンプリングでの CPU 使用率は、10% 未満に最適化されています。メトリクスサンプリングは Self-Balancing で metric.sampling.interval.ms の構成内容(たとえば、3 分ごと)に従って、定期的に実行されます。通常のクラスターワークロードでは、プロデューサーのスループットは 365 MB/秒で、コンシューマーのスループットは 250 MB/秒です。
  • Self-Balancing では、平均で 10 秒かけてアルゴリズムを生成し、"ブローカーの削除" 計画を算出します。

コントローラーの定期的な再生

このテストの目的は、コントローラーが失われたときに、Kafka により効率的にフェイルオーバーが実行され、新しいコントローラーが Self-Balancing のコントローラーの起動で中断されることなく割り当てられることを検証することです。

テストの説明

このテストでは、Kafka コントローラーを複数回削除し、コントローラーセットアップでの Self-Balancing のフェイルオーバーの影響を判定します。

Self-Balancing は Kafka コントローラーと同じノードで動作します。したがって、コントローラーのフェイルオーバーは Self-Balancing のフェイルオーバーもトリガーします。つまり、コントローラーのスタートアップコードと同時に、Self-Balancing のスタートアップコードが実行されます。

クラスターの構成

  • 8 ブローカー
  • 9 万レプリカ(3 万パーティション)
  • t2.2xlarge マシン
  • 5 トピック(6000 パーティション、レプリケーション係数 3)

パフォーマンスの結果

  • コントローラーのフェイルオーバーによる CPU 使用率は平均で 4.5% です。
  • フェイルオーバーイベントを受信した後、Self-Balancing は 2 秒かけてスタートアップチェックを完了し、新しいコントローラーで準備状態になります。
  • これらの結果は、Self-Balancing のフェイルオーバーが、多数のパーティションがあるコントローラーのセットアップに過剰な負荷をかけていないことを示しています。