コンテンツに移動
AI & 機械学習

Vertex AI Pipelines のネットワーク到達性を拡張

2022年3月15日
https://storage.googleapis.com/gweb-cloudblog-publish/images/vertexai.max-2600x2600.jpg
Google Cloud Japan Team

※この投稿は米国時間 2022 年 3 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

Vertex AI Pipelines とジョブは、Service Networking API を使用してネットワークを構成します。そのため、プロジェクトのネットワークにピアリングされているテナント プロジェクト内の Google が所有する VPC ネットワークで実行します。このピアリングには、次の標準 VPC ピアリング ネットワークの制約が適用されます。

  • Google が所有するネットワークには、独自のデフォルト ルートがあり、ユーザーのネットワークのデフォルト ルートはインターネットにインポートされません。

  • ピアリングされたネットワークは、静的ルートと動的ルートを相互にエクスポートするように構成されます。ただし、推移的なピアリングは許可されません。したがって、テナント プロジェクトの Vertex AI ジョブは、デフォルトではネットワークにピアリングされている他のネットワークに到達できません。

このようなことから、たとえば、Vertex AI ジョブへのアクセスを許可するファイアウォール ルールをパブリック エンドポイントに適用できないように最初は見えます。さらに、これらのジョブは、ネットワークとピアリングされている他のサービスに到達するために、ネットワークを介して即座にルートすることができません。

この記事では、Google が管理する VPC 内にある Vertex AI Pipeline ジョブが次の接続を完了するための構成を提案しています。

  • 自身が制御する送信元のパブリック IP を使用してインターネット上のエンドポイントにアクセスする

  • ネットワークを介して接続を転送して、ピアリングされた他のエンドポイントにアクセスする

データ サイエンティストとして、組織のネットワーク管理者とネットワーク要件に関する会話にこれをリファレンスとして役立てることができます。

送信元パブリック IP の制御

一部のユースケースでは、パイプライン ジョブがインターネット経由でエンドポイントに接続できるようにする必要があります。このような接続を許可するファイアウォール ルールを構成するために、管理者はパイプラインによって使用される送信元パブリック IP を把握している必要があります。

パイプライン ジョブは、ユーザーがアクセスできない Google が所有するプロジェクトで実行されるため、そこからインターネットへの直接の送信接続を制御することはできません。

IAM 認証を使用してこのようなエンドポイントを保護することをおすすめしますが、一部のユーザーはサービス拒否攻撃から保護し、組織のセキュリティ要件に遵守するファイアウォール ルールをデプロイする必要もあります。

次のワークフローは、このような接続用の送信元 IP を制御する方法を示しています。

NAT インスタンスを介したアクセス

この構成によりパイプラインは、ユーザーが制御する NAT インスタンスの送信元 IP を使用してインターネット上のエンドポイントにアクセスできるようになります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_Vertex_AI_Pipelines.max-700x700.jpg

ワークフロー

  • 1 つのインターフェースをピアリングされたネットワークに、もう 1 つを送信ネットワークに備えた NAT インスタンスを作成します。要件を満たす任意の画像を選択できますが、話を先に進めるために、ここでは標準の Debian インスタンスを使用します。注: User Network1 は NAT インスタンスを 8.8.8.8 へのネクストホップとして参照するため、NAT インスタンスがトラフィックを 8.8.8.8  に転送して、User Network2 の他のインターフェースに送り、User Network1 でルーティングがループすることを防ぐ必要があります

  • このインスタンス上で IP 転送が有効になっていて、それがパブリック IP であることを確認してください

  • プロジェクトの VPC ルートのページにアクセスし、インスタンスをネクストホップとしたターゲットに静的ルートを追加します。以下の例では、ターゲットとして 8.8.8.8 を使用しています

  • また、ピアリング構成にアクセスし、[カスタムルートのエクスポート] を有効にして、この静的ルートがテナント プロジェクトにエクスポートされるようにします。ここでは、8.8.8.8 への静的ルートがサービス ネットワークにエクスポートされていることがわかります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_Vertex_AI_Pipelines.max-1200x1200.jpg

  • インスタンスの UI にアクセスします。そのインスタンスを構成して、転送されたトラフィックの送信元 IP をその固有の送信インターフェースに変換します。以下の例では、Debian インスタンス上のインターフェース en4 は、ピアリングされたネットワーク内にあります。en5 は、送信ネットワークです。

読み込んでいます...

  • また、User Network2 の送信インターフェースとゲートウェイをネクストホップとしたエンドポイントへの静的ルートで、インスタンスを構成します。

読み込んでいます...

インスタンスからの次のパケット キャプチャは、パイプラインの 10.100.1.2 アドレスからの送信接続がインスタンスの 10.1.1.2 アドレスに変換されることを確認します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_Vertex_AI_Pipelines.max-1000x1000.jpg
https://storage.googleapis.com/gweb-cloudblog-publish/images/4_Vertex_AI_Pipelines.max-1000x1000.jpg

プロキシを介したアクセス

特定のサービスに接続するときに Vertex が使用する送信元 IP を制御する必要がある場合は、ネットワークにサービス プロキシを構成することもできます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/5_Vertex_AI_Pipelines.max-500x500.jpg

Vertex AI ジョブは、直接ピアリングされたネットワークのプロキシに到達できます。パイプラインからの外部エンドポイントへのリクエストは、プロキシを介してリレーされ、プロキシのパブリック IP アドレスから発信されているように表示されます。

同様に、Vertex AI ジョブからの接続は、プロキシのパブリック IP から発信されているようにパブリック エンドポイントに表示されます。

他のピアリングされたサービスへのアクセス

パイプラインは、サービス ネットワークを使用する別のサービスへのアクセスが必要な場合があります。

この話を先に進めるために、ここでは Memorystore for Redis を使用します。推移的ピアリングはサポートされていないことを思い出してください。以下の例では、Vertex ネットワークからの接続は、デフォルトで自身のネットワークを介して Redis ネットワークに転送できません。

https://storage.googleapis.com/gweb-cloudblog-publish/images/6_Vertex_AI_Pipelines.max-700x700.jpg

ピアリングされたサービスのコロケーション

推奨されるオプションは、同じ Service Networking の予約で相互に通信する必要があるすべてのサービスをデプロイすることです。以下の例では、Vertex AI ジョブが Redis に直接到達できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/7_Vertex_AI_Pipelines.max-600x600.jpg

この範囲を拡張して他のサービスに対応する方法については、Vertex AI の IP 範囲を予約するをご参照ください。多くのサービスには、新しい範囲を予約するか、既存の範囲を使用するかのオプションが提供されています。既存の範囲を使用する方法については、専用のサービス ドキュメントをご参照ください。

NAT インスタンス

NAT インスタンスまたはプロキシを介して Vertex AI Pipelines のパブリック IP を割り当てるための上記のワークフローは、この Redis へのアクセス例に簡単に取り入れられます。

次の図では、User Network1 に、NAT インスタンスをネクストホップとした Redis への静的ルートがあります。これを Vertex ネットワークにエクスポートします。Vertex AI からの接続は、User Network2 の NAT インスタンスのインターフェースから発信されているかのように Redis に表示されます。

サービス ネットワーク IP 範囲が新たに追加された場合に備えて、この構成により管理するルートの数が減らされる可能性があります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/8_Vertex_AI_Pipelines.max-900x900.jpg

ルーティング インスタンス

NAT インスタンスを User Network1 と User Network2 の間のルーティング インスタンスに置き換えることもできます。

この構成では、User Network1 の Redis IP 範囲への静的ルートと User Network2 の Vertex AI IP 範囲への静的ルートが必要です。両方の静的ルートは、ネクストホップとしてルーティング インスタンスを指します。

この構成は、NAT インスタンスを使用するよりトラブルシューティングが簡単な場合があります。双方向の接続を維持するために、新しいサービスを導入する場合、ネットワーク管理者とどのように連携して、両方のネットワークのルーティング テーブルを更新するかです。

Cloud VPN

ルーティング インスタンスではなく、User Network1 と User Network2 の間に Cloud VPN を構成することもできます。この場合も静的ルートを双方向にエクスポートする必要があります。それにより、それぞれのサービス ネットワークが相互に到達するようにネットワークを介してルートすることを認識できるようになります。静的ルートを維持する必要がありますが、このオプションにより、ルーティング インスタンスを自分で管理する必要がなくなります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/9_Vertex_AI_Pipelines.max-800x800.jpg

プロキシ インスタンス

同様に、Vertex がプロキシを経由して Redis にアクセスする場合、それらの接続はプロキシの IP から発信されているかのように表示されます。Redis インスタンスは、Vertex AI ネットワークに到達する方法を知らなくても応答できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/10_Vertex_AI_Pipelines.max-700x700.jpg

概要

Vertex AI は、Service Networking API を使用して Google が所有するテナント プロジェクトをコンシューマ プロジェクトに接続できるようにする、数あるサービスの一つです。このようなサービスのデプロイガイドでは、サービスをプロジェクトのエンドポイントに接続する方法について説明しています。

このドキュメントは、ネットワーク構成の説明に及んでおり、Vertex AI をインターネット内の他の Service Networking コンシューマまたはエンドポイントに接続するためのオプションを提示しています。



- テクニカル ソリューション エンジニア Bernie Ongewe
投稿先