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 エンドポイントが必要です。エンドポイントは自動的にプロビジョニングされます。
クラスタの保護
このサービスは、クラスタのセキュリティのために、認証、認可、暗号化、パッチ適用、リソース分離などの機能を提供します。また、認証されていない接続や暗号化されていない接続、ストレージも禁止します。
認証
このサービスは、SASL（Simple Authentication and Security Layer）と相互 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 つのセキュリティ機能は、リソースの分離です。マネージド サービスは、パブリック IP アドレスを介してアクセスできないプライベート VPC のテナント プロジェクトにクラスタをデプロイします。各プロジェクトには、専用のテナント プロジェクトと専用のサービス エージェント アカウントがあります。これにより、サービスに付与されるアクセスの範囲を制限できます。
スキーマ レジストリ
プロデューサーとコンシューマー間の連携を簡素化するために、Managed Service for Apache Kafka にはスキーマ レジストリ API が含まれています。サービスによって提供されるレジストリは、アプリケーション間で共有されるスキーマのリポジトリとして機能します。
このサービスは、既存の Kafka アプリケーションとの統合に役立つ Confluent Schema Registry REST API を実装しています。Apache Avro とプロトコル バッファ（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 デプロイや BigQuery、Cloud Storage、Pub/Sub などの Google Cloud サービスを含むさまざまなシステムに接続できます。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などのストレージ関連の設定が含まれます。
次のステップ
- Managed Service for Apache Kafka クラスタを作成する。
- Managed Service for Apache Kafka クラスタを使用してメッセージを送受信する。
- Managed Service for Apache Kafka の制限事項を確認する。
- Managed Service for Apache Kafka の料金について学習する。