クラスタの平均CPU使用率は45％に達し、Xiaohongshuの大規模コロケーション技術の実践が明らかになった。

ガートナーの予測データによると、世界のIT支出は2024年に5.1兆米ドルに達し、2023年から8％増加すると予想されています。ただし、同機関の別の調査データによると、世界中のデータセンターサーバーの平均CPU使用率は一般的に20％未満であり、リソースの大きな浪費につながっています。数百万個の CPU コアを備えたデータセンターを例にとると、全体的なリソース使用率が 1 パーセントポイント増加するごとに、毎年数千万元のコストが節約されると推定されます。リソース使用率の向上は、企業の運用コストの削減に大きな効果があることがわかります。

Google は早くも 2015 年に、その代表的な論文「Borg による Google での大規模クラスタ管理」の中で、リソース管理とスケジューリングに関する実践的な経験を公開しました。同社は、コロケーション技術を通じてリソースの利用率を向上させた最初の企業の 1 つです。国内の大手インターネット企業の多くも同様の技術的ソリューションを実装し、リソース利用率の向上に大きな成果を上げています。

小紅書の事業が急速に発展するにつれ、さまざまなオンラインおよびオフラインのビジネスからのコンピューティング リソースの需要が増加しています。同時に、一部のオンライン クラスターの 1 日あたりの平均使用率は低いレベルに留まっていることがわかりました。この現象の主な理由は次のとおりです。

• オンライン サービスのリソース使用量は、エンド ユーザーの使用習慣に応じて安定した変動現象を示しています。夜間の CPU 使用率は極めて低いため、クラスター全体の平均 CPU 使用率も低下します。
• このビジネスには、多数の専用リソース プールがあります。リソース プールの断片化により、多数のリソース フラグメントが生成され、CPU 使用率が低下します。
• 安定性上の理由から、企業は過剰なリソースを予約する傾向があり、CPU 使用率がさらに低下します。

上記のような背景を踏まえ、企業のリソース使用コスト削減を支援するため、Xiaohongshu のコンテナ チームは 2022 年に大規模なコロケーション テクノロジの実装を開始し、クラスターの CPU 使用率を向上させました。現在、コロケーション クラスターの平均 CPU 使用率は 45% を超えており、ビジネスに数百万のコアのコンピューティング パワー コストの最適化を提供します。

1. 技術の進化

Xiaohongshu のコロケーション テクノロジーの進化は、次の 4 つの段階に分けられます (図を参照)。

フェーズ1: 未使用リソースの再利用

初期の頃、Xiaohongshu のクラスター リソース管理は比較的広範囲にわたっており、クラスター内にはビジネス専用のリソース プールが多数存在していました。リソースの断片化などの要因により、各クラスター内に割り当て率が低い非効率的なノードが多く存在し、大量のリソースが無駄になります。同時に、Kubernetes (K8s) によってリリースされたトランスコーディングのニアライン/オフライン シナリオに基づくと、1 日を通してコンピューティング リソースに対する大きな需要があります。上記の背景に基づいて、Xiaohongshu のコンテナ プラットフォームは技術的な手段を使用してクラスター内のアイドル リソースを収集し、トランスコーディングのビジネス シナリオに割り当てます。

全体的なアーキテクチャの観点から見ると、オフライン ビジネス リリース ポータルは 1 つのクラスターに統合されており、これをメタデータ クラスターと呼びます。目的は、ビジネスの基盤となるマルチ物理 K8s クラスターを保護することです。メタデータ クラスターと物理クラスターは Virtual-Kubelet を介して接続され、アイドル リソースはメタデータ クラスターに集約され、トランスコーディング タスクはメタデータ クラスター内でスケジュールされ、基盤となる物理クラスターに分散されます。

戦略面では、セカンダリ スケジューラはクラスター内のすべてのノードを検査し、非効率的なノードを識別してマークする役割を担います。次に、Virtual-Kubelet は物理クラスター内の非効率的なノードの使用可能なリソースをクラスターアイドルリソースとして取得し、それらをオフライントランスコーディングシナリオに再度割り当てます。同時に、セカンダリ スケジューラは、オンライン サービスにリソース要件が発生すると、オフライン Pod が直ちに削除され、リソースが返されることを保証します。これにより、クラスター リソースの利用効率が向上し、リソースの無駄が削減され、トランスコーディング シナリオのコンピューティング リソース要件を満たすことができます。

フェーズ2: マシン全体の再配置とタイムシェアリング再利用

検索およびプロモーション サービス専用のリソース プールでは、CPU 使用率の急激な上昇現象が顕著に見られ、特に夜間は使用率が極端に低くなります。通常、リソース プール内の 1 つのノードには、大規模なビジネス ポッドが 1 つだけデプロイされます。この状況を踏まえ、プラットフォームは、弾性容量（HPA）を使用して、早朝のオフピーク時間帯にオンラインサービスを比例的に縮小し、マシン全体のリソースを解放し、この期間中にトランスコーディングやトレーニングなどのオフラインポッドを実行することで、リソースの最適化を実現し、利用の「谷を埋める」効果を実現します。

具体的な実装プロセスでは、すべてのオンライン サービスが指定された時間内に開始できることを確認する必要があります。この目的を達成するために、オフライン サービスの早期終了を実装し、スケジューラのプリエンプション メカニズムを使用して、ビジネスのピークが到来する前にオンライン サービスが完全にタイムリーに再開されるようにするという戦略を採用しています。

このフェーズでは、リソースの使用を最大限に活用できるため、オフピーク期間中にオフライン サービスを効率的に運用しながら、ビジネスのピーク期間中にオンライン サービスを迅速に復旧できます。

フェーズ3: 通常のコロケーション

リソースの断片化とビジネスリソースの保有コストを削減するために、プラットフォームは大規模なビジネスプーリングを継続的に推進し、ビジネスを専用リソースプールからプラットフォームがホストするパブリックコロケーションプールに移行します。プールのマージやリソースの過剰販売などの技術的手段により、CPU 割り当て率は効果的に改善されましたが、夜間にマージされたリソース プールの使用率が低いという問題は依然として解決されていません。さらに、プールのマージ後の複雑なコロケーション シナリオでは、マシン全体の再配置とタイムシェアリング コロケーションのオフラインでのスケジュール戦略を継続的に実装することが困難です。平均使用率を向上させるという目標を達成するには、プラットフォームで以下の点を含む、よりきめ細かいリソース管理およびスケジューリング機能を構築する必要があります。

1. スケジュール面

• 動的オーバーセリング技術は、オフライン サービスに再割り当てできる利用可能なリソースを取得するために使用され、オフライン リソース ビューは、K8s スケジューラがこれらのオフライン リソースを認識できるように抽象化されます。スケジューラは、対応するノードにオフライン負荷をディスパッチし、ノード使用率に対するオフライン サービスの「谷埋め」効果を実現します。
• 負荷スケジューリングにより、オンライン サービスが高負荷のマシンにスケジュールされることを可能な限り回避し、クラスター内のノードの負荷をより均等にすることができます。
• セカンダリ スケジューリングにより、負荷ホットスポット マシン上の使用率の高いサービスが排除され、クラスターの負荷が動的にバランスのとれた状態に維持されます。

2. 片側機械側

• QoS (Quality of Service) 保証戦略をサポートし、サービスの QoS レベルに基づいて差別化されたランタイム リソース保証機能を提供します。
• 干渉検出、オフライン排除などの機能をサポートします。オフライン サービスがオンラインの機密サービスに干渉する場合、直ちに排除されます。
• 上記の技術的手段により、サービスのハイブリッド展開の安定性を効果的に確保し、ノード上のオンラインおよびオフラインのワークロードの正常なハイブリッド操作を実現し、利用の「谷埋め」効果を最大化できます。

フェーズ4: 統合スケジュール

通常のコロケーションと大規模なリソース プーリングの継続的な進歩により、Xiaohongshu のクラウド ネイティブ リソース スケジューリングは次の課題に直面することになります。

1. さまざまなビジネスシナリオでは、リソースのスケジュール設定に対する機能要件とパフォーマンス要件が複雑かつ異なります。

• ビッグデータおよび AI シナリオ: キュー スケジューリング、バッチ スケジューリング (All-or-Nothing)、高スループット スケジューリングなどの要件。
• オンラインの機密性の高いサービス シナリオ: リソース スケジューリングの成功率保証要件とサービス ランタイム品質保証要件。

2. GPUなどの異種リソースのスケジューリング要件

• GPU 共有スケジューリングやビン パッキングなどのスケジューリング機能をサポートし、GPU マシン上の GPU 使用率と CPU 使用率を向上させます。
• GPU トポロジ認識やアフィニティ スケジューリングなどのスケジューリング機能をサポートし、GPU 間の通信効率を最適化することで大規模トレーニングの効率を大幅に向上します。

上記背景を踏まえ、ハイブリッド クラウド アーキテクチャ向けの統合スケジューリング ソリューションを提案します。このソリューションは、統合リソース プールをベースとし、統合スケジューリング機能を通じて異機種コンピューティング リソースを管理し、さまざまなビジネス フォームのワークロード スケジューリング機能をサポートします。グローバルな視点を取り入れることで、ワークロードを最も適切なノードにスケジュールすることができ、ビジネスをより迅速かつ安定的に実行し、グローバルなリソース使用コストを削減できます。重要な技術的ポイントは次のとおりです。

1. オフライン統合スケジュール

K8s に基づく統合スケジューリング機能を提供し、オンラインの機密サービスやビッグデータ/AI タスクベースのワークロードを含む統合リソース スケジューリングをサポートします。

2. QoSを考慮したスケジューリング

サービス プロファイリングに基づいて、システム インジケーターが組み合わされ、干渉源が識別され、ノード リソースの品質が特徴付けられます。総合スケジューリング、再スケジューリング、単一マシンスケジューリングなどのさまざまな次元のスケジューリング機能により、サービスの混在展開による干渉が軽減され、オンラインサービスの運用品質が向上します。

3. GPUスケジューリング

GPU 共有、ビン パッキング、複数の GPU カード間のアフィニティ スケジューリングなどのスケジューリング機能をサポートし、GPU リソースの利用効率を向上させます。

4. リソース販売モデル

リソースの品質、リソースの供給形態（定期供給リソース、タイムシェアリング潮汐リソース、スポットリソースなど）、リソースパッケージ仕様などの複数の次元に基づいて差別化されたリソース販売モデルを定義し、リソース使用の全体的なコストを削減します。

5. リソース割り当て

タイムシェアリング クォータ、エラスティック クォータ、階層構造管理などのリソース クォータ管理機能をサポートし、複数のテナント間のリソース競合を回避し、リソース利用効率を向上させます。

2. アーキテクチャの設計と実装

Xiaohongshu のコンテナ統合リソース スケジューリング システム Tusker (効率性と信頼性のための Kubernetes ベースの統合スケジューリング システム) のアーキテクチャ設計を図に示します。

Xiaohongshu のさまざまなビジネス シナリオは、複数の公開プラットフォームとタスク プラットフォームを通じて送信され、上位層の負荷オーケストレーション機能を通じて Pod の形式で統合スケジューリング システムに配信されます。統合スケジューリング システムは、さまざまなスケジューリング要件に基づいて、オンライン サービスに対して強力なリソース配信機能と差別化された QoS 保証機能を提供すると同時に、オフライン サービスに対して最小リソース要件保証機能と極めて高い弾力性を提供します。

スケジューリング側では、オフライン スケジューリングは Coscheduling テクノロジーを使用します。セカンダリ スケジューリングは、ホットスポットの削除や断片化などのリソース ホットスポットの問題を処理します。負荷スケジューリングは CPU の水位に基づいて行われ、リソースの使用率が向上します。リソース ビューは、リソースの検査とシミュレーションのスケジュールに使用されます。

単一マシン側では、BVT (Borrowed Virtual Time) などの抑制戦略を通じてパフォーマンス制御とリソース制限が実行され、メモリの追い出し操作が実行されます。 QoS 保証の観点では、コア バインディングやハイパースレッディング干渉抑制などのテクノロジを使用して、差別化されたリソース保証を実現します。利用可能なバッチリソース情報が計算され、報告されます。カーネルから収集される指標には、PSI (圧力失速情報) やスケジュール情報が含まれます。干渉検出は、CPI（Cycles Per Instruction）、PSI（Pressure Stall Information）、ビジネス指標などに基づいて行われ、干渉状況を検出して処理します。

2.1 オフライン スケジューリング リソース ビュー

オフライン サービスのリソース スケジューリングの基本原則は、オンライン サービスの負荷認識機能に基づいた動的な過剰販売です。具体的な実装は、ノードのアイドル リソースをオフライン サービスに再割り当てすることです。

オフラインで使用可能なリソースは、ノード上のアイドル リソース (未割り当てのリソースと割り当て済みの未使用のリソースの合計を含む) と、安全のために予約されたリソースを差し引いた残りのリソースです。オフラインで利用可能なリソースの計算式は次のとおりです。

オフラインで利用可能なリソース = マシンリソース – 予約済みリソース – オンラインサービスの実際の使用量

計算されたオフラインで利用可能なリソースは、図に示すように時間に応じて分配されます (図の緑色の部分)。

実際の実装プロセスでは、オフラインで利用可能なリソースがオンライン サービスのリソース使用量によって大きく変動し、オフライン リソースの品質とオフライン サービスの動作の安定性に影響することを防ぐために、上記の式の実際のオンライン サービス使用状況データをリソース プロファイリングでさらに処理してデータ ノイズを除去し、最終的に比較的安定したオフラインで利用可能なリソース量 (図の緑色の部分) を計算できます (図を参照)。

2.2 ハイブリッド QoS 保証戦略

2.2.1 QoS分類

ビジネスのサービス品質 (QoS) 要件に応じて、Xiaohongshu のビジネス タイプは、次の表に示すように、3 つの QoS レベルに簡単に分類できます。

2.2.2 QoS保証

サービスの QoS 要件に応じて、ノード側は Pod レベルの階層型リソース保証を採用して、異なるリソース次元に対して差別化された QoS 保証戦略を実装できます。具体的な保証パラメータは次のとおりです。

CPU コア オーケストレーション レベルでは、さまざまな需要シナリオに合わせて 3 種類のコア バインディングを設定し、洗練された CPU コア オーケストレーション戦略のセットを設計しました。割り当て図は次のとおりです。

コアバインディングには 3 つのタイプがあります。

エクスクルーシブ

機能: バインド cpuset スケジューリング ドメイン、CCD 認識、NUMA バインディング、排他

シナリオ: レイテンシに非常に敏感な大規模な検索およびプロモーションサービスに適用可能

シェア(推奨)

機能: cpuset スケジューリング ドメインのバインド、CCD 認識、NUMA (オプション) バインディング、Share/Exlusive 排他、None タイプのビジネスと共有可能

シナリオ: ある程度の干渉を許容するJavaマイクロサービス、アプリケーションゲートウェイ、Webサービスなどに適用可能

再生

特徴: cpuset バインディングなし、非排他的コアバインディングサービスによるコアの共有が可能、コア割り当てはカーネルによって完全に制御、CPU リソースが需要を 100% 満たせない可能性がある

シナリオ: バッチオフラインサービスおよび遅延を必要としない一部のコンピューティングサービスに適用可能

2.2.3 オフラインでの削除

マシン全体のメモリ使用量が高く、OOM がトリガーされるリスクがある場合や、オフライン サービスの CPU 要件を長時間満たすことができないなどの極端なシナリオでは、オフライン エビクション戦略を採用できます。スタンドアロン側では、オフライン サービスが内部的に定義する優先度設定、リソース使用量、実行時間などの複数の次元に基づいてオフライン サービスをソートした後、順番にオフライン サービスを排除することをサポートし、リソース利用効果を最大限に高めます。

2.3 オフラインビジネスシナリオの例

数億人のユーザーを抱えるコンテンツ コミュニティとして、Xiaohongshu には、多数のビデオおよび画像トランスコーディング シナリオ、検索とプッシュ、CV/NLP アルゴリズム推論トレーニング、アルゴリズム機能の生成、データ ウェアハウス クエリなど、豊富で多様なオフライン ビジネス シナリオがあります。具体的には、以下の業種が含まれます。

• ほぼオフラインのトランスコーディングシナリオ（コンテナ化）
• Flink ストリーミング/バッチ コンピューティング (コンテナ化)
• Spark バッチ コンピューティング (コンテナ化されていない、YARN 上)
• CV/NLP アルゴリズム リトレースメント シナリオ (コンテナ化)
• トレーニングシナリオ（コンテナ化）

K8s に基づく統合オフライン スケジューリング機能により、これらのオフライン ビジネスはオンライン サービスと混合され、統合リソース プールに展開されます。オンライン サービスに差別化されたリソース品質保証を提供できるだけでなく、オフライン サービスに低コストの大規模なコンピューティング能力を提供して、リソース効率を向上させることもできます。

2.3.1 K8s と YARN のハイブリッド デプロイメント ソリューション

Xiaohongshu の商業化、コミュニティ検索などのビジネスには、アルゴリズムベースの Spark タスクが多数あります。オフライン クラスター リソースが不足しているため、タスクをタイムリーに処理できず、タスクが蓄積されます。同時に、ビジネスのオフピーク時間帯には、オンライン クラスターのリソース使用率が低くなります。さらに、Spark タスク リソース スケジューリングのかなりの部分は、依然として YARN スケジューラ上で実行されます。このような背景から、ビジネス移行のコストを迅速に削減するために、ソリューションの選択に関して Kooridinator コミュニティと協力し、YARN on K8s ハイブリッド展開ソリューションを採用して、Spark オフライン シナリオのハイブリッド展開を迅速に実装することを選択しました。具体的な解決策は図に示されています。

オンラインおよびオフラインのワークロードは、コンテナ化された環境内の K8s リンクを通じてオンライン クラスターに公開されます。 Spark ジョブは、YARN ResourceManager を通じて特定のノードにスケジュールされ、ノード上の NodeManager コンポーネントによって開始されます。 NodeManager は、効果的なリソース管理を実現するためのコンテナとしてオンライン K8s クラスターにデプロイされます。さらに、次のコンポーネントが関係します。

1. スケジュール面

Koord-Yarn-Operator: K8s と YARN スケジューラ間のリソース ビューの双方向同期をサポートし、リソース情報の共有と一貫性を保証します。

2. ノード側

Copilot: NodeManager の運用エージェントとして、YARN タスクの管理および制御インターフェースを提供します。

Tusker-agent/koordlet: オフライン リソースの報告、ノード上のオフライン Pod/タスクの管理、競合解決、削除、抑制戦略などの機能の処理を担当します。

マルチスケジューラリソース同期

K8s スケジューラと YARN スケジューラはもともと独立しており、お互いを認識しません。割り当てノードで利用可能なオフライン リソース全体を共有するには、2 つのスケジューラ間で双方向のリソース同期と調整を実行し、2 つの同期リンクを実装する Koord-Yarn-Operator コンポーネントが必要です。

1. K8s -> YARN スケジューラ リソース同期リンク。YARN の観点からオフライン リソースの合計量を同期する役割を担います。 YARN オフライン リソースの合計量は次のように計算されます。

YARN オフライン リソースの合計 = オフラインで使用可能なリソースの合計 - K8s ノードに割り当てられたリソース

2. YARN -> K8s スケジューラ リソース同期リンク。割り当てられた YARN リソースの同期を担当し、K8s オフライン リソースの合計量は次のように計算されます。

K8s オフライン リソースの合計 = オフラインで使用可能なリソースの合計 - YARN ノードに割り当てられたリソース

2 つのスケジューラは、それぞれのノードのオフライン リソース ビューに基づいてスケジュールを決定し、オフライン ポッドと YARN タスクを適切なノードにスケジュールします。同期プロセスはロックに適していないため、リソースの過剰割り当ての問題が発生する可能性があります。

具体的な解決策は、スタンドアロン側に仲裁ロジックを追加することです。ノードに割り当てられたオフライン サービス リソースの量が、ノードの利用可能なオフライン リソースを長時間超過し、オフライン使用率が高いままになると、オフライン サービスがリソースを取得できず、リソースが枯渇するリスクがあります。スタンドアロン側は、オフライン サービスの優先度、リソース使用量、実行時間などの要素に基づいてスコアを計算し、順番に排除します。

3. 着陸特典

現在、Xiaohongshu のコロケーション機能は数十万台のマシン、数百万のコンピューティング コアをカバーし、数万のオンラインおよびオフライン シナリオ サービスのリソース スケジューリングをサポートしています。大規模コンテナのコロケーションを継続的に推進することで、小紅書はリソースコスト効率の面で次の 2 つの側面を含む大きなメリットを実現しました。

CPU使用率

• オンラインサービスの品質を確保しながら、オンラインコロケーションクラスターの1日あたりの平均CPU使用率は45％以上に増加し、一部のクラスターの1日あたりの平均CPU使用率は安定して55％まで増加しました。
• オフライン コロケーションなどの技術的手段により、オンライン クラスターの CPU 使用率は 8% ～ 15% 増加し、一部のストレージ クラスターの使用率は 20% 以上増加しました。

リソースコスト

• オフラインビジネスの安定性を確保しながら、Xiaohongshu のさまざまなオフライン シナリオに数百万コア時間の低コストのコンピューティング パワーを提供します。
• コロケーション クラスターの CPU 割り当て率は 125% 以上に増加し、専用リソース プールと比較してリソースの断片化率が大幅に減少します。

4. まとめと展望

小紅書は過去1年ほどコロケーション技術の探求を通じて、リソース効率の向上に関する豊富な経験を蓄積し、良好な成果を達成してきました。当社の事業規模が徐々に拡大し、シナリオがより複雑になるにつれて、多くの新たな技術的課題に直面することになります。今後の目標は、ハイブリッド クラウド アーキテクチャ向けの統合リソース スケジューリング機能を構築することです。具体的な作業は次の 3 つの側面に重点を置きます。

1. ハイブリッド ワークロード スケジューリング機能のサポート: すべての Xiaohongshu ビジネス シナリオのリソース スケジューリング機能とパフォーマンス要件を満たすために、タスクベースの作業 (ビッグ データ、AI などを含む) の負荷スケジューリング機能の開発に重点を置いています。
2. リソース効率がさらに向上します。ハイブリッド クラウド アーキテクチャでは、より大規模なリソース プーリングを推進し、クォータベースのリソース配信を推進します。弾力性、コロケーション、オーバーセリングなどのより高度なテクノロジーを採用することで、クラスター リソースの使用率をさらに向上させ、リソース コストを大幅に削減できます。
3. より高いサービス品質保証機能: より厳しい CPU 使用率目標の下で、QoS を考慮したスケジューリング機能と干渉検出機能を構築し、セキュア コンテナなどの技術的手段を利用して、深海混合展開で発生する可能性のあるさまざまな干渉問題を解決します。

5. 著者について

Sandor (Song Zehui): 基礎技術部/クラウドネイティブプラットフォーム

Xiaohongshu のリソース スケジューリング担当者は、コンテナ リソース スケジューリング、コロケーション展開、リソース分離などの豊富な実務経験を持ち、現在は主に Xiaohongshu の大規模コンテナ リソース スケジューリングとオフライン コロケーションの技術研究開発を担当しています。

黄来（蘇増善）：基礎技術部/クラウドネイティブプラットフォーム

Xiaohongshu Resource Scheduling のシニア R&D エンジニア。主にリソース スケジューリングとワークロード オーケストレーションに関する R&D 作業を担当しています。

慧在（イェ・ヤンジエ）：基礎技術部/クラウドネイティブプラットフォーム

Xiaohongshu リソース スケジューリング R&D エンジニア。主にオフライン コロケーション方向の R&D 作業を担当。

Xiaohongshu のオーディオおよびビデオ アーキテクチャ チーム、データ エンジン チーム、取引アルゴリズム チームのすべてのビジネス 同僚に特に感謝します。