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

クライアントは、 Google Cloudプロジェクトの任意の Virtual Private Cloud（VPC）ネットワークから Managed Service for Apache Kafka クラスタに接続できます。

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

概要

クラスタを作成すると、サービスは Google Cloudによって管理される VPC ネットワークにクラスタを配置します。このネットワークはテナントネットワークと呼ばれます。Managed Service for Apache Kafka クラスタには、それぞれ独自の分離されたテナントネットワークがあります。クライアントアプリケーションがクラスタと通信できるようにするには、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 つのサブネットを指定する必要があります。後で、クラスタを更新して、サブネットを追加または削除できます。

接続されたサブネットは、クラスタと同じ 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 クライアントがある場合は、次の方法でクラスタに接続できます。

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

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

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

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

例: project-1 にクラスタが含まれており、project-2 のクライアントがクラスタにアクセスできるようにする場合は、project-1 の Managed Kafka サービスアカウントに project-2 の Managed 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 ホストプロジェクトで必要なロールを Managed Kafka サービスアカウントに付与します。
Managed Service for Apache Kafka クラスタを共有 VPC ネットワークのサブネットに接続します。

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

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

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

このセクションでは、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 ネットワーク構成のトラブルシューティング

サービスが Managed Service for Apache Kafka クラスタにアクセスするためのコンシューマー VPC ネットワークを構成できない場合、次のようなメッセージがログに記録されます。

Managed Service for Apache Kafka failed to set up networking in VPC subnet
to the cluster project.

Kafka クライアントが Managed Service for Apache Kafka クラスタに接続できない場合は、次のトラブルシューティングの手順を行います。

コンシューマー VPC ネットワークの親プロジェクトで Compute Engine API と Cloud DNS API を有効にします。
Managed Service for Apache Kafka クラスタとコンシューマー VPC ネットワークが異なるプロジェクトにある場合は、必要な権限を構成します。複数のプロジェクトにわたってクラスタを接続するをご覧ください。
組織のポリシー制約によって、サービスがコンシューマー VPC ネットワークのプロジェクトに必要なリソースを作成できないことがないようにします。
クライアントが正しいブートストラップアドレスを使用していることを確認します。
Kafka クライアントが、Managed Service for Apache Kafka クラスタにアクセスするように構成された VPC ネットワークで実行されていることを確認します。
パソコンやノートパソコンで Kafka クライアントを実行する場合は、Managed Service for Apache Kafka クラスタにアクセスするためのプロキシとして使用する Compute Engine インスタンスを設定できます。詳細については、クライアントマシンを設定するをご覧ください。

Managed Service for Apache Kafka のネットワーキングを構成する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

概要