AWS、Azure、GCP全体のクラウドネットワーキング
1.はじめに
オンプレミス環境からパブリッククラウドに移行する企業は、野心的な目標ではなく、急速に現実のものになりつつあります。 このクラウド導入に着手した後、企業は、 1)復元力とコストの考慮のために単一のプロバイダーにロックされる恐れがある 2)サービスを提供するのにより適している可能性があるクラウドを選択するため、特定のアプリケーションを複数のパブリッククラウドを評価する必要性をすぐに認識します。 3)競争力のあるビジネス目標。 アプリケーション開発者とアーキテクトは、主にマルチクラウドへの移行を主導しています。 彼らは通常、アプリケーションの要件にどのように適合するかに基づいて、クラウドベースのソリューションを採用することに熱心です。 多くの場合、内部の利害関係者に複数のクラウドを活用するように説得することができます。 アプリケーション開発者にとって、特定のクラウドの機能を学習するだけで済みますが、ネットワークエンジニアやアーキテクトは、機能を学習するだけでなく、既存のクラウドやオンプレミスのネットワークアーキテクチャにどのように影響して統合するかを理解する必要があります。 パブリッククラウドプロバイダー全体に新しいネットワーク機能が絶えず流入しているため、最新の状態を維持することはさらに悪化しています。 ここでは、マルチクラウドネットワークアーキテクチャに関連するさまざまなトピックに関する視点を確認、分析、共有します。 クラウドネットワーキングの基本を取り上げ、すべての主要なパブリッククラウドプロバイダーに適用されるさまざまなクラウドネットワーキングの概念とアーキテクチャを共有します。
2.クラウドネットワーキングの基本
クラウドネットワーキングの最も基本的な概念は、単一のパブリック・クラウド内または複数のパブリッククラウドにまたがる物理的なデータセンターを仮想的に表現することです。
この仮想構成は、コンピュートノード、IPアドレスサブネット、ファイアウォール、アクセスリスト、およびルーティング要素をもてなすことができます。本質的には、クラウドのデータセンターとして扱うことができます。
たとえば、Webサービス、データベース、バックエンドシステムなど、アプリケーションのさまざまな部分にサブネットを設定できます。これらのサブネットは、アプリケーションの要件に基づいてプライベートまたはパブリックにすることができます。 アマゾンウェブサービス(AWS)とGoogle Compute Platform(GCP)は、この構成を仮想プライベートクラウド(VPC)と呼んでいますが、Microsoft Azureはこれを仮想ネットワーク(VNet)と呼んでいます。
AWSとMicrosoftAzureの場合、この構成のスコープは単一のクラウドリージョンに制限されますが、GCPの場合、スコープはグローバルです。 GCPを使用すると、複数のサブネットを持つことができ、それぞれが同じVPCの一部である異なるリージョンに存在することができます。
ただし、特定のサブネットはリージョンにまたがっていません。グローバルルーティングを有効にすると、同じVPC内の異なるリージョンのサブネットがGCPのバックボーンを使用して通信できます。
次の図は、グローバルVPCの概念を説明しています。
3.VPC/VNetはどのように相互接続しますか?
当初、VPCおよびVNetコンストラクトの提供の背後にある考え方は、システム管理者とアプリケーション開発者がコンピューティングリソースとストレージリソースを管理できる、パブリッククラウドに相当する物理的なオンプレミスデータセンターを持つことです。 ネットワークチームによってサブネットが割り当てられ、仮想マシンを展開してコードを実行し、アプリケーションをもてなします。 ネットワークチームは、VPC/VNet内およびVNet間通信のサブネットのセキュリティとインターネットワーキングの管理も担当します。 VPC/VNetを相互接続するために、クラウドプロバイダーはピアリングサービスを提供します。顧客が異なるリージョンにVPC/VNetを持っている場合、それらはフルメッシュ方式で相互接続できるため、クラウドバックボーンを使用して相互に通信できます。 このアーキテクチャは、VPC/VNetがクラウドデータセンターとして扱われる場合に非常にうまく機能します。これは、クラウドプロバイダーが最初にサービスを想定した方法です。 しかし実際には、開発者は必要なときに必要な場所でVPC/VNetを簡単に作成できると感じています。これは、分離された環境で作業している場合に最適ですが、多くの場合、企業内の他のVPC/VNetと相互接続する必要があります。 その結果、ネットワークエンジニアは、これらのプライベートクラウド環境を相互接続するためのソリューションを見つけるよう求められます。 ピアリングサービスの問題は、接続数が多い場合に拡張できないことです。ピアリングの制限に遭遇する可能性があり、管理するピアリング接続の数が非常に複雑であるため、運用が不可能になります。 全体像を把握するために、50台のVPCを相互接続する必要がある場合、1225台のピアリング接続が発生するとします。式n(n-1)/ 2を使用して、ピアリング接続の数を計算できます。ここで、「n」はVPC/VNetの数です。 このユースケースは、別のネットワーククラウドアーキテクチャを生み出しました。これは、リージョンごとにある種のトランジット接続を使用し、リージョンをこれらのトランジットを介して接続することです。 これは、スポークがそれぞれのハブにのみ接続し、ハブがフルメッシュで相互に接続される地域のハブアンドスポークネットワークと考えてください。 AWSトランジットゲートウェイまたはAzureトランジットVNetサービスの前は、パブリッククラウドプロバイダーは、VPC/VNet間のトランジットタイプの接続用のクラウドネイティブサービスを提供していませんでした。 これにより、従来のネットワーキング、セキュリティ、およびSD-WANベンダーは、トランジットVPC/VNetに配置され、すべてのルーティングを制御する仮想ルーター、ファイアウォール、またはSD-WANアプライアンスを使用したソリューションを提供できました。 ネットワークエンジニアは、クラウドマーケットプレイスからイメージをダウンロードし、トランジットVPC/VNet内にインストールして、IPSecまたはVPCピアリングを使用してリージョン内のすべてのVPC/VNetを終端させることができます。 これは、トランジットルーター間でIPSecとBGPを実行することにより、他のリージョンに拡張できます。 ほとんどの企業は、このソリューションを使用してさまざまな接続を行っています 同じクラウド内またはクラウド間のリージョン。
4.パブリッククラウドをオンプレミスに接続する方法は?
企業がクラウド導入のどの段階にあるかに関係なく、オンプレミス接続の必要性は常に存在します。 ブランチ、データセンター、およびリモートサイトでは、引き続きクラウド環境への安全な接続が必要です。 クラウドからオンプレミスまでの接続には、(i)パブリックと(ii)プライベートの2種類があります。
オンプレミスからのパブリック接続
オンプレミスからクラウドへのパブリック接続は、IPSecとBGPを使用してインターネット経由で行われます。 通常、IPSec接続は、VPC/VNet内のプライベートゲートウェイで直接終了します。また、Transit Gateway forAWSやTransitVNet forAzureなどのクラウドトランジットで終了することもできます。 トランジットタイプの接続の場合、サードパーティのアプライアンスまたはルーターをインストールして、それを介してクラウドにトランジットすることもできます。 このシナリオの単一のIPSec接続は最大1.25Gbpsをサポートしますが、より高いスループットを得るためにECMPを使用して複数のIPSecトンネルを構築するオプションがあります。
オンプレミスからプライベート接続
クラウドへのプライベート接続は通常、コロケーション施設または物理データセンター内にあるカスタマールーターから拡張されます。 すべての主要なパブリッククラウドプロバイダーは、このタイプのサービスを提供するためにサービスプロバイダーおよびコロケーションとパートナーシップを結んでいます。 このサービスはAWS、Azure、GCPで非常に似ていますが、名前はすべて異なります。これは、AWSの場合はDirect Connect、Azureの場合はExpressRoute、GCPの場合はDedicatedInterconnectと呼ばれます。 企業がこのタイプの接続を必要とする主なユースケースは2つあります。
- プライベートMPLS接続をクラウドに拡張して、企業が同じレベルのSLAとQoSをクラウドに拡張できるようにします。
- オンプレミスのデータセンターからクラウドへのバックアップとデータレプリケーションのための高帯域幅接続。
まとめ
このブログを読んだ後、異なるパブリッククラウドプロバイダー間の違いよりも概念的に多くの類似点があることを理解したに違いありません。 ただし、アーキテクチャと実装の詳細は大きく異なり、ネットワークエンジニアがマルチクラウド環境を設計および統合するのは簡単に困難になる可能性があります。 マルチクラウドネットワークアーキテクチャの採用を検討している企業は、クラウドごとに社内の専門家か、複雑さを抽象化し、さまざまなパブリッククラウドに接続するための統一された方法を提供できるAlkiraのようなサービスを必要とします。
元記事の著者:Misbah Rehman
Misbahは、Alkira Incのテクニカルマーケティングチームを率いています。彼は、ネットワークで10年以上の経験があり、サービスプロバイダー規模のネットワークとソリューションの構築と管理に情熱を注いでいます。彼のキャリアの中で、彼はエンジニアリング、セールス、テクニカルマーケティング全体でさまざまな技術的役割を果たしてきました。Alkiraに入社する前は、シスコのエンタープライズビジネスユニットでテクニカルマーケティングのシニアマネージャーを務め、Tier Iサービスプロバイダーに技術的リーダーシップを提供し、ViptelaSDWANソリューションを使用したマネージドサービスの作成を支援しました。Misbahは、コロラド大学ボルダー校で電気通信の修士号を取得しています。