コンテナ時代のネットワーキング

過去数年間、仮想化、そして現在ではコンテナ化によって、特定のハードウェア上のアプリケーションの密度が高まってきたため、私たちは南北トラフィックではなく東西トラフィックを管理するという課題に頭を悩ませるようになりました。

データセンターのトラフィック パターンについてまだあまり詳しくない方のために、要約します。 North-South は、ユーザーからアプリ、クライアントからサーバー、またはデータ センターの入出力を指します。 East-West は、サーバー間、アプリ間、サービス間、または単にデータ センター内です。

南北のトラフィック パターンは、ユーザー、アプリ、モノの増加によって影響を受けます。 必要なユーザー アプリ接続が増えるほど、南北トラフィックも増えます。 東西トラフィックは、アプリケーション アーキテクチャとインフラストラクチャ テクノロジの影響を受けます。 仮想化やコンテナなどのテクノロジーをマイクロサービスなどの新しいアーキテクチャと組み合わせると、データセンター全体で相互に通信する必要がある「アプリ」や「サービス」の数が指数関数的に増加します。

基本的に、アプリケーション アーキテクチャとそのインフラストラクチャの分散化が進むほど、東西トラフィックが増加します。

この増加に拍車をかけているのが、アプリの「適正規模化」の傾向です。 キャパシティ プランニングは成長予測に基づいて行われるのではなく、現在必要なものに少しだけ上乗せしたものに基づいて行われます。 自動スケーリングなどの成熟したテクノロジーのおかげで、リソースをより効率的に使用できるようになり、コンピューティング リソースやネットワーク リソースがアイドル状態のままになることが減り、予算を消費しながらもそれに見合った価値を生み出すことがなくなります。 ちなみに、これはプライベート クラウドの利点の 1 つです。つまり、リソースのリアルタイム使用を可能にするサービス指向のプロビジョニングと管理を提供することで、無駄にアイドル状態のままになるリソースをより有効に活用できるということです。

しかし、話が逸れてしまいました。 重要なのは、アーキテクチャとテクノロジーのおかげで、東西のトラフィックが南北の増加を上回る速度で増加しているということです。

さて、過去 20 年間のアプリケーション アーキテクチャとテクノロジのあらゆる大きな変化は、「ネットワーク」に同様の反応をもたらしました。 これは、トラフィックがどの方向に進んでいるかに関係なく、ネットワークがトラフィックを管理する責任があるためです。 東西、南北は関係ありません。 仮想か物理かに関係なく、トラフィックが現在の場所から必要な場所に確実に到達できるようにするには、ネットワークが必要です。

マイクロサービスによるアプリケーションの分解により、東西トラフィックがさらに増加している中で、ネットワークはどのように対応すべきかが問題となっています。 もっと正確に言えば、アプリをユーザーや他のアプリに配信するために必要な重要な機能 (可用性、セキュリティ、最適化) を提供するために、ネットワーク内のサービスはどのように対応すればよいのでしょうか。

インパクトワン: アプリへの移行 

この質問に対する最初の答えは、アプリケーションに類似したサービスはアプリに近づく必要がある、ということです。アプリケーションに類似したサービスは、南北パターンの端に留まり、主に東西パターンでサービスを使用するアプリにサービスを提供し続けることはできません。 これは、ネットワーク リソースの非効率的な使用と、ルーティング パターンの影響により、アプリケーション通信に遅延が生じる原因となります。 ここで、マシンを離れてネットワークを北上し、同じマシンに戻ることを必要とするネットワーク経由のルートを説明するトラフィック パターンの「トロンボーン」や「ヘアピニング」などの用語が聞かれるようになります。 この遅延は、生産性の低下（「今日は『コンピュータ』が遅いので、ご容赦ください」）や消費者によるショッピング カートや Web アプリの放棄の増加という点で、実際のビジネス コストにつながります。 これは私たちが避けたいことです。トラフィックが東西方向に流れる場合は、サービスはそのデータ パス内にある必要があります。

影響その2: 運用互換性 

2 番目の答えは、負荷分散や Web アプリのセキュリティなどのサービスは、運用上互換性のある形式で展開可能である必要があるということです。 言い換えれば、出現するすべてのアプリ (またはマイクロサービス) の前にネットワーク ハードウェアを配置するつもりはありません。 したがって、これらのサービスが提供されるプラットフォームは、新しいアーキテクチャやテクノロジーと運用上の互換性を保つために、仮想化またはコンテナ化する必要があります。 また、これらはプログラム化されており、プロビジョニングと管理に対する DevOps 指向のアプローチを可能にする API とテンプレートを提供する必要があります。 アプリケーションであろうとネットワークであろうと、サービスはオーケストレーション可能である必要があります。 SDN は、インフラストラクチャとアプリケーション運用環境を支配するツールやフレームワークと統合できれば、このニーズにも対応できます。 

影響3: アーキテクチャは重要

3 番目の答えは、建築がこれまで以上に重要になるということです。 ネットワーク サービスをアプリケーションと同じホストにデプロイできるからといって、必ずしもそこにデプロイする必要があるわけではありません。 それが何であるか、そして他のサービス（およびサービスのインスタンス）とどのように相互作用するかに応じて、配置は考慮すべき重要な問題になります。 たとえば、ロード バランシングの設計が不十分だと、恐ろしいトラフィック パターンが発生し、不要な遅延が発生する可能性があります。この遅延は、ビジネス上の利益、または損失に直接影響します。 このシナリオでは、サービスが展開されているホストで障害 (ハードウェア、ソフトウェア、ネットワーク、ストレージ) が発生すると、アプリの可用性を確保するサービスも停止するため、ダウンタイム (しかもひどいダウンタイム) が発生します。 高度に分解されたアプリケーション アーキテクチャ (マイクロサービス) では、これらのアプリへの依存度が高い場合、これは悲惨な結果を招く可能性があります。

最も明白な（そして最も簡単な）答えの誘惑によって、パフォーマンスと可用性に関するベスト プラクティスが無視されないようにするには、慎重な考慮（アーキテクチャ）が必要です。

ネットワークは依然としてアーキテクチャの課題である

ネットワーキングは、現在も、そしてこれからも、アーキテクチャ上の取り組みであり続けます。 これは単なるフォーム ファクターの問題ではなく、必要な場所にネットワーク リソースをより迅速かつ効率的に配置するための方法にすぎません。 それは、それらのリソースの配置と、それがスタックの上流にあるすべて、つまりネットワーク サービス、アプリ サービス、アプリのパフォーマンス、そして最終的にはビジネスの成功または失敗にどのように影響するかに関するものです。

コンテナ、仮想化、クラウドの時代におけるネットワーキングは、運用だけでなくアーキテクチャも重要です。