第15章 Cruise Control を使用したクラスターのリバランス

サポートされているゴールは事前に定義されており、Cruise Control 最適化プロポーザルの生成に使用できます。サポートされているゴールとしてリストされていないゴールは、Cruise Control 操作では使用できません。サポートされているゴールの一部は、ハードゴールとして事前設定されています。

cruisecontrol.properties でサポートされているゴールを設定します。

最適化プロポーザルを生成するには、ハードゴールを満たす必要があります。ソフトゴールは、すべてのハードゴールが満たされた後に Cruise Control が達成しようとするベストエフォートゴールです。ハードゴールとソフトゴールの分類は、Cruise Control コードで固定されており、変更できません。

Cruise Control は、まずハードゴールの達成を優先し、次にリストされている順序に従ってソフトゴールに取り組みます。すべてのハードゴールを満たすプロポーザルは、たとえソフトゴールの一部に違反していたとしても有効です。

たとえば、ソフトゴールとしては、トピックのレプリカを均等に分散することが考えられます。Cruise Control は、ソフトゴールが完全に満たされていない場合でも、最適化プロポーザルを生成し続けます。

cruisecontrol.properties でハードゴールを設定します。

ハードゴールの数を増やすと、Cruise Control が最適化プロポーザルを生成する可能性が低くなります。

Cruise Control はデフォルトゴールを使用して最適化プロポーザルを生成します。デフォルトゴールは、サポートされている最適化ゴールのサブセットにする必要があります。

このサポートされているゴールリストに基づく最適化プロポーザルがその後生成され、キャッシュされます。

cruisecontrol.properties でデフォルトゴールを設定します。

Cruise Control はブローカー内ゴールを使用して、同じブローカー上のディスク間でデータのバランスを取ります。これは、JBOD ストレージと複数のディスクを使用したデプロイメントに役立ちます。

cruisecontrol.properties でブローカー内ゴールを設定します。

プロポーザル固有の最適化ゴールは、特定のゴールリストに基づいた最適化プロポーザルの作成をサポートします。プロポーザル固有のゴールが設定されていない場合は、デフォルトのゴールが使用されます。

カスタマイズ用にサポートされている最適化ゴールのサブセットとして、実行時にプロポーザル固有のゴールを指定します。

たとえば、単一のプロポーザル固有のゴールを定義することで、ディスク容量や使用率を考慮せずに、Kafka クラスター全体でトピックリーダーレプリカの分散を最適化できます。

プロポーザル固有のゴールを指定するときは、設定されているすべてのハードゴールを含めてください。そうしないと、エラーが発生します。

最適化プロポーザルの設定済みのハードゴールを無視するには、skip_hard_goals_check=true パラメーターをリクエストに追加します。

設定を変更しない限り、Streams for Apache Kafka は Cruise Control からゴールを継承します。

次のリストは、Streams for Apache Kafka が Cruise Control から継承したサポートされているゴールを、優先順位の降順で示しています。ハードとラベル付けされたゴールは、最適化プロポーザルのために満たす必要がある必須の制約です。

リソース配分ゴールは、ブローカーリソースの 容量制限 の影響を受けます。

各最適化ゴールの詳細は、Cruise Control Wiki の Goals を参照してください。

default.goals=com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.CpuCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaDistributionGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.PotentialNwOutGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskUsageDistributionGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundUsageDistributionGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundUsageDistributionGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.CpuUsageDistributionGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.TopicReplicaDistributionGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.LeaderReplicaDistributionGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.LeaderBytesInDistributionGoal

hard.goals=com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.CpuCapacityGoal

default.goals=com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.CpuCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaDistributionGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.PotentialNwOutGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskUsageDistributionGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundUsageDistributionGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundUsageDistributionGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.CpuUsageDistributionGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.TopicReplicaDistributionGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.LeaderReplicaDistributionGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.LeaderBytesInDistributionGoal

hard.goals=com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal,com.linkedin.kafka.cruisecontrol.analyzer.goals.CpuCapacityGoal

curl -v -X POST 'http://<cc_host>:<cc_port>/kafkacruisecontrol/rebalance?goals=RackAwareGoal,ReplicaCapacityGoal,ReplicaDistributionGoal&skip_hard_goal_check=true'

curl -v -X POST 'http://<cc_host>:<cc_port>/kafkacruisecontrol/rebalance?goals=RackAwareGoal,ReplicaCapacityGoal,ReplicaDistributionGoal&skip_hard_goal_check=true'

リクエストで skip_hard_goals_check=true が指定されている場合、Cruise Control は、プロポーザル固有のゴールに設定されたすべてのハードゴールが含まれているかどうかを確認しません。これにより、最適化プロポーザルを生成する際の柔軟性が向上しますが、すべてのハードゴールを満たさないプロポーザルにつながる可能性があります。

ただし、skip_hard_goals_check=true の場合でも、プロポーザル固有のゴールに含まれるハードゴールは、Cruise Control にハードゴールとして扱われます。

リバランスのプロポーザルは、3 つのエンドポイントのいずれかにリクエストを送信して生成できます。

通常、full リバランスエンドポイントを使用して、ブローカー間で負荷を分散し、Kafka クラスターをリバランスします。add_broker エンドポイントと remove_broker エンドポイントは、クラスターをスケールアップまたはスケールダウンし、それに応じてレプリカをリバランスする場合にのみ使用してください。

結局のところ、リバランスを実行する手順は、3 つの異なるエンドポイント間で同じとなります。唯一の違いは、リクエストでエンドポイントを指定することと、必要に応じて追加されたブローカーまたは削除されるブローカーをリストすることです。

最適化プロポーザルが生成されると、変更の概要が返されます。

サマリーは、Cruise Control API を介した HTTP リクエストへの応答で返されます。サマリーは、プロポーザルされたクラスターリバランスの概要を提供し、関係する変更の規模を示します。提供される情報は完全な最適化プロポーザルのサマリーになります。

最適化プロポーザルのサマリーは、プロポーザルされた変更の範囲を示しています。

/rebalance エンドポイントに POST リクエストを行うと、最適化プロポーザルのサマリーがレスポンスで返されます。

curl -v -X POST 'http://<cc_host>:<cc_port>/kafkacruisecontrol/rebalance'

curl -v -X POST 'http://<cc_host>:<cc_port>/kafkacruisecontrol/rebalance'

サマリーを使用して、最適化プロポーザルを承認するか拒否するかを決定します。

最適化プロポーザルを使用して、リバランスに必要な動作を評価します。たとえば、サマリーではブローカー間およびブローカー内の動きを記述します。ブローカー間のリバランスは、別々のブローカー間でデータを移動します。JBOD ストレージ設定を使用していると、ブローカー内のリバランスでは同じブローカー上のディスク間でデータが移動します。このような情報は、プロポーザルを承認しない場合でも有用な場合があります。

リバランスの際には Kafka クラスターに追加の負荷がかかるため、最適化プロポーザルを却下したり、承認を遅らせたりする場合があります。プロポーザルが長期間遅れると、クラスターの負荷が大幅に変化する可能性があるため、新しいプロポーザルをリクエストしたほうがよい場合があります。

次の例では、プロポーザルは別々のブローカー間のデータのリバランスを提案しています。リバランスには、ブローカー間での 55 個のパーティションレプリカ (合計 12 MB のデータ) の移動が含まれます。このプロポーザルでは、24 のパーティションリーダーも別のブローカーに移動します。これにはクラスターメタデータの変更が必要ですが、パフォーマンスへの影響はわずかです。

バランススコアは、最適化プロポーザルが承認される前後の Kafka クラスターの全体的なバランスの測定値です。バランススコアは、最適化ゴールに基づいています。すべてのゴールが満たされていると、スコアは 100 になります。達成されないゴールごとにスコアが減少します。バランススコアを比較して、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.                            a4f833bd-2055-4213-bfdd-ad21f95bf184

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.                            a4f833bd-2055-4213-bfdd-ad21f95bf184

パーティションレプリカのブローカー間の移動は、パフォーマンスに大きな影響を与えますが、データ総量はそれほど多くありません。合計データが膨大な場合は、プロポーザルを却下するか、リバランスを承認するタイミングを考慮して Kafka クラスターのパフォーマンスへの影響を制限できます。

provision ステータスは、現在のクラスター設定が最適化ゴールをサポートするかどうかを示します。プロビジョニングステータスを確認し、ブローカーを追加または削除する必要があるかどうかを確認します。

以下の表は、最適化プロポーザルのサマリーに含まれるプロパティーを説明しています。

Cruise Control は、設定済みのデフォルト最適化ゴールを基にして キャッシュされた最適化プロポーザル を維持します。このプロポーザルはワークロードモデルから生成され、Kafka クラスターの現在の状態を反映するために 15 分ごとに更新されます。デフォルトのゴールを使用して最適化プロポーザルを生成すると、Cruise Control は最新のキャッシュバージョンを返します。

ワークロードが急速に変化するクラスターの場合は、最適化プロポーザルが最新の状態を反映するように、更新間隔を短くすることが推奨されます。ただし、間隔を短くすると、Cruise Control サーバーの負荷が増加します。更新レートを調整するには、Cruise Control デプロイメント設定の proposal.expiration.ms 設定を変更します。

クラスターリバランスのパフォーマンスは、パーティション再割り当てコマンドのバッチに適用される レプリカ移動ストラテジー の影響も受けます。デフォルトでは、Cruise Control は BaseReplicaMovementStrategy を使用し、生成された順序で再割り当てを適用します。ただし、このストラテジーでは、大規模なパーティションの再割り当てが生成され、最初に順序付けされると、他のパーティションの再割り当てが遅延される可能性があります。

Cruise Control は、最適化プロポーザルに適用できる代替のレプリカ移動ストラテジーを 4 つ提供します。

これらのストラテジーをシーケンスとして設定できます。最初のストラテジーは、内部ロジックを使用して 2 つのパーティション再割り当ての比較を試みます。再割り当てが同等である場合は、順番を決定するために再割り当てをシーケンスの次のストラテジーに渡します。

Cruise Control または個別のリバランスを設定するときに、次のリバランスチューニングオプションを設定できます。

次のいずれかの方法でチューニングオプションを設定します。

両方の方法に関連する設定を以下の表にまとめています。

デフォルト設定を変更すると、リバランスの完了までにかかる時間と、リバランス中の Kafka クラスターの負荷に影響します。値を小さくすると負荷は減りますが、かかる時間は長くなります。その逆も同様です。