クラスタの平均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 レベルに簡単に分類できます。

QoS レベル	例示する	ビジネスシナリオ
遅延に敏感	最高のQoS保証レベル、遅延に極めて敏感なサービス	検索とプロモーションの遅延が極めて重要なシナリオ
ミッド	デフォルトの QoS レベルは、ある程度の干渉遅延を許容します。	ゲートウェイ、Java マイクロサービス
バッチ	最低のQoS保証レベル、遅延に敏感ではない、リソースはいつでも奪われる可能性がある	トランスコーディング、Spark、Flink、トレーニングなどのコンピューティングシナリオ

2.2.2 QoS保証

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

リソース	特性	遅延に敏感	ミッド	バッチ
CPU	CPUバースト	有効にする	有効にする	無効にする
	スケジュールの優先順位	最高	デフォルト	低い
	バインディングコア	共有（デフォルト）	共有（デフォルト）	再生された
	ヌマ	強力な保証	優先（デフォルト）	なし
	L3 キャッシュ	100%	100% (デフォルト)	30% （デフォルト）
	メモリ帯域幅	100%	100% (デフォルト)	30% （デフォルト）
メモリ	OOM優先度	最低	デフォルト	最高
メモリ	メモリリサイクルウォーターライン	調整する	デフォルト	より低い

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 つの側面に重点を置きます。

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