このガイドを読む前に、VPC ピアリングの資料を理解しておいてください。
デフォルトでは、ピアリング構成は、ピアリングされた Vertex AI ネットワークがローカル サブネットのエンドポイントに到達することのみを許可します。カスタムルートをエクスポートすると、プロデューサー ネットワークは、お客様のネットワークに静的ルートまたは動的ルートがある他のネットワークにアクセスできます。
推移的ピアリングはサポートされていないため、「カスタムルートのエクスポート」を有効にしても、Vertex AI からの接続は、ネットワークに直接ピアリングされている他のネットワークのエンドポイントに到達できません。次の図の例では、パケットはピアリング接続 #1 を通過できますが、ピアリング接続 #2 は通過できません。
Vertex AI がユーザー ネットワーク #2 に到達できるようにするには、次の図に示すように、ピアリング接続 #2 を VPN #2 に置き換えます。
ピアリング接続 #1 でカスタムルートを有効にすると、Vertex AI ネットワークからの IP パケットがユーザー ネットワーク #2 に到達できるようになります。
ユーザー ネットワーク #2 からのレスポンス パケットを Vertex AI ネットワークにルートバックできるようにするには、ユーザー ネットワーク #2 のルーティング テーブルにも戻りルートが存在する必要があります。VPN ルートは Cloud Router の Border Gateway Protocol（BGP）を使用して交換されます。このため、ユーザー #1 はピア ユーザー ネットワーク #2 への 10.1.0.0/16 の Vertex AI ネットワーク範囲にルートをアドバタイズして、BGP 構成をカスタマイズすることができます。
VPN #1 BGP 構成の両側を編集して、オンプレミス ネットワークと Vertex AI ネットワークが相互にルートを学習し合えるようにできます。Vertex AI ネットワークから転送パスのパケットを送信することも、単一のネットワークに関して連続するピアリング接続でレスポンス パケットを送信することもないため、これらの転送の試行はいずれも明示的にブロックされています。
Vertex AI からインターネットへの接続を設定する
ワークロードの起動時にネットワークが指定されていない場合、ワークロードは別の Google 管理のプロデューサー プロジェクトで実行されます。
ネットワークが指定されている場合、コンシューマー プロジェクトにピアリングされたプロデューサー プロジェクトでワークロードが実行されます。
デフォルトでは、Vertex AI ネットワークにはインターネットへの独自のルートが、プロデューサー ネットワークにはインターネットへの独自のデフォルト ルートがあります。
プロデューサー ネットワークからのアウトバウンド接続を強制的にネットワーク経由でルーティングするには、ピアリングの VPC Service Controls を有効にします。これは VPC Service Controls とは別の構成であることに注意してください。
ピアリングで VPC Service Controls を有効にすると、Vertex AI ネットワークで次の変更が行われます。
- デフォルトのインターネット ルートを削除します。
- デフォルト インターネット ゲートウェイのネクストホップを使用して、宛先
199.36.153.4/30のルートを作成します。 - ホスト名をこれらの 4 つのアドレスのいずれかにマッピングする適切なレコードを使用して、
*.googleapis.comの Cloud DNS 限定公開マネージド ゾーンを作成します。 - そのゾーンに対して、
servicenetworkingVPC ネットワークの使用を承認します。
この変更を行うと、ネットワークからデフォルト ルートをエクスポートして、インターネットへのアウトバウンド接続が VPC ネットワーク経由でルーティングされるようになります。この変更により、Vertex AI からのアウトバウンド トラフィックに必要なポリシーを適用することもできます。
VPC Service Controls の操作
ワークロードにネットワークが指定され、VPC Service Controls が有効になっている場合、ワークロードは、コンシューマー プロジェクトにピアリングされ、コンシューマー ネットワークと同じポリシーが適用されるプロデューサー ネットワークで実行されます。
これらのポリシーがアウトバウンド トラフィックをブロックすると、ワークロードも同様にインターネットに到達できなくなります。この場合、前の手順で、ワークロードからのアウトバウンド トラフィックを VPC ネットワークの NAT インスタンスを通過させる必要があります。
プロキシを使用して Vertex AI から接続を設定する
Vertex AI からのアウトバウンド IP を制御するもう一つの方法は、ワークロードからのアウトバウンド接続に、自身が管理するウェブプロキシを経由させることです。これにより、コンプライアンスのためにアウトバウンド接続を検査することもできます。
ただし、サードパーティのプロキシを使用すると、認証に対する申し立てに対し、ユーザーがプロキシの証明書を管理する必要が出てきます。さらに、これらのプロキシでは、Vertex AI SDK と API で想定される暗号スイートのリストが提案されない場合があります。
Google Cloud では、このパターンを容易に実現するために Secure Web Proxy が提供されています。クイックスタート ガイド Secure Web Proxy インスタンスをデプロイするに沿ってワークロードを調整し、アウトバウンド接続に使用できるようになりました。これらの接続は、プロキシの送信元 IP アドレスから発信されているように表示されます。
KFP ライブラリがコンポーネント イメージにまだインストールされていない場合、パイプラインは、プロキシを指定したコードを実行する前に、そのライブラリをインストールしようとします。
パイプラインがインターネットからパッケージをインストールするためにプロキシに依存している場合、この試行は失敗し、次のようなエラーが表示されることがあります。
Could not find a version that satisfies the requirement kfp==2.7.0
このような場合、つまりコードを実行する前に KFP をインストールできない場合は、KFP がすでにインストールされているイメージを使用する必要があります。
任意のベースイメージに KFP を追加して、リポジトリに push できます。
次の Dockerfile の例では、python:3.8 ベースイメージに KFP を追加しています。
FROM python:3.8
RUN pip install kfp==2.7.0
次に、このイメージを使用するようにパイプライン @component を構成します。
@component(base_image="$PATH_TO_YOUR_REPOSITORY:YOUR_IMAGE")
パイプライン コンポーネントが実行されると、コードはプロキシを介して他のパッケージを自由にインストールできます。次の例では、https://10.10.10.10:443 のプロキシを使用して numpy をインストールします。
import subprocess
subprocess.call(['pip', 'install', '--proxy', 'https://10.10.10.10:443', 'numpy'])`
API アクセスの許可リストを設定する
Vertex AI ワークロードと Google API の間のトランザクションでは、ワークロードから Google API が使用する IP 範囲へのアクセスを許可する必要があります。そのためには、提供されているスクリプトを実行してデフォルト ドメインの IP アドレスを返すことができます。