Kubernetes ノードの規模が 7,500 を超える

[[382903]]

[編集者注] 2018 年 1 月、OpenAI の公式ブログでは、Kubernetes クラスターを 2,500 ノードに拡張したことが発表されました。 3年後の2021年1月、OpenAI公式ブログは、Kubernetesクラスターが7,500ノードに拡大し、GPT-3、CLIP、DALL·Eなどの​​大規模モデルのニーズを満たすだけでなく、小規模な反復研究にも高速に対応できるようになったことを再度発表しました。以下の記事は OpenAI 公式ブログからのもので、7500 ノード規模に到達する過程で遭遇した問題と解決策、および将来の方向性のビジョンについて説明しています。

当社の Kubernetes クラスターは 7,500 ノードにまで成長し、GPT-3、CLIP、DALL·E などの大規模なトレーニング モデルにスケーラブルなインフラストラクチャを提供するとともに、ニューラル言語モデルのスケーリング法則などの小規模で迅速な反復研究にも使用できます。単一の Kubernetes クラスターをこのサイズに拡張するのは困難であり、そのプロセスには細心の注意が必要です。しかし、このシンプルなインフラストラクチャの利点は、機械学習研究チームがコードを変更することなく迅速に拡張できることです。

2,500 ノードへのスケーリングに関する前回の投稿以来、私たちは研究者のニーズを満たすためにインフラストラクチャのスケーリングを続けており、その過程で多くのことを学んできました。この記事では、Kubernetes コミュニティの利益のためにこれを要約し、最後に私たちがまだ直面しなければならない問題を紹介し、解決策について説明します。

作業負荷

始める前に、作業量について説明することが重要です。 Kubernetes を実行するために使用するハードウェアとソフトウェアは、お客様の会社にあるものとは異なる場合があります。私たちの質問とそれに対応する解決策は、適用できる場合も、できない場合もありますので、適宜適用してください。

大規模な機械学習ジョブは多くのノードにまたがり、各ノード上のすべてのハードウェア リソースにアクセスできる場合にのみ最も効率的に実行できます。このようにして、GPU は NVLink を介して直接相互通信したり、GPU は GPUDirect を介して NIC と直接通信したりすることができます。したがって、多くのワークロードでは、ノードには 1 つのポッドのみが配置されます。 NUMA、CPU、または PCIE リソースの競合はスケジューリングの要因ではないため、ビンパッキング スケジューリングや断片化は一般的な問題ではありません。既存のクラスターには完全な二分帯域幅があるため、考慮するラックやネットワーク トポロジはありません。これらすべてから、Kubernetes には多数のノードがあるものの、スケジュールの圧力は比較的低いことがわかります。

ただし、kube-scheduler ではピーク圧力が頻繁に発生します。新しいジョブには、一度に作成されるものの、使用率が低い数百のポッドが含まれる場合があります。

私たちの最大のジョブは MPI プロトコル (Message Passing Interface プロトコル) を実行し、ジョブ内のすべての Pod が同じ MPI コミュニケーターに参加します。ポッドがダウンすると、ジョブ全体が一時停止され、再起動する必要があります。チェックポイントは定期的に保存され、ジョブが再開されると、最後のチェックポイントから復元されます。したがって、Pod はセミステートフルであると見なすことができます。終了したポッドを置き換えてジョブを続行できます。ただし、この方法は通常の仕事に支障をきたすため、最小限に抑える必要があります。

HTTPS チャネルのトラフィックは非常に少なく、A/B テスト、ブルー/グリーン、カナリア デプロイメントの必要がないため、負荷分散には Kubernetes に完全に依存していません。ポッドは、サービス エンドポイントではなく、SSH 経由の IP アドレスを使用して MPI 経由で直接相互に通信します。当社のサービスの「検出」機能は非常に限られており、通常はジョブの開始時に MPI でポッドを見つけるための検索を実行するだけで済みます。

私たちのジョブのほとんどは、何らかの形式の Blob ストレージを使用します。通常、Blob ストレージからストリームとして直接データを読み取り、特定のシャードのチェックポイントを作成するか、一時的なローカル ディスクにキャッシュします。 POSIX セマンティクスが必要な場合には永続ボリュームも使用しますが、Blob ストレージの方がスケーリングが容易で、低速なデタッチ/アタッチ操作も必要ありません。

最後に、私たちの仕事の多くは研究に基づいているため、作業量自体は常に変化していることを念頭に置いてください。スーパーコンピューティング チームは実稼働レベルのコンピューティング インフラストラクチャを提供するために懸命に取り組んでいますが、クラスター上で実行されるアプリケーションのライフ サイクルは短く、開発者は非常に迅速に反復作業を行います。新しい使用パターンがいつでも出現する可能性があるため、傾向を予測して適切なトレードオフを行うことが難しくなります。状況の変化に応じて迅速に対応できる持続可能なシステムが必要です。

ネットワーク

クラスター内のノードとポッドの数が増え続けるにつれて、Flannel が必要なスループットにスケーリングすることが困難になることがわかりました。そのため、ネイティブ Pod ネットワーク テクノロジを使用して、Azure VMSS と関連する CNI プラグインの IP 構成を管理することにしました。このようにして、Pod はホストレベルのネットワーク スループットを取得できます。

当社の最大規模のクラスターでは約 200,000 個の IP アドレスが使用されており、ルートベースの Pod ネットワーキングをテストしたところ、効果的に利用できるルートの数が大幅に制限されていることがわかりました。そのため、代わりにエイリアスベースの IP アドレスを使用します。

カプセル化を回避すると、基盤となる SDN またはルーティング エンジンの要件が増加しますが、ネットワーク設定はシンプルに保たれます。追加のアダプタなしでトンネルを追加できます。ネットワークの一部では MTU が低いため、パケットの断片化を心配する必要はありません。ネットワーク ポリシーとトラフィックの監視もシンプルです。パケットの送信元と宛先については曖昧さはありません。

ホスト上で iptables を使用して、名前空間と Pod ごとのネットワーク リソースの使用状況を追跡します。これにより、研究者はネットワークがどのように使用されているかを視覚化できます。具体的には、多くの実験ではインターネットとポッド間通信に固有のパターンがあるため、ボトルネックが発生する可能性のある場所を調査できることが不可欠です。

iptables mangle ルールは、指定されたルールを満たすすべてのデータ パケットをマークできます。トラフィックが内部のものか外部ネットワーク宛のものかを検出するために、次のルールを使用します。 FORWARD ルールはポッド間のトラフィックを担当し、INPUT ルールと OUTPUT ルールはホストからのトラフィックを担当します。

 iptables -t mangle -A 入力! -s 10.0.0.0/8 -m コメント--comment "iptables-exporter openai トラフィック = インターネット入力"  
 iptables -t mangle -A転送します! -s 10.0.0.0/8 -m コメント--comment "iptables-exporter openai トラフィック = インターネット入力"  
 iptables -t mangle -A出力! -d 10.0.0.0/8 -m comment --comment "iptables-exporter openai Traffic=internet-out"  
 iptables -t mangle -A転送します! -d 10.0.0.0/8 -m コメント--comment "iptables-exporter  

マークを付けた後、iptables はルールに一致するデータ パケットのバイト数をカウントします。これらの統計は、iptables コマンドを使用して確認できます。

 % iptables -t マングル -L -v
チェーンFORWARD (ポリシー ACCEPT 50M パケット、334G バイト)
 pkts バイト ターゲット protオプトイン     送信元 送信先
....
 1253K 555Mすべて   -- any any anywhere !10.0.0.0/8 /* iptables-exporter openai traffic=internet-out */  
 1161K 7937Mすべて   -- 任意 任意 !10.0.0.0/8 どこでも 

これらのトレースを監視システムにエクスポートするために、iptables-exporter と呼ばれるオープンソースの Prometheus エクスポーターを使用しました。これにより、さまざまな条件を満たすデータ パケットを直接追跡できます。

当社のネットワーク モデルは、ノード、ポッド、サービス ネットワークの CIDR 範囲が研究者に完全に公開されているという点で独特です。ネットワークはハブアンドスポーク モデルを採用し、ネイティブ ノードとポッドの CIDR 範囲を使用してルーティングを行います。研究者は中央ハブに接続し、そこから任意のクラスターにアクセスできます。しかし、2 つのクラスターは相互に通信できません。これにより、各クラスターが分離され、クラスター間の依存関係がなくなることが保証されます (そうでない場合、障害分離の原則に違反することになります)。

クラスター外部からのトラフィックの CIDR 範囲を変換するために、「NAT」ホストを使用します。この構造により、研究者は実験のニーズに合わせて、使用するネットワーク構成とその使用方法を自由に選択できます。

API サーバー

API サーバーと etcd は、クラスターが正常に動作するために Kubernetes の重要なコンポーネントであるため、これらのコンポーネントには特別な注意を払います。私たちは、kube-prometheus が提供する Grafana ダッシュボードと、独自に設計したダッシュボードを使用しました。当社の API サーバーで HTTP 429 (リクエストが多すぎます) および 5xx (サーバー エラー) エラーに関する高レベルのアラートを送信することが非常に効果的であることがわかりました。

多くの人が API サーバーを Kubernetes 内で実行していますが、私たちはクラスター外で実行することを選択しました。 etcd サーバーと API サーバーは両方とも別々のノードで実行されます。最大のクラスターは、負荷を分散してダウンタイムの影響を軽減するために、5 つの API サーバーと 5 つの etcd ノードを実行します。 Kubernetes イベントを別の etcd クラスターに分離して以来、etcd の問題によって発生する障害は発生しなくなりました。 API サーバーはステートレスなので、自己修復インスタンス グループまたはスケールセットを実行するだけで済みます。 etcd クラスターの自己修復自動化は、ほとんど失敗しないため、構築を試みていません。

API サーバーは大量のメモリを消費し、メモリ使用量はクラスター内のノード数に応じて直線的に増加します。 7500 ノードのクラスターの場合、各 API サーバーが占有するヒープ領域は最大 70 GB ですが、これはハードウェアが耐えられる範囲内です。

API サーバーに対する最大のプレッシャーの 1 つは、エンドポイントの WATCH です。 kubelet や node-exporter などの一部のサービスは、クラスター内のすべてのメンバーにサービスを提供します。クラスターにノードが追加または削除されるたびに、WATCH がトリガーされます。また、各ノード自体が kube-proxy を介して kubelet サービスを監視するため、これらのサービスからの応答数と必要な帯域幅は N^2、つまり 1 秒あたり約 1 GB 増加します。 Kubernetes 1.17 でリリースされた EndpointSlices により、この負担が大幅に軽減され、負荷が 1000 倍も削減されました。

一般的に、API サーバーへのリクエスト数がクラスターのサイズに応じてどのように増加するかについては注意が必要です。 DaemonSet が API サーバーと通信しないようにします。各ノードで変更を監視する必要がある場合は、中間キャッシュ サービス (DatadogCluster Agent など) を導入すると、クラスター全体のボトルネックを回避するのに適した方法となる可能性があります。

クラスターが大きくなるにつれて、自動スケーリングの有効性は低下していきました。しかし、時折、大規模な自動スケーリングが発生します。クラスターに参加する新しいノードは多くのリクエストを生成し、一度に数百のノードを追加すると、API サーバーが処理できる容量を超えてしまいます。リクエスト レートをわずか数秒でも平滑化することで、この問題を効果的に回避できます。

Prometheus と Grafana による時系列メトリックの測定

時系列メトリックの収集には Prometheus を使用し、グラフのプロット、ダッシュボードの表示、アラートの生成には Grafana を使用します。まず、さまざまなメトリックを収集し、ダッシュボードを視覚化するために kube-prometheus をデプロイしました。時間の経過とともに、独自のダッシュボード、メトリック、アラートが数多く追加されました。

ノードの数が増えると、Prometheus によって収集されたメトリックを理解することがますます困難になります。 kube-prometheus は非常に有用なデータを多数公開しますが、その一部は不要であり、一部は細分化されすぎて効率的に収集、保存、クエリを実行することができません。そこで、Prometheus ルールを使用していくつかのメトリックを「削除」しました。

長い間、私たちを悩ませてきた問題がありました。Prometheus はメモリをどんどん消費し、最終的にはメモリ不足のためにクラッシュしてしまうのです。 Prometheus に大量のメモリを与えても役に立ちません。さらに悪いことに、クラッシュが発生するたびに、先行書き込みログ ファイルを再実行して正常に使用できるようになるまでに何時間もかかります。

最後に、Prometheus のソースコードを調査したところ、メモリ枯渇は Grafana と Prometheus の相互作用によって引き起こされていることがわかりました。 Grafana は Prometheus の /api/v1/series API を使用し、{le!=""} (「すべてのヒストグラム メトリックを取得する」という意味) のクエリを実行します。 /api/v1/series の実装では、実行時間とスペースに制限はありません。クエリ結果が多すぎると、消費されるメモリと時間がどんどん増えていきます。要求者が要求を放棄して接続を閉じた場合でも、クエリは実行され続けます。私たちの場合、メモリがどれだけあっても、Prometheus は最終的にクラッシュしてしまいます。そこで、Prometheus にパッチを適用し、この API をコンテキストでラップしてタイムアウトを実装したところ、最終的に問題が解決しました。

Prometheus のクラッシュ数は大幅に減少しましたが、依然として頻繁に再起動する必要があるため、先行書き込みログ (WAL) の再実行が依然として問題となっています。通常、Prometheus が起動してメトリックとクエリ要求の収集を開始するまでに、すべての WAL を再実行するのに数時間かかります。 Robust Perception の助けを借りて、GOMAXPROCS=24 に設定するとこの問題が大幅に改善されることがわかりました。 Prometheus は WAL 実行中にすべての CPU コアを使用しようとするため、コア数が多いサーバーではコア間の競合によりパフォーマンスが大幅に低下します。

以下の「未解決の問題」セクションで説明されているように、監視機能を強化するための新しいオプションを検討しています。

健康チェック

このような大規模なクラスターでは、問題のあるノードを検出して削除するために自動化に頼る必要があります。時間の経過とともに、私たちは一連の健康チェックシステムを構築しました。

パッシブヘルスチェック

一部のヘルスチェックはパッシブであり、常にノード上で実行されます。これらのヘルス チェックは、ネットワークのダウンタイム、ディスク障害、ディスクの空き容量、GPU エラーなどの基本的なシステム リソースを監視します。 GPU ではさまざまなエラーが発生する可能性がありますが、最も一般的なのは「修正不可能な ECC エラー」です。 Nvidia のデータセンター GPU マネージャー (DCGM) ツールは、このエラーだけでなく、他の多くの「Xid」エラーのクエリにも役立ちます。エラーを追跡する 1 つの方法は、dcgm-exporter ツールを使用してメトリックを Prometheus 監視システムにエクスポートすることです。これにより、発生した最新のエラー コードを含む DCGM_FI_DEV_XID_ERRORS メトリックが作成されます。さらに、NVMLDevice Query API は、GPU の健全性と動作に関するより詳細な情報を提供できます。

エラーが検出されると、通常は再起動によって GPU またはシステムが修復されますが、場合によってはグラフィック カードを交換する必要があります。

別の種類のヘルスチェックでは、上流のクラウド サービス プロバイダーからのメンテナンス イベントを追跡します。すべての主要なクラウド サービス プロバイダーは、現在使用中の VM がメンテナンスを受け、サービスが中断されるかどうかを確認する方法を提供しています。ハイパーバイザーにパッチを適用したり、物理サーバー上のハードウェアを交換したりする必要があるため、VM を再起動する必要がある場合があります。

これらのパッシブ ヘルス チェックは、すべてのノードでバックグラウンドで継続的に実行されます。ヘルスチェックが失敗し始めると、ノードは自動的にフェンスされ、新しいポッドがそのノードにスケジュールされなくなります。より深刻なヘルスチェックの失敗の場合、現在実行中のすべての Pod が直ちに終了するように要求して、Pod の終了も試みます。このような終了を許可するかどうかは、Pod 中断予算によって構成された Pod 自体が決定します。最終的には、すべてのポッドが終了するか、7 日が経過すると (SLA の一部)、VM を強制的に終了します。

アクティブGPUテスト

残念ながら、すべての GPU の問題が DCGM からのエラー コードにつながるわけではありません。当社では、追加のエラーを検出し、ハードウェアとドライバーが期待どおりに動作していることを確認する独自の GPU テスト ライブラリを構築しました。これらのテストを実行するには、数秒または数分間 GPU を排他的に使用する必要があるため、バックグラウンドで実行することはできません。

まず、ノードの起動時に「事前実行」と呼ばれるテストを実行します。クラスターに参加するすべてのノードは、「preflight」で汚染され、タグ付けされます。この汚染により、通常のポッドがノード上でスケジュールされなくなる可能性があります。次に、そのラベルを持つすべての Pod で事前実行テストを実行するように DaemonSet を構成します。テストが成功すると、テスト プログラムによって汚染が除去され、ノードは正常に使用できるようになります。

また、ノードのライフサイクル中に定期的にテストを実行します。テストは CronJob を介して実行されるため、クラスター内の利用可能な任意のノードで実行できます。これにより、どのノードでテストを実行するかは制御できませんが、十分な時間があれば、サービスに大きな混乱を引き起こすことなく、適切なテスト範囲を提供できることがわかりました。

割り当てとリソースの使用

クラスターの規模が拡大するにつれ、研究者は割り当てられたすべての容量にアクセスすることが困難になり始めました。従来のジョブ スケジューリング システムには、競合するチーム間で作業を公平に実行できるさまざまな機能がありますが、Kubernetes にはこれらの機能がありません。時間の経過とともに、私たちはこれらのジョブ スケジューリング システムからインスピレーションを得て、Kubernetes にいくつかのネイティブ機能を追加しました。

チームの汚点

各クラスターには複数の機能を備えたサービス「team-resource-manager」があります。そのデータ ソースは、特定のクラスターで機能するすべての研究チームのタプル (ノード セレクター、適用するチーム ラベル、割り当て量) を指定する ConfigMap です。クラスター内の現在のノードを追跡し、適切な数のノードを設定します。

 openai.com/team=チーム名:NoSchedule。

「team-resource-manager」には、各ジョブが送信されると、送信者のチーム メンバーシップに基づいて対応する許容値が適用されるような、アドミッション Webhook サービスもあります。テイントを使用すると、優先度の低いポッドに対して「任意」の許容を許可するなど、Kubernetes ポッド スケジューラを柔軟に制約できるため、チームは大規模な調整を必要とせずに互いに容量を借りることができます。

CPU と GPU のバルーン

クラスターオートスケーラーを使用してクラスターを動的にスケーリングするだけでなく、クラスター内の不健全なノードを削除して再追加します。これは、クラスターの最小サイズをゼロに設定し、最大サイズを使用可能な容量に設定することによって行われます。ただし、クラスターオートスケーラーはアイドル状態のノードを検出すると、クラスターを必要なサイズに縮小しようとします。このアイドル状態のスケーリングは、多くの観点から理想的ではありません (VM の起動遅延、事前割り当てコスト、API サーバーへの影響)。

そのため、CPU のみのホストと GPU 対応ホストの両方にバルーン展開を導入しました。デプロイメントには、優先度の低いポッドの最大数を設定するレプリカセットが含まれています。これらのポッドはノード内のリソースを占有するため、オートスケーラーはノードをアイドル状態とは見なしません。ただし、これらのポッドの優先度は低いため、スケジューラは実際のジョブのためのスペースを確保するためにいつでもそれらを削除できます。 (DaemonSet がノード上のアイドル負荷と見なされるのを避けるために、DaemonSet ではなく Deployment を使用することを選択しました。)

注目すべき点の 1 つは、Pod が最終的にノード全体に均等に分散されるようにするために、Pod アンチアフィニティを使用していることです。 Kubernetes の初期バージョンでは、Pod のアンチアフィニティを処理する際のスケジューラのパフォーマンスは O(N^2) でしたが、バージョン 1.8 以降では修正されました。

問題のあるスケジュール

私たちの実験では、多くの場合、1 つ以上の StatefulSet が関与し、それぞれがトレーニング ジョブの一部を担当します。オプティマイザーに関しては、研究者はトレーニング ジョブが完了するようにすべての StatefulSet をスケジュールすることを要求します (オプティマイザーのさまざまなメンバーを調整するために MPI を使用することが多く、MPI はグループ内のメンバー数の変化に非常に敏感であるため)。

ただし、Kubernetes は必ずしもデフォルトで StatefulSet のすべてのリクエストを優先するわけではありません。たとえば、2 つの実験の両方でクラスター容量の 100% が必要な場合、Kubernetes は必ずしもすべてのポッドを実験にスケジュールするわけではありません。代わりに、各実験に対してポッドの半分をスケジュールし、どちらの実験も完了できないデッドロック状態になる可能性があります。

いくつかの解決策を試しましたが、いずれも通常の Pod スケジュールと競合する極端な状況に遭遇しました。 Kubernetes 1.18 では、コア スケジューラ用のプラグイン アーキテクチャが導入され、機能の追加が非常に簡単になりました。この問題を解決するために、最近 Coscheduling プラグインをリリースしました。

未解決の問題

Kubernetes クラスターは成長し続けていますが、解決すべき問題はまだたくさん残っています。質問には次のようなものがあります:

測定

現状の規模では、Prometheus の組み込み TSDB ストレージ エンジンには、速度が遅い、再起動時に WAL (事前書き込みログ) の再実行に時間がかかるなど、多くの問題があります。クエリによって、「クエリがロードするデータが多すぎる可能性があります」というエラーが発生する可能性もあります。現在、Prometheus と互換性のある別のストレージおよびクエリ エンジンへの移行を進めています。

ポッドネットワークトラフィック

クラスターが拡大するにつれて、各ポッドは一定量のインターネット帯域幅を占有するようになります。したがって、全員のインターネット帯域幅を合計すると無視できないものとなり、研究者が意図せず、ダウンロード数などインターネットの他の部分に無視できないリソース圧力をかけてしまう可能性があります。

要約する

Kubernetes は私たちの研究ニーズに非常に柔軟に対応できるプラットフォームであることがわかりました。最も要求の厳しいワークロードにも対応できるように拡張する機能を備えています。しかし、Kubernetes にはまだ改善の余地が多く残されており、OpenAI のスーパーコンピューティング チームは Kubernetes を拡張する方法を引き続き模索していきます。