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 の数を変更すると、既存のブローカーに分散されます（ブローカーあたり最大 15 個の vCPU）。クラスタサイズをブローカーあたり 15 個の vCPU を超えて増やすと、システムは新しいブローカーをプロビジョニングします。新しいブローカーをプロビジョニングすると、1 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 vCPU / 15）= 6 ブローカー

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

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

  • 75 個の vCPU / 5 個のブローカー = ブローカーあたり 15 個の vCPU

  • 130 GiB / 5 ブローカー = ブローカーあたり 26 GiB

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

  • 80 個の vCPU / 6 個のブローカー = ブローカーあたり 13.33 個の vCPU（11.1% の削減）

  • 140 GiB / 6 ブローカー = ブローカーあたり 23.33 GiB（10.2% の削減）

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

アップスケール オペレーションが成功した場合の例

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

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

  • ceiling（85 vCPU / 15）= 6 ブローカー

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

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

  • 75 個の vCPU / 5 個のブローカー = ブローカーあたり 15 個の vCPU

  • 130 GiB / 5 ブローカー = ブローカーあたり 26 GiB

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

  • 85 vCPU / 6 ブローカー = ブローカーあたり 14.17 vCPU（5.5% 削減）

  • 150 GiB / 6 ブローカー = ブローカーあたり 25 GiB（3.8% 削減）

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

次のステップ

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