可用性、同時実行性、パフォーマンスに優れたクラウドネイティブ コンテナ ネットワークを構築するにはどうすればよいでしょうか?

クラウドネイティブ インフラストラクチャの構築について話すとき、クラウドネイティブ コンテナ ネットワークについて必ず言及することになります。

ご存知のとおり、コンテナ ネットワークは、クラウド ネイティブの基礎として、クラウド ネイティブ プラットフォームに欠かせない基本コンポーネントであり、クラウド ネイティブ コンテナ プラットフォームを構築する上での最大の課題の 1 つです。

銀行アプリケーションの数と種類が増加し続けるにつれて、ネットワークの複雑さに対する要件もますます高くなっています。銀行アプリケーションにはそれぞれ独自の特徴があります。銀行アプリケーションにはさまざまな管理レベルとアクセス機能があります。従来のネットワーク アーキテクチャとの互換性を保ちながら、従来のネットワークとコンテナ ネットワーク間の相互接続を実現する方法を検討する必要があります。同時に、従来のアプリケーションのコンテナ化移行後に固定 IP を実現する方法、コンテナの複数のネットワーク プレーンと複数のネットワーク カードの管理、マルチテナントおよびクロスクラウド ネットワーク、コンテナ トラフィックの監視、スケジューリング、QoS など、新たな課題にも直面しています。

現在、多くの銀行コンテナネットワークの内部構造は、実際には「ブラックボックス」になっています。コンテナの内部ネットワークと外部ネットワークは接続されておらず、クラウドやマルチネットワーク クラスター間の相互通信は実現できません。変革と改修が早急に必要です。

このようなプレッシャーの下では、高性能なコンテナ ネットワークを構築することが特に重要です。しかし：

• 2 サイト 3 センター アーキテクチャのコンテナ ネットワークを変換して可用性を高めるにはどうすればよいでしょうか?
• 同時実行性の高いシナリオで銀行のコンテナ ネットワークを計画するにはどうすればよいでしょうか?
• 高性能なコンテナネットワークを構築するにはどうすればよいでしょうか?

この記事ではあなたの質問にお答えします。

2 サイト 3 センター アーキテクチャのコンテナ ネットワークを変換して可用性を高めるにはどうすればよいでしょうか?

アプリケーションの高可用性要件に対応するため、多くの銀行では、2 つの場所に 3 つのセンターを構築したり、異なる場所に災害復旧システムを構築したりすることを積極的に行っています。では、コンテナ プラットフォームのアプリケーションと従来の仮想マシンおよび物理マシンの古いビジネス システム間の通信ニーズを満たすために、コンテナ プラットフォームのネットワークを接続または変換し、銀行の既存のネットワーク管理モデルへの影響を回避または最小限に抑えるにはどうすればよいでしょうか。

まず、全体的な観点から、2 サイト 3 センター アーキテクチャにおけるコンテナ ネットワークの変革は、コンテナ プラットフォームが依存する IaaS 機能に基づいて行う必要があります。たとえば、コンテナ プラットフォームが従来の仮想化プラットフォーム上に展開され、SDN ネットワークが有効になっていない場合、コンテナ ネットワークがホストネットワーク モードとして設計されていれば、コンテナ POD のアプリケーションと従来の仮想マシンおよび物理マシンの古い業務システムが直接通信できます。

コンテナ プラットフォームのホスト ノードが IaaS 仮想マシンを使用しており、SDN ネットワークが有効になっており、コンテナ プラットフォームの CNI 機能が有効になっている場合、コンテナ Pod のアプリケーションは IaaS 仮想マシンのビジネス アプリケーションと直接通信できます。従来のネットワークで古いアプリケーションと通信する場合は、IaaS の NAT 機能を有効にするか、ホスト ノードに EIP アドレスを構成する必要があります。

銀行のコンテナ プラットフォーム内のコンテナ アプリケーションと、従来の仮想マシンおよび物理マシン内の古いビジネス システム間の通信で発生する最も一般的な問題は、IP 状態の問題に集中しています。これは、従来のコンテナ プラットフォーム上のアプリケーションが外部通信を実現する場合、主に 2 つの方法があるためです。1 つはホスト マシンの IP + ポートに基づく方法であり、もう 1 つはドメイン名に基づく方法です。これら両方のアプリケーション公開モードでは、コンテナ プラットフォーム上のアプリケーションの実際の IP 情報が隠されます。そのため、従来の仮想マシンや物理マシンの古い業務システムがコンテナ プラットフォーム上のアプリケーションの IP フラット化アクセスにアクセスできないという問題が発生するだけでなく、銀行の既存のネットワーク管理モデルでは、コンテナ プラットフォーム上のアプリケーションの IP ポジショニングやネットワーク リソース管理を実行できなくなります。

上記の問題に対処するために、銀行は Kube-OVN アンダーレイ ネットワーク ソリューションを使用して、2 サイト 3 センター アーキテクチャのコンテナ プラットフォーム ネットワークに接続したり変換したりできます。 Kube-OVN アンダーレイ ネットワーク ソリューションは、OpenStack の ovs レイヤー 2 仮想スイッチング テクノロジーを使用して、コンテナー プラットフォーム上のアプリケーションと従来の仮想マシンおよび物理マシン内の古いビジネス システムをレイヤー 2 ネットワーク プレーンにフラット化します。これにより、コンテナー プラットフォーム上のコンテナー アプリケーションは、従来の仮想マシンや物理マシンなどの基盤となるネットワーク リソースを使用して、直接 IP 通信を実現できます。これにより、銀行の既存のネットワーク管理モデルは、Kube-OVN のアンダーレイ コンテナ ネットワークの下でも有効に維持されます。

同時実行性の高いシナリオで銀行のコンテナ ネットワークを計画するにはどうすればよいでしょうか?

同時実行性の高いシナリオでは、銀行の従来のネットワーク アーキテクチャは柔軟性に欠け、俊敏なビジネスの高まる需要を満たすことができなくなります。コンテナを導入した後、コンテナ ネットワークが従来のネットワークやセキュリティ管理とどのように互換性を持ち、拡張の柔軟性を提供できるかは、すべての銀行ユーザーが懸念する問題です。

金融業界での広範な実践を通じて、クラウドネイティブ プラットフォームの考え方と従来の IT ラインの考え方の間には一定の矛盾があることがわかりました。クラウド ネイティブは、YAML ファイルを通じてアプリケーションを記述することを目的としています。すべての展開プロセス、アプリケーション コンピューティング、ストレージ、およびネットワークは自動的に生成される必要があります。しかし、銀行の専用ネットワーク部門では、ネットワーク仕様が厳密に定義されています。両者の矛盾は特に銀行業界で顕著です。

実践的な実施の観点から、この矛盾を的確に解決し、銀行のコンテナ ネットワークを合理的に計画するために、次の提案を行うことができます。

まず技術的な考え方としては、アンダーレイとオーバーレイを同時に行うことが推奨されます。現在、コンテナ ネットワークの 2 つの基本的な技術的アイデアは、オーバーレイとアンダーレイです。 Overlay は仮想ネットワークを構築するもので、コンテナは仮想 IP を使用します。アンダーレイは基盤となる物理ネットワークを再利用することであり、コンテナは基盤となるネットワークを仮想マシンのように使用します。ある意味では、オーバーレイはプラットフォーム思考の産物であり、アンダーレイはライン管理思考の産物です。一部の銀行では、大規模なオーバーレイを許可し、一部のシナリオ（マルチキャスト、運用管理機能など​​）でアンダーレイを使用することで、両方を同時に実行し、同時に考慮できるようにしています。さらに、一部の銀行は現在、基本的にオーバーレイの余地がなく、アンダーレイ管理を好んでいます。一方、一部の銀行では仮想化をベースにコンテナプラットフォームを構築しており、アンダーレイが使用できない（アンダーレイがIaaSネットワークと競合する可能性がある）ため、オーバーレイを使用しています。このような状況を考慮して、両方を使用し、異なるクラスターに異なるソリューションを採用し、さらに複数のネットワーク カードを介してアンダーレイとオーバーレイを同時に使用することをお勧めします。たとえ需要が 1 つしかない場合でも、将来の拡張の可能性を確保するために両方のソリューションが計画されています。

構築の考え方としては、IaaS のネットワーク構築の考え方を参考にすることができます。 IaaS の典型的なネットワークの考え方は、3 ネットワーク分離または 4 ネットワーク分離です。コンテナネットワークは現在計画中です。 IaaS はインフラストラクチャ ネットワークの責任をより多く負っていたため、このソリューションは過去には考慮されていませんでした。ただし、コンテナ プラットフォームをベア メタル上に展開すると、IaaS で最初に発生した問題が、現在のコンテナ プラットフォームでも発生することになります。

コンテナネットワークと外部ネットワーク間の通信制御に関しては、統合アクセスポイント（イングレス、エグレス）を使用してコンテナネットワーク内のネットワーク相互作用を制御することで、「定常状態」と「敏感な状態」間のセキュリティ相互作用を強化できます。

ネットワーク ポリシー管理の観点からは、可能であれば、ネットワーク ポリシーを使用して各アプリケーションのセキュリティ制御ポリシーを設定することが多くなります。これは、より「クラウドネイティブ」なアプローチでもあります。

クラスター管理の観点から見ると、コンテナ クラウドには複数のクラスターが存在します。高同時実行性と高パフォーマンスを備えたクラスターでは、ホスト マシンでは従来のネットワークが使用され、コンテナー ネットワークでは ovs が使用されます。大容量でスケーラビリティの高いクラスターは、ホスト上で IaaS VPC 分離された SDN ネットワークを使用します。コンテナ ネットワークは CNI コンポーネントを使用し、ホスト ネットワークに直接オフロードされます。

高性能なコンテナネットワークを構築するにはどうすればよいでしょうか?

一部の銀行では従来のネットワークの最適化に多大な努力を払ってきましたが、ネットワーク プラグインの簡素化により、解決されていないパフォーマンスの問題が依然として多く残っています。これらの問題はコンテナ クラウドでは問題にならないかもしれませんが、財務シナリオでは比較的大きな課題となります。

したがって、従来のネットワークからコンテナ ネットワークへのスムーズな移行を実現するためのツールが必要です。現在、業界では比較的優れた CNI ソリューションがいくつか登場しています。現在アクティブな Kube-OVN ネットワーク ソリューションを例にとると、成熟した OVS がコンテナ ネットワーク ベースとして使用されます。 OpenStack分野の成熟したネットワーク機能をKubernetesに移行することで、セキュリティ強化、インテリジェントな運用と保守、ハードウェアアクセラレーションなどの複数の機能を統合し、Kubernetesコンテナネットワークのセキュリティ、操作性、管理性、パフォーマンスを大幅に向上させます。

Kube-OVN の最適化により、パフォーマンスの低下なしに、既存のコンテナ ネットワークと同じトラフィック パフォーマンスを実現できます。例えば、ある株式会社銀行では、物理ネットワークのパフォーマンスに最も近いスループットである Calico ソリューションを以前使用していました。比較すると、Kube-OVN のパフォーマンスは Calico に匹敵します。さらに、OVS や DPDK などのカスタム プロトコル スタックやハードウェア アクセラレーション ソリューションもサポートされるため、コンテナー全体のパフォーマンスが向上します。通常、金融業界では、コアシステムをインストールする際に、厳格なコンテナ ネットワーク パフォーマンス ストレス テストを受ける必要があります。テスト結果は基本的に期待どおりであり、パフォーマンスに関する懸念は解消されます。

さらに、当社はさまざまな銀行の経験、特にセキュリティ、管理、規制の要件を組み合わせて対応する構造を構築し、銀行ユーザーが金融クラウドネイティブに適した高性能コンテナネットワークを構築するのに効果的に役立てることができます。

最後に、皆様が自社の実情を踏まえ、高同時実行性、高可用性、高性能なクラウドネイティブコンテナネットワークの構築に成功し、安定的かつ効率的にクラウドネイティブ化を実現されることを願っています。