このドキュメントは、Google Cloud で一元管理されたネットワーク アプライアンスを実行するネットワーク管理者、ソリューション アーキテクト、運用の専門家を対象としています。Google Cloud の Compute Engine と Virtual Private Cloud（VPC）ネットワーキングに関する知識が必要です。
企業環境では、インターネット、オンプレミス ネットワーク、他のクラウドへのルーティングで、トラフィックのモニタリング、変換、またはブロックを行う VM ベースの仮想アプライアンスが必要になることが少なくありません。同じクラウド環境の別の部分へのルーティングでも、このようなアプライアンスが必要になることがあります。
このドキュメントでは、VPC ネットワークをセグメント化し、一元管理された仮想ネットワーク アプライアンスに相互接続する設計オプションについて説明します。VPC ネットワーク、オンプレミス ネットワーク、インターネット間の通信はすべて、一元管理されたデバイスを経由してルーティングされます。アプライアンスのグループをデプロイすることで高可用性構成を実現できます。高可用性を必要としない場合は、単一のネットワーク アプライアンスをデプロイできます。
仮想アプライアンスを介したトラフィックのルーティングは困難な場合があります。たとえば Google Cloud では、インターネットを指すルートを置き換えて、トラフィックを一連の仮想アプライアンスにリダイレクトできますが、VPC ネットワーク内のサブネットワーク間でルーティング動作を変更することはできません。サブネットワーク間のルーティングは自動的に行われ、これらのルートは削除またはオーバーライドできません。
また、仮想アプライアンスの役割が重要であることから、可用性の高い構成でデプロイする必要があります。すべてのトラフィックが仮想アプライアンスのいずれかを経由してルーティングされ、これらのアプライアンス間のフェイルオーバーが自動的に行われるようにする必要があるため、これは困難です。
アーキテクチャ
次の図は、一元管理された仮想ネットワーク アプライアンスを特長とする複数の設計オプションについて、典型的なユースケースを示しています。
上の図は、セグメント化された VPC ネットワーク、オンプレミス ネットワーク、インターネットの間の通信パスと、一元管理された仮想ネットワーク アプライアンスを介してそれらのパスがルーティングされる方法を示しています。
このアーキテクチャの主なユースケース
このアーキテクチャは、トラフィックのルーティングを行う仮想ネットワーク アプライアンスを必要とする複数のユースケースに使用できます。次の点に注意してください。
- さまざまなベンダーの多くのアプライアンスを Google Cloud Marketplace で確認できます。
- アプライアンス ベンダーによっては、ウェブサイトやサポートページに Google Cloud 向けにカスタマイズされた Compute Engine イメージも用意されています。
- オープンソースのネットワーキング ソフトウェアを使用すると、独自の仮想アプライアンスを作成できます。また、独自のイメージを作成することも可能です。
多くの場合、ベンダーでは高可用性構成で仮想化アプライアンスを実行するための独自のリファレンス アーキテクチャまたはデプロイガイドを用意しています。詳細については、ベンダーのウェブサイトをご覧ください。
ベンダーのリファレンス アーキテクチャが、このドキュメントで説明しているすべてのオプションを網羅しているとは限りません。
各アプローチの利点と欠点を理解することが重要です。トラフィックがルーティングされる仮想アプライアンスの一般的なユースケースは次のとおりです。
- 次世代ファイアウォール（NGFW）。一元管理されたファイアウォールのセットで、VPC ファイアウォール ルールで利用できない機能を提供する仮想マシンとして機能します。これが最も一般的なユースケースです。NGFW 製品の典型的な機能として、ディープ パケット インスペクション（DPI）とアプリケーション レイヤでのファイアウォールがあります。一部の NGFW ファイアウォールでは、TLS / SSL トラフィック検査の他に、以下の箇条書きのユースケースで説明する他のネットワーキング機能も提供されます。
- 侵入検知システム / 侵入防止システム（IDS / IPS）ネットワーク ベースの IDS では、不正な可能性があるトラフィックをすべて可視化する必要があります。侵入を防止するため、トラフィックは通常、トラフィック パスの IPS によって直接ブロックされます。
- 透過プロキシ。透過プロキシは、HTTP(S) トラフィックのモニタリングやウェブアクセスの制限を適用するためによく使用されます。
- ネットワーク アドレス変換（NAT）ゲートウェイ。NAT ゲートウェイは IP アドレスとポートを変換します。これにより IP アドレスの重複を回避できます。Google Cloud は Cloud NAT をマネージド サービスとして提供していますが、このサービスは、インターネットに到達するトラフィックにのみ対応しています。オンプレミス トラフィックや他の VPC ネットワークでは利用できません。
- ウェブ アプリケーション ファイアウォール（WAF）。WAF は、ウェブ アプリケーションに送信される不正な HTTP トラフィックをブロックします。Google Cloud では、Google Cloud Armor セキュリティ ポリシーを介して WAF 機能を提供します。正確な機能は WAF ベンダーによって異なるため、必要なものを正確に判断することが重要になります。
一般的な要件
一元管理された仮想アプライアンスを介してトラフィックをルーティングする際の要件は、個別のユースケースによって異なります。ただし、次の要件は一般的に適用されます。
- 異なるネットワーク セグメント（別のチームによって管理されており、セキュリティ要件が異なる環境など）間のトラフィック、またはアプリケーションの異なるモジュール間のトラフィックは、すべて一元管理された仮想アプライアンスを通過する必要があります。
- インターネットとセキュア環境との間で送受信されるトラフィックはすべて、一元管理された仮想アプライアンスを通過する必要があります。
- Cloud VPN、Dedicated Interconnect、または Partner Interconnect を介して Google Cloud に接続されたオンプレミス システムとの間で送受信されるトラフィックは、すべて一元管理された仮想アプライアンスを通過する必要があります。
- 複数の一元管理された仮想アプライアンスは、アクティブ / アクティブまたはアクティブ / パッシブのいずれかの高可用性構成で設定されます。いずれかの仮想アプライアンスでソフトウェアまたはハードウェアの問題が発生した場合は、フェイルオーバーが自動的に実施されます。
- すべてのトラフィックはステートフルにルーティングされるため、2 つの仮想マシン間の 1 つのトラフィック フローは常に同じ仮想アプライアンスを通過します。
- 一元管理化された仮想アプライアンスのシステムのスループットは、次のいずれかの方法でスケーリングできます。
- 仮想アプライアンスの垂直スケーリング: 各仮想マシンのコア数またはメモリ量を増やします。
- 仮想アプライアンスの水平スケーリング: トラフィックの分散に使用する仮想アプライアンスの数を増やします。
アーキテクチャ オプション
仮想アプライアンス間で高可用性を実現するための複数のオプションが用意されています。ネットワーク セグメントを仮想アプライアンスに接続するためのオプションも複数用意されています。
高可用性を実現するためのオプションをネットワーク セグメントを接続するためのオプションと組み合わせることができます。このドキュメントの後半で説明する一般的なオプションは、VPC ネットワーク ピアリングとパススルー ネットワーク ロードバランサをネクストホップとして使用するアーキテクチャです。
高可用性オプションの選択
次の 2 つの方法で複数のインスタンスを使用し、アーキテクチャを構築して一元管理されたアプライアンスの高可用性を実現できます。
内部パススルー ネットワーク ロードバランサをネクストホップとして使用する。このアプローチでは、複数の仮想アプライアンスを内部パススルー ネットワーク ロードバランサの背後にあるマネージド インスタンス グループに配置します。このロードバランサは、アプライアンスに接続されている VPC ネットワークのデフォルト ルートを置き換えるデフォルト ルートのネクストホップとして使用されます。アプライアンスは、内部パススルーネットのワークロードバランサのフェイルオーバーを採用することで、アクティブ / アクティブ構成（標準構成）またはアクティブ / パッシブ構成で使用できます。ヘルスチェックは正常なインスタンスにトラフィックを転送します。障害発生時にアプライアンスを自動的に再作成する場合は、自動修復を使用できます。デバイスで複数のネットワーク インターフェースが使用されている場合、ネクストホップとして機能する内部パススルー ネットワーク ロードバランサは、任意のネットワーク インターフェースにバックエンドを持つことができます。
次の図は、内部パススルー ネットワーク ロードバランサをネクストホップとして使用する場合のトポロジを示しています。
上の図は、ネクストホップとして機能する内部パススルー ネットワーク ロードバランサの背後にある複数の仮想アプライアンスを含む、VPC ネットワーク内のマネージド インスタンス グループを示しています。
ルーティングを使用する。このアプローチでは、Google Cloud のルートにより、接続された VPC ネットワークから仮想アプライアンスにトラフィックが転送されます。異なる優先度ルートを使用してアクティブ / パッシブ構成でアプライアンスを使用できます。または、ルートが同じ優先度で構成されているときはアクティブ / アクティブ構成でアプライアンスを使用できます。その場合、トラフィックを分散させるには、等価コスト マルチパス（ECMP）ルーティングを使用します。自動修復を使用すると、正常でないアプライアンスを自動的に再起動できます。
次の図は、ルーティングの使用に関するトポロジを示しています。
上の図は、Google Cloud のルートが接続された VPC ネットワークから仮想アプライアンスにトラフィックをルーティングする VPC ネットワーク内のマネージド インスタンス グループを示しています。
内部パススルー ネットワーク ロードバランサをネクストホップとして使用することには、高可用性を目的として Google Cloud ルーティングを使用する場合に比べて、次のようなメリットがあります。
- ヘルスチェックによりトラフィックの転送先が決まり、正常なインスタンスにのみトラフィックが転送されるようになります。ローカル インスタンスやエンドツーエンドのパスが検証されるように、ヘルスチェックを公開できます。
- ヘルスチェック タイマーを微調整して、フェイルオーバーを高速化できます。この方法により、異常なインスタンスが発生した場合にフェイルオーバーを最短時間で行うことができます。
- 対称ハッシュを使用すると、戻りトラフィックが送信トラフィックと同じ仮想マシンにルーティングされます。
Google Cloud のルーティングを使用すると、次のようなメリットがあります。
- 一貫性のある対称ハッシュにより、プロトコルとセッション アフィニティの選択に応じて、特定の接続のパケットがリクエストとレスポンスの両方で同じバックエンド VM によって処理されるようになります。プロトコルとセッション アフィニティの選択によって、接続トラッキングが使用されるかどうかが決まります。ユースケースによっては、バックエンド インスタンスにソース NAT（SNAT）構成を適用すると効果が得られる場合があります。たとえば、あるネットワークから別のネットワークへのレスポンス接続が、同じ 2 つのネットワーク間の同じ方向の別のリクエスト接続と一致する必要がある場合などです。
Google Cloud のルーティングには、次のようなデメリットがあります。
- ヘルスチェックでインスタンス プールから異常なインスタンスが削除され、再作成されます。ただし、ヘルスチェックが失敗してもトラフィック フローは変更されません。これは、異常なインスタンスの削除と新しい正常なインスタンスの作成に時間がかかるためです。このため、フェイルオーバーにかかる時間が長くなります。
- インスタンスの削除と再作成が不必要に行われることを回避するためにヘルスチェック タイマーを設定すると、フェイルオーバー時間が長くなります。
内部パススルー ネットワーク ロードバランサをネクストホップとして使用する場合でも、Google Cloud ルーティングとして使用する場合でも、すべてのプロトコル トラフィックがサポートされます。このサポートの詳細については、TCP、UDP、およびその他のプロトコル トラフィックの処理をご覧ください。
同様に、どちらのソリューションでも、特定のネットワーク タグへのルート制限がサポートされています。たとえば、VM インスタンスをリージョンでセグメント化し、異なるアプライアンス セットを使用できます。
ネットワーク セグメントを接続するためのオプションの選択
サブネットワーク間のルーティングはオーバーライドできないため、ネットワーク セグメントの実装には個別の VPC ネットワークを使用します。これらの VPC ネットワーク間のトラフィック、オンプレミス環境とインターネットへ送信されるトラフィックは、一元管理されたアプライアンスを経由してルーティングする必要があります。これらのネットワーク セグメントはすべて、スタンドアロン VPC ネットワークまたは共有 VPC ネットワークのいずれかとして設定できます。
ネットワーク セグメントを接続する際には、次のいくつかのオプションがあります。
複数のネットワーク インターフェース。仮想アプライアンスを介して複数の VPC ネットワークを接続する最も簡単な方法は、複数のネットワーク インターフェースを使用し、各インターフェースをいずれかの VPC ネットワークに接続することです。インターネットとオンプレミスの接続は、1 つまたは 2 つの個別のネットワーク インターフェースを介して行われます。多くの NGFW プロダクトでは、NGFW ソフトウェアで信頼不可としてマーキングされているインターフェースを介してインターネットに接続しています。
次の図は、このトポロジを示しています。
上の図は、複数のネットワーク インターフェースを使用して仮想アプライアンス経由で接続する VPC ネットワークを示しています。各インターフェースは、いずれかの VPC ネットワークに接続します。この図は、信頼できないネットワークを介したインターネット接続など、別のネットワーク インターフェースを介したインターネット接続とオンプレミス接続を示しています。
VPC ネットワーク ピアリング。このトポロジでは、ハブアンドスポークのコンセプトを VPC ネットワーク ピアリングと組み合わせて使用しています。ネットワーク セグメントは、ハブ VPC ネットワークで VPC ネットワーク ピアリングを使用してピアリングされる一連のスポーク VPC ネットワークとして実装されます。この場合、トラフィックは仮想アプライアンスの一元化されたプールを介してルーティングされます。内部パススルー ネットワーク ロードバランサをネクストホップとして指すデフォルト ルート、または仮想アプライアンスを直接指すデフォルト ルートは、VPC ネットワーク ピアリングを介してカスタムルートとしてエクスポートされます。インターネットとオンプレミスの接続は、1 つまたは 2 つの個別のネットワーク インターフェースを介して行われます。
次の図は、このトポロジを示しています。
上の図は、複数のネットワーク インターフェースが複数のハブ VPC ネットワークに接続された仮想アプライアンスの一元管理されたプールを示しています。各ハブ VPC ネットワークは、VPC ネットワーク ピアリングを介して複数の VPC ネットワークに接続されています。いずれか 2 つの VPC ネットワーク間のトラフィックは、一元管理された仮想アプライアンスのプールを経由してルーティングされます。
複数のネットワーク インターフェースと VPC ネットワーク ピアリングの組み合わせ。このアプローチでは、前の 2 つのオプションを組み合わせてスケーラビリティを強化します。複数のネットワーク インターフェースが複数のハブ VPC ネットワークに接続され、各ネットワークが VPC ネットワーク ピアリングを介して複数のスポーク VPC ネットワークに接続されます。ハブアンドスポーク VPC ネットワークごとに、VPC ネットワーク ピアリングの場合と同じアプローチを使用します。
次の図は、このトポロジを示しています。
上の図は、VPC ネットワーク ピアリングを介して複数の VPC ネットワークに接続しているハブ VPC ネットワークを示しています。トラフィックは、ハブ ネットワーク内にネットワーク インターフェースが 1 つある仮想アプライアンスの一元管理されたプールを介してルーティングされます。
次のディシジョン ツリーを参考に、ネットワーク セグメントを接続する最適な方法を決定できます。
複数のネットワーク インターフェースを使用する（前述の例で示した最初の方法）のが、最も簡単な実装方法です。
ただし、複数のネットワーク インターフェースを使用することには、次のようなデメリットがあります。
- 仮想マシン インスタンスあたりのネットワーク インターフェース数は 8 つに制限されています。インターネット接続に 1 つのネットワーク インターフェース、オンプレミス接続に 1 つのネットワーク インターフェースを使用する場合、Google Cloud で接続できるネットワーク セグメントは 6 個までです。一部のアプライアンスでは、追加のネットワーク インターフェースを必要とするため、5 つのネットワーク セグメントに制限されます。
- インスタンスの作成後にネットワーク インターフェースを追加または削除することはできません。
VPC ネットワーク ピアリングを使用するメリットは次のとおりです。
- 単一の VPC ネットワークからの VPC ネットワーク ピアリング接続の上限までスケールアップできます。この上限を引き上げる必要がある場合は、Google Cloud セールスチームにお問い合わせください。
- VPC ネットワーク ピアリングを設定することで、このアーキテクチャに対して VPC ネットワークの追加または削除を簡単に行うことができます。
ただし、VPC ネットワーク ピアリングを使用することには、次のようなデメリットがあります。
- この方法は、複数のネットワーク インターフェースを使用する方法よりもやや複雑になります。
- 接続できる VPC の数は、組み合わせによる方法よりも制限されます。
複数のネットワーク インターフェースと VPC ネットワーク ピアリングを組み合わせた方法には、次のようなメリットがあります。
- 上限がネットワーク インターフェースの上限と VPC ピアリング接続の上限に基づくものであるため、これは最もスケーラブルな方法です。たとえば、6 個のハブ VPC ネットワークを個別のネットワーク インターフェースに接続し、各インターフェースに 25 個のスポーク VPC ネットワークを接続できます。これにより、1 つの仮想アプライアンスのセットでトラフィックを交換する VPC ネットワーク数が 150 に制限されます。
ただし、この方法には次のデメリットがあります。
- これは最も複雑な実装方法になります。
アーキテクチャ例
以下にアーキテクチャの例を 2 つ示します。最初のアーキテクチャの例では、高可用性の実現を目的として内部パススルー ネットワーク ロードバランサをネットワーク セグメントを接続するための VPC ネットワーク ピアリングと併用する方法を示しています。特別なユースケースである 2 番目のアーキテクチャの例は、Google Cloud 上の単一の共有 VPC ネットワークから、オンプレミス環境とインターネットにトラフィックをルーティングする方法を示しています。
VPC ネットワーク ピアリングと内部パススルー ネットワーク ロードバランサをネクストホップとして使用するアーキテクチャの例
このアーキテクチャは、高可用性の実現を目的として内部パススルー ネットワーク ロードバランサをネットワーク セグメントを接続するための VPC ネットワーク ピアリングと併用する、エンタープライズ環境向けの一般的なユースケースです。
次の図は、このアーキテクチャのトポロジを示しています。
上の図は、VPC ネットワーク ピアリングを使用してハブ VPC ネットワークでピアリングされたハブ VPC ネットワークと複数のスポーク VPC ネットワークを示しています。ハブ VPC ネットワークには、内部パススルー ネットワーク ロードバランサの背後にあるマネージド インスタンス グループ内の仮想アプライアンスの 2 つのインスタンスがあります。静的デフォルト ルートは、ネクストホップとして内部パススルー ネットワーク ロードバランサをポイントします。この静的デフォルト ルートは、カスタムルートを使用して、VPC ネットワーク ピアリング経由でエクスポートされます。スポーク VPC ネットワークのインターネット ゲートウェイへのデフォルト ルートが削除されます。
次の方法で要件を満たすことができます。
- VPC ネットワーク ピアリングは推移的ではないため、スポーク VPC ネットワーク間ではデータを直接交換できません。このため、スポーク間の接続はファイアウォールによって自動的にルーティングされます。仮想アプライアンスを構成して、スポークがトラフィックを交換できる条件とポリシーを設定できます。
- インターネット ゲートウェイへのデフォルト ルートがスポーク VPC ネットワークから削除されたため、インターネットへの接続は仮想アプライアンス経由でのみ行えます。仮想アプライアンスには、別のネットワーク インターフェースを経由するデフォルトのルートがあります。NGFW の場合は。これは信頼不可としてマーキングできます。
- オンプレミス ネットワークへの接続は、個別のネットワーク インターフェースで仮想アプライアンスと VPC ネットワークを接続することで実現されます。Cloud VPN または Cloud Interconnect 接続はこの接続 VPC ネットワークで終端します。
- 高可用性は、内部ロードバランサのカスタマイズされたヘルスチェックを使用して実現されます。内部パススルー ネットワーク ロードバランサのフェイルオーバーを使用して、アプライアンスをアクティブ / パッシブとして構成できます。これにより、トラフィックが常に 1 つの仮想アプライアンスを経由するようになります。
異なる VPC ネットワーク間の通信が TCP / UDP の場合、またはその他のプロトコル トラフィックの場合、このサンプル アーキテクチャを使用できます。VPC ネットワークあたりの VPC ネットワーク ピアリング接続の上限まで、スケーリングできます。
仮想アプライアンスとして NAT ゲートウェイを使用するこのアーキテクチャの実装例については、ロードバランサをネクストホップとして使用して、ハブアンドスポーク ネットワークをデプロイするをご覧ください。前述のユースケースのセクションで説明したように、同じパターンを使用して他の仮想アプライアンスをデプロイできます。
Google Cloud で 1 つの共有 VPC ネットワークを使用する特別なユースケース
この特別なユースケースでは、異なる VPC ネットワーク間のトラフィックは仮想アプライアンスを通過する必要がありません。代わりに、1 つの共有 VPC ネットワークからのトラフィックのみがオンプレミス環境とインターネットにルーティングされます。このユースケースを実装するには、このドキュメントで説明した高可用性オプションをそれぞれ 1 つのネットワーク インターフェースと組み合わせて使用し、共有 VPC ネットワーク、オンプレミス、Google Cloud への接続を実現します。一元化されたアプライアンスを介して実行せずにサブネット間のトラフィックを表示する必要がある場合は、パケット ミラーリングが便利です。
次の図は、このトポロジを示しています。
上の図は、1 つの共有 VPC ネットワークから仮想アプライアンスのプールを介して、オンプレミス ネットワークとインターネットにルーティングされるトラフィックを示しています。
仮想アプライアンスを使用したアーキテクチャの実装
セグメント間での VPC ネットワーク ピアリングの使用と、高可用性オプションとしての内部パススルー ネットワーク ロードバランサの使用については、ロードバランサをネクストホップとして使用して、ハブアンドスポーク ネットワークをデプロイするをご覧ください。
Google Cloud パートナーの Cloud Marketplace からアプライアンスをデプロイする場合は、アプライアンス ベンダーにお問い合わせいただくか、ベンダーのウェブサイトで Google Cloud にアプライアンスをデプロイする方法についてのガイドラインを検索してください。
次のステップ
- VPC 設計のベスト プラクティスとリファレンス アーキテクチャ
- ハイブリッドおよびマルチクラウドのネットワーク トポロジ
- Google Cloud アーキテクチャ フレームワークでのネットワーク設計のベスト プラクティス
- VPC のドキュメント
- 内部パススルー ネットワーク ロードバランサのドキュメント
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。