Managed Service for Apache Kafka の概要

Managed Service for Apache Kafka は、安全でスケーラブルなオープンソースの Apache Kafka クラスタの実行に役立つ Google Cloud サービスです。このページでは、このサービスによって自動化および簡素化される内容の概要について説明します。Apache Kafka の詳細については、Apache Kafka ウェブサイトをご覧ください。

シンプルなサイズ設定とスケーリング

Managed Service for Apache Kafka クラスタのサイズ設定またはスケーリングを行うには、クラスタの合計 vCPU 数と RAM サイズを設定するだけです。ストレージなどのブローカーの管理は完全に自動化されています。クライアントの要求に対応するため、vCPU やその他のリソースの使用状況をモニタリングし、必要に応じて増減できます。

vCPU 数と RAM サイズを設定すると、ブローカーのサイズ変更とプロビジョニングが自動的に行われます。クラスタサイズを大きくするために新しいブローカーが必要な場合、パーティションをブローカー間で自動的に再調整できます。

ブローカーのプロビジョニング

クラスタの合計 vCPU 数と RAM サイズを構成すると、新しいブローカーがプロビジョニングされ、既存のブローカーがスケーリングされます。一般的なクラスタ構成では、合計 vCPU 数と RAM サイズはすべてのブローカーに均等に分割されます。つまり、ブローカーあたりの vCPU 数は整数でなくてもかまいませんが、ブローカーごとに 1 つ以上の vCPU が必要です。すべてのクラスタは 3 つのゾーンに分散されます。つまり、クラスタごとに最低 3 つの vCPU と 3 GiB の RAM が必要です。

クラスタサイズを大きくすると、ブローカーはブローカーあたり最大 15 個の vCPU まで垂直方向にスケーリングされます。この上限に達すると、新しいブローカーが作成されます。クラスタサイズを小さくすると、既存のブローカーは 1 つの vCPU にスケールダウンされますが、削除はされません。

ブローカーの最大サイズはいつでも変更される可能性があります。この制限は、vCPU 数に応じてブローカーのスループットを線形にスケーリングするために選択されました。

スケーリングアルゴリズム

ブローカーの数は、クラスタの合計 vCPU 数またはメモリ容量によって決まります。スケーリング比率は、15 vCPU または 120 GiB のリソースごとに 1 つのブローカーです。ブローカーの数が多い方が優先されます。vCPU とメモリの比率（vCPU:GiB）は 1:1 ～ 1:8 にする必要があります。ブローカーは 3 つのゾーンに均等に分散され、最大差は 1 です。

たとえば、70 個の vCPU と 130 GiB の RAM でクラスタを構成し、レプリケーションファクタを 3 に設定した場合、ブローカーの数は次のように計算されます。

vCPU を考慮するために必要なブローカーの数を計算します。ceiling(70 vCPUs / 15 vCPUs) = 5 ブローカー
メモリを考慮するために必要なブローカーの数を計算します。ceiling(130 GiB / 120 GiB) = 2 ブローカー

このシナリオでは、ブローカーの数は vCPU の数によって決まるため、クラスタには 5 つのブローカーがあります。3 つのゾーンのうち 2 つにはそれぞれ 2 つのブローカーが割り当てられ、最後のゾーンには 1 つのブローカーが割り当てられます。

ストレージ管理

ストレージ管理は自動化されています。ほとんどの場合、費用を管理したり、データ保持ポリシーを満たしたりするために、個々のトピックの保持期間を設定する必要があります。永続ディスクをプロビジョニングして管理する必要はありません。

このサービスは階層型ストレージ（KIP-405）に依存しています。階層型ストレージは、ブローカーに接続された事前プロビジョニング済みの永続ディスクボリュームと、事実上無制限のオブジェクトストレージを組み合わせたものです。

パフォーマンス、可用性、費用をバランスさせるため、vCPU ごとに少なくとも 100 GiB の SSD 永続ディスクが割り当てられます。ブローカーあたりの実際のディスクサイズがこの値を超える場合でも、vCPU あたり 100 GiB の料金が請求されます。クラスタがスケールダウンされても、ブローカーあたりのディスクサイズが小さくなることはありません。

各パーティションリーダーは、これらの永続ディスク上のセグメントファイルにメッセージをバッファリングします。セグメントがロールオーバーされると、リージョン Cloud Storage にバックアップされた永続オブジェクトストレージに移動します。これらのセグメントファイルのサイズは、log.roll.ms と log.segment.bytes の設定によって決まります。

これらの詳細は理解するのに役立ちますが、ストレージはサービスによって管理されます。 vCPU あたりの永続ディスク容量などの具体的な構成は、変更される可能性のある実装の詳細です。永続ストレージに使用される Cloud Storage バケットに直接アクセスすることはできません。

再調整

新しくプロビジョニングされたブローカーがパフォーマンスの維持に役立つようにするには、既存のブローカーからこれらの新しいマシンにトラフィックを移動する必要があります。これを簡単にするために、自動再調整を有効にできます。

自動再調整が有効になっている場合、新しいブローカーがプロビジョニングされると、既存のブローカーからパーティションが自動的に再調整されます。階層型ストレージモデルでは、新しいブローカーにコピーする必要があるデータ量が比較的少ないことを確認し、再調整を高速化します。

再調整アルゴリズムはパーティションの数に基づいています。各パーティションで処理される実際のトラフィックは考慮されません。

柔軟なネットワーキング

このサービスにより、任意の VPC からクラスタに安全にアクセスできます。これには、複数の VPC、プロジェクト、リージョンからのアクセスが含まれます。

クラスタのネットワーキングを構成するには、クラスタがアクセスできるサブネットのセットを指定します。このサービスは、各サブネットのブートストラップサーバーとブローカーにプライベート IP アドレスをプロビジョニングします。また、各 IP アドレスの URL を使用してプライベート Cloud DNS を設定します。ブートストラップサーバーにはロードバランサがあるため、クラスタごとに 1 つのブートストラップ URL があります。URL はすべての VPC で同じであるため、環境間でクライアント構成を統一できます。

このレベルの柔軟性は、Private Service Connect（PSC）によって実現されています。クラスタに割り当てられた各 IP アドレスには PSC エンドポイントが必要です。エンドポイントは自動的にプロビジョニングされます。

クラスタの保護

このサービスには、クラスタのセキュリティのための次の機能があります。認証、認可、暗号化、パッチ適用、リソース分離。また、認証されていない接続と暗号化されていない接続、ストレージは許可されません。

認証

このサービスは、Simple Authentication and Security Layer（SASL）と相互 TLS（mTLS）の 2 つの認証方法をサポートしています。mTLS 認証は、2025 年 6 月 24 日以降に作成されたクラスタで使用できます。マネージドクラスタへのすべての接続は、SASL を使用する IAM ID であるプリンシパルまたは mTLS を使用するクライアント証明書で認証されます。SASL を使用する場合、プリンシパルとしてユーザーアカウント、サービスアカウント、フェデレーションアカウントがサポートされます。

このサービスは、SASL/GSSAPI、SASL/SCRAM-SHA-256、SASL/SCRAM-SHA-512 などの他のプロトコルをサポートしていません。また、認証されていない接続は許可されません。

承認

このサービスでは、認可に階層型アプローチを採用しています。IAM は、リソースの作成、更新、削除などのクラスタ管理アクションを制御します。認証されたプリンシパルの認可は、使用する方法によって異なります。

SASL: IAM を使用するプリンシパルは、 Google Cloud IAM ロールバインディングまたはクラスタの Kafka ACL を介して認可されます。詳細については、SASL 認証を構成するをご覧ください。
mTLS: mTLS で認証するプリンシパルは、Kafka ACL を介して認可されます。詳細については、mTLS 認証を構成するをご覧ください。

Kafka ACL は、 Google Cloud ツールまたはサードパーティの Kafka ツールで管理できます。 IAM と Kafka ACL の構成の詳細については、 IAM と Kafka ACL によるアクセス制御をご覧ください。

暗号化

暗号化が必要です。クラスタへのすべての接続で TLS を使用する必要があります。ブローカーによって提示される TLS 証明書は、Public Certificate Authority によって署名されます。保存されたデータは常に暗号化されます。保存データの暗号化に Google マネージド暗号鍵と顧客管理の暗号鍵（CMEK）のどちらを使用するかを選択します。

パッチ適用と

サービスチームは、オープンソースコードで発見されたセキュリティの脆弱性を追跡します。脆弱性が発見されると、クラスタに自動的にパッチが適用されます。

リソース分離

このサービスのもう 1 つのセキュリティ機能は、リソース分離です。マネージドサービスは、テナントプロジェクトのプライベート VPC にクラスタをデプロイします。パブリック IP アドレスからはアクセスできません。各プロジェクトには、専用のサービスエージェントアカウントを持つ専用のテナントプロジェクトがあります。これにより、サービスに付与されるアクセス権の範囲を制限できます。

スキーマレジストリ

プロデューサーとコンシューマー間の調整を簡素化するため、Managed Service for Apache Kafka にはスキーマレジストリ API が含まれています。このサービスによって提供されるレジストリは、アプリケーション間で共有されるスキーマのリポジトリとして機能します。

このサービスは、既存の Kafka アプリケーションとの統合に役立つ Confluent Schema Registry REST API を実装しています。Apache Avro と Protocol Buffer（Protobuf）のスキーマ形式がサポートされています。JSON はサポートされていません。

Managed Service for Apache Kafka には、スキーマレジストリとスキーマを管理するための管理 API とツールセットも用意されています。ツールセットには、 Google Cloud コンソール、gcloud CLI、クライアントライブラリが含まれます。

スキーマレジストリの詳細については、スキーマレジストリの概要をご覧ください。

Kafka Connect によるデータ統合

Managed Service for Apache Kafka は、Kafka Connect によるデータ統合を簡素化します。Kafka Connect には、Connect クラスタでホストされる組み込みコネクタプラグインがいくつか用意されています。これらのコネクタは、移行、バックアップ、障害復旧、高可用性、データ統合に使用されます。これらのコネクタを使用すると、 Managed Service for Apache Kafka クラスタを、他の Kafka デプロイや Google Cloud BigQuery、Cloud Storage、Pub/Sub などのサービスを含むさまざまなシステムに接続できます。 Kafka Connect は、オペレーションのオーバーヘッドを削減し、モニタリングとロギングを統合することで、スケーラブルで信頼性の高いデータ統合を実現します。

Kafka Connect の詳細については、Kafka Connect の概要をご覧ください。

高可用性クラスタ

このサービスの目標は、ミッションクリティカルなアプリケーションにリージョンクラスタを提供することです。具体的には、個々のゾーンまたはブローカーの障害から保護します。

これを実現するため、すべてのクラスタはラック認識の 3 ゾーン構成でプロビジョニングされます。デフォルトのトピック構成では、少なくとも 3 つのレプリカが必要です。ラック認識により、レプリカが異なるゾーンに作成されます。デフォルトの同期レプリカの最小数は 2 です。つまり、クラスタはゾーンまたはブローカーの完全な損失に耐えることができます。

ソフトウェア、ハードウェア、ネットワークの障害によりブローカーで障害が発生すると、自動的に置き換えられます。ブローカーの障害が検出されると、必要に応じて別のマシンで自動的に再起動されます。ブローカーが使用可能になると、Apache Kafka がブローカーをクラスタに統合します。ゾーンが完全に停止すると、新しいブローカーを作成できなくなる可能性があります。ただし、他の 2 つのゾーンが使用可能な限り、クラスタは動作を継続します。

これらの特定の機能に加えて、内部ツールとプロセスのリストが増え続けており、サービスの健全性、Apache Kafka コード、更新をプロアクティブに維持しています。データとメタデータのバックアップは複数のレベルで維持されるため、多くの人的ミスやソフトウェア障害から復旧できます。

このサービスは、リージョンまたはデュアルゾーンの障害から保護しません。このレベルの保護が必要なアプリケーションの場合は、2 つの別々のリージョンクラスタを実行することをおすすめします。Kafka Connect の MirrorMaker 2.0 などのツールを使用して、2 つのクラスタ間でデータを同期できます。

管理スタイルに合わせたツール

このサービスは、クラスタの管理とトラブルシューティングのスタイルに合わせて、完全なツールセットを提供することを目指しています。これには、管理、モニタリング、ロギングのツールが含まれます。

Managed Service for Apache Kafka は Google Cloud API として公開されます。つまり、REST API と gRPC API を使用して、クラスタとクラスタリソースを管理できます。これらの API には、次のような複数のクライアントとインターフェースが用意されています。

Infrastructure as Code アプローチを使用する場合は、Terraform プロバイダ。
ブラウザでインタラクティブに作業するための Google Cloud コンソール UI。
シェルでインタラクティブに作業するための gcloud CLI。
カスタム開発とスクリプト作成のための Java、Python、Go などの言語のクライアントライブラリ。

モニタリングとトラブルシューティングのために、指標が Cloud Monitoring にエクスポートされます。一部の指標はサービス UI で確認できます。インタラクティブな作業、アラートの構成、他のシステムへのエクスポートを行うための完全なセットは、Cloud Monitoring で使用できます。

また、ブローカーログは Cloud Logging にエクスポートされます。これらのログは検索可能で、ログベースの指標とアラートの作成に使用できます。

アップグレードとパッチ

Managed Service for Apache Kafka クラスタは Apache Kafka バージョン 3.7.1 で実行されます。重大なセキュリティ脆弱性には自動的にパッチが適用されます。

オペレーティングシステムやオーケストレーションレイヤなどの基盤となるインフラストラクチャの更新は、継続的かつ自動的に行われます。ブローカーはローリングリスタートで更新され、クラスタのダウンタイムは発生しません。

ブローカーで実行されている Apache Kafka コードは、新しいマイナーバージョンに自動的にアップグレードされません。

透明性の高い費用

Managed Service for Apache Kafka の料金モデルは、Compute Engine で Apache Kafka を自分で実行する場合の料金と似ています。プロビジョニングしたリソース（vCPU、RAM、ローカルストレージ）と、使用したリソース（永続ストレージとデータ転送）に対して料金が発生します。Managed Service for Apache Kafka では、同様のシステムを自分で設定する場合と比較して、永続ストレージと vCPU の費用が高くなります。一方、データ転送とローカルストレージの料金は、Managed Service for Apache Kafka とセルフマネージド Kafka でほぼ同じです。料金の詳細については、 Managed Service for Apache Kafka の料金をご覧ください。

Apache Kafka を実行しているため互換性がある

Managed Service for Apache Kafka は、環境で実行しているのと同じオープンソースソフトウェアを実行します。サービスに移行するためにアプリケーションコードを変更する必要はありません。

制限事項

Managed Service for Apache Kafka には次の制限があります。

各クラスタには、3 つのゾーンそれぞれに同じリソースが必要です。シングルゾーンまたは 2 ゾーンの Managed Service for Apache Kafka クラスタはサポートされていません。
クラスタの作成時にゾーンを選択することはできません。
クラスタのローカルストレージの容量を構成することはできません。
Managed Service for Apache Kafka は KRaft モードで実行されます。Zookeeper モードはサポートされていません。
指標の JMX API はサポートされていません。
zstd を使用したトピックの圧縮は対象外です。compression.type でサポートされている値は、lz4、gzip、snappy、uncompressed です。
read-only 更新モードでブローカー構成をいつでも変更できますが、これらの変更はブローカーが再起動したときにのみ有効になります。再起動は、Google のメンテナンスとアップグレードプロセスの一環として定期的に行われますが、スケジュールは設定されておらず、手動でトリガーする方法もありません。そのため、これらの変更が有効になるタイミングを制御することはできません。read-only 構成の例としては、auto.create.topics.enable や background.threads などがあります。message.max.bytes など、cluster-wide 更新モードで構成を更新する場合、再起動は不要で、すぐに有効になります。
一部のブローカー構成パラメータはサービスによって管理され、更新できません。これには、broker.id や、remote.log.storage.system.enable などのストレージ関連の設定が含まれます。

次のステップ

Apache Kafka® は、Apache Software Foundation または米国その他の諸国における関連会社の商標です。