コーディネーターはクラウドネイティブアプリケーションのパフォーマンス向上に役立ちます: Xiaohonshu ハイブリッドテクノロジの実践

著者: Song Zehui (Xiaohongshu)、Zhang Zuowei (Alibaba Cloud)

編集者注:

Koordinator は、Alibaba 内でのコンテナのスケジューリングとコロケーションにおける長年の実践経験に基づいて開発されたオープンソースプロジェクトであり、本番環境に対応し、大規模シナリオを想定した業界初のオープンソースコロケーションシステムです。アプリケーションのサービス品質の向上とリソース使用効率の最適化に取り組んでいます。2022 年 4 月に正式にオープンソース化されて以来、業界の多くの優れたエンジニアからの貢献、参加、議論を集めてきました。

Xiaohongshu はコーディネーターコミュニティの積極的なメンバーであり、プロジェクトの初期の頃から一連の重要な機能の進化に深く関わってきました。この記事は、2023 Yunqi Conference でコーディネーターについて共有された実際の記録に基づいており、コーディネーターコミュニティメンバーの Song Zehui (Xiaohongshu) と Zhang Zuowei (Alibaba Cloud) が、Xiaohongshu のハイブリッドテクノロジの実践とコーディネーターの最近の計画を紹介しました。

背景の紹介

Xiaohonshu のビジネスの急速な発展に伴い、さまざまなオンラインおよびオフラインビジネスのためのコンピューティングリソースの需要も急速に成長しています。同時に、一部のオンラインクラスターの 1 日の平均使用率は低いレベルに留まっており、この現象の主な理由は次のとおりです。

オンラインサービスリソースの使用量は、エンドユーザーの使用習慣に従って安定した傾向を示し、夜間の CPU 使用率は非常に低くなり、その結果、クラスターの平均 CPU 使用率が低くなります。
ビジネスは多数の排他的なリソースプールを維持しており、リソースプールの断片化により多数のリソースフラグメントが生成され、CPU 使用率が低下します。
安定性の理由から、企業はリソースを過剰に蓄え、CPU 使用率をさらに低下させます。

上記の背景に基づき、企業のリソース使用コストの削減とクラスターの CPU 使用率の向上を支援するために、Xiaohongshu コンテナーチームは 2022 年からコロケーションテクノロジーの大規模実装を通じてクラスターのリソース効率を大幅に向上させ、ビジネスリソースのコストを削減します。。

技術の進化

Xiaohonshu コロケーションテクノロジーの進化は、次の 4 つの段階に分かれています。

フェーズ 1: アイドル状態のリソースの再利用

初期の頃は、クラスタのリソース管理が広範囲に及んでいたため、クラスタ内に業務専用のリソースプールが多数存在し、リソースの断片化などにより、割り当て率が低い非効率なノードが多数存在していました。さまざまなクラスターに分散されているため、大量の資源の無駄が発生します。一方、K8s によってリリースされたトランスコーディングに基づく一部のニアライン/オフラインシナリオでは、1 日を通して大量のコンピューティングリソースが必要になります。上記の背景に基づいて、コンテナプラットフォームは技術的手段を使用してクラスター内のアイドル状態のリソースを収集し、それらをトランスコーディングビジネスシナリオに割り当てます。

virtual-kubelet を使用してメタデータクラスターと物理クラスターを接続し、アイドル状態のリソースを収集し、メタデータクラスターのトランスコーディングシナリオでそれらをニアライン/オフラインコンピューティングサービスに割り当てます。戦略的には、セカンダリスケジューラーはクラスター内のすべてのノードを検査し、非効率なノードとしてマークする責任を負い、Virtual-kubelet は物理クラスター内の非効率なノードの利用可能なリソースをクラスターのアイドルリソースとして取得し、それらをオフラインのトランスコーディングに割り当てます。セカンダリスケジューラは、オンラインサービスがリソース要件を満たしたら、すぐにオフラインポッドを削除してリソースを返すことを保証する必要があります。

ステージ 2: マシン全体をタイムシェアリング方式で移動して再利用する

検索プロモーションなどのサービス専用のリソースプールでは、CPU 使用率の潮汐現象が顕著で、夜間は使用率が非常に低くなり、リソースプール内の 1 つのノードに大規模なビジネス Pod が 1 つしかデプロイされないことがよくあります。上記の背景にあるように、プラットフォームはエラスティック機能 (HPA) を使用します。早朝のビジネスの少ない時間帯には、オンラインビジネスが比例して縮小され、マシン全体が空になり、その間にトランスコーディングやトレーニングなどのオフラインポッドが実行されます。この期間は、利用において「谷を埋める」効果があります。

具体的な実装では、すべてのオンラインサービスを指定時間内に確実に開始できるようにする必要があるため、戦略としてオフラインの早期撤退を実装し、スケジューラのプリエンプションメカニズムを使用してオンラインサービスが確実に開始できるようにしました。繁忙期前に全額引き上げてください。

ステージ 3: 通常の混合部門

リソースの断片化率を減らし、ビジネスリソースの保持コストを削減するために、プラットフォームは引き続き大規模なビジネスプーリングを推進し、ビジネスを専用プールからプラットフォームがホストするパブリック混合プールに移行します。およびその他の技術的手段、CPU 割り当て効率は効果的に改善されましたが、結合されたリソースプールの夜間使用率が低いという問題はまだ解決できません。一方、プール統合後の複雑なコロケーションシナリオでは、タイムシェアリングコロケーションとマシン全体のオフライン展開のスケジューリング戦略を継続して実装することは困難であり、プラットフォームは平均使用率を達成する必要があります。よりきめ細かいリソース管理とスケジューリング機能の構築。改善の目標には、具体的には次のものが含まれます。

スケジューリング側:

- オフラインに二次的に割り当てることができる利用可能なリソースの量は、動的な過剰販売技術によって取得され、オフラインリソースビューは、K8s スケジューラが認識できるように抽象化されます。スケジューラは、対応するノードへのオフラインロードをスケジュールして、オフラインで「リソースを満たす」を実現します。ノード使用率の「谷」。
- 負荷のスケジューリングを通じて、オンラインサービスが高負荷のマシンにスケジュールされるのを回避し、クラスター内のノードの負荷のバランスが取れるようにします。
- セカンダリスケジューリングを通じて、負荷ホットスポットマシン上の使用率の高いサービスが排除されるため、クラスターの負荷は動的にバランスの取れた状態になります。

単一マシン側:

- Qos (サービス品質) 保証戦略をサポートし、サービスの Qos レベルに基づいて差別化されたランタイムリソース保証機能を提供します。
- 干渉検出、オフラインエビクションなどの機能をサポートしており、オフライン干渉がオンラインの機密サービスに干渉する場合、できるだけ早くオフラインでエビクションされます。

上記の技術的手段により、サービスが混在している場合でもサービスの安定性を効果的に確保できるため、オンラインとオフラインのワークロードをノード上で定期的に実行でき、利用率の谷埋め効果を最大化できます。

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

Xiaohonshu コンテナリソーススケジューリングアーキテクチャの設計を次の図に示します。

Xiaohonshu のさまざまなビジネスシナリオは、さまざまなパブリッシングプラットフォームやタスクプラットフォームを通じて送信された後、上位層のロードオーケストレーション機能を通じてポッドの形式で統合スケジューリングシステムに配信されます。さまざまなスケジューリング要件に基づいて、統合スケジューリングシステムは、オンラインサービスのリソース配信機能、差別化された Qos 保証機能、およびオフラインサービスの最小リソース要件と究極の弾力性の保証機能の強力な保証を提供します。

スケジューリング側:

オフラインスケジューリング: 相互スケジューリング。
二次スケジューリング: ホットスポットの削除、デフラグ。
負荷スケジューリング: CPU の水位に基づく。
リソースビュー: シミュレーションのスケジュール。

単一マシン側:

抑制戦略: bvt 抑制、メモリ削除。
Qos保証：コアバインディング、ハイパースレッディング干渉抑制など。
バッチリソースレポート: バッチ利用可能なリソースの計算とレポート。
インジケーターのコレクション (カーネルから): psi、スケジュール情報など。
干渉検出: cpi、psi、およびビジネス指標に基づいて干渉を検出します。

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

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

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

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

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

実際の実装プロセスでは、オンラインサービスのリソース使用量の変動により利用可能なオフラインリソースが大きく変動し、オフラインリソースの品質やオフラインサービスの運用の安定性に影響を与えることを避けるために、上記のオンラインサービスの実際の使用量データが使用されます。次の図に示すように、式はリソースポートレートを通じてさらに処理されてデータノイズが除去され、最終的に比較的安定したオフラインで利用可能なリソースの量 (図の緑色の部分) が計算されます。

同一場所にある QoS 保証戦略

QoSの分類

サービス品質 (QoS: サービス品質) のビジネス要件に従って、次の表に示すように、Xiaohongshu のビジネスタイプを 3 つの QoS レベルに単純に分割します。

QOSレベル	説明する	ビジネスシーン
遅延に敏感な	最高の Qos 保証レベル、非常に遅延に敏感なサービス	検索とプロモーションの遅延が非常に敏感なシナリオ
半ば	デフォルトの Qos 保証レベル、ある程度の干渉遅延を許容	ゲートウェイ、Java マイクロサービス
バッチ	最低の Qos 保証レベル、遅延の影響を受けにくい、リソースがいつでも奪われる可能性がある	トランスコーディング、スパーク、フリンク、トレーニング、その他のコンピューティングシナリオ

QoS保証

サービスの QoS 要件に従って、ノード側は Pod 粒度で階層型リソース保証を実行し、リソース次元ごとに差別化された QoS 保証戦略を実装します。具体的な保証パラメーターは次のとおりです。

リソース	特性	遅延に敏感な	半ば	バッチ
CPU	CPUバースト	有効にする	有効にする	無効にする
スケジュールの優先順位	最高	デフォルト	低い
タイドコア	共有(デフォルト)	共有(デフォルト)	回収された
沼	強力な保証	優先する (デフォルト)	なし
L3キャッシュ	100%	100% (デフォルト)	30% (デフォルト)
メモリ帯域幅	100%	100% (デフォルト)	30% (デフォルト)
メモリ	OOM の優先順位	最低	デフォルト	最高
メモリ再利用のウォーターライン	現れる	デフォルト	断る

CPU コアのスケジューリングレベルでは、3 種類のコアバインディングが設定され、一連の洗練された CPU コアオーケストレーション戦略が設計されており、割り当て図は次のとおりです。

バインディングコアには次の 3 種類があります。

排他的（推奨されません）

- 機能: CPUset スケジューリングドメインのバインディング、CCD センシング、NUMA バインディング、排他的
- シナリオ: 非常に機密性の高い検索プロモーションと遅延に敏感な大規模なサービス

- 機能: CPUset スケジューリングドメインのバインディング、CCD 認識、NUMA (オプション) バインディング、共有/排他的排他、どのタイプのビジネスとも共有可能
- シナリオ: Java マイクロサービス、アプリケーションゲートウェイ、部分的な干渉を許容する Web サービス

回収された

- 特徴: cpuset バインディングなし、非排他的コアバインディングモードサービスとコアを共有する可能性がある、コア割り当ては完全にカーネルに任せられる、CPU リソースは 100% 満たされない
- シナリオ: バッチオフラインサービス、遅延を必要としない一部のコンピューティングサービス

オフラインでのエビクション

マシン全体のメモリ使用量が高い、OOM が発生するリスクがある、またはオフラインサービスの CPU が長時間満たされないなどの極端なシナリオでは、単一マシン側が優先順位に従って多次元統合をサポートします。オフラインサービス用に内部的に定義された構成、リソース使用量、実行時間など。スコアでソートした後、順番に排除されます。

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

何億人ものユーザーがいるコンテンツコミュニティとして、Xiaohongshu には、多数のビデオと画像のトランスコーディングシナリオ、検索とプッシュ、CV/NLP アルゴリズム推論トレーニング、アルゴリズム機能生成、データウェアハウスクエリ、オフラインなどのシナリオには、具体的には次のビジネスタイプが含まれます。

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

K8 に基づいた統合オフラインスケジューリング機能を提供することで、これらのオフラインサービスとオンラインサービスが統合コンピューティングリソースプールに混合して展開され、オンラインサービスに対して差別化されたリソース品質保証を提供し、オフラインサービスに対して大規模な低レベルのコンピューティング能力を提供します。効率。

K8s と YARN コロケーションソリューション

Xiaohonshu の社内商業化により、コミュニティ検索やその他のビジネスでアルゴリズムスパークタスクが大量に存在しますが、オフラインクラスターリソースの不足によりタスクが蓄積され、処理が間に合わなくなります。ビジネスの閑散ピーク時間帯ではオンラインクラスタの利用率が低い一方、Sparkタスクのリソーススケジューリングのかなりの部分が依然としてYarnスケジューラ上で実行されていることから、業務移行コストとソリューション選択を削減するため、 Kooridinator コミュニティと協力し、迅速な実装のために Yarn on K8s ハイブリッドソリューションを採用することを選択しました。Spark オフラインシナリオミキシングの具体的な計画を図に示します。

コンテナー化されたオンラインおよびオフラインのワークロードは、K8s リンクを通じてオンラインクラスターに公開され、Spark ジョブは Yarn ResourceManager を通じて特定のノードにスケジュールされ、ノード上の Nodemanager コンポーネントによってプルアップされます。Nodemanager は、コンテナーを介してオンラインの K8s クラスターにデプロイされ、さらに次のコンポーネントも含まれます。

スケジューリング側

- koord-yarn-operator: K8 と糸スケジューラーのリソースビューの双方向同期をサポートします。

ノード側

- copilot: NodeManager 操作エージェント。Yarn タスクの管理および制御インターフェイスを提供します。
- Neptune エージェント/koordlet: オフラインリソースレポート、ノードオフラインポッド/タスク管理、競合解決、エビクション、抑制戦略。

K8s と YARN のハイブリッド展開をサポートするコア機能はコミュニティで開発されており、11 月下旬に Koordinator バージョン 1.4 でリリースされる予定です。

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

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

K8s->YARN スケジューラリソース同期リンクは、Yarn の観点からオフラインリソースの総量を同期する役割を果たします。YARN オフラインリソースの総量は次のように計算されます。

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

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

K8s オフラインリソースの合計量 = オフラインで利用可能な合計量 - YARN 側ノードが割り当てられています

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

具体的な解決策としては、シングルマシン側に調停ロジックを追加することで、ノードに割り当てられたオフラインサービスリソースの量が、ノードの利用可能なオフラインリソースを超え、オフライン使用率が高い状態が続くと、オフラインサービスがリソースを取得できず餓死する可能性があるため、オフラインサービスは優先度、リソース使用量、実行時間などの要素に基づいて総合的に計算され、順番に排除されます。

Alibaba Cloud EMR 製品サポート

同時に、Alibaba Cloud EMRチームが製品レベルでコロケーション機能の開発サポートを提供し、EMR独自のログ、監視、運用保守ロジックとの互換性をベースに、K8sクラスタの機能をサポートします。 NodeManager ポッドを弾性的に拡張および縮小します。

実施収入

これまでのところ、Xiaohongshu のコロケーション機能は数十万のマシン、数百万のコアのコンピューティング能力をカバーし、数万のオンラインおよびオフラインのシナリオサービスのリソーススケジューリングをサポートしています。大規模なコンテナハイブリッド展開の継続的な推進により、Xiaohongshu は、次の 2 つの側面を含む、リソースのコスト効率とその他の側面で大幅な向上を達成しました。

CPU使用率

- オンラインサービスの品質を確保するという前提の下、オンラインコロケーションクラスターの 1 日あたりの平均 CPU 使用率は 45% 以上に増加し、一部のクラスターの 1 日あたりの平均 CPU 使用率は 55% まで着実に増加する可能性があります。
- オフラインコロケーションなどの技術的手段により、オンラインクラスターの CPU 使用率を 8% ～ 15%増加させることができ、一部のストレージクラスターの CPU 使用率を 20% 以上増加させることができます。

リソースコスト

- オフラインビジネスの安定性を確保することを前提として、 Xiaohongshu のさまざまなオフラインシナリオに数百万コア時間の低コストのコンピューティング能力を提供します。
- コロケーションクラスターのCPU割り当て率は125%以上に向上し、排他的リソースプールと比較してリソースの断片化率が大幅に低下しました。

コミュニティの共同構築プロセス

Xiaohongshu は、Koordinator コミュニティに参加した初期の企業の 1 つです。2022 年 4 月に、Koordinator は正式にオープンソースになりました。同年 6 月に、Xiaohongshu は社内でオフラインコロケーションプロジェクトを立ち上げ、Koordinator ソリューションの設計とコードに参加し始めました提出。2022 年 8 月、Xiaohongshu とコミュニティは共同でランタイムプロキシコンポーネントを構築し、内部シナリオに実装しました。2023 年 4 月、Xiaohongshu はコミュニティで YARN と K8s の共同展開プロジェクトを主導し、2023 年 8 月にこの計画は Xiaohongshu 内で大規模に実装されました。

これまでのところ、Koorindiator の支援により、Xiaohongshu のコロケーションは会社の数万のノードをカバーし、数十万のコアオフラインリソースを提供し、全体的なコロケーションクラスターの使用率は 45% 以上に増加しました。良好な着地効果を実現しました。

概要と展望

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

混合ワークロードスケジューリング機能のサポート:小紅樹のすべてのビジネスシナリオのリソーススケジューリング機能とパフォーマンス要件を満たす、ビッグデータと AI を含むタスクベースのワークロードスケジューリング機能の構築。
リソース効率がさらに向上:ハイブリッドクラウドアーキテクチャでは、大規模なリソースプーリングを促進し、クォータベースのリソース配信を促進し、より抜本的な弾力性、コロケーション、過剰販売、およびその他の技術的手段を通じてクラスターリソースの使用率をさらに向上させます。コストの面で。
より高いサービス品質保証機能:より積極的な CPU 使用率目標のコンテキストで、Qos を意識したスケジューリング機能、干渉検出機能を構築し、セキュリティコンテナなどの技術的手段に依存することで、深海で遭遇する可能性のあるさまざまな種類の混乱を回避します。混合展開も解決可能、外部干渉問題も解決可能。

コーディネーターコミュニティの最近の計画

今後のいくつかのバージョンでは、コーディネーターは次の側面に焦点を当てます。

スケジューラーのパフォーマンスの最適化:同等のクラスのスケジューリングをサポートし、ポッドを同じリクエストにマージすることでフィルター、スコア、その他のスケジューリングプロセスの繰り返し計算を回避します。
ネットワーク QoS:ネットワークはコンテナサービスの品質を評価し、優先度の高い帯域幅を確保し、最小帯域幅要件を確保するように要求/制限モデルを設計します。
ビッグデータロード: Gang スケジューリングのアトミックプリエンプションとグループごとの Pod の全体的なプリエンプション、Hadoop YARN タスクの QoS ポリシー適応をサポートします。
リソース干渉検出:基礎となる指標に基づいて、コンテナリソースの競合を感知し、異常なポッドを特定し、干渉を排除し、スケジューリングリンクをフィードバックします。

DingTalk を使用してグループ番号 33383887 を検索し、Koordinator コミュニティ DingTalk グループに参加できます。

コーディネーターの詳しい紹介と使い方はこちら！