Managed Service for Apache Kafka のコスト削減方法: 確約利用割引、圧縮など

※この投稿は米国時間 2025 年 2 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

ビジネスやストリーミング ワークロードの拡大に伴い、Apache Kafka クラスタの運用および管理には高いコストがかかることがあります。このたび Google は、Managed Service for Apache Kafka の確約利用割引（CUD）の一般提供を開始しました。これにより、コンピューティング コストを最大 40% 削減できます。ぜひこの続きを読み、CUD やその他のコスト削減機能を活用してコストを削減する方法をご確認ください。

Google Cloud Managed Service for Apache Kafka は、オープンソースの Apache Kafka を Google Cloud 上で実行するための、セキュアで高スケーラブルなフルマネージド型サービスです。このマネージド Kafka サービスは、自動でのブローカー サイズ調整とリバランシングによりクラスタ作成を処理することで、手動によるブローカー管理にかかるコストを削減します。また Cloud Monitoring、Cloud Logging、Identity and Access Management（IAM）と統合されているほか、すべてのデプロイメントがデフォルトで高可用性構成を用いて作成されます。

確約利用割引やその他のコスト削減機能を通じて、Managed Service for Apache Kafka のコストを最適化するためのヒントをご紹介します。

確約利用割引を利用してコンピューティング コストを節約する

Managed Service for Apache Kafka の確約利用割引（CUD）を利用すると、vCPU と RAM の使用を事前に確約することで、最大 40% の節約が可能になります。費用ベースの CUD を適用することで、同一の請求先アカウントに紐づけられているすべての Kafka クラスタとプロジェクトが定常的に使用するコンピューティング容量のコストを削減できます。

1 年間のコミットメントでは、オンデマンド料金と比べて 20% の節約が可能です。3 年間のコミットメントでは 40% の節約が可能です。コンピューティング コストが一定額を下回らないと予測でき、最低 1 年間コミット可能な場合は、Managed Service for Apache Kafka の CUD を購入することをおすすめします。

Google Cloud コンソールの確約利用割引ページにアクセスすると、今すぐ CUD を購入できます。詳細については、CUD のドキュメントと料金ページをご確認ください。

ゾーン間転送コストを最適化する

異なるゾーンにある Kafka ブローカーとコンシューマー間のデータ転送にはコストが発生する可能性があります。ゾーン間のデータ転送には Private Service Connect（PSC）による転送料金が発生しますが、同じゾーン内のブローカーとコンシューマー間のデータ転送にはこの料金はかかりません。

デフォルトでは、コンシューマーはリーダー レプリカから直接データを取得します。この設定では、異なるゾーン間でデータを読み取る際に、ゾーン間のデータ転送コストが発生します。Apache Kafka バージョン 2.4（KIP-392）以降では、コンシューマーと同じゾーン内のレプリカからメッセージを読み取るよう、Kafka コンシューマーを構成することが可能です。この機能は「ラック認識」と呼ばれ、ここでのラックはクラウドゾーンを指します。この構成により、データ転送コストとレイテンシの両方を削減できます。

コンシューマーがラック認識をできるよう設定するには、コンシューマーのクライアント ラック ID が、それらがデプロイされているクラウドゾーンと一致するように構成する必要があります。各ブローカーのラック ID は、そのクラウドゾーンに設定されています。ブローカーがデプロイされている場所を確認するには、クラスタログで「broker.rack =」を検索します。一致するラック ID を持つレプリカが 1 つ以上存在する場合、アルゴリズムは最も同期の進んだレプリカを選択します。クライアント ラック ID が空（null）の場合、またはコンシューマーと同じゾーンにレプリカが存在しない場合、レプリカ セレクタはレプリカ リーダーにフォールバックします。ブローカーが存在する各ゾーンに少なくとも 1 つのコンシューマーをデプロイし、トピックに対し十分な数のレプリカを構成する必要があります。

圧縮を有効にする

圧縮を有効にすると、メッセージのサイズが縮小されるため、ネットワーク トラフィックとレイテンシが低減し、必要なストレージ容量も削減されることで、ネットワーキングおよびストレージ コストの両方を削減できます。圧縮は、プロデューサー レベルとブローカー レベルの両方で有効にできます。圧縮は、トピックレベルでも利用できますが、すべてのトピックに圧縮が適用されるよう、プロデューサー レベルとブローカー レベルで圧縮を有効にすることを推奨します。

メッセージ バッチサイズを大きくすることで、圧縮の効果を高められます。圧縮の形式としては gzip、lz4、または snappy を設定できます（zstd 圧縮形式はまだご利用いただけません）。プロデューサーで圧縮を有効にすると、デフォルトで、プロデューサーからブローカーへの通信、ブローカー上のストレージ、およびブローカーからコンシューマーへの通信に圧縮が適用されます。

バッチサイズを微調整する

さまざまなバッチサイズを試すことで、スループットを向上させながら、CPU とネットワーク帯域幅を節約できます。社内のベンチマークによると、使用するバッチサイズによってプロデューサーのスループットが 3 倍程度変動する可能性があることが示されています。微調整を行うことで、特定のクラスタ構成に最適なバッチサイズを見つけられます。バッチサイズの最適値を探す際は、バッチサイズとレイテンシのトレードオフを考慮することになります。まず、プロデューサーの設定で linger.ms を使用して許容可能な最大待機時間を設定し、その後、さまざまなバッチサイズを試して、特定のクラスタ構成に最適なバッチサイズを見つけることを推奨します。

テスト環境での保持期間とストレージを削減する

メッセージを長期間保持する必要がない場合、Kafka メッセージの保持期間に上限を設けることで、保存されるデータ量を削減し、それに伴うストレージ コストを抑えられます。たとえば、メッセージの履歴（バックログ）が不要な場合は、log.retention.ms と log.retention.bytes を使用して保持期間とデータサイズを削減できます。これにより、保持期間が過ぎる、またはパーティションの最大サイズに達すると、メッセージが期限切れになります。テスト環境では、レプリケーション係数を 2 に設定し、最小同期レプリカ数を 1 に設定してトピックを作成することで、さらにストレージを削減できます。ただし、これにより信頼性と可用性が低下する可能性があります。本番環境のワークロードには推奨されません。これはテスト環境でのみ行うことをおすすめします。

メッセージ変換を避ける

Kafka クライアントとブローカーが異なるバージョンの Kafka を使用している場合、基盤となるバイナリ メッセージ形式が一致しない可能性があります。この不一致によりメッセージ変換が必要となり、処理のオーバーヘッドが発生し、クラスタの CPU およびメモリ使用量が増加します。メッセージ変換を防ぎ、コストを削減するために、すべての Kafka クライアント（プロデューサーとコンシューマーの両方）が Kafka ブローカーと同じバージョンの Kafka を使用していることを確認してください。

使ってみる

Kafka のコストを抑えるために実施できることは多数あります。CUD を購入するには、Google Cloud コンソールの確約利用割引ページに移動します。詳細を確認するには、CUD ドキュメントをご覧ください。上述で説明したベスト プラクティスを必ずご確認ください。Managed Service for Apache Kafka の詳細については、こちらのクイックスタートをご覧ください。

-Google Cloud、シニア プロダクト マネージャー、Qiqi Wu