コンテナを大規模に実行する場合の最適なデータ ストレージ パス

K8s やその他のコンテナ オーケストレーション プラットフォームは、急速に主流のインフラストラクチャ設定に浸透しつつあります。ほとんどのビジネス指向のアプリケーションでは、従来のデータ センターからコンテナー デプロイメントへの移行は比較的独立しており、簡単です。しかし、データベースや高速データ分析ワークロードなど、要求の厳しいコアアプリケーションとなると、物事はそれほど単純ではありません。

まず、アプリケーションのコンテナ化により、ネットワーク、ストレージ、フォールト トレランスなどの基盤となるインフラストラクチャに対する要求が高まります。 K8s はこれらの面で大きな進歩を遂げていますが、アプリケーションはローカルで実行するかクラウドで実行するかにかかわらず、依然としてパフォーマンスの低下を経験します。第二に、K8s ネットワークは、中規模のアプリケーションであっても、低く予測可能なレイテンシを提供できません。

私たちは、IT システムをスムーズに稼働させるために必要な CPU、帯域幅、ストレージ容量が、展開を最適化する上で重要であると考えています。したがって、システムがデータをどのように通過するかを理解することで、パフォーマンスが最適でない潜在的な原因とその解決策が明らかになります。

コンテナ化されたワークロードにストレージを提供する 3 つのアプローチ

プライベートクラウドと共存アプライアンス/ストレージクラスタ

ローカル ストレージは通常、最も機能が豊富でスケーラブルなストレージ方法ですが、コンテナー ネイティブのデプロイメントでは完璧ではない可能性があります。これらのローカル インスタンスでは、ストレージは K8s システムと並行して存在し、K8s はコンテナ ストレージ インターフェイス (CSI) プラグインを介してアプリケーションをストレージに接続します。このプラグインは、アプリケーション コンテナを外部ストレージに直接接続することで機能し、K8s によって制御されるネットワークを完全にバイパスします。

コンテナストレージソフトウェア

コンテナで生まれ、コンテナを使用して実装されるソリューションには、コンテナ用に構築されるという利点があります。これらの製品は「機能優先」のアプローチを採用しており、IT チームがシン プロビジョニングや重複排除などの機能を維持できるように支援します。ただし、大規模でも本番環境でも、パフォーマンスはデータ パスに依存します。これらのソリューションは、それ自体がコンテナとして実装されているストレージ コントローラーを介してストレージ デバイスへのアクセスを提供するため、データ パス全体が K8s ネットワークを通過する必要があり、レイテンシに影響を及ぼします。

K8s でネイティブに実行されるソフトウェア定義ストレージ

市場には純粋なソフトウェア定義ストレージのオプションがいくつかありますが、そのうち K8s でネイティブに実行されるのはほんのわずかです。これらには、K8s に移植されて使用され、プライベート クラウドとハイブリッド クラウドの展開もサポートされるスタンドアロンのベアメタル ソフトウェア定義ストレージ製品が含まれます。

K8s のオリジナルのソフトウェア定義ストレージは、上記の 2 つの方法の利点を活用して、最適なパフォーマンスとスケーラビリティを実現します。これはコンテナネイティブであり、実装によってはデータパスが K8s から分離されるため、コンテナ ストレージ ソフトウェアのみのアプローチでは CSP よりもパフォーマンスが優れています。

これにより、データ センター アーキテクトは、従来のオンプレミス アーキテクチャとコンテナーのみのストレージの両方の利点を最大限に活用できるようになります。レイテンシの予測可能性を確保するために、K8s の下のデータ パス (コンテナーと NVMe SSD の間) はカーネルからクライアント デバイス ドライバー、ターゲット ドライバーへと移動し、そこから NVMe ドライバーに直接アクセスします。

この方法では、クライアントは完全に独立しており、クライアント間の通信なしでターゲットと直接通信できます。これにより、ネットワーク ホップ数と通信回線数が削減され、接続数がドメイン サイズの小さな倍数である大規模な環境でこのモードを使用できるようになります。

Elasticsearch アプリケーション

システムを K8s でネイティブに実行できるようにするいくつかのユースケースは、ソフトウェア定義アプローチの利点を実証しています。たとえば、EMEA 地域の大手通信プロバイダーは、大規模な K8 で Elasticsearch の 3 つのストレージ アプローチを試しました。外部の iSCSI ベースの SDS はスケーラブルですが、ミリ秒単位の遅延があるため、インデックス作成のパフォーマンスが低下します。一方、K8s ネイティブのストレージ ソリューションは、数百のノードのスケール要件を満たすことができません。どちらのアプローチも、エンドユーザーのエクスペリエンスを大幅に悪化させます。 3 番目のアプローチは、NVMe ベースのスケーラブルな SDS です。K8s ノードに組み込まれた NVMe ドライブを使用し、K8s 制御プレーンと管理プレーンへのネイティブ統合を組み合わせることで、大幅に優れたパフォーマンスとレイテンシを実現します。

ベアメタルパフォーマンスを備えたK8sのNVMeネイティブ共有ストレージシステムアーキテクチャ

CI/CD アプリケーション

別の例では、トップクラスの Web 企業が、数万のノードを持つデータセンターの CI/CD アプリケーションで K8s でネイティブに SDS を実行し、コンパイル、ビルド、ローカル テストのための強力な制御環境を提供しました。図 1 は、SDS の NVMe ベースのクライアントとスケールアウト アーキテクチャにより、ベアメタル パフォーマンスを維持しながら CI/CD ワークロードを K8s に移行できる様子を示しています。

K8s で実行する場合、このアプローチは、特権コンテナを使用してクライアントおよびターゲット デバイス ドライバーの展開を制御し、K8s 環境のコンテナ化された性質からデータ パスを保護し、すべての制御プレーンおよび管理プレーン コンポーネントをネイティブ コンテナ API ベースの操作に移動します。このトップ ネットワーキング カンパニーの運用環境では、ストレージ ソフトウェアが複数のリモート NVMe ドライブを単一の仮想ボリュームに集約し、アプリケーションを実行するコンテナーに提示するため、アプリケーションのパフォーマンスがベアメタルよりも 15% ～ 20% 高くなります。

成功への優れたデータパス

アプリケーションのスケーラビリティとパフォーマンスのニーズを満たす適切なストレージを見つけることは、万能のアプローチではありません。ストレージ アーキテクトがデータ パスの影響を理解してコンテナーのストレージを選択すると、コンテナー化されたハイブリッド展開でアプリケーションをよりスムーズに実行し、スケーラブルで高性能かつ俊敏なストレージを実現できます。