コンテンツに移動
ネットワーキング

複数の VPC なしでネットワーク仮想アプライアンス(NVA)をデプロイする - 技術詳解

2023年6月6日
Google Cloud Japan Team

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

ネットワーク仮想アプライアンスを移行するという課題

ネットワーク内のファイアウォールなどのステートフル アプライアンスの統合はこれまで、ネットワーク トポロジに依存してきました。トラフィックがステートフル アプライアンスを通過することを保証するため、これらのアプライアンスは、2 つ以上のネットワーク間のトラフィックが必ずそのパスを通るようにデプロイされます。また、許容できるレベルの復元性を確保するため、アプライアンスは冗長化されます。トラフィックの対称性を保証しながらこの冗長性を提供するルーティングは非常に複雑であり、特定のトラフィック フローのみがアプライアンスを経由するよう指定するポリシーを実装すると、結果的にトポロジが変化し、ルーティングがより一層複雑になります。  

これらのサービスをネットワーク仮想アプライアンス(NVA)としてクラウドに移行すれば、復元性、迅速なフェイルオーバー、トラフィックの対称性を維持したまま、特定のフロー用のネットワーク アプライアンスを挿入して NVA を柔軟にスケールできるようにするために必要なネットワーキングを大幅に簡素化できます。

クラウドで使用されるよく知られたデプロイ パターンの一つに、2 つの VPC の間に NVA をデプロイすることが挙げられます。そうすると、NVA が、信頼されるネットワークと信頼されないネットワークをつなぐ唯一のパスになります。このシナリオを図 1 に示します。ロードバランサを使用すると、このデプロイメントが持つ復元性とトラフィックの対称性の問題は解決しますが、依然としてこのソリューションはトポロジに依存し、NVA を選択的に追加 / 削除する柔軟性に欠けています。ロード バランシングとポリシーベース ルーティングを利用することで、Google Cloud は、ネットワーク仮想アプライアンス(NVA)をお客様のクラウド ネットワークに挿入するための、トポロジに依存しないポリシーベースのメカニズムを提供します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/NVA_Blog_Figure_1.max-1000x1000.jpg
図 1. マルチ NIC / マルチ VPC での NVA の挿入

ロード バランシングとポリシーベース ルーティングを利用することで、Google Cloud は、ネットワーク仮想アプライアンス(NVA)をお客様のクラウド ネットワークに挿入するための、トポロジに依存しないポリシーベースのメカニズムを提供します。このアプローチでは、特定のフロー用の NVA をポリシーに基づいて挿入できます。特定の VPC トポロジ構成は必要ありません。

ソリューションの概要

ポリシーベースのルートを使用した NVA の挿入には、主に次の 2 つの機能要素が関与します。

  1. NVA 復元性

  2. トラフィック ステアリング

このソリューションは、内部 TCP / UDP ロードバランサを利用して NVA をグループ化し、NVA に復元性を提供します。また、ポリシーベース ルーティングを使用してトラフィックを NVA にステアリングします。NVA は、Google Cloud のパートナー エコシステムからさまざまなものを選択できます。図 2 にソリューションの概要を示します。
https://storage.googleapis.com/gweb-cloudblog-publish/images/NVA_Blog_Figure_2.max-1000x1000.jpg
図 2. ポリシーベースの NVA の挿入

NVA の復元性を確保するため、NVA は内部 TCP / UDP ロードバランサのバックエンドとしてマネージド インスタンス グループ(MIG)にデプロイされます。NVA のフロントエンドに内部 TCP / UDP ロードバランサを配置することで、アプライアンスの冗長性、処理能力を柔軟に拡大 / 縮小する自動スケーリング、ステートフルな双方向トラフィック処理をサポートするフローの対称性を実現します。Google Cloud NVA 挿入ソリューションでは、アプライアンスを冗長化するためのネットワーキングが著しく簡素化され、NVA は容易に参照可能なロードバランサ フロントエンドに抽象化されます。

NVA をグループ化して抽象化したら、次のタスクは、トラフィックをロードバランスされた NVA のグループにステアリングすることです。ポリシーベース ルートは、VPC において他のルートより優先され、トラフィックの送信先と送信元に基づいてトラフィックをステアリングします。特定のエンドポイントを通るようにトラフィックをステアリングするため、ポリシーベース ルートはネットワーク内の異なる場所に選択的に配置できます。その結果として生じるマルチステージ ルーティング モデルを図 3 に示します。そこでは、より具体的な接続フローに対して具体的なトラフィック パスを細かく定義できます。ファブリック内の各エンドポイントは同じ宛先について異なるルートのセットを持ち、ルーティングの決定において複数のステージが効果的に生み出されます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/NVA_Blog_Figure_3.max-1000x1000.jpg
図 3. マルチステージ ルーティング

以下の例で、トラフィック ステアリングの動作とポリシーを具体的に説明します。この例では、単一の VPC がワークロード VM をホストし、オンプレミスの施設に接続しています。オンプレミスとサブネット A のワークロードの間のトラフィックは、NVA ファイアウォールで検査する必要があります。3 つのファイアウォール NVA からなるクラスタがマネージド インスタンス グループにデプロイされています。図 4 にこの例を示します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/NVA_Blog_Figure_4.max-1000x1000.jpg
図 4. NVA 挿入における内向きトラフィック

この例では、オンプレミス(送信元アドレス: 10.100.100.0/24)からサブネット A のワークロード VM(10.0.10.2)にトラフィックが送信されています。通常は、このトラフィックは相互接続のアタッチメントを介して VPC ネットワークに入り、VPC テーブルに登録されている直接ルートに従ってワークロード VM に送られます。この例では、ポリシールートを定義してそれをリージョン相互接続に適用しているため、トラフィックは VPC ルートテーブルに従わずに内部 TCP / UDP ロードバランサに送られます。マルチステージ ルーティングとサービス挿入は以下のように行われます。

  1. Cloud Interconnect 接続に到着したトラフィックをチェックして、その IP 送信元と送信先がポリシーベース ルートと一致するかどうかが確認されます。この例では、ポリシーベース ルートと一致した場合、ネクストホップは内部 TCP / UDP ロードバランサ(10.20.20.10)になります。トラフィックは内部 TCP / UDP ロードバランサ フロントエンドに送られます。このポリシーベース ルートは Interconnect に到着したトラフィックにのみ適用され、ネットワーク内に他のエンドポイントはないことに注意してください。

  2. 内部 TCP / UDP ロードバランサがトラフィックを受け取り、送信元および送信先情報のハッシュを評価して、バックエンドにあるいずれかの NVA インスタンスにトラフィックを送信します。

  3. NVA がトラフィックを処理し、同じインターフェースから返します。このトラフィックがネットワーク ファブリックに「再び入る」とき、新しいルーティング ルックアップを実行する必要があります。NVA エンドポイントにはポリシーベース ルーティングは適用されないため、VPC ルートテーブルのルートに従ってトラフィックが直接宛先に送られます。

この例からわかるように、マルチステージ ルーティングは、ネットワーク内の特定のエンドポイントでポリシーベース ルーティングを適用することによって実現されます。単一 VPC 内でのこのトラフィックのリダイレクトはポリシーベース ルートによって行われるため、特定のトポロジや複数の VPC といった前提条件なしにファイアウォールのような NVA を挿入できます。

ポリシーは思いどおりに選択的にすることができます。この例では、サブネット C はポリシーに含まれていないため、サブネット C 宛てのトラフィックは NVA を通じてステアリングされません。

リターンパスも同じように動作します。オンプレミスの宛先へのポリシーベース ルートは、ファイアウォールが必要とされているワークロードにのみ適用されます。この例では、これはサブネット A のワークロード(10.0.10.0/24)です。ネットワーク タグを使用して、ポリシーベース ルートを特定のインスタンスのみに割り当てることができます。また、ロードバランサの対称ハッシュにより、リターン トラフィックが内向きトラフィックと同じ NVA を通ることが保証されます。リターンパスのパケットフローを図 5 に示します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/NVA_Blog_Figure_5.max-1000x1000.jpg
図 5. NVA 挿入におけるリターン トラフィック
  1. 10.0.10.2 からのオンプレミス プレフィックス(10.100.100.0/24)宛てのトラフィックは、ワークロード VM に適用されているポリシーベース ルートと一致します。トラフィックは内部 TCP / UDP ロードバランサ フロントエンドに送られます。

  2. 内部 TCP / UDP ロードバランサでは対称ハッシュが行われるため、内向きトラフィック時に選択されたのと同じ NVA が外向きトラフィックに対しても選択されます。

  3. NVA がトラフィックを処理し、クラウド ネットワーク ファブリックに返します。NVA にはポリシールートは適用されないため、VPC ルートテーブルに登録されているオンプレミスへのルートに従ってトラフィックが送られます。

オンプレミス ルートは動的に学習されます。リターン トラフィックのポリシーベース ルーティング ポリシーを更新する必要を避ける簡単な対策の一つに、ポリシーベース ルーティング ポリシーで 0/0 の宛先を使用することが挙げられます。このようにすると、このポリシーベース ルートが適用されているインスタンスから送信されたすべてのトラフィックが内部 TCP / UDP ロードバランサに送られることに留意してください。ポリシーベース ルーティングは、VPC ルートテーブルに登録されているすべてのルート(サブネット ルートを含む)より優先されます。これは、VM 間のフローを含むすべてのフローを NVA を通じてステアリングしたい場合に役立ちます。ポリシーベース ルートを 0/0 の宛先に一致させ、サブネット A とサブネット C のすべての VM に適用すると、すべての VM 間通信(サブネット間およびサブネット内)が NVA を通じてステアリングされることが保証されます。NVA を介した VM 間通信(East-West)が望ましくない場合は、ポリシーベース ルーティング ポリシーをオンプレミス プレフィックス、またはオンプレミス空間を集約する包括プレフィックスと一致させます。

同じ動作を異なるトポロジで使用できます。上記の例は、VPC ネットワーク ピアリングを介してトランジット VPC に接続されているスポーク VPC にワークロードが存在するマルチ VPC トポロジに簡単に展開できます。内向きトラフィックについては、動作は変わりません。リターンパスについては、ルート オーバーライドを関連インスタンスに適用しなければならないポリシーベース ルートよりも静的ルートを使用することをおすすめします。図 6 にこのシナリオを示します。
https://storage.googleapis.com/gweb-cloudblog-publish/images/NVA_Blog_Figure_6.max-1000x1000.jpg
図 6. NVA 挿入における VPC ネットワーク ピアリングでのリターン トラフィック

リターン ポリシーに静的ルートを使用することで、オンプレミス プレフィックス空間内の多様性を抽象化するデフォルトの(0/0)一致を使用できます。また、オンプレミスのロケーションから学習された動的ルートが VPC ピアリングによって伝播しないようにする必要もあります。これにより、オンプレミスへの特定のルートを持たないスポーク VPC のワークロードは、トランジット VPC の内部 TCP / UDP ロードバランサを指す 0/0 静的ルートを使用するため、NVA を介したリターンパスを効果的に提供できます。静的ルートは VPC ルートテーブルに登録されているローカル サブネットのサブネット ルートより優先度が低いため、この構成では VPC 内部の VM 間のトラフィックは NVA にステアリングされません。スポークで 0/0 静的ルートを使用すると、インターネットに向かうすべてのトラフィックも NVA にステアリングされます。

静的ルートの一致する宛先として 0/0 を使用すると、スポーク VPC 同士が通信できるようになります。静的ルートは VPC ルートテーブルに登録されているローカル サブネットのサブネット ルートより優先度が低いため、この構成では VPC 内部の VM 間のトラフィックは NVA にステアリングされませんが、スポーク間のトラフィックは NVA にステアリングされます。通信を可能にするには、NVA にルーティングされるスポーク間トラフィックを NVA で明示的に許可する必要があります。これがうまく機能するのは、ソリューションに存在する NVA グループの数が 1 つだけの場合に限られます。マルチリージョンのケースのように複数の NVA MIG が存在すると、トラフィックの対称性が問題になります。十分な労力を費やせば、複数の NVA グループを通じてスポーク間通信を可能にするポリシーを設計しデプロイすることは可能ですが、これを追求することはおすすめしません。

リージョンに関する考慮事項

複数のリージョンを使用する場合は、複数の NVA グループ(通常はリージョンごとに 1 つずつ)が必要になります。どの NVA インスタンス グループを使用するかは、そのフローに関与するクラウド上のワークロードに合わせることをおすすめします。Google ではこのコンセプトを「リージョン アフィニティ」と呼んでおり、同じリージョン内の NVA インスタンス グループとワークロードの間でアフィニティを作成することをおすすめしています。リージョン A のワークロードに関わるフローの場合は、リダイレクト ポリシーによってトラフィックをリージョン A の NVA インスタンス グループにステアリングします。つまり、North-South フローに対して相互接続で適用されるインバウンド ポリシーはワークロード宛先サブネットと一致させ、宛先サブネットと同じリージョンにある内部 TCP / UDP ロードバランサをネクストホップとして含めます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/NVA_Blog_Figure_7.max-1000x1000.jpg
図 7. リージョン アフィニティ

North-South トラフィック フローの場合、あるリージョンの相互接続を介して Google Cloud に入り、そこから別のリージョンのワークロードにアクセスするトラフィックは、宛先リージョンの NVA インスタンス グループにリダイレクトされます。この NVA インスタンス グループの内部 TCP / UDP ロードバランサの VIP には、VPC ルーティング テーブルの情報を使用して到達できます。他のリージョンのクライアントが内部 TCP / UDP ロードバランサに到達できるように、内部 TCP / UDP ロードバランサでグローバル アクセスを有効にする必要があります。サービスノードからオンプレミスへのリターン トラフィックは VPC ルーティング テーブルに依存します。外向きルートがリージョンを越えて認識されるように、VPC でグローバル動的ルーティングを有効にする必要があります。リターン トラフィックは、返信元ワークロードと同じリージョンにあるロードバランサにルーティングされます。

このソリューションの復元性プロファイルは、MIG と内部 TCP / UDP ロードバランサ フロントエンドがゾーンにまたがって分散していることでリージョン内に提供される高い復元性に支えられています。ポリシーベース ルーティングでは静的ポリシーが使用されるため、NVA インスタンス グループ全体の障害に備えたクロスリージョン フェイルオーバーは選択肢にありません。

Babi Seal 氏(ロード バランシングとクラウド ネットワーキングのプロダクト マネージャー)、Zach Seils 氏(Google Cloud のネットワーキング スペシャリスト カスタマー エンジニア)、Osvaldo Costa 氏(Google Cloud のネットワーキング スペシャリスト カスタマー エンジニア)に深く感謝します。


- プロダクト マネージャー Victor Moreno
投稿先