_{コンテナのポータビリティと短いライフサイクルによって、従来のネットワーキングスタックが圧迫される可能性があります。どのように対処すればよいでしょうか。}

エンタープライズアプリケーションに向けたアーキテクチャーとして、コンテナベースのマイクロサービスが選ばれることが多くなっています。コンテナ内で実行されるサービスは緊密に相互接続され、分散されたバッキングデータサービスとも接続されています。したがって、コンテナエコシステムにおいてはネットワーキングが重要な要素となります。ただし、動的で高度にスケーラブルであるというコンテナアーキテクチャーの性質によって、企業データセンターのネットワークには深刻な課題が発生します。

これらの課題の中心は、可視性と制御に関するものです。以前の、物理ハードウェアから仮想ハードウェア (仮想マシン) への移行の際にも可視性と制御の課題はありましたが、コンテナではこの課題がさらに大きくなります。問題の1つは、単純にコンテナの数が仮想マシンの数よりもはるかに多いことです。単一のアプリケーションが単一の仮想マシンで実行されるか、複数の仮想マシンで負荷分散されるのに対して、大量のコンテナはそれぞれ複数のマイクロサービスを実行しています。仮想マシン普及の初期段階では、管理対象の仮想マシンが効率的に管理できないほど増大したときに可視性と制御の課題が発生しましたが、コンテナによってその課題がさらに深刻になりました。

その他の大きな課題として、コンテナ化された本番環境を実行するために必要なさまざまなプラットフォームとフレームワークの統合があります。DevOpsプロセス全体と、Docker Hub、Kubernetes、Jenkinsや多数の専用ツールなど、大量のツール全体を対象にアプリケーションのデータフローを可視化し、制御することは簡単ではありません。そこにパブリッククラウドが加われば、コンテナ化されたワークロードを駆動するネットワークでセキュリティ、可視化、制御が困難になることは容易に想像がつきます。

コンテナベースのアプリケーションの革新的な性質によってもたらされるこの問題に対して、確実な解決策はまだありません。また、そのように多様で急速に変化するテクノロジーの組み合わせに対して、特定の推奨事項を決めてしまうことも困難です。最適なアプローチは、代表的な課題とベストプラクティスを把握しながら、常に新しい解決策に目を向けることです。

 

アプリケーションアーキテクチャーによって発生するネットワークの可視性と制御の課題

近年、企業のIT部門の関心はコンテナへの移行とコンテナ内で実行されるコードに向けられていますが、コンテナには多くの複雑性がつきまといます。ITリーダーが大規模なコンテナ導入を計画する際には、これらの複雑性を考慮に入れる必要があります。アプリケーションはマイクロサービスとして設計されているため、通信形態がそれぞれ異なり、異なる負荷とトラフィックのパターンをネットワークに発生させる可能性があります。主要な考慮事項の1つは、コンテナはデータセンター内で移動し、相互に通信するため、多くのクライアントが単一のデータセンターリソースのクラスターにアクセスするNorth-South型トラフィックではなく、East-West型トラフィックに変わることです。

現在のデータセンターのトラフィックは、コンテナの登場前とはまったく異なります。クラウドリソースのプールが重視されるため、ほとんどのデータセンターが物理インフラストラクチャ (サーバー、ストレージ、ネットワーク)、少なくとも1層のソフトウェア定義型インフラストラクチャ、専用サーバー、仮想サーバー、コンテナの組み合わせで構成され、仮想サーバーとコンテナは実行中に物理ロケーション内を動的に移動します。

仮想マシンの普及によってデータセンターネットワークの設計、プロビジョニング、管理、保護の方法が変わったように、コンテナアーキテクチャーによって新しい課題が発生します。中でも最も緊急な課題は、単純にコンテナの数が仮想マシンの数よりもはるかに多いことです。

IDCの調査によれば、平均的な仮想マシンの密度はサーバーあたり2～3個から始まり、現在は10個以上に増加しました。Datadogの調査によれば、Dockerを導入している企業は各ホストで平均8個のコンテナを同時に実行しており、25パーセントの企業は18個、さらに1パーセントの企業は40個以上のコンテナを実行しています。Dockerコンテナを導入している大手企業の一部は1000個を超えるホストを実行していることを考えれば、問題の大きさは明白です。

仮想マシンの導入率が急増するにつれて、仮想マシンの普及によって発生する課題も急増しました。コンテナとコンテナの普及においても同様であることが予測できます。

単純なコンテナの数以外の懸念としては、コンテナが増減する速度があります。Dockerの導入に関するDatadogのアンケートによれば、コンテナは仮想マシンよりも9倍早く削除され、平均的な寿命は仮想マシンの23日に対して2.5日となっています。データセンター運用チームは、これまでのいかなる環境より5～20倍も大きな規模になりうる、急速かつ常に変化する環境をどのように可視化し、制御すればよいのでしょうか。

トップオブラックでは、このような環境を可視化することはできません。仮想化環境でさえ、トップオブラックレベルの物理ネットワーク管理では十分でなくなり、必要なレベルの可視性と制御を達成するために仮想統合を追加する必要がありました。当然ながら、コンテナ化された環境においてはセキュリティも重要な懸念事項ですが、コンテナ化環境の性質によって発生する課題も深刻です。可視性や制御などの基本的なことでさえ、コンテナ化環境では重大な課題となります。データ侵害が発生した場合、問題のある要素を発見して隔離する作業はずっと困難になります。侵害されたコンテナが短い間しか存在しない場合や、データセンター内を動き回っている場合があるためです。

コンテナ化されたワークロードへの移行によって、物理インフラストラクチャとソフトウェア定義型のインフラストラクチャを統制する必要があるため、ネットワークの運用とトラブルシューティングはずっと複雑になります。ソフトウェア定義型のインフラストラクチャは、Docker HubやKubernetesなどの複数のオープンソースプラットフォームにまたがるため、複雑さがさらに増します。たとえば、ネットワークの観点から、これらの複数のプラットフォームに対してアプリケーションのパフォーマンス速度の低下を解決するにはどうすればよいでしょうか。コンテナが侵害される可能性はあるのでしょうか。ネットワークまたはセキュリティチームが、そのコンテナが存在する場所と実行されている正確な場所を追跡し、データセンター内のその他すべての要素とどのように通信しているかを把握するにはどのくらいの時間がかかるでしょうか。

Kubernetesから直接コンテナを削除することは簡単です。それで安全と考えるかもしれません。しかし、そのコンテナはどこかの時点でデータベースに接続されていた可能性があります。データベースが侵害されていないという確証はありません。また、すぐに削除してしまうとしたら、問題のコンテナがKubernetesノード間を移動する間に何を侵害し、何を侵害しなかったかをどのように把握すればよいのでしょうか。IPアドレスを動的に割り当てられるノードのプールによって実行されるコンテナのプール全体で、トラフィックを監査し、潜在的な問題要素を隔離するにはどうすればよいでしょうか。

 

 

セルフサービスのDevOpsとネットワークセキュリティ

コンテナベースのマイクロサービスによって発生するネットワークプランニング、トラブルシューティング、セキュリティの課題は、パズルの1ピースにすぎません。DevOpsプロセスの2つの主要な要素である開発者のセルフサービスと自動化、特に継続的統合/継続的開発 (CI/CD) は、俊敏性よりも制御性を重視する傾向にある従来のエンタープライズネットワークおよびセキュリティのプラクティスとはっきりとした対照をなしています 驚くべきことに、多くの企業で、開発者はセキュリティのポリシーに従うことよりもDevOpsのスケジュールを守ることにより重点を置いています。ご存知でしたでしょうか。

DevOpsとコンテナの核となるのは、開発者 (それとKubernetesのようなコンテナオーケストレーションプラットフォーム) が、すばやく簡単にコンテナをプロビジョニングし、非常に迅速に起動し、それよりもさらに迅速に終了し、負荷に応じてデータセンター内を移動させることができるという考えです。コンテナは、ネットワーク全体と通信できるようにすると同時に保護する必要があります。また、異なるワークロードからのトラフィックは隔離する必要がある場合があります。少なくとも機密性の高いワークロードは、Kubernetesやスイッチングファブリック内など、すべてのレイヤーで隔離する必要があります。それでもまだ、同じゾーンでEast-West型に侵害が広がっている恐れがあります。

どのように考えても、コンテナとDevOpsにはより流動的な環境が必要となります。そして、それによって、企業のデータセンターネットワークとその中のデータに対するリスクは増大します。

 

推奨事項

コンテナが企業のデータセンターネットワークに及ぼす影響に対する万能薬はありませんが、いくつかのツールとプラクティスが役に立ちます。

DDI (DNS、DHCP、IPAM) プラットフォームは、ネットワークの動的な側面を管理するための有益なツールとなります。DDIツールは、コンテナベースの環境の自動化をサポートするために必要な、動的なネットワーク構成の迅速な可視化と詳細な履歴分析を可能にします。DDIによって、ネットワークおよびセキュリティスタッフは核となるネットワーク機能が正確に構成され、複数の環境とプラットフォームにかけて一貫して適用されていることを検証できます。

DDIソリューションはプロビジョニングだけでなく、従来の分散的な手法では不可能だった相関的な可視性や経験則を提供します。ネットワークの可視性とログ記録は非常に重要なニーズであるため、これらのDDIソリューションには、大規模な動的ネットワーク構成をすばやく把握するためにデータの視覚化とAI駆動の自動検出プロセスが含まれている場合もあります。

ネットワークのサービス品質と、KubernetesやDockerが提供するようなソフトウェア定義型QoSを統合することは、エンドツーエンドのQoSに不可欠です。構成が一貫していない場合、複数のチームがアプリケーションのパフォーマンス低下の調査に無駄な労力を費やさなければならない可能性があります。それにより、DevOpsチームが自ら問題に対処しなければならない場合があります。

ネットワークとセキュリティの設計だけでなく、プロセスも計画する必要があることに注意してください。ワークロードをコンテナに移行することは、ネットワーク、サーバー、アプリケーションチームの責任と、その境目も変化することを意味します。

コンテナベースのマイクロサービスへと移行する各ステップを制御および可視化し、この新しいアプローチに適合するようにプロセスを調整してください。適切に取り組めば、高度に動的な複数の環境を保護できます。

HPE Pointnext Servicesによるサポートをご利用ください。これまでの経験と、複数の主要ベンダーとのパートナーシップによって、お客様のニーズとコンテナ環境に合ったソリューションを見つけるお手伝いをいたします。お客様に迅速にソリューションをお届けする方法の一例として、HPE P5モデルおよびHPE Enterprise Security Referenceモデルに基づくコンテナ専用のセキュリティリファレンスアーキテクチャー (SRA) があります。

 

コンテナとネットワーキング: リーダーのためのアドバイス
 

• コンテナは動的で高度にスケーラブルであるため、可視性と制御の観点で、企業のデータセンターネットワークに深刻な課題をもたらします。
• DDIプラットフォームのようなツールを利用することで、データの視覚化やAIベースの自動検出などにより、動的なネットワーク構成を管理できます。
• ネットワーク、サーバー、アプリケーションの各チームの責任が変化するため、ネットワークとセキュリティの設計だけでなく、プロセスにも焦点を当ててください。