このページでは、Managed Service for Apache Kafka が Kafka クラスタのブローカーをプロビジョニングする方法について説明します。
概要
Kafka クラスタは、1 つ以上のブローカーで構成されます。プロデューサー アプリケーションはブローカーにメッセージを送信し、コンシューマー アプリケーションはブローカーに接続してメッセージを読み取ります。複数のコンシューマーが通常はコンシューマー グループを使用して、メッセージを並行して読み取ることができます。トピックの各パーティションにはリーダー ブローカーが割り当てられます。リーダーは、受信したパーティション データを他のブローカーに複製します。
Managed Service for Apache Kafka は、ブローカーを自動的に作成します。ブローカーの数を直接構成することはできませんが、クラスタをスケールアップしてブローカーを追加することはできます。
ブローカーのプロビジョニング
Managed Service for Apache Kafka クラスタを作成すると、サービスは 3 つのゾーンそれぞれに少なくとも 1 つのブローカーをプロビジョニングします。ブローカーの数は次のように計算されます。
number of brokers = max(3, ceiling(vCPUs / 15))
たとえば、75 個の vCPU を持つクラスタは 5 個のブローカーで開始します。
ブローカーはゾーン間でできるだけ均等に分散され、すべてのブローカーに同じ数の vCPU が割り当てられます。この値は小数になることがあります。各ブローカーには、少なくとも 1 つの vCPU があります。
サービスは、ブローカーのディスク容量を自動的にプロビジョニングします。必要に応じて、クラスタの作成時にブローカーあたりのディスク容量を構成し、後で増やすことができます。詳細については、ブローカーのディスクサイズを構成するをご覧ください。
クラスタのスケーリング
クラスタのサイズを大きくすると、追加の vCPU が既存のブローカーに分散されます（ブローカーあたり 15 個の vCPU まで）。クラスタサイズがブローカーあたり 15 個の vCPU を超えると、サービスは新しいブローカーをプロビジョニングします。ブローカーは 3 つのゾーンに均等に分散され、最大差は 1 です。
クラスタサイズを小さくすると、vCPU は既存のブローカーに分散され、ブローカーあたりの最小 vCPU 数は 1 になります。クラスタの存続期間中にブローカーが削除されることはありません。新しいブローカーがプロビジョニングされると、1 つの vCPU にスケールダウンできますが、削除されることはありません。
ブローカー パーティションの再調整
多くの場合、クラスタをスケールアップする理由は、一部のパーティションを新しいブローカーに再割り当てして、既存のブローカーの負荷を軽減するためです。このプロセスは「再調整」と呼ばれます。リバランスは自動または手動で実行できます。
自動再調整。自動リバランシングはクラスタ全体の設定です。新しいブローカーがプロビジョニングされると、自動再調整が有効になっている場合、サービスは既存のブローカーからパーティションを自動的に再調整します。再調整アルゴリズムはパーティション数に基づいており、ブローカーあたりのパーティション数をほぼ同じに保つことを目的としています。各パーティションで処理される実際のトラフィックは考慮されません。詳細については、再調整の構成をご覧ください。
手動再調整。パーティションの割り当てを変更することで、パーティションのバランスを手動で再調整できます。これは、自動再調整が無効になっている場合や、パーティションが他のパーティションよりも大幅に多くのトラフィックを受信している場合（ホット パーティションと呼ばれる）に行うことがあります。詳細については、パーティションの割り当てを変更するをご覧ください。