15.6. 最適化プロポーザルの概要


最適化プロポーザル は提案された変更の概要です。適用されると、パーティションのワークロードをブローカー間でより均等に分散し、よりバランスになった Kafka クラスターを生成します。各最適化プロポーザルは、その プロポーザルの生成に使用された最適化ゴール のセットが基になっており、ブローカーリソースの設定済みの 容量制限 の対象となります。

/rebalance エンドポイントに POST リクエストを送信すると、最適化プロポーザルが応答で返されます。プロポーザルの情報を使用し、プロポーザルを基にしてクラスターのリバランスを開始するかどうかを決定します。または、最適化ゴールを変更し、別のプロポーザルを生成することもできます。

デフォルトでは、最適化プロポーザルは個別に開始する必要 があるドライラン として生成されます。生成できる最適化プロポーザルの数に制限はありません。

キャッシュされた最適化プロポーザル

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

以下のゴール設定が使用されると、最新のキャッシュされた最適化プロポーザルが返されます。

  • デフォルトの最適化ゴール
  • 現在のキャッシュされたプロポーザルによって満たすことができるユーザー提供の最適化ゴール

キャッシュされた最適化プロポーザルの更新間隔を変更するには、cruisecontrol.properties ファイルの proposal.expiration.ms 設定を編集します。更新間隔を短くすると、Cruise Control サーバーの負荷が増えますが、変更が頻繁に行われるクラスターでは、更新間隔を短くするよう考慮してください。

最適化プロポーザルの内容

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

表15.2 最適化プロポーザルに含まれるプロパティー
プロパティー説明

n inter-broker replica (y MB) moves

n: 個別のブローカー間で移動されるパーティションレプリカの数。

リバランス操作中のパフォーマンスへの影響度: 比較的高い。

y MB: 個別のブローカーに移動される各パーティションレプリカのサイズの合計。

リバランス操作中のパフォーマンスへの影響度: 場合による。MB の数が大きくなると、クラスターのリバランスの完了にかかる時間が長くなります。

n intra-broker replica (y MB) moves

n: クラスターのブローカーのディスク間で転送されるパーティションレプリカの合計数。

リバランス操作中のパフォーマンスへの影響 度: 比較的高いが inter-broker replica moves よりも低い。

y MB: 同じブローカーのディスク間で移動される各パーティションレプリカのサイズの合計。

リバランス操作中のパフォーマンスへの影響度: 場合による。値が大きいほど、クラスターのリバランスの完了にかかる時間が長くなります。大量のデータを移動する場合、同じブローカーのディスク間で移動する方が個別のブローカー間で移動するよりも影響度が低くなります( inter-broker replica movesを参照)。

n excluded topics

最適化プロポーザルでのパーティションレプリカ/リーダーの移動の計算から除外されるトピックの数。

トピックは以下のいずれかの方法で除外できます。

cruisecontrol.properties ファイルで、topics.excluded.from.partition.movement プロパティーに正規表現を指定します。

/rebalance エンドポイントへの POST リクエストで、excluded_topics パラメーターに正規表現を指定します。

正規表現に一致するトピックは応答に一覧表示され、クラスターのリバランスから除外されます。

n leadership moves

n: リーダーが別のレプリカに切り替えられるパーティション数。ZooKeeper 設定の変更を伴います。

リバランス操作中のパフォーマンスへの影響度: 比較的低い。

n recent windows

n: 最適化プロポーザルの基になるメトリクスウインドウの数。

n% of the partitions covered

n%: 最適化プロポーザルの対象となる Kafka クラスターのパーティションの割合(パーセント)。

On-demand Balancedness Score Before (nn.yyy) After (nn.yyy)

Kafka クラスターの全体的なバランスの測定。

Cruise Control は、複数の要因を基にして Balancedness Score を各最適化ゴールに割り当てます。要因には、優先度( default.goals またはユーザー提供ゴールのリストのゴールの位置)が含まれます。On-demand Balancedness Score は、違反した各ソフトゴールの Balancedness Score の合計を 100 から減算して計算されます。

Before スコアは、Kafka クラスターの現在の設定を基にします。After スコアは、生成された最適化プロポーザルを基にします。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.