Netflix が最新の CPU でコンテナをスケーリングする際のカーネルレベルのボトルネックを発見

のエンジニア Netflixが暴露した コンテナのスケーリングにおける深いパフォーマンスのボトルネック Kubernetes または、containerd のみを使用しますが、CPU アーキテクチャと Linux カーネル自体を使用します。詳細なブログ投稿の中で、Netflix の技術者は、最新のコンテナ ランタイムへの移行により、グローバル マウント ロックに関する驚くべき競合がどのように明らかになったかを説明しています。 カーネルの仮想ファイルシステム (VFS)、基盤となるハードウェア トポロジとロック競合により、たとえ強力なクラウド サーバー上であっても、数百のコンテナの同時スケーリングが制限される可能性があることが明らかになりました。

この問題が最初に表面化したのは、Netflix ワークロードを実行しているノードが同時実行性が高い状態で数十秒間停止し始め、単純な正常性プローブがタイムアウトし、コンテナーの作成がフリーズしたためです。調査の結果、多層コンテナー イメージの起動中にマウント テーブルが劇的に膨張し、containerd が各イメージ レイヤーのユーザー名前空間をマップするために数千回のバインド マウント操作を実行したため、カーネルのグローバル マウント ロックに負担がかかることが判明しました。すべてのコンテナで数十回のマウントとアンマウントが必要になるため、大規模バースト中の累積ワークロードは 20,000 マウント システムコールを軽く超え、すべてが同じカーネル ロックにアクセスする必要があり、これがオペレーティング システムの奥深くにある古典的な同時実行ボトルネックでした。

Netflix のパフォーマンス チームは、この負荷の下ではすべての CPU アーキテクチャが同じように動作するわけではないことを発見しました。古いデュアルソケット AWS r5.metal インスタンス (複数の NUMA ドメイン メッシュ ベースのキャッシュ コヒーレンスなど）、同時実行性が高いと、共有キャッシュとグローバル ロックでの競合が加速され、パフォーマンスが大幅に低下します。対照的に、分散キャッシュ アーキテクチャを備えた AWS m7i.metal (Intel) や m7a.24xlarge (AMD) などの新しいシングルソケット インスタンスは、コンテナ数が増加してもストールが少なく、はるかにスムーズにスケールできました。分析の結果、NUMA 効果、ハイパースレッディング、キャッシュ マイクロアーキテクチャなどの要因が、グローバル ロック競合がシステム全体にどのように伝播するかに大きな影響を与えていることが明らかになりました。

Netflix のエンジニアは、ハードウェア設計が大規模な場合に重要であることを確認しました。 NUMA によるリモート メモリ アクセスの遅延 競合するハイパースレッドによってロック待機が悪化する一方で、分散キャッシュ設計によりボトルネックが軽減されました。たとえば、ハイパースレッディングを無効にすると、一部の構成でレイテンシが最大 30 % 改善され、単一ソケット インスタンスではクロスドメイン メモリのペナルティが完全に回避されました。これらの実験は、コンテナーの負荷が高いワークロードの信頼性の高いスケーリングを実現するには、ソフトウェアの同時実行性とハードウェアの動作の両方を理解する必要があることを実証しました。

この洞察をもとに、チームは 2 つの主要な緩和策を検討しました。 新しいカーネル マウント API ファイル記述子を使用してグローバル ロックを完全に回避し、コンテナあたりのマウント操作の数がレイヤー数の線形 (O(n)) からコンテナあたりの一定時間 (O(1)) に減少するようにオーバーレイ ファイルシステムの構築方法を再設計しました。 Netflix が後者を選択したのは、新しいカーネルを必要とせずにより広範囲にデプロイでき、実際にはマウント競合がなくなるためです。レイヤー マウントを共通の親の下にグループ化すると、カーネル上のマウント負荷が大幅に低下し、高負荷下でもコンテナの起動がスムーズになります。

Netflix は、要求の厳しいワークロードを、 グローバルロック ハードウェアを意識したスケジューリングとソフトウェアの改善を組み合わせて、より適切に実行します。彼らの調査結果は、大規模な組織にとってより広範な教訓を浮き彫りにしています。分散システムで予測可能なパフォーマンスを達成するには、多くの場合、コンテナー オーケストレーションやファイルシステムの使用法からカーネル内部や CPU マイクロアーキテクチャに至るまで、スタック全体にわたる共同設計が必要です。

Netflix チームは、これらのパフォーマンスに関する洞察をより広範なエンジニアリング コミュニティと共有するために詳細な調査結果を公開し、最新のクラウド プラットフォームのボトルネックは、ほとんどの開発者が通常考慮しない場所で発生する可能性があり、それらを解決するには、低レベルのシステム調整と、ワークロードを実行しているハードウェアの明確な理解の両方が必要になる可能性があることを強調しました。

いくつかの組織が、コンテナのスケーリングとカーネルレベルの競合に関する Netflix の調査結果と密接に一致するベスト プラクティスを公開しています。に重点が置かれています ハードウェアを意識したワークロードの配置、特に NUMA トポロジについて理解する キャッシュコヒーレンス設計、 そして ハイパースレッディング動作 高密度コンテナーのワークロードを実行する場合。有利なベストプラクティスもあります シングルソケットアーキテクチャ または慎重に選択してくださいインスタンスファミリー これにより、クロスドメインのメモリ遅延が最小限に抑えられ、システム負荷の高い操作にはベアメタルまたは専用のインスタンスが使用されます。ソフトウェアレベルでは、 Kubernetes そして コンテナランタイムコミュニティ 共有ボトルネックを回避するために、マウントおよびアンマウント操作を最小限に抑え、ファイルシステム層を統合し、可能な限り新しいカーネル API を採用することで、グローバル ロック競合を軽減することを提唱しています。

また、以下のような団体も、 グーグル そして メタ のようなツールを使用して、コアスケーリング実践としてシステムレベルの深い可観測性を強調します。 eBPF、 パフォーマンス、 そして フレームグラフ 隠れたカーネル ストールと同時実行時のロック競合を検出します。クラウド プロバイダーは、イメージ キャッシュ、オーバーレイ ファイル システムの最適化、および起動時の増幅効果を軽減するためのランタイム構成の調整にローカルの一時ストレージを活用することも推奨しています。これらの実践は、ハードウェアとソフトウェアの共同設計への広範な業界の移行を反映しており、予測可能なコンテナのスケーリングは、オーケストレーションとランタイムの改善だけでなく、CPU マイクロアーキテクチャ、ファイルシステムの動作、およびカーネル内部の理解にも依存しており、これは Netflix の分析で強調されているのと同じスタック間アプローチです。