クラウドネイティブ・ネットワーキングの探究をナビゲート

クラウドネイティブネットワーキングの動きは大手通信事業者やネットワークベンダーがウェブスケールの世界の成功から何らかを学び、その学びを自社のビジネスやネットワークの進化に応用できると認識したことに端を発しています。5G コア、エッジコンピューティング、SASE の展開、企業のデジタル変革などいずれもネットワーク設計にクラウドネイティブの原則を取り入れようとしています。ネットワーク業界はハイパーコンバージドインフラ、クラウドネイティブネットワーク機能（CNF）、サービスメッシュレイヤー、SDN対応ネットワークオーケストレーション、自動化ソリューションを提供し、クラウド時代のネットワークを実現しようとしているのです。

クラウドネイティブの原則とクラウドネイティブネットワークへの適用方法

サービス、アプリケーション、マイクロサービスが分散したドメインに出現し、これらのアプリケーションに対して優れたエンドユーザー体験を提供するためには高い拡張性、回復力、俊敏性、安全性を備えたネットワーク接続が必要になります。

クラウドネイティブネットワーキングで留意すべき3つの主要原則は次のとおりです。

1. 小規模でステートレスなマイクロサービス

“Big Iron”アプライアンスやモノリシックな仮想アプライアンスは、デカップル（依存関係がほとんどない）、特定機能、小規模（コードサイズ、計算フットプリント）のソフトウェアコンポーネントからなるマイクロサービス・アーキテクチャへと変化しており、CNFを構成しています。

可能であれば、これらの個別機能はステートレス（マイクロサービスをホストするコンテナはコンテナ内に状態を保存せず、共通/共有のデータベースまたはストレージに保存する）かつ不変のコンポーネント（つまり、コンテナが起動したらそれを変更しない）になります。これらの特徴により、スケーリングやアップグレード/ダウングレードがより迅速かつ効率的になります。サービスに問題が発生した場合、それを最後の状態に復元する必要がないためです。

さらに、マイクロサービス・アーキテクチャではモノリシック・アプリケーションの場合とは異なり、スケーリングが必要なサービスのみを柔軟にスケーリングすることができます。より小さなコンポーネントがコンテナ内にデプロイされるため、スケールインとスケールアウトはVMよりもはるかに高速に行うことができます。

アップグレードの場合も同様で、更新されたソフトウェアを搭載した新しいコンテナ・インスタンスを起動し、古いインスタンスを停止させることで、ダウンタイムなしのシームレスなプロセスを実現できます。ステートフルなサービスは状態の一貫性と移植性に対処しなければなりません。通常1つまたは複数のコンテナ間でレプリケーションを行い、スケーリングやアップグレードの際に状態の一貫性を維持できるようにする必要があります。

2. DevOps と自動化

アジリティと漸進的なイノベーションを実現するために、クラウドネイティブなネットワークは DevOps モデルを採用する必要があります。

先に述べたように、ステートレスなマイクロサービス・アーキテクチャを採用したクラウド・ネイティブ・ネットワーク機能は、相当数のコンポーネントで構成される傾向にあります。さらに、各マイクロサービスは独立してスケールインおよびスケールアウトするように設計されているため、CNFの負荷を処理するために各マイクロサービスの複数のインスタンスがデプロイされることになります。

つまり、CNFのインスタンス化には数十から数百ものコンテナをデプロイする必要があるのです。このようなデプロイを手動で行うのは現実的ではないため、CNFは常にデプロイプロセスを自動化する方法でオーケストレーションされます。同様に、異なるマイクロサービスのスケーリングや故障したインスタンスの修復などのオペレーションを自動化するためにもオーケストレーションは必要です。

一般的にネットワーク機能は CLI や API によって操作される数百から数千の設定オプションを提供します。従来のネットワークの設定は目的の設定状態に向けて一連の手順を踏むことで手続き的に定義されていました。

これに対して、クラウドネイティブのデプロイメントとコンフィギュレーションに対するアプローチは宣言型です。希望するデプロイとコンフィギュレーションは構造化されたドキュメント（YAMLとHELM）に全て記述されており、コンテナオーケストレーターで利用できるようになります。構成に対する宣言型アプローチは変更に対するはるかに大きなコントロールを提供し、不適切な構成がネットワークに注入される可能性を低減し、DevOpsパイプラインで自動化できるため回復が大幅に高速化されます。

堅牢なDevOpsを実現するもう一つの重要な点は、異なるマイクロサービスや異なるベンダーのCNFを相互接続しエンドツーエンドのサービスチェーンを構築するために使用できる、明確に定義されたAPIを持つことです。

3. プラットフォームに依存しないデプロイメント

結局のところ、通信事業者と企業はベンダーにとらわれることなく、どこにでも導入できるソリューションを求めています。理論的にはクラウドネイティブ・コンテナ・アーキテクチャは、COTSハードウェア、オンプレミス、パブリッククラウド上で直接、アプリケーションとネットワークを「プラットフォームに依存しない」形で実行するための抽象化を提供します。

クラウドネイティブネットワーク事業者が直面する主な課題

クラウドネイティブネットワーキングは明らかに有望な変革ですが、他のイノベーションと同様に課題がないわけではありません。次のセクションではクラウドネイティブネットワークのオペレータが直面している主な課題について説明します。

1. レガシーバッグへの対応：現実には一夜にして全てがクラウドネイティブになるわけではありません。多くの事業者は移行に伴い、レガシーな仮想ネットワークやネットワーク機能に対処しています。また、クラウドネイティブのネットワーク機能はマイクロサービスの切り離しが十分でないため、ネットワークの拡張や運用が面倒になっています。

2. 移動するパーツが多く、障害点が多い：プラットフォームにとらわれないということは、すべてが分解されオンデマンドでネットワークの変更が可能になることを意味します。この柔軟性により、ネットワークオペレータはコンピュート、NIC、コンテナオーケストレータ（OpenShift、TANZU、Kubernetes）、クラウドインスタンス（AWS EKS、GCP GKE、Azure AKS）、および複数のベンダーの各種 CNF オプションの多くのオプションを提供し、それが障害ポイントを増やすことにつながる可能性があります。新しいCPUやKubernetes CNI、Linuxディストリビューションの新バージョンへの単純なアップグレードでさえパフォーマンスに予期せぬ結果をもたらす可能性があります。移動パーツが多いため、トラブルシューティングや根本原因の分析が非常に困難になります。

3. エラスティックなスケーリングの影響：クラウドネイティブなインフラストラクチャは負荷や需要に応じてワークロードをダイナミックにスケーリングすることができます。ワークロードの寿命は従来の数ヵ月、数年から数分、数時間に短縮されます。このためクラウド・ネイティブなネットワークやサービスの導入に伴い、エンドユーザーの体感品質（QoE）の低下を最小限に抑えつつ、クラウドインフラのサイズ適正化とコストの最適化を図るという新たな課題が発生します。　また、クラウドネイティブ環境ではネットワーク機能が他のサービスと基盤となるインフラを共有するため、CNFやサービスのパフォーマンスを確保する際にマルチテナント（「ノイジーネイバー」）の影響を補正するための特性評価も必要です。

4. 組み込みセキュリティ：ネットワーク・セキュリティのパラダイムも変化しています。コンテナ環境の俊敏性は環境をサービスまたは保護するミドルボックスが一連のユニークな課題に直面することを意味します。クラウド・ネイティブ・アプリケーションには何百ものサービスが関連付けられているため、ミドルボックスはより高速かつ大規模にコンテナの柔軟でダイナミックな性質を処理する必要があります。ネットワーク事業者はアプリケーション資産が作成されると同時に、セキュリティとアプリケーションのポリシーが自動的にスケールインおよびスケールアウトされ、そのリソースが存在しなくなるまですべての変更を追跡できる必要があります。DevSecOps はセキュリティの一部を CI/CD パイプラインに統合し、チームが開発フェーズにセキュリティを取り込むことを促進します。さらに、これらのポリシーがパフォーマンスとユーザ体感に与える影響を関連付ける必要があります。

5. 回復力の発揮：回復力はクラウド・ネイティブ・アーキテクチャのもう一つの重要な課題です。このダイナミックな環境では問題が発生することは避けられないため、分散マイクロサービス・ソリューションを設計し、クラウド・プラットフォームやコンテナ・オーケストレーション・エンジンがインフラの問題を検出し軽減できるようにすることが不可欠です。マイクロサービスは再起動したりスケールアウトしたり、別のノードに再分配されたりする可能性があります。マイクロサービスの障害（ポッドの故障、ノードの再起動、ネットワーク遅延、CPUスパイクなど）がCNFに与える影響を確実に把握する必要があります。目標は商用展開前に実際の障害をエミュレートし、CNFが本番ネットワークに展開される前に問題をプロアクティブに発見することです。これによって回復力を高めるためのアクションを実行するための適切な閾値を設定することができます。

6. 絶え間ない変化への対応：最後に、クラウドネイティブ環境における変化のスピードはレガシーネットワークの10倍にもなります。クラウドプラットフォーム、NFVI、CNF を提供するベンダーは常に新しいイノベーションを市場に投入しており、そのスピードはかつてないほど速くなっています。ネットワーク事業者は堅牢な継続的インテグレーション、継続的開発、継続的テスト（CI/CD/CT）を実践するためにベースライン（アップデート前）と新しい性能（アップデート後）を比較することで、変化やアップデートの影響を把握しインフラコンポーネントを検証・最適化する必要があります。

クラウドネイティブ環境における変化の影響を把握

上記の課題を克服するためには、プロアクティブなテストと継続的な検証を実施することが鍵となります。Spirent CyberFloodはコンテナ環境におけるアプリケーションパフォーマンスおよびセキュリティテストをサポートしており、オンプレミス、VM、パブリッククラウド、コンテナ環境にわたって拡張可能で現実的なアプリケーションワークロードエミュレーションを実現し、クラウドネイティブネットワークソリューションのパフォーマンス、ユーザー体験、セキュリティを最適化できるよう支援しています。

以下は、クラウドネイティブネットワークへの対応するためにCyberFloodが取り組む主なユースケースの例です。

1. OpenShift、AWS EKSなどのさまざまなKubernetes実装のパフォーマンスをテストすることによって、クラウドインフラ、クラウドインスタンスを適切なサイズにし、適切なNICドライバ、Linuxディストリビューション、CNIで最適化

2. クラスタへの外部トラフィックのエミュレーション（南北）により、Ingress Controllerのパフォーマンスとスケールを検証

3. NGFW、WAF、ELB CNFのパフォーマンスと柔軟なスケーラビリティを実際のアプリケーションワークロードでベンチマーク

4. CNFの複雑な分散型、ハイブリッド型、コンテナ型配備を検証

5. セキュリティの有効性、およびセキュリティポリシーがパフォーマンスとユーザー体感に与える影響を検証

6. 新しいアプリケーションまたはサービスのあらゆる展開段階において、自動化された反復可能なテストのため、あらゆるCI/CD「パイプライン」にシームレスに統合するための包括的なAPIを提供

CyberFloodがどのようにプロアクティブテストと継続的検証を支援し、クラウドネイティブネットワーキング探究のお役に立てるか、ぜひご覧ください。