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

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

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

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

ブローカーあたりの上限は 4,000 個のパーティション レプリカです。これはハードリミットではありません。この数を超えるレプリカを処理する必要がある場合は、クラスタのサイズを大きくしてブローカーをプロビジョニングすることを検討してください。サービスがブローカーの数を決定する方法については、 ブローカーのプロビジョニングをご覧ください。

パーティションを処理するのに十分な数のブローカーを用意したら、スループットに対応できるようにブローカーのサイズをスケーリングできます。

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

Managed Service for Apache Kafka クラスタを作成したら、ニーズに合わせて vCPU 数とメモリを調整できます。詳細については、 Managed Service for Apache Kafka クラスタを更新するをご覧ください。

既存のクラスタを更新する場合は、次のルールが適用されます。

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

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

• クラスタに カスタム ディスク構成がある場合、 更新はローカル ストレージの ディスク構成要件 を満たしている必要があります。

• スケールアップする場合、ブローカーあたりの平均 vCPU とメモリは、更新前の平均値と比較して 10% 以上減少させることはできません。たとえば、クラスタを 45 個の vCPU（3 個のブローカー）から 48 個の vCPU（4 個のブローカー）にスケールアップしようとすると、ブローカーあたりの平均 vCPU が 15 から 12 に減少し、20% の削減となり、10% の上限を超えます。

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

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

更新オペレーションの例

次の例では、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 は、各ブローカーに vCPU あたり 100 GiB を割り当てます。デフォルトの割り当てでは、ほとんどのワークロードに十分なローカル ストレージが提供されますが、 特定の要件に合わせて ブローカーのディスクサイズを構成できます。このセクションでは、必要なディスク容量を見積もる方法について説明します。

ブローカーはメッセージを受信すると、メッセージをローカル セグメント ファイルに書き込みます。 セグメント ファイルが最大サイズまたは最大経過時間に達すると、閉じられ（または「ロール」され）、リモート ストレージに移動します。セグメント ファイルの最大サイズは log.roll.bytes 設定で指定され、最大経過時間は log.segment.ms 設定で指定されます。

セグメント ファイルがロールされると、ブローカーは新しいセグメント ファイルを開きます。ロールされたセグメントは、ブローカーがリモート ストレージにコピーしている間、ローカル ストレージに残ります。 したがって、各パーティションには、ロールされたセグメント ファイルを保存するのに十分なスペースと、ロールされたセグメントがリモート ストレージに移動している間に新しいセグメント ファイルを保存するスペースが必要です。

デフォルトでは、セグメント ファイルの最大サイズは 230 MiB です。使用率が中程度のクラスタでは、ロールされたセグメントの移動中にバッファ スペースを追加するために、パーティションごとに 250 MiB が必要であると想定できます。この想定を使用すると、ブローカーあたりの最小ディスクサイズは次のようになります。

250 MiB * partition count * replication factor / broker count

ただし、必要なサイズは、セグメント ファイルの最大サイズ、クラスタの負荷、新しいデータの書き込みレート、長期保存ストレージへの書き込みのレイテンシなどの要因によって異なります。

十分なディスク容量を確保するには、 パーティションのディスクサイズを managedkafka/byte_size 指標を使用してモニタリングします。

次のステップ

• Managed Service for Apache Kafka クラスタを作成する
• Managed Service for Apache Kafka クラスタをモニタリングする
• Managed Service for Apache Kafka クラスタを更新する
• ブローカーのディスクサイズを構成する