Managed Service for Apache Kafka クラスタのサイズを計画する

このドキュメントでは、Managed Service for Apache Kafka クラスタに必要な容量を見積もる方法と、既存のクラスタのサイズを調整する方法について説明します。

Managed Service for Apache Kafka クラスタを作成するときに、クラスタのサイズに対して次のパラメータを選択します。

• vCPUs: クラスタ内の vCPU の数。最小 vCPU 数は 3 です。

• メモリ: vCPU あたりのメモリ量。vCPU あたり 1 GiB ～ 8 GiB の範囲でプロビジョニングする必要があります。

クラスタの作成後にこれらの値を更新できます。

初期クラスタ サイズを選択する

初期クラスタ サイズを選択するには、特定のワークロードに基づいて次の値を推定します。

• 書き込みスループット: プロデューサーが クラスタにデータを送信する合計レート（MBps）。
• 読み取りスループット: コンシューマーが クラスタからデータを読み取る合計レート（MBps）。

このスループットを処理するために必要なクラスタのサイズを見積もるには、次の手順を行います。

1. レプリケーションを含む合計書き込み帯域幅を計算します。

   Total write bandwidth = produce rate * replicas

   この値には、クライアントからリーダー ブローカーへの帯域幅と、リーダーからレプリカ ブローカーへの帯域幅が含まれます。レプリカのデフォルト数は 3 です。

2. レプリケーションを含む合計読み取り帯域幅を計算します。

   Total read bandwidth = consume rate + produce rate * ( replicas - 1)

   この値には、クライアントの読み取りオペレーションの帯域幅（消費率）と、レプリカを同期状態に保つために必要な帯域幅が含まれます。レプリカは、パーティション リーダーからデータを読み取って同期します。パーティション リーダーはレプリカから読み取らないため、(replicas - 1) という用語が使用されます。

3. 書き込み相当のデータレートを計算します。

   一般に、読み取り帯域幅は書き込み帯域幅よりも 4 倍効率的です。この違いを考慮して、次のように書き込み相当のデータレートを計算します。

   Write-equivalent rate = (total write bandwidth) + (total read bandwidth / 4)

4. 目標 vCPU 使用率を決定します。この値は、vCPU 容量に対する割合として平均 vCPU 使用率を表します。実際の使用率は時間の経過とともに急増または低下する可能性があります。

   • ベースラインとして、使用率の目標値を 50% に設定します。
   • 予想されるトラフィック パターンがわかっている場合は、使用率の目標値を、対応する必要があるピーク帯域幅に対する書き込み相当の平均帯域幅の比率に設定します。

   一般に、使用率を上げると、クラスタのサイズが縮小するため、クラスタの費用が削減されますが、トラフィックが推定値を超えるとリスクも高まります。 vCPU の使用率が高すぎると、レイテンシの増加やエラーが発生する可能性があります。

5. vCPU の数を計算します。

   vCPU count = ceiling (write-equivalent rate / 20 MBps / utilization)

   単一ゾーンの単一 vCPU の推定容量は 20 MBps です。 したがって、vCPU が 100% の使用率で実行される場合、(write-equivalent rate / 20) 個の vCPU が必要になります。実際の数を取得するには、その値を目標使用率で割り、切り上げます。

   また、10 KB 未満のバッチでメッセージを送信すると、CPU あたりのスループットが、ここで示すベンチマークと比較して低下します。その場合は、スループット容量の低下を考慮するか、バッチサイズを大きくすることを検討してください。

6. 必要なメモリを見積もります。vCPU ごとに 4 GiB の RAM をおすすめします。

   Memory = vCPU count * 4 GiB

最も正確なサイジングを行うには、実際のワークロードでテストします。クラスタのリソース使用量をモニタリングし、必要に応じてスケールアップします。

サイズ計算の例

ワークロードの書き込みレートが 50 MBps、読み取りレートが 100 MBps、レプリカが 3 つ、目標 vCPU 使用率が 50% であるとします。

1. Total write bandwidth = 50 MBps * 3 replicas = 150 MBps
2. Total read traffic = 100 MBps + 50 MBps * (3 - 1) = 200 MBps
3. Write-equivalent rate = 150 MBps + (200 MBps / 4) = 200 MBps
4. Target utilization = 0.5
5. Number of vCPUs = ceiling (200 MBps / 20 MBps / 0.5) = 20 vCPUs
6. Memory = 20 vCPUs * 4 GiB = 80 GiB

ブローカー

クラスタを作成すると、3 つのゾーンそれぞれに少なくとも 1 つのブローカーがプロビジョニングされます。ブローカーはゾーン間でできるだけ均等に分散され、すべてのブローカーの vCPU 数は同じです。ブローカーの数は、次の数式で計算できます。

number of brokers = max(3, ceiling(vCPUs / 15))

たとえば、75 個の vCPU を持つクラスタは、5 つのブローカーで開始されます。

vCPU の数を変更すると、既存のブローカーに分散されます。ブローカーあたりの vCPU の最大数は 15 です。クラスタサイズをブローカーあたり 15 個の vCPU を超えて増やすと、新しいブローカーがプロビジョニングされます。新しいブローカーがプロビジョニングされたら、1 vCPU にスケールダウンできますが、削除することはできません。

パーティション レプリカの上限

クラスタのサイズ設定を行う際は、クラスタごととブローカーごとのパーティション レプリカ数に上限があることを考慮する必要があります。

クラスタあたりの上限は 100,000 個のパーティション レプリカです。これはハードリミットであり、クラスタ内のブローカーの数とは無関係です。ワークロードで 100,000 個を超えるパーティション レプリカが必要な場合は、2 つ以上のクラスタに分割することを検討してください。

ブローカーあたりの上限は 4,000 個のパーティション レプリカです。これはハードリミットではありません。この数を超えるレプリカを処理する必要がある場合は、ブローカーのプロビジョニングを増やすことを検討してください。クラスタの vCPU サイズを最大ブローカーサイズまで増やすことで、ブローカーの数を増やすことができます。パーティションを処理するのに十分な数のブローカーを用意したら、スループットに合わせてブローカーのサイズをスケーリングできます。

クラスタ サイズを更新する

Managed Service for Apache Kafka クラスタを作成したら、ニーズに合わせて vCPU 数とメモリを調整できます。既存のクラスタを更新する場合は、次のルールが適用されます。

• クラスタの全体的な vCPU 対メモリ比は、常に 1:1 ～ 1:8 の範囲内である必要があります。

• スケールダウンする場合は、既存のブローカーごとに少なくとも 1 つの vCPU と 1 GiB のメモリが必要です。ブローカーの数が減ることはありません。

• スケールアップして、変更によって新しいブローカーが追加される場合、ブローカーあたりの平均 vCPU とメモリは、更新前の平均値と比較して 10% 以上減少することはできません。

  たとえば、クラスタを 45 個の vCPU（3 つのブローカー）から 48 個の vCPU（4 つのブローカー）にスケールアップしようとすると、オペレーションは失敗します。これは、ブローカーあたりの平均 vCPU が 15 から 12 に減少し、20% の削減となり、10% の上限を超えているためです。

CPU 数を 10% 以上減らす必要がある場合は、段階的に減らすことをおすすめします。更新ごとに、リソース使用量をモニタリングし、必要に応じてパーティションを再調整します。

ただし、更新後にブローカーに十分な容量があることが確実な場合は、このチェックを無効にできます。チェックを無効にするには、gcloud managed-kafka clusters update コマンドで allow_broker_downscale_on_cluster_upscale フラグを true に設定します。このフラグは、潜在的なパフォーマンス リスクを受け入れることを示します。

クラスタを更新するには、 Managed Service for Apache Kafka クラスタを更新するをご覧ください。

更新オペレーションの例

次の例では、75 個の vCPU 130 GiB の RAM、および 5 つのブローカー を持つクラスタから開始します。

スケールアップ オペレーションが失敗する例

クラスタを 80 個の vCPU と 140 GiB の RAM にスケールアップします。

• サービスは、新しいブローカーが必要かどうかを判断します。

  • ceiling (80 vCPUs / 15) = 6 brokers

  クラスタは 5 つから 6 つのブローカーに増加するため、10% の安全チェックがトリガーされます。

• ブローカーあたりの現在の平均値は次のとおりです。

  • 75 vCPUs / 5 brokers = 15 vCPUs per broker

  • 130 GiB / 5 brokers = 26 GiB per broker

• 6 つのブローカーの場合、新しい平均値は次のようになります。

  • 80 vCPUs / 6 brokers = 13.33 vCPUs per broker, an 11.1% reduction

  • 140 GiB / 6 brokers = 23.33 GiB per broker, a 10.2% reduction

  これらの平均値が 10% を超えているため、オペレーションは失敗します。

スケールアップ オペレーションが成功する例

クラスタを 85 個の vCPU と 150 GiB の RAM にスケールアップします。

• サービスは、新しいブローカーが必要かどうかを判断します。

  • ceiling (85 vCPUs / 15) = 6 brokers

  クラスタは 5 つから 6 つのブローカーに増加するため、10% の安全チェックがトリガーされます。

• ブローカーあたりの現在の平均値は次のとおりです。

  • 75 vCPUs / 5 brokers = 15 vCPUs per broker

  • 130 GiB / 5 brokers = 26 GiB per broker

• 6 つのブローカーの場合、新しい平均値は次のようになります。

  • 85 vCPUs / 6 brokers = 14.17 vCPUs per broker, a 5.5% reduction

  • 150 GiB / 6 brokers = 25 GiB per broker, a 3.8% reduction

ブローカーあたりの平均 vCPU とメモリの削減が 10% の上限内であるため、このオペレーションは成功します。

次のステップ

• Managed Service for Apache Kafka クラスタを作成する
• Managed Service for Apache Kafka クラスタをモニタリングする
• Managed Service for Apache Kafka クラスタを更新する