13.6. 最適化プロポーザルの概要
最適化プロポーザル は、パーティションのワークロードをブローカー間でより均等に分散することで、Kafka クラスターの負荷をより均等にするために提案された変更の概要です
各最適化プロポーザルは、それを生成するために使用された 最適化ゴール のセットに基づいており、ブローカーリソースに設定された 容量制限 が適用されます。
すべての最適化プロポーザルは、提案されたリバランスの影響の 見積もり です。提案は、承認または却下できます。最初に最適化プロポーザルを生成しなければに、クラスターのリバランスは承認できません。
以下のエンドポイントのいずれかを使用して最適化プロポーザルを実行できます。
-
/rebalance -
/add_broker -
/remove_broker
13.6.1. エンドポイントのリバランス
最適化プロポーザルを生成するために POST 要求を送信するときに、リバランスエンドポイントを指定します。
/rebalance-
/rebalanceエンドポイントは、クラスター内のすべてのブローカーにレプリカを移動して完全なリバランスを実行します。 /add_broker-
add_brokerエンドポイントは、1 つ以上のブローカーを追加することで、Kafka クラスターのスケールアップ後に使用されます。通常、Kafka クラスターをスケールアップした後、新しいブローカーは、新しく作成されたトピックのパーティションのみをホストするために使用されます。新しいトピックが作成されないと、新たに追加されたブローカーは使用されず、既存のブローカーは同じ負荷のままになります。ブローカーをクラスターに追加してすぐにadd_brokerエンドポイントを使用すると、リバランス操作はレプリカを既存のブローカーから新たに追加されたブローカーに移動します。POST 要求で、新しいブローカーをbrokeridリストとして指定します。 /remove_broker-
/remove_brokerエンドポイントは、1 つ以上のブローカーを削除して Kafka クラスターをスケールダウンする前に使用されます。Kafka クラスターをスケールダウンすると、レプリカをホストする場合でもブローカーはシャットダウンされます。これにより、レプリケートが不十分なパーティションとなる可能性があり、一部のパーティションが最小 In-Sync レプリカ (ISR) を下回る可能性があります。この問題を回避するため、/remove_brokerエンドポイントは、削除予定のブローカーからレプリカを移動します。これらのブローカーがレプリカをホストしなくなった場合は、スケールダウン操作を安全に実行できます。POST 要求で、削除するブローカーをbrokeridリストとして指定します。
通常、/rebalance エンドポイントを使用して、ブローカー間で負荷を分散し、Kafka クラスターをリバランスします。/add-broker エンドポイントと /remove_broker エンドポイントは、クラスターをスケールアップまたはスケールダウンし、それに応じてレプリカを再調整する場合にのみ使用してください。
結局のところ、リバランスを実行する手順は、3 つの異なるエンドポイント間で同じとなります。唯一の違いは、要求に追加されたブローカーや、要求から削除されるブローカーのリスト表示のみです。
13.6.2. 最適化プロポーザルの承認または拒否
最適化プロポーザルのサマリーは、提案された変更の範囲を示しています。サマリーは、Cruise Control API を介した HTTP リクエストへの応答で返されます。
/rebalance エンドポイントに POST リクエストを行うと、最適化プロポーザルのサマリーがレスポンスで返されます。
最適化プロポーザルの要約を返す方法
curl -v -X POST 'cruise-control-server:9090/kafkacruisecontrol/rebalance'
サマリーを使用して、最適化プロポーザルを承認するか拒否するかを決定します。
- 最適化プロポーザルの承認
-
/rebalanceエンドポイントに POST リクエストを送信し、dryrunパラメーターをfalse(デフォルトはtrue) に設定して、最適化のプロポーザルを承認します。Cruise Control は、プロポーザルを Kafka クラスターに適用し、クラスターのリバランス操作を開始します。 - 最適化プロポーザルの拒否
-
最適化プロポーザルを承認しないことを選択した場合は、最適化ゴールの変更 または 任意のリバランスパフォーマンスチューニングオプションの更新 を行い、その後で別のプロポーザルを生成できます。
dryrunパラメーターなしでリクエストを再送信して、新しい最適化プロポーザルを生成できます。
最適化プロポーザルを使用して、リバランスに必要な動作を評価します。たとえば、要約ではブローカー間およびブローカー内の動きについて記述します。ブローカー間のリバランスは、別々のブローカー間でデータを移動します。JBOD ストレージ設定を使用していると、ブローカー内のリバランスでは同じブローカー上のディスク間でデータが移動します。このような情報は、プロポーザルを承認しない場合でも有用な場合があります。
リバランスの際には Kafka クラスターに追加の負荷がかかるため、最適化プロポーザルを却下したり、承認を遅らせたりする場合があります。
次の例では、プロポーザルは別々のブローカー間のデータのリバランスを提案しています。リバランスには、ブローカー間での 55 個のパーティションレプリカ (合計 12 MB のデータ) の移動が含まれます。パーティションレプリカのブローカー間の移動は、パフォーマンスに大きな影響を与えますが、データ総量はそれほど多くありません。合計データが膨大な場合は、プロポーザルを却下するか、リバランスを承認するタイミングを考慮して Kafka クラスターのパフォーマンスへの影響を制限できます。
リバランスパフォーマンスチューニングオプションは、データ移動の影響を減らすのに有用です。リバランス期間を延長できる場合は、リバランスをより小さなバッチに分割できます。一回のデータ移動が少なくなると、クラスターの負荷も軽減できます。
最適化プロポーザルサマリーの例
Optimization has 55 inter-broker replica (12 MB) moves, 0 intra-broker replica (0 MB) moves and 24 leadership moves with a cluster model of 5 recent windows and 100.000% of the partitions covered. Excluded Topics: []. Excluded Brokers For Leadership: []. Excluded Brokers For Replica Move: []. Counts: 3 brokers 343 replicas 7 topics. On-demand Balancedness Score Before (78.012) After (82.912). Provision Status: RIGHT_SIZED.
このプロポーザルでは、24 のパーティションリーダーも別のブローカーに移動します。これによるパフォーマンスへの影響はほとんどありません。
バランススコアは、最適化プロポーザルが承認される前後の Kafka クラスターの全体的なバランスの測定値です。バランススコアは、最適化ゴールに基づいています。すべてのゴールが満たされていると、スコアは 100 になります。達成されないゴールごとにスコアが減少します。バランススコアを比較して、Kafka クラスターのバランスがリバランス後よりも悪いかどうかを確認します。
provision ステータスは、現在のクラスター設定が最適化ゴールをサポートするかどうかを示します。プロビジョニングステータスを確認し、ブローカーを追加または削除する必要があるかどうかを確認します。
| Status | 説明 |
|---|---|
| RIGHT_SIZED | クラスターには、最適化ゴールを満たす適切な数のブローカーがあります。 |
| UNDER_PROVISIONED | クラスターはプロビジョニングされておらず、最適化ゴールに対応するために追加のブローカーが必要になります。 |
| OVER_PROVISIONED | クラスターはオーバープロビジョニングされており、最適化ゴールを満たすためにブローカーの数を減らします。 |
| UNDECIDED | ステータスは関連性がなく、まだ決定されていません。 |
13.6.3. 最適化プロポーザルサマリーのプロパティー
以下の表は、最適化プロポーザルに含まれるプロパティーを表しています。
| プロパティー | 説明 |
|---|---|
|
|
リバランス操作中のパフォーマンスへの影響度: 比較的高い。
リバランス操作中のパフォーマンスへの影響度: 場合による。MB の数が大きいほど、クラスターのリバランスの完了にかかる時間が長くなります。 |
|
|
リバランス操作中のパフォーマンスへの影響度: 比較的高いが、
リバランス操作中のパフォーマンスへの影響度: 場合による。値が大きいほど、クラスターのリバランスの完了にかかる時間が長くなります。大量のデータを移動する場合は、同じブローカーのディスク間で移動する方が個別のブローカー間で移動するよりも影響度が低くなります ( |
|
| 最適化プロポーザルのパーティションレプリカ/リーダーの移動の計算から除外されたトピックの数。 以下のいずれかの方法で、トピックを除外することができます。
正規表現と一致するトピックが応答にリスト表示され、クラスターのリバランスから除外されます。 |
|
|
リバランス操作中のパフォーマンスへの影響度: 比較的低い。 |
|
|
|
|
|
|
|
| Kafka クラスターの全体的なバランスの測定。
Cruise Control は、複数の要因を基にして
|
13.6.4. キャッシュされた最適化プロポーザル
Cruise Control は、設定済みの デフォルトの最適化ゴール を基にした キャッシュされた最適化プロポーザル を維持します。キャッシュされた最適化プロポーザルはワークロードモデルから生成され、Kafka クラスターの現在の状況を反映するために 15 分ごとに更新されます。
以下のゴール設定が使用される場合に、キャッシュされた最新の最適化プロポーザルが返されます。
- デフォルトの最適化ゴール
- 現在キャッシュされているプロポーザルで達成できるユーザー提供の最適化ゴール
キャッシュされた最適化プロポーザルの更新間隔を変更するには、Cruise Control デプロイメント設定の cruisecontrol.properties ファイルの proposal.expiration.ms 設定を編集します。更新間隔を短くすると、Cruise Control サーバーの負荷が増えますが、変更が頻繁に行われるクラスターでは、更新間隔を短くするよう考慮してください。
