クラウドコンピューティングの相互接続の未来とは?

ビジネスを運営するアプリケーションにおけるセキュリティ侵害やパフォーマンス関連の問題は、間違いなく収益に影響を与えます。たとえば、ホテル予約システムの問題は、Office 365 のようなドキュメント アプリケーションよりも収益に直接影響を及ぼします。

クラウド コンピューティングの導入では、ネットワークが原因でビジネスに影響を与えるパフォーマンスの問題が発生することがよくあります。目標は、ユーザーが最小限の遅延でアプリケーションを使用できるようにすることです。ただし、ネットワーク アーキテクチャは、トラフィックをプライベート ネットワークからパブリック インターネットワークにバックホールします。

企業がミッションクリティカルなアプリケーションをクラウド プラットフォームに移行する際には、既存のクラウド相互接続を再考する必要があります。業界の専門家が、クラウド コンピューティングの相互接続の将来と、インターネット デザインと呼ばれる新たなパラダイムについての考えを共有します。

通常、市場が成熟するにつれて、マルチハイブリッド クラウド アーキテクチャによって推進される従来のクラウド相互接続の上に構築される相互接続ネットワーク設計への移行が見られます。

オリジナルインターコネクトの紹介

クラウド プラットフォームに接続するには、従来の方法がいくつかあります。それぞれのアプローチには、速度、クラウド エコシステム、価格、セキュリティ、パフォーマンスの点で長所と短所があります。

• 最初の最も一般的な接続方法は、IPsec トンネルなどのグローバル インターネット接続を介して実行される安全なネットワークを介することです。
• クラウドに接続する 2 番目の方法は、クラウド コンピューティングの相互接続を介したものです。ユーザーは、Equinix Cloud Exchange などのクラウド相互接続へのプライベートで直接的な高速接続を取得し、さまざまなクラウド コンピューティング サービス プロバイダー (CSP) のクラウドへのイーサネット クロスコネクトを購入します。
• 3 番目の方法は、直接のワイド エリア ネットワーク (WAN) を使用することです。ユーザーは既存の WAN MPLS/VPLS プロバイダーを使用し、必要に応じてクラウド サービス プロバイダー (CSP) を追加するだけです。

実際には、多くのユーザーは接続モデルを組み合わせて使用​​することになります。それはすべて、ユーザーの所在地と選択したアプリの種類によって決まります。たとえば、多数の異なるソースからデータを取得するビッグ データ アプリケーションは、クラウド相互接続モデルに適しています。

一方、ユーザーがオフィス内にいる場合は、インターネット伝送を使用するリモートワーカーとは異なり、WAN に直接接続することを選択します。

複雑な建築

従来のクラウド コンピューティング データ センター相互接続設計には冗長負荷が含まれています。これにより、IPsec トンネルまたはイーサネット接続のいずれかのポイントツーポイント接続の複雑なアーキテクチャが生まれます。

グリッド構造はスケーリングがうまくいかず、一般的に N の 2 乗の問題になります。データ センターを追加するたびに、追加される各データ/クラウド コンピューティング センターに追加される接続数の 2 乗を追加する必要があります。

したがって、複雑さを管理するために、何らかのタイプのオーバーレイが使用されます。これらのオーバーレイは、何らかのセグメンテーション オーバーヘッドを伴う IPsec トンネルの形式で提供されます。ほとんどの場合、Virtual Extensible LAN (VXLAN) が使用されます。

このアーキテクチャは、ルーター、ファイアウォール、ロード バランサー、WAN オプティマイザー、IDS/IPS などの多くの単機能サービスで構成されています。単一機能のサービスでは機器が無秩序に増加し、複雑さとコストが増加します。バックアップ デバイスがアイドル状態になると、構成が複雑になるだけでなく、追加コストも発生する可能性があります。

安全を確保する

安全性を確保するにはいくつかの課題があります。 IPsec は同じ暗号化キーを使用してトンネル内のすべてのものを暗号化します。つまり、セキュリティ レベルが異なる複数のセグメントがある場合、各論理セグメントは同じ暗号化キーを共有します。

これは、ユーザーが各ネットワーク セグメントを同じ方法で暗号化するため、すべてまたは何も行わない暗号化です。ルーティングおよびピアリング ネットワークは認証されないため、事前の検証なしにネットワークに接続を追加できます。

したがって、ユーザーはファイアウォールを追加する必要があります。本質的に、多くのユーザーはルーティングと環境に統合されていないセキュリティに苦労しています。ネットワーク セキュリティ ルールに従っていない。セキュリティ ルールはネットワークに応じて動的に変更される可能性があります。

アプリケーションのパフォーマンス保証なし

既存のモデルでは、アプリケーションのパフォーマンスが保証されません。パスの選択は、パフォーマンスではなく、基礎となるルーティングに基づいて行われます。 IPsec トンネルは、距離の観点から見ると選択されたパスが頻繁に使用される場合でも、ユーザーのデータをポイント A からポイント B に伝送します。

さらに、ユーザーは NetFlow などの別のツールを使用してアプリケーションのパフォーマンスを測定する必要があります。

敏捷性の欠如

既存のシステムには、すべてのポイントツーポイント リンクのカスタム構成など、柔軟性が欠けています。この構成は通常は自動ではありません。手動で駆動するアーキテクチャでは、常にエラーが発生しやすくなります。

専用リンク (マルチプロトコル ラベル スイッチングなど) を使用する場合、特に冗長リンクを含める場合は、展開時間が長くなります。これらのほとんどは依然としてコマンド ライン (CLI) で実行されることに注意してください。

関連料金

当然のことながら、それにかかるコストはかなり高額です。 MPLS リンクが 1 つある場合は、冗長性のために別の MPLS リンクを使用する必要があります。デフォルト値のままにしておくと、インターネットをバックアップとして使用することはできません。プライベート リンクはグローバル インターネット リンクの 10 倍のコストがかかることが多いことに注意してください。

このギャップを埋めるために、企業は依然として特殊なハードウェアやソフトウェアを購入したり、高価な機器をレンタルしたりしています。たとえば、ユーザーは洗練された Amazon EC2 ソフトウェア インスタンス上でルーターを実行していません。

ネットワーク相互接続設計

ネットワーク相互接続設計の目標は、プライベートかパブリックかを問わず、データ センターを 1 つの論理データ センターに統合することです。物理的な場所が複数ある場合でも、ネットワークの観点からは 1 つの論理データ センターのように見える場合があります。

インターネットワーキングのもう 1 つの重要な側面は、コンピューティングの最後のステップであるルーティングです。これが重要な理由の 1 つは、マルチクラウド戦略を採用しており、VMware ソリューションを採用して AWS および Azure クラウド プラットフォームに統合したい場合です。

シンプルなアーキテクチャ

ネットワーク相互接続設計により、数千のサイトに拡張できるシンプルなアーキテクチャが提供されます。インターネットワークは、ポイントツーポイント ネットワークではなく、エンドツーエンドのルーティング環境を提供します。この論理メッシュを作成するために使用されるプロトコルは、ベンダーによって異なります。

サプライヤーによって目標は異なります。ベンダーの中には、インターネットワーキングのゼロトラスト セキュリティに重点を置いているところもあれば、インターネットワーキングを使用してアプリケーション パフォーマンスに関連する問題に対処するところもあります。セッションをサポートしていないベンダーはオーバーレイを使用する必要があります。

シングルスタックセキュリティ

理想的な世界では、すべてのネットワーク機能に単一のソフトウェア スタックが使用されます。ルーティングとセキュリティの融合が人々に認識され始めています。今日のネットワークとセキュリティのチームおよび製品は異なっており、ルーティングとセキュリティを統合することが求められています。

一部の SD-WAN ベンダーは、ルーティングとセキュリティがうまく連携するようにセキュリティ ベンダーと提携しています。一例として、ネットワーク機能仮想化 (NFV) の使用が挙げられます。

ここでは、ソフトウェア スタックを取得して同じハードウェア インスタンス上で実行し、サービスをリンクします。場合によっては、すべてをクラウドにプッシュするだけです。すべてのセキュリティと自己修復はクラウド内で実行され、複雑さが排除されます。どのアプローチがユーザーにとって最適であるかにかかわらず、セキュリティとネットワークの未来はより近づくでしょう。

テラビットクラスのネットワークをサポート

ユーザーがインターネットでテラビットの速度を利用したい場合は、対応する機器を購入して拡張することができます。ネットワーク相互接続アーキテクチャは、テラビット規模のネットワークに高いパフォーマンスとサポートを提供します。

独立したIPアドレス

IP アドレスの独立性と重複する IP アドレスのサポートは重要です。多くの組織では、制限なく運用するチームを割り当てており、その結果、AWS アカウントの数は数千に上ります。最終的に、ユーザーが共有サービス、ログ記録、または ID ベースのポリシー (IAM) に移行する場合、IP アドレスの競合が発生する可能性が高くなります。

ここでは 2 つのオプションがあります。ユーザーがすべてを読み取るか、IP アドレスを抽出するベンダー製品を使用するかです。抽象 IP アドレスは、名前付きデータ ネットワーキングなどの他の変数に基づいてルーティングされます。

ゼロトラストセキュリティ

ゼロトラストセキュリティも提供します。ゼロトラスト セキュリティの基本的な定義は、事前の認証と承認なしに、伝送制御プロトコル (TCP) またはユーザー データグラム プロトコル (UDP) が確立されないことです。

適応型暗号化とセッション認証

適応型暗号化は、トランスポート層セキュリティ (TLS) を使用してアプリケーション層で暗号化し、ネットワーク レベルでオプションで再暗号化するものです。もちろん、二重暗号化は単一暗号化よりも安全であるという利点があります。アプリケーション層で TLS を使用している場合でも、TLS セッションのセットアップ中に TLS 接続に関するメタデータを取得できます。

ただし、ネットワーク層での暗号化では異なるキーが使用されるため、ユーザーは TLS セッションに関するメタデータを隠すことができます。ただし、暗号化をネットワーク層で実行すれば、ネットワーク パフォーマンスが向上します。この問題に対処するには、暗号化を容易にするための追加のリソースが必要になる場合があります。

1:1分割

インターネット設計では 1:1 の分割が提供されます。これは、あるアプリケーションまたはサービスから別のアプリケーションまたはサービスへのマッピングです。正確に言うと、仮想サーバーでは、このポート上のアプリケーションは、一般的なサーバー間マッピングではなく、別のポート上のアプリケーションとのみ通信できます。

アプリケーションパフォーマンスとサービス保証

アプリケーション パフォーマンスとサービス保証により、アプリケーションが効率的に実行されることが保証されます。さらに、アプリケーションが、使用率が高くなる可能性のある最短パスではなく、最適なパスを選択するようにします。

決定論的ルーティング

ユーザーは非対称ルーティングを望まないため、セキュリティ スタックを通過するときは決定論的かつ動的なルーティングが必須です。

一部の SD-WAN ベンダーは、ping の送信、双方向転送検出 (BFD)、またはその他の独自のキープアライブ アクセス リンク測定を通じてリンクを監視します。ボーダー ゲートウェイ プロトコル (BGP) ルーティングはルーティングを制御しますが、静的であり、ルールまたはホップに基づいて構成できます。ただし、これらのメトリックはいずれもリンク使用率に基づいていません。

一定期間内に 10% を超えるパケットがドロップされた場合、ユーザーはルーティングをより適切なパスに設定できる必要があります。多くの SD-WAN がこれを宣伝しているのは、過去に Cisco Intelligent WAN (IWAN) が設定されていたときに、ジッターやパケット損失に関係なく、データ フローはそのフローの最後まで同じリンクを使用するように設定されていたためです。

大規模セッションのリンク負荷分散

グローバル インターネットは、大規模なセッションのリンク負荷分散を提供します。たとえば、バックアップを実行する場合、単一のリンクを使用する代わりに、特定の AWS または Azure インスタンスを同時に使用できる複数のリンクのバランスをとることで、大容量のファイル転送を容易にすることができます。

伝送制御プロトコル (TCP) の観点から見ると、依然として同じに見えます。 TCP は、異なるパスを通る場合でも、シーケンス番号を順序どおりに保持します。これは、負荷分散が OSI (Open Systems Interconnection) モデルのネットワーク層で実行されるためです。

セッション状態の維持

ネットワークでは、セッションはファイアウォールを通過します。トポロジの変更によってリターンパスが変化するとどうなりますか?

非対称ルーティングにより、ファイアウォールはセッションをドロップします。したがって、ファイアウォールの境界やネットワーク トポロジの変更を越えてセッション状態を維持する必要があります。したがって、リンクのパフォーマンスが低下している場合は、ルートの変更が一方向ではなく双方向であることを確認する必要があります。これにより、ユーザーは正しくフェイルオーバーできるようになります。この場合、TCP の観点から見ると、ユーザーは引き続き TCP 状態を維持しています。