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

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

6. 必要なメモリを推定します。各 vCPU には 4GiB の 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% 以上減らす必要がある場合は、数段階に分けて減らすことをおすすめします。更新のたびにリソース使用率をモニタリングし、必要に応じてパーティションの再調整を行います。

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

更新オペレーションの例

次の例では、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

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

各ブローカーで未使用のディスク容量を維持することが重要です。ディスク容量のないブローカーの動作は予測できず、データ損失やクラスタの不安定化につながる可能性があります。ディスク使用量（disk/used_bytes）を、使用可能なディスクの合計サイズ（disk/limit）と比較します。ディスク使用量が使用可能なディスクの合計サイズの 80% を超えている場合は、ディスクサイズを大きく構成します。詳細については、クラスタ容量をモニタリングするをご覧ください。

次のステップ

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