IaaS 向けのクラウドホスト型 SD-WAN の隠れたコスト
- Sd WAN
- 2021年9月11日
SD-WAN が普及した業界では、ブランチ ロケーションをクラウドに接続する一般的な方法が 3 つあります。ここでは、それぞれの利点と限界について詳しく説明します。
多くの企業は、クラウド移行戦略を実行した後で、アプリケーションの最新化に進みます。これには SD-WAN も含まれます。コンテナ化、マイクロサービス、サーバーレス アーキテクチャ (SD-WAN など) を利用して、クラウドネイティブ アーキテクチャに移行すると、時間が経つにつれコストを低減し、拡張性を高め、開発サイクルと市場投入期間を短縮できます。
ただし、次の課題は、ブランチ サイトがこの最新化されたパブリック クラウドベース アプリケーションに確実に接続できるようにすることです。ところが、プライベート クラウドでホストされるレガシー アプリケーションや、第 2 または第 3 のパブリック クラウド プロバイダーでホストされるサービスがまだいくつも残っているとしたらどうなるでしょうか?
SD-WAN が一般に普及し、エンタープライズ WAN が MPLS からブロードバンドベースのアンダーレイに移行する数が増加するに伴い、ビジネスクリティカルなトラフィックは、ベスト エフォート型のパブリック インターネット ベースの接続を経由するようになりました。こうした「クラウド対応ブランチ」へシフトするには、企業アーキテクチャの観点から再設計が必要になることは明白です。
1 つの選択肢は、クラウドに向かうトラフィックをブランチ サイトからデータ センターに戻し、その後、できればプライベート接続を使ってクラウドに送り出すというものです。これは上手く機能する場合もありますが、企業のデータ センターの地理的場所によっては、ヘアピン現象が発生し、レイテンシーが大幅に増加し、アプリケーションのパフォーマンスが低下することがあります。第 2 の選択肢は、ブランチ サイトとクラウドとの直接通信を許可することです。これを実現するには、次のようにさまざまな方法があります。
- クラウド サービス プロバイダー VPN ゲートウェイ (AWS VPG、Azure VNG、Google Cloud VPN)
- クラウドベース SD-WAN (AWS Transit VPC、Azure Virtual WAN、Google Cloud NCC など)
- NaaS (Megaport Virtual Edge)
VPN トンネルを利用した標準的なブランチからクラウドへの接続
中規模の小売企業を例にして考えましょう。この企業は、全米に 40 箇所のブランチ サイトを展開しており、クラウドでホストされている POS/在庫管理プラットフォームにアクセスする必要があります。簡単で信頼できるソリューションとして、クラウド プロバイダーによって提供される標準的なサイト間 VPN ゲートウェイを活用する方法があります。
AWS 環境において、これは 1 つの仮想プライベート クラウド (VPC) に接続された仮想プライベート ゲートウェイへのパブリック インターネットを経由する IPsec トンネルを構築することを意味します。この設計の欠点は、Azure にも適用される 1:1 ルールです。これに相当する VPN ゲートウェイも 1 つの VNet にしか接続できません。仮想ネットワークは 1 つのゲートウェイにのみ制限されるため、これは企業が 2 つ目の仮想ネットワークを構築する場合、2 つ目の VGW と、40 箇所すべてのブランチ サイトへの新しい IPsec トンネルが必要になることを意味します。クラウド プロバイダーでは、1 つの VPN ゲートウェイに接続するブランチ サイトのトンネルの最大数を設けています。Azure の場合、最大数は 30 で、AWS は 10 です (ただし、増設をリクエストできます)。
達成可能なネットワーク速度にも上限が設けられています。よくある誤解として、クラウドへの IPsec トンネルは 1.25 Gbps に制限されているというものがありますが、実際にはこれはゲートウェイの総スループットです。したがって、40 箇所のブランチ サイトを構成する場合、各サイトはその 1.25 Gbps を共有するため、各サイトのスループットは約 30 Mbps となります。また、ブランチ サイトの 30Mbps はパブリック インターネットを 100% 経由しており、ジッター、パケット ロス、レイテンシーが予測できないレベルで発生する可能性があることも考慮する必要があります。最終的に、クラウドからブランチ サイトへのトラフィックは、パブリック インターネットを経由するため、標準的なクラウド プロバイダーのエグレスまたはデータ転送量 (DTO) 料金として、仮想ネットワークから出て行くギガビットごとに約 10 セントがかかります。
クラウドホスト型 SD-WAN エッジ
前述の標準的な VPN トンネルベース設計の課題を克服するために、クラウド プロバイダーと従来のネットワーク ハードウェア プロバイダー (Megaport パートナーの Cisco や Fortinet ) は、エンタープライズ SD-WAN に統合可能なソリューションを開発しました。
Fortinet Secure SD-WAN が Megaport Virtual Edge (MVE) に対応するようになりました。こちらのブログをお読みください。
SD-WAN は、MPLS、ブロードバンド、LTE などさまざまな基盤となるトランスポート方式を利用して、ブランチ サイトをプライベート/パブリック クラウドでホストされるアプリケーションに接続する仮想化された WAN アーキテクチャです。SD-WAN の主な利点の 1 つは、オーバーレイ WAN 全体でトラフィック パスを誘導するコントロールやルーティングの機能が一元化されている点です。
若干の違いはあるものの、基本的にこのアーキテクチャは、Infrastructure as a Service (IaaS) を利用して SD-WAN ファブリックをパブリック クラウドに拡張し、SD-WAN ベンダー ソフトウェアをクラウド プロバイダーのマーケットプレイスから読み込みます (BYOL: Bring Your Own License (所有しているライセンスの持ち込み))。これにより、極めて迅速な構築、高レベルの自動化、ベンダーの管理コンソールを使用したオペレーションの簡素化が可能になります。
まず、AWS における IaaS ベース ソリューションとその主要コンポーネントを見ていきましょう。最初の Transit VPC は、ブランチ サイトから送受信されるすべてのトラフィックの中央ハブとして、またアプリケーション仮想プライベート クラウド (VPC) へのルートとして機能します。
Transit VPC で 2 つの仮想マシンがスピンアップされ、SD-WAN ベンダーのイメージが読み込まれ、2 つの仮想ルーターが作成されます。仮想ルーターの管理は、Cisco vManage、FortiManager などによって行われます。基盤となる AWS 仮想マシンの時間単位の使用料金は、構築時に選択した仕様によって異なります。
上の図では、仮想ルーターにノースバウンド IPsec トンネルが構築され、各仮想プライベート ゲートウェイ (VPG) を経由して本番環境、開発環境、テスト VPC に接続されています。両方の仮想ルーターには、SD-WAN 内の各ブランチ サイトへのサウスバウンド IPsec インターネットベース接続もあります。冗長化のため、各ブランチ サイトでは、各仮想ルーターへのトンネルを構築することを推奨します。アプリケーションの VPC 内のプライベート サブネットは、BGP 型ルーティング プロトコルを使用して仮想ルーターにアドバタイズされ、そのサブネットから 40 箇所のブランチ サイトに再アドバタイズされます (分かりやすくするために、図では 5 つのブランチ サイトのみを表示しています)。
Cisco SD-WAN でブランチから Azure への接続をスピンアップする場合は、こちらのステップバイステップのビデオをご視聴ください。
SD-WAN ブランチ サイトの数が増えると、追加の仮想マシン (ルーター) が必要になる可能性があります。必要な IPsec トンネルの暗号化/復号化の量によって、CPU および帯域幅に制限があるからです。
この SD-WAN ソリューションは、パブリック インターネットを活用するため、標準エグレス料金が適用されますが、もう 1 つの隠れたコストとして、エグレス料金の二重課金の可能性を認識する必要があります。ノースバウンド接続はインターネット IPsec トンネルを使用しているため、アプリケーションの VPC から Transit VPC へ転送されるギガバイトごとに料金が請求されます。トラフィックの転送先がブランチ サイトの場合、サウスバウンド Transit VPC であるため、ギガバイトごとに追加料金が発生します。事実上、顧客にはブランチ サイトに到達するギガバイトごとにエグレス料金が二重課金されます。
ワークロードおよびトラフィック フローに応じて、IaaS ベースの SD-WAN ソリューションは、多くの企業で極めて効果的に機能します。ベンダー ロックインの回避、事業継続の計画、あるいは Microsoft Azure などの内部で最適に動作する新しい社内アプリケーションを使用するために、2 番目のクラウド プロバイダーを導入する場合を考えてみましょう。40 箇所すべてのブランチ サイトが AWS VPC および新しい Azure VNets へのアクセスを許可する必要があるため、アーキテクチャは大幅に複雑化します。
Azure 環境では、仮想 WAN が構築され、仮想ハブ VNet が作成されます (多くの場合、AWS Transit VPC に対しても同様)。ここでも、2 台の仮想マシンがこのハブ内でスピンアップされ、ネットワーク仮想アプライアンス (NVA) を作成するために SD-WAN ソフトウェアは追加で読み込まれます。既存のブランチ サイトは、IPsec トンネル経由で Azure 仮想ハブ内の両方の NVA に接続されます (AWS への既存の 2 つのトンネルに追加)。図に示すように、これは数百の IPsec トンネルがあることを意味します。
ここまでは、ブランチからクラウドへのフローにおけるマルチクラウドのみを考慮してきましたが、クラウド間接続にも要件があります。例えば、クロスクラウド データ レプリケーションです。ここでの選択肢としては、トラフィックをオンプレミス データ センターに U ターンさせる方法 (レイテンシーが高めになる) や、Azure 仮想ハブと AWS Transit VPC 間の新しい IPsec トンネルを構築する方法があります。もちろん、インターネット エグレス料金が発生し、トンネル速度にも制限がかかります。
Megaport Virtual Edge (MVE)
AWS Direct Connect、Azure ExpressRoute、Google Cloud Interconnect などのプライベート レイヤー 2 クラウド接続と組み合わせた Megaport Virtual Edge (MVE) は、上記の 2 つのソリューションで特定された欠点の多くに対処します。
MVE は、重要なアプリケーションがどこにあっても、その最適な経路を戦略的に構築する機能を提供することで、既存のエンタープライズ SD-WAN プラットフォームを強化します。基本的に、MVE を利用すると、企業は独自のリージョンの PoP を数分で構築し、Megaport のグローバル Software Defined Network (SDN) を活用することで、WAN 範囲を拡張できます。現在、全世界に 22 の MVE 大都市圏リージョンがあり、各リージョンには少なくとも 2 つのデータ センターとインターネット トランジット プロバイダーがあり、エンドツーエンド WAN 障害耐性を提供するために MVE アベイラビリティー ゾーンをサポートしています。
ここでは、MVE の中核となる要素と機能を理解するために、MVE のボンネットの中を見てみましょう。
MVE は、vCPU、IP トランジット、接続されるブランチ サイトの数の組み合わせに基づいて、3 つのサイズで提供される仮想化されたオンデマンド SD-WAN エッジ デバイスです。SD-WAN ベンダー ソフトウェアは顧客が選択できます。現在、MVE がサポートしているのは Cisco および Fortinet ですが、2021 年内にはさらに選択肢が増える予定です。今後、MVE は企業の WAN ファブリック内で通常の SD-WAN アプライアンスと同様に効率的に管理され、Cisco vManage や FortiManager などから構成できるようになります。
ブランチ トラフィックは、ファーストマイルのローカル インターネット経由で MVE に到達します。通常、近接度にもよりますが、10ms 未満です。そこから、MVE は、プライベート レイヤー 2 接続 (AWS Direct Connect、Azure ExpressRoute、Google Cloud Interconnect など) に対応する 235 を超えるパブリック クラウド オンランプを含むグローバル Megaport ファブリックにアクセスできます。
仕組み
SD-WAN ブランチ サイトは、Megaport が提供するパブリック IP アドレスを使用して、内蔵の冗長、Tier 1 IP トランジットを経由して、MVE への IPsec アタッチメントを構築できます。ブランチ トラフィックが MVE に到達したら、企業は一元化された MVE ロケーションでブランチ サイト トラフィックを集約し、直ちにインターネット IPsec トンネルから移行して、Megaport バックボーン経由でそのトラフィックを大手クラウド プロバイダーに再ルーティングします。これには数多くの利点があります。
利点
**アプリケーション パフォーマンス:**以前はパブリック インターネット経由でクラウドベース アプリケーションにアクセスしていたブランチでパフォーマンスが向上します。これにより、「ファーストマイル」のみがインターネットを経由し、大部分のパスは Megaport のバックボーンを経由することになり、ジッター、レイテンシー、パケット ロスが減少します。
Megaport ファブリックへのアクセス:MVE は、全世界で 360 を超えるサービス プロバイダーと 700 を超える対応データ センターから構成される Megaport のエコシステムにアクセスを許可します。このエコシステムには、235 以上のクラウド オンランプ、ほとんどのニュートラル Network as a Service (NaaS) プロバイダーが含まれます。
運営コストの削減:インターネット IPsec トンネルを経由してハイパースケーラーのプライベート接続を使用することで、エグレス料金は 70 ～ 80% 下がります。北米の場合、これはギガバイトごとに平均 10 セントから約 2 セントまで削減されることを意味します。40 のブランチ サイトをベースラインとし、デュアル AWS VM (C5 ラージ) でクラウドからブランチに毎月 10TB 転送するとして MVE と IaaS SD-WAN トランジット ソリューションを比較する場合、エグレス料金以外にも MVE ソリューションは月額 15% のコスト削減を実現します。
**ネットワークの簡素化:**ここでも 40 のブランチ サイトを例にすると、IaaS ソリューションでは、サイトごとに 4 本以上の IPsec トンネルが必要になり、最低でも合計 160 本のトンネルが必要になることを意味します。これらのトンネルには、それぞれ /30 IP アドレス、リンク状態通知が必要になり、ブランチとクラウドベース仮想ルーターの両方で貴重な CPU リソースを大量に消費してしまいます。MVE に移行することで、企業はネットワーク アーキテクチャの複雑さを大幅に軽減することができます。
**SD-WAN の効率化:**SD-WAN プラットフォームを MVE に統合すると、Megaport の 仮想クロス コネクト (VXC) を使用して WAN 全体で戦略的ミドルマイル トランスポートを構築できます。SD-WAN トラフィックシェーピング サービスは、エンドツーエンド アプリケーションのためにより効率的な経路を即座に活用します。
**オンデマンド:**機器を購入したり、データ センター内に設置したり、クロス コネクトを実行したりする必要はありません。(IaaS ソリューション同様) MVE はリアルタイムでプロビジョニングでき、数分以内に使用準備が整います。
**クラウド間接続:**最後に、MVE には AWS および Azure へのプライベート レイヤー 2 接続が含まれるため、クラウド間トラフィックもその接続を活用し、コストがかかる IPsec トンネルを回避できます。また、オンプレミス ルーターにトラフィックを U ターンさせることも強制されません。
初期の SD-WAN 構築の多くは、高額なブランチの MPLS 接続をブロードバンドや LTE などのよりコスト効率の高いソリューションに置き換えるという長期的な目標が動機となっています。これと並行して、同じ組織がクラウド移行やアプリケーションの近代化戦略を進めています。Megaport Virtual Edge は、SD-WAN とクラウド (プライベート、パブリック、ハイブリッド、マルチクラウドを含む) 間のブリッジとして機能することで、このようなすべての目標を達成することを可能にします。
SD-WAN 技術は極めて強力です。その中心的な価値は、アプリケーション トラフィックを形成し、複数の WAN トランスポートを介してそれを誘導する能力です。Megaport Virtual Edge をエンタープライズ WAN ファブリックに挿入すると、企業は WAN をより柔軟にコントロールし、アプリケーションを最適化できます (これは、クラウドホスト型 SD-WAN エッジを使用する場合には必ずしも実現できません)。MVE があれば、ネットワークを大幅に簡素化すると同時に、イグレス料金を大幅に削減できます。
Megaport Virtual Edge は、北米、アジア太平洋地域、ヨーロッパの 22 箇所のロケーションで SD-WAN エッジ ルーターの仮想インスタンスをホストできます。詳細については、こちら をクリックしてください。
