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

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

ここ数年、仮想化に加えてコンテナ化が進み、個々のハードウェア上でアプリケーションの高密度化が進展するにつれ、南北トラフィックではなく東西トラフィックの管理という課題に注目が集まるようになりました。

データセンターのトラフィックパターンについてまだ十分に理解していない方のために、ここでおさらいしましょう。ノースサウスとは、ユーザーとアプリ間、クライアントとサーバー間、またはデータセンター内外を行き来するトラフィックです。イーストウェストとは、サーバー間、アプリ間、サービス間、つまりデータセンター内部のトラフィックです。

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

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

この増加に拍車をかけているのが、アプリを「適正規模」にする傾向です。成長予測に基づいてキャパシティを計画するのではなく、現時点で必要な量に少し余裕を加えてキャパシティを決定します。自動スケーリングなどの技術が成熟したことで、リソースをより効率的に利用できるようになり、アイドル状態のコンピューティングリソースやネットワークリソースを減らせます。つまり、相応の価値を生み出さずに予算を消費するリソースを削減できます。これは、プライベートクラウドのメリットの1つでもあります。リソースをリアルタイムで利用できるサービス指向のプロビジョニングと管理により、本来なら無駄にアイドル状態となるリソースを、より有効に活用できます。

話がそれました。要点は、アーキテクチャとテクノロジーの進化により、東西トラフィックが南北トラフィックを上回るペースで増加している可能性が高いということです。

さて、過去20年間、アプリケーションのアーキテクチャやテクノロジーに大きな変化が起こるたびに、「ネットワーク」も同じように変化してきました。これは、トラフィックがどの方向に流れるかにかかわらず、その管理をネットワークが担っているためです。東西方向でも南北方向でも変わりません。仮想環境か物理環境かを問わず、トラフィックを現在地から目的地まで確実に届けるには、ネットワークが関与します。

現在、マイクロサービスによるアプリケーションの分割に伴い、東西トラフィックがさらに増加しています。こうした状況にネットワークはどう対応すべきでしょうか。より正確には、アプリケーションをユーザーに、そして増加しつつあるアプリケーション間で提供するために必要な重要機能（可用性、セキュリティ、最適化）を実現できるよう、ネットワーク内のサービスはどう対応すべきでしょうか。

影響1：アプリへの移行

この問いに対する最初の答えは明白です。つまり、アプリケーションに密接に関連するサービスを、アプリの近くに移動する必要があります。こうしたサービスをノースサウス型通信の境界に置いたまま、主にイーストウェスト型通信で利用するアプリに提供することはできません。ネットワークリソースを効率的に利用できないうえ、そのルーティングパターンによってアプリケーション間の通信に遅延が生じるためです。ここで耳にするようになるのが、トラフィックパターンの「トロンボーニング」や「ヘアピニング」といった用語です。これは、あるマシンから出てネットワークを北方向に通過し、同じマシンに戻る必要があるネットワーク経路を指します。この遅延は、生産性の低下（「すみません、今日は『コンピューター』が遅くて」）や、消費者によるショッピングカートやWebアプリの利用中断の増加という、実際のビジネスコストにつながります。こうした事態は避けなければなりません。トラフィックがイーストウェスト方向に流れるのであれば、サービスもそのデータパス上に配置する必要があります。

影響2：運用上の互換性

2つ目の答えは、負荷分散やWebアプリケーションセキュリティなどのサービスを、運用面で互換性のある形態で導入できるようにする必要があるということです。つまり、新たに登場するすべてのアプリケーション（またはマイクロサービス）の前段に、ネットワークハードウェアを配置するわけにはいきません。そのため、これらのサービスを提供するプラットフォームは、新たなアーキテクチャやテクノロジーとの運用上の互換性を確保できるよう、仮想化またはコンテナ化する必要があります。また、プログラムによる制御に対応し、プロビジョニングと管理にDevOps指向のアプローチを採用できるAPIやテンプレートを提供することも必要です。アプリケーションサービスかネットワークサービスかを問わず、オーケストレーションが可能でなければなりません。SDNも、インフラストラクチャおよびアプリケーション運用環境で広く使われているツールやフレームワークと統合できれば、このニーズに対応できます。

影響3：アーキテクチャが極めて重要

3つ目の答えは、アーキテクチャがこれまで以上に重要になるということです。ネットワークサービスをそのアプリケーションと同じホストにデプロイできるからといって、必ずしもそこにデプロイすべきとは限りません。そのサービスの内容や、他のサービス（およびそのインスタンス）との連携方法によっては、配置が慎重に検討すべき重大な問題となります。たとえば、設計が不十分なロードバランシングは、不要なレイテンシーを生じさせる深刻なトラフィックパターンにつながる可能性があります。このレイテンシーは、事業の利益、あるいは損失に直結します。このシナリオでは、サービスがデプロイされているホストで何らかの障害（ハードウェア、ソフトウェア、ネットワーク、ストレージ）が発生すると、アプリケーションの可用性を確保するサービスも停止するため、ダウンタイム（しかも深刻なダウンタイム）が発生します。高度に分割されたアプリケーションアーキテクチャ（マイクロサービス）では、これらのアプリケーションへの依存度が高い場合、壊滅的な事態につながる可能性があります。

最も明白で簡単な答えに安易に飛びつき、パフォーマンスと可用性に関するベストプラクティスを軽視することがないよう、アーキテクチャを慎重に検討する必要があります。

ネットワーキングでは今なおアーキテクチャ設計が重要

ネットワークの構築は、これまでも、そして今後もアーキテクチャ設計の取り組みであり続けます。単にフォームファクターだけの問題ではありません。フォームファクターは、必要な場所にネットワークリソースをより迅速かつ効率的に配置するための手段にすぎません。重要なのは、そうしたリソースをどこに配置するか、そしてその配置がスタックの上位にあるネットワークサービス、アプリケーションサービス、アプリケーションのパフォーマンス、さらには最終的なビジネスの成否にどう影響するかです。

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

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事