Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

Managed Service for Apache Kafka のネットワーキングを構成する

クライアントは、 Google Cloud プロジェクトの任意の Virtual Private Cloud（VPC）ネットワークから Google Cloud Managed Service for Apache Kafka クラスタに接続できます。公共のインターネット経由で信頼できる IP 範囲からのアクセスを有効にすることもできます。

このページでは、Managed Service for Apache Kafka でのネットワーキングの構成方法、Kafka クライアントとクラスタ間の接続を有効にする方法、異なるプロジェクト間でクライアントとクラスタをプライベートに接続する方法について説明します。

VPC ネットワークは、 Google Cloud内に実装された物理ネットワークを仮想化したネットワークです。VM インスタンス、コンテナワークロード、その他のリソースに安全なプライベートネットワーク接続を提供します。詳細については、VPC ネットワークの概要をご覧ください。

概要

クラスタを作成すると、サービスはクラスタブローカーとネットワークエンドポイントを Google が管理するプロジェクト内の VPC ネットワークに配置します。このプロジェクトはテナントプロジェクトと呼ばれ、ネットワークはテナントネットワークと呼ばれます。一方、リソース、クライアントアプリケーション、クライアント VPC ネットワークは、コンシューマープロジェクトと呼ばれる独自のプロジェクトに存在します。Managed Service for Apache Kafka クラスタごとに、独自の分離されたテナントネットワークがあります。

VPC ネットワークはサブネットワーク（サブネット）と呼ばれるパーティションに分割されます。各サブネットは、クラウドネットワークの特定のリージョンで IP アドレスの範囲を定義します。クライアントアプリケーションがクラスタと通信できるようにするには、VPC ネットワーク内のサブネットをテナントネットワークに接続するか、必要に応じてパブリッククラスタアクセスを有効にしてパブリックインターネット経由で接続します。

次の図は、project-1 と project-2 の 2 つの Google Cloud プロジェクトを示しています。Managed Service for Apache Kafka クラスタは project-1 にあります。

3 つの接続されたサブネットを持つ Managed Service for Apache Kafka クラスタ

次のサブネットがクラスタに接続されています。

project-1 の VPC ネットワーク vpc-1 内の subnet-1。
project-1 の VPC ネットワーク vpc-2 内の subnet-2。
project-2 の VPC ネットワーク vpc-3 内の subnet-3。

サブネットをクラスタに接続する

Managed Service for Apache Kafka クラスタを初めて作成するときは、少なくとも 1 つのサブネットを指定する必要があります。後で、クラスタを更新してサブネットを追加または削除できます。

接続されたサブネットは、クラスタと同じコンシューマープロジェクトに属することも、別のコンシューマープロジェクトに属することもできます。接続された VPC ネットワーク内の任意のリージョンにあるクライアントアプリケーションは、クラスタに接続できます。サブネットのロケーションと数については、制限事項をご覧ください。

接続されているサブネットワークを表示する方法については、クラスタを表示するをご覧ください。

クラスタ DNS エントリ

サブネットをクラスタに接続すると、サービスはクラスタのブートストラップアドレスとブローカーの DNS エントリをそのサブネットネットワーク内に作成します。Kafka クライアントは、ブートストラップアドレスを使用してブローカーを特定し、接続を確立します。ブートストラップサーバーがクライアントを特定のブローカーにリダイレクトするときに、IP アドレスではなくブローカー URL を使用します。

ブートストラップ URL とブローカー URL はクラスタの存続期間中は固定されますが、URL の形式はクラスタによって異なる場合があります。クラスタのブートストラップアドレスを取得するには、クラスタのブートストラップアドレスを表示するをご覧ください。

DNS 名は、接続されているすべてのサブネットで同じですが、各サブネットの異なる IP アドレスに対応しています。DNS 名は一貫しているため、すべての Kafka クライアントアプリケーションで同じブートストラップアドレスを使用できます。

Managed Service for Apache Kafka に接続するクライアントアプリケーションの例については、次のチュートリアルをご覧ください。

サブネットのサイズ設定

サブネットをクラスタに追加する場合、サブネットには十分な数の IP アドレスが使用可能である必要があります。各サブネットには、Kafka ブローカーごとに 1 つの IP アドレスと、ブートストラップアドレス用に 1 つの IP アドレスが必要です。Managed Service for Apache Kafka の最小クラスタサイズは 3 つのブローカーであるため、各サブネットにはブートストラップアドレスを含む少なくとも 4 つの使用可能な IP アドレスが必要です。

クラスタに 45 個を超える vCPU がある場合、クラスタには 15 個の vCPU ごとに 1 つのブローカーがあります。この場合、各サブネットの IP アドレスの最小数を次のように計算します。

vCPU の数を 15 で割ります。
最も近い整数に切り上げます。
ブートストラップアドレスを考慮して 1 を追加します。

たとえば、60 個の vCPU を持つクラスタには、少なくとも（60/15 + 1）= 5 個の使用可能な IP アドレスが必要です。

Google は、ブローカーと vCPU の比率を変更する場合があります。変更に対応するため、前の手順で計算した IP アドレスの数の 3 倍を割り当てることをおすすめします。

サブネットのサイズを計画するときは、クラスタをスケールアップする最大サイズに基づいて計算します。

Kafka Connect を使用する場合は、Connect クラスタのサブネット要件も考慮してください。詳細については、ワーカーサブネットをご覧ください。

プライベートで使用されるパブリック IP 範囲

クラスタを RFC 1918 以外のアドレス空間を使用するサブネットに接続できます。このような IP アドレス範囲は、プライベートで使用されるパブリック IP（PUPI）範囲と呼ばれます。

PUPI サブネットに接続するために追加の構成は必要ありません。PUPI サブネットは、禁止されている IPv4 サブネット範囲ではない有効な IPv4 範囲を使用する必要があります。

プロジェクト間でクライアントとクラスタをプライベートに接続する

異なる Google Cloudプロジェクトの Kafka クライアントをクラスタに非公開で接続する場合は、次のいずれかの方法を使用します。

複数のプロジェクトの VPC ネットワークにクラスタを接続する。
共有 VPC を使用してプロジェクトを接続する。

以降のセクションでは、これらのオプションについて説明します。

プロジェクト間でクラスタを接続する

他のプロジェクトのサブネットをクラスタに接続できます。クロスプロジェクトアクセスを有効にするには、クラスタに関連付けられている Google マネージドサービスアカウントに権限を付与する必要があります。Kafka クライアントがクラスタにアクセスできるようにする各プロジェクトで、サービスアカウントにそのプロジェクトの Managed Kafka Service エージェント IAM ロールが必要です。このロールにより、クラスタはGoogle Cloud リソースにアクセスして、ネットワークリソースと DNS エントリを作成できます。

たとえば、project-1 にクラスタが含まれており、project-2 のクライアントがクラスタにアクセスできるようにする場合は、project-1 のマネージド Kafka サービスアカウントに project-2 のマネージド Kafka サービスエージェントロールを付与します。次に、サブネットをクラスタに接続するの説明に従って、project-2 からクラスタにサブネットを接続します。

必要なロールを付与する手順は次のとおりです。

コンソール

Kafka クライアントが Managed Service for Apache Kafka クラスタにアクセスするプロジェクトを特定します。 Google Cloud
プロジェクトごとに、 Google Cloud コンソールでそのプロジェクトの [IAM] ページに移動します。

[IAM] に移動
[ アクセスを許可] をクリックします。
[新しいプリンシパル] フィールドに、次の値を入力します。
```
service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com
```
CLUSTER_PROJECT_NUMBER は、Managed Service for Apache Kafka クラスタを含むプロジェクトのプロジェクト番号に置き換えます。
[ロールを追加] をクリックします。
[ロールを検索] フィールドに「Managed Kafka Service Agent」と入力します。検索結果にサービスエージェント名が表示されます。
検索結果で [Managed Kafka Service Agent] を選択します。
[適用] をクリックします。
[保存] をクリックします。

gcloud

Kafka クライアントが Managed Service for Apache Kafka クラスタにアクセスするプロジェクトを特定します。 Google Cloud
プロジェクトごとに、gcloud projects add-iam-policy-binding コマンドを実行します。
```
gcloud projects add-iam-policy-binding CLIENT_PROJECT_ID \
    --member=serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com \
    --role=roles/managedkafka.serviceAgent
```
次のように置き換えます。
- CLIENT_PROJECT_ID: 接続する VPC ネットワークを含むプロジェクトの名前
- CLUSTER_PROJECT_NUMBER: Managed Service for Apache Kafka クラスタを含むプロジェクトのプロジェクト番号

共有 VPC を使用してプロジェクトを接続する

共有 VPC を使用すると、組織は複数のプロジェクトのリソースを共通の VPC ネットワークに接続できます。Managed Service for Apache Kafka で共有 VPC を使用するには、次の操作を行います。

Managed Service for Apache Kafka クラスタを作成します。
共有 VPC をプロビジョニングする。
前のセクションで説明したように、共有 VPC ホストプロジェクトで必要なロールをマネージド Kafka サービスアカウントに付与します。
Managed Service for Apache Kafka クラスタを共有 VPC ネットワークのサブネットに接続します。

共有 VPC ホストプロジェクトまたはサービスプロジェクトのクライアントは、クラスタに接続できます。

ネットワークアーキテクチャで共有 VPC を使用するタイミングについては、VPC 設計のベストプラクティスとリファレンスアーキテクチャをご覧ください。

クライアントをパブリッククラスタに接続する

VPC ネットワークの外部にクライアントアプリケーションがある場合は、クラスタへのパブリックアクセスを有効にできます。パブリッククラスタには、接続されたサブネットが必要です。ただし、トラフィックを送信する必要はありません。

パブリッククラスタ機能を有効にすると、サービスはクラスタのブローカーとブートストラップエンドポイントに外部 IPv4 アドレスをプロビジョニングします。このサービスは、クラスタ DNS エントリをこれらのパブリック IP アドレスに一般公開して解決できるようにします。つまり、外部クライアントは同じブートストラップアドレスを使用してブローカーを見つけて接続を確立できます。この実装では、スプリットホライズン DNS を使用します。接続されたサブネットを含む VPC ネットワーク内のクライアントは引き続きプライベートエンドポイントを解決しますが、他のネットワーク内のクライアントはパブリックエンドポイントを解決します。パブリッククラスタ機能を有効にしても、コンシューマープロジェクトに追加のリソースは作成されません。

パブリッククラスタ機能を有効にする場合は、許可するソース IP 範囲を 1 つ以上指定する必要があります。許可される範囲のサイズと上限の詳細については、パブリッククラスタまたは制限事項をご覧ください。

許可された送信元 IP 範囲は、クラスタを更新することで追加または削除できます。Managed Service for Apache Kafka は、Cloud Next Generation Firewall を使用して、パブリッククラスタへのアクセスを制限します。許可された送信元 IP 範囲の削除は、新しい接続にのみ適用されます（既存のトラフィックへの影響をご覧ください）。

このサービスでは、パブリッククラスタのセキュリティを確保するために、いくつかの対策が講じられています。すべての接続は TLS を使用して転送中に暗号化され、すべての接続で認証が必要です。SASL を使用する IAM ID または mTLS を使用するクライアント証明書を使用して認証する必要があります。匿名アクセスは許可されていません。詳細については、Kafka ブローカーの認証タイプをご覧ください。

セキュリティ管理者は、カスタム組織のポリシーの制約を使用して、プロジェクト内のパブリッククラスタを禁止できます。組織のポリシーの詳細については、カスタム制約を作成するをご覧ください。

外部ネットワークからの下り（外向き）ファイアウォールを構成する

シナリオによっては、ブローカーとブートストラップエンドポイントの外部 IPv4 アドレスを特定する必要がある場合があります。これらの値を取得する手順については、パブリッククラスタの詳細をご覧ください。

このサービスでは、次の方法でこの情報を利用できます。

クラスタに関連付けられている外部 IPv4 アドレスは、Managed Service for Apache Kafka API、gcloud、Terraform で確認できます。
このサービスは、1 つ以上のディスカバリ DNS レコードを保持します。これらは、クラスタに関連付けられているすべての外部 IPv4 アドレスを含む DNS A レコードです。これらのレコードは、 Cloud NGFW などの FQDN ベースのファイアウォールで使用できます。このファイアウォールでは、エンドポイントのリストが変更されるとルールが自動的に更新されます。検出エンドポイントのリストは、API、gcloud、Terraform で確認できます。

クラスタに関連付けられたパブリック IP アドレスを使用する場合は、次の点を考慮してください。

クラスタに関連付けられているパブリック IPv4 アドレスのリストは変更または拡大される可能性があります。そのため、この情報の使用方法を自動化するか、クラスタをスケールアップするときに新しい検出 DNS レコードを考慮するプロセスを定義します。次のような場合に変更が発生する可能性があります。
- クラスタをスケーリングします。スケールアップすると、新しいブローカーが追加されるときに 1 つ以上の外部 IPv4 アドレスが追加されることがあります。vCPU の数がブローカーの数に与える影響については、サブネットのサイズ設定をご覧ください。
- パブリッククラスタ機能をオフにしてからオンにします。このアクションにより、新しい外部 IPv4 アドレスのセットがクラスタに割り当てられます。
各検出 DNS レコードには、最大 30 個の IP アドレスが含まれます。これは、FQDN ファイアウォールによって適用される一般的な上限内に収まります。ブローカーが 29 個以下のクラスタには、30 個の外部 IPv4 アドレス（ブートストラップレコードを含む）を含む検出 DNS レコードが 1 つあります。このサービスは、30 個のブローカーを追加するごとに 1 つの検出 DNS レコードを追加します。vCPU の数がブローカーの数に与える影響については、サブネットのサイズ設定をご覧ください。
検出 DNS レコードに接続するように Kafka クライアントを構成しないでください。代わりに、ブートストラップアドレスに接続するようにクライアントを構成します。詳細については、制限事項をご覧ください。
この情報を使用して下り（外向き）ファイアウォールを構成する場合は、TCP ポート 9092（SASL）と 9192（mTLS）への接続を許可します。

クラスタのネットワークアーキテクチャ

このセクションでは、Managed Service for Apache Kafka で使用されるネットワーキングアーキテクチャの詳細について説明します。

Kafka クラスタは、テナントネットワークと 1 つ以上のコンシューマーネットワークにまたがっています。
テナントネットワークでは、クラスタに単一のブートストラップ IP アドレスと URL があります。このブートストラップアドレスは、クラスタ内のすべてのブローカーに接続されたロードバランサに対応しています。各ブローカーは個別にブートストラップサーバーとして機能することもできますが、信頼性を高めるためにブートストラップアドレスを使用することをおすすめします。
各コンシューマーネットワーク内で、サービスはブートストラップアドレスの Private Service Connect エンドポイントと、ブローカーごとに 1 つのエンドポイントを作成します。
ブートストラップアドレスの URL は、クラスタが接続されている VPC ネットワーク間で同じです。IP アドレスはコンシューマーネットワークに対してローカルです。
クライアントは DNS 名を使用して Kafka ブローカーに接続します。これらの名前は、Kafka クラスタが接続されているすべての VPC ネットワークに自動的に登録されます。ブートストラップアドレスとそのポート番号は、クラスタのプロパティとして使用できます。
クライアントはブートストラップアドレスを使用してブローカー URL を取得します。これらの URL は、各 VPC ネットワークのローカル IP アドレスに解決されます。実際のブローカーの IP アドレスと URL は Cloud DNS で確認できます。

次の図は、Managed Service for Apache Kafka クラスタネットワークのアーキテクチャの例を示しています。

Managed Service for Apache Kafka ネットワーク * この例では、クラスタに 3 つのブローカーがあり、クラスタはテナント VPC にあります。

ブローカーはデフォルトの Kafka ポート（9092）を介してクライアントと通信し、一意の IP アドレスを持ちます。この例では、3 つのブローカーの IP アドレスはそれぞれ 10.128.10.2、10.128.10.3、10.128.10.4 です。
3 つのブローカーすべてがブートストラップロードバランサに接続します。ブートストラップアドレスが単一のブローカーまたはゾーンに限定されないため、高可用性とリージョンフォールトトレランスが保証されます。

制限事項

VPC 接続とパブリッククラスタには、次の制限が適用されます。

サブネットリージョン。接続されたサブネットは、クラスタと同じリージョンに存在する必要があります。
サブネット数。クラスタには、最小 1 つ、最大 10 個のサブネットを接続できます。
ネットワークあたりのサブネット数。VPC ネットワークごとに最大 1 つのサブネットをクラスタに接続できます。
サブネットサイズ。接続された各サブネットには、ブローカーごとに少なくとも 1 つの IP アドレスと、ブートストラップアドレス用の 1 つの IP アドレスが必要です。使用可能な IP アドレスが 4 つ以上必要です。詳細については、サブネットのサイズ設定をご覧ください。
パブリッククラスタの接続済みサブネット。パブリックアクセスを有効にするには、トラフィックを送信する必要はありませんが、クラスタに少なくとも 1 つの接続されたサブネットが必要です。
許可する送信元 IP 範囲。パブリッククラスタで許可される送信元 IP 範囲は、IPv4 CIDR 表記で指定する必要があります。各 CIDR サブネットのサイズは /16～/32 の範囲内である必要があります。CIDR 範囲は重複しないようにしてください。IPv6 アドレスはサポートされていません。許可される送信元 IP 範囲は最大 500 個まで指定できます。
検出レコードの DNS の解決。検出 DNS レコードは、FQDN ベースの下り（外向き）ファイアウォールを構成するためだけに設計されています。これらの検出レコードに接続するように Kafka クライアントを構成しないでください。代わりに、ブートストラップアドレスに接続するようにクライアントを構成します。

トラブルシューティング

ネットワーキングの問題のトラブルシューティング方法については、ネットワーキングエラーをご覧ください。

次のステップ

クラスタの作成方法の詳細については、Managed Service for Apache Kafka クラスタを作成するをご覧ください。
クラスタを更新する方法については、Managed Service for Apache Kafka クラスタを更新するをご覧ください。
クラスタのサブネットワークとアクティブなブローカーを表示する方法については、クラスタを表示するをご覧ください。
メッセージのパブリッシュと使用方法については、メッセージのパブリッシュと使用をご覧ください。