クライアントは、プロジェクト内の任意の Virtual Private Cloud（VPC）ネットワークから Managed Service for Apache Kafka クラスタに接続できます。 Google Cloud
このページでは、Managed Service for Apache Kafka でのネットワーキングの構成方法、Kafka クライアントとクラスタ間の接続を有効にする方法、プロジェクト間の接続を有効にする方法について説明します。
概要
クラスタを作成すると、サービスは、 が管理する Google CloudVPC ネットワークにクラスタを配置します。このネットワークはテナント ネットワークと呼ばれます。 Managed Service for Apache Kafka クラスタごとに、独自の分離されたテナント ネットワークがあります。クライアント アプリケーションがクラスタと通信できるようにするには、VPC ネットワーク内のサブネットをテナント ネットワークに接続します。
次の図は、2 つの Google Cloud プロジェクト（project-1 と
project-2）を示しています。Managed Service for Apache Kafka クラスタは project-1 にあります。
次のサブネットがクラスタに接続されています。
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 つの サブネット を指定する必要があります。後で、クラスタを 更新して サブネットを追加または削除できます。
接続されたサブネットは、クラスタと同じ Google Cloud プロジェクトに属していても、 別のプロジェクトに属していてもかまいません。接続されたサブネットはクラスタと同じリージョンに存在する必要がありますが、同じ VPC 内の任意のリージョンのクライアントは、そのサブネット内の IP アドレスに接続できます。クラスタに接続できる VPC ネットワークごとのサブネットは 1 つまでです。
クラスタに接続されているサブネットを表示するには、 クラスタのサブネットを表示するをご覧ください。
クラスタ DNS エントリ
サブネットをクラスタに接続すると、 サービスは、クラスタのブートストラップ アドレスとブローカーの DNS エントリをそのサブネットネットワーク内に作成します。Kafka クライアントはブートストラップ アドレスを使用してブローカーを特定し、接続を確立します。
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 クライアントがある場合は、 次の方法でクラスタに接続できます。
次のセクションでは、これらのオプションについて説明します。
プロジェクト間でクラスタを接続する
他のプロジェクトのサブネットをクラスタに接続できます。プロジェクト間のアクセスを有効にするには、クラスタに関連付けられている Google マネージド サービス アカウントに権限を付与する必要があります。Kafka クライアントがクラスタにアクセスするプロジェクトごとに、サービス アカウントにそのプロジェクトに対する Managed Kafka Service Agent IAM ロールが必要です。このロールにより、クラスタはリソースにアクセスして、ネットワーク リソースと DNS エントリを作成できます。Google Cloud
例: project-1 にクラスタが含まれていて、project-2 のクライアントがクラスタにアクセスできるようにする場合は、project-1 の Managed Kafka サービス アカウントに project-2 に対する Managed Kafka Service Agent ロールを付与します。次に、サブネットをクラスタに接続するの説明に従って、project-2 のサブネットをクラスタに接続します。
必要なロールを付与する手順は次のとおりです。
コンソール
Kafka クライアントが Managed Service for Apache Kafka クラスタに アクセスする Google Cloud プロジェクトを決定します。
プロジェクトごとに、 Google Cloud コンソールで、そのプロジェクトの [IAM] ページ に移動します。
[**アクセスを許可**] をクリックします。
[新しいプリンシパル] フィールドに、次の値を入力します。
service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.comCLUSTER_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 ホスト プロジェクトに必要なロールを Managed Kafka サービス アカウントに付与します。
Managed Service for Apache Kafka クラスタを 共有 VPC ネットワーク内のサブネットに接続します。
共有 VPC ホスト プロジェクトまたはサービス プロジェクトのクライアントは、クラスタに接続できます。
ネットワーク アーキテクチャで共有 VPC を使用する場合については、 VPC 設計のベスト プラクティスとリファレンス アーキテクチャをご覧ください。
クラスタのネットワーク アーキテクチャ
このセクションでは、Managed Service for Apache Kafka で使用されるネットワーキング アーキテクチャの詳細について説明します。
Kafka クラスタは、テナント ネットワークと 1 つ以上のコンシューマー ネットワークにまたがります。
テナント ネットワークでは、クラスタに 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 クラスタ ネットワークのサンプル アーキテクチャを示しています。
この例では、クラスタに 3 つのブローカーがあり、クラスタはテナント VPC にあります。
ブローカーはデフォルトの Kafka ポート（9092）を介してクライアントと通信し、一意の IP アドレスを持ちます。この例では、3 つのブローカーの IP アドレスはそれぞれ 10.128.10.2、10.128.10.3、10.128.10.4 です。
3 つのブローカーはすべてブートストラップ ロードバランサに接続します。ブートストラップ アドレスは単一のブローカーまたはゾーンに限定されないため、高可用性とリージョン フォールト トレランスが確保されます。
トラブルシューティング
ネットワーキングの問題のトラブルシューティング方法については、 ネットワーキング エラーをご覧ください。