Didi の弾力性のあるクラウドハイブリッド展開の実装に関する 10,000 語の説明

コロケーションとは、関連する特性に基づいて異なるビジネスサービスを同じ物理マシンまたは仮想マシンに展開し、主要なビジネスサービスの品質を確保しながらクラスターリソース全体の利用率を向上させ、総コストを削減することを意味します。コロケーションの種類によって、オンラインサービスのコロケーションとオフラインサービスのコロケーションに分けられます。オンラインコロケーションは、パブリッククラスター内のオンラインサービス間のコロケーションと、分離されたクラスター内のオンラインサービスとストレージサービス間のコロケーションに分けられます。オフラインコロケーションには、主にオンラインサービスとオフラインサービスのコロケーションが含まれます。

コロケーションは業界で一般的なコスト削減方法ですが、多くの技術的な課題を伴います。要約すると、次のようになります。

サービスを合理的に分類し、さまざまなレベルのサービス QoS を定義する方法
クラスターがより合理的なスケジュールとパッケージングを実行し、リソースの競合の可能性を減らすように導くために、洗練されたビジネスポートレートを実施する方法
高品質なサービスのためのサービス品質を確保するために、CPU、メモリ、IO、LLCキャッシュ、ネットワークなどのリソースを含む単一のマシンに対してカーネルレベルのリソース分離戦略を実装する方法
単一マシンのパフォーマンス干渉を検出し、単一マシンの排除とスケジュールの最適化をガイドする方法

Elastic Cloud Colocation の詳細な紹介

全体的なアーキテクチャ

Elastic Cloud ハイブリッドランディングプロセス

フェーズ 1: パブリッククラスターのオンラインコロケーション

時は2017年の初めに遡り、クラウドコンピューティング、コンテナ、Borg、Kubernetes、Mesosなど、さまざまな新しいテクノロジーや製品が急増し、注目を集めていました。 Didi は業界のトレンドに従い、クラウドコンピューティング軍に加わり、社内のビジネスのクラウド移行を推進してコストの削減と効率の向上に貢献しています。ビジネスをクラウドに移行したいので、まず「クラウド」とは何か、Didi の中に「クラウド」があるかどうかという問いに答えなければなりません。当時、すべてのビジネスは独自の物理マシンリソース上で実行されていました。 Didiにとって「クラウド」はその名前と同じくらい幻想的なものであり、同社の技術的基盤である基本プラットフォーム部門がDidiの「クラウドベース」の構築の責任を負った。

クラウドの場合、最も基本的な運搬エンティティはコンテナです。当時、Docker、コンテナ、cgroupなどのコンテナ技術は比較的成熟しており、大手企業で使用されていました。しかし、Kubernetes や Mesos など、これらの大規模コンテナクラスターのスケジューリングおよびオーケストレーション戦略には多くのルートがありました。 Didi はまた、2 つの技術ルートを同時に進化させることを選択しました。時間が経つにつれて、Kubernetes 陣営に加わる企業はますます増えました。 Kubernetes は、コンテナのスケジューリングとオーケストレーションの事実上の標準になりました。 Didi はついに Kubernetes を採用することを選択しました。

ライドシェア、オンライン配車、エンジン、地図、ミドルオフィス、都市交通サービス、国際化などのビジネスがエラスティッククラウドに接続されるにつれて、エラスティッククラウドコロケーションの最初のプロトタイプ、つまりオンラインビジネスコロケーションが形成されます。エラスティッククラウドに接続するビジネスが増えるにつれて、エラスティッククラウドの展開密度はますます高くなり、スケジュール要件はますます多様化しています。これにより、Elastic Cloud 全体に大きな安定性の課題が生じます。以下では、コンテナランタイム環境とクラスタースケジューリングの 2 つの側面から紹介します。

Elastic Cloud を使用すると、複数の業務のコンテナが 1 台の物理マシンに同時にデプロイされます。誰もが「混合」環境にいます。リソース使用率を向上させるために、オーバーセリングなどのテクノロジーを通じてコンテナの展開密度が高められています。これは、同じ物理マシンに展開されるコンテナの数が増えることを意味し、リソースの競合がますます深刻化し、業務の遅延が増加し、不具合が頻繁に発生することになります。したがって、私たちが直面する最初の重要な問題は、リソース競合の問題を解決することです。客観的に言えば、総リソースが固定されている場合、コンテナの展開密度を高めると、必然的にリソースの競合が発生し、これは避けられません。したがって、解決すべき問題は、リソースの競合をなくすことではなく、リソースの競合を合理的に割り当て、主要サービスの動作品質を確保することです。これらの問題を解決する方法を見てみましょう。

弾力性のあるクラウド階層型セキュリティシステム

現在の Elastic Cloud Online パブリッククラスターの全体的なリソースは過剰販売されており、ビジネスの平均レベルをはるかに超えているため、完全な階層保証システムを確立することが、良好なコロケーションの前提条件となります。現在の階層型システムの中核となる考え方は、クラスターと単一マシンという 2 つの次元からリソースの確実性を提供し、優先度の異なるサービスに対して異なるレベルのリソース保証を提供することです。簡単な要約は次のとおりです。

サービスは、その重要性と機密性に応じて合理的に等級分けされ、それに応じたリソースの過剰販売ルールが策定される必要があります。
単一マシンレベルでのリソース (CPU、メモリ、ディスク IO、ネットワーク、キャッシュなど) の割り当てにより、高品質なサービスのニーズを確実に満たすことが優先されます。
クラスターレベルでは、クォータ管理と制御、および k8s 階層型スケジューリング機能など、さまざまなレベルのサービスに対してリソース保証が提供されます。

k8s スケジューリング機能のサポート

上の図は、k8s スケジューリングのフローチャートです。スケジューリングの中心的な作業は、新しく作成されたポッドを実行するために最も適したノードを選択することです。スケジューリングプロセス全体は、事前選択戦略 (述語) と優先順位戦略 (優先順位) の 2 つの段階に分かれています。プロセス中に、さまざまなアルゴリズム戦略が選択および最適化され、さまざまなカスタマイズされたスケジューリング戦略を追加できます。以下では、スケジューリングレイヤーが上記のコロケーションシナリオをどのようにサポートするかについて説明します。

1. 強化されたスケジュール事前選択戦略

リソース制限の強化
大規模コンテナの単一マシンのスケジュール制限
IO に敏感なコンテナスケジューリングの適応
実際の使用スケジュール制限
ホストリソース競合スケジュール制限
クラスタトポロジの断片化の強化
同じ sts での Tor 散乱戦略
同じ sts の下のノード分散戦略
コンピュータルームにおけるノードスパースネス戦略
指示されたスケジュール戦略

2. スケジュール最適化戦略

ActualBalancedResourceAllocation戦略: 実際のリソース使用量が可能な限りバランスのとれたホストにスケジュールする
BalancedResourceAllocation戦略: 可能な限りリソース使用のバランスが取れたホストにスケジュールする
ActualLeastResourceAllocation戦略: 実際のリソース使用量が可能な限り少ないホストにスケジュールする
LeastResourceAllocation戦略: 可能な限りリソース使用量が少ないホストにスケジュールする
InterPodAffinityPriority戦略: 指定されたトポロジキーを持つホストに可能な限りスケジュールする
NodeAffinityPriority戦略: 指定されたノードアフィニティを可能な限り満たすホストにスケジュールする
TaintTolerationPriority戦略: 可能な限りPodとコンテナにtaintsが設定されているホストにスケジュールする

最適な戦略の重み付け

3. スケジュールの変更

k8s クラスターのリソースは、クラスターの拡張と縮小、マシンの交換、ビジネストラフィックやデプロイメントモデルの変更など、動的に変化するため、コンテナー使用率が過去最高に達するなど、リソースの使用状況も変化します。また、その後のリソース要件はスケジューリング時に予測できないため、スケジューラは、スケジューリング時のクラスターリソースと動作状況に基づいてのみスケジューリングの決定を行うことができます。さらに、スケジューリング戦略自体も変更される可能性があり、完了したスケジューリング決定にスケジューリング戦略の変更をどのように適用するかも検討する必要がある問題です。そのため、当社は、クラスターの定期的な検査を通じて上記のシナリオにおける不合理なスケジューリング決定を検出し、スケジューラによる再スケジュールをトリガーして、クラスターの全体的なシステムリソース割り当てをより合理的にする再スケジュールサービスを提供しています。

再スケジュールサービスの全体的なワークフローを下図に示します。再スケジュールサービスは、ホスト/ビジネスクラスターの状態を定期的に検査し、さまざまな再スケジュール戦略に従って再スケジュールする必要があるホストを選択し、特定の戦略に従ってドリフトするコンテナーを選択し、スケジューラに対してコンテナー IP 変更ドリフト要求を開始します。

写真

弾力性のあるクラウド階層保証システム、スケジューリングおよび再スケジューリング機能のサポートにより、パブリッククラスター内のオンラインサービス間のコロケーションは比較的成熟しました。ピーク時のクラスターの CPU 使用率は、約 50% の安全なレベルに維持されます。具体的な CPU 使用率は次の図に示されています。

コンピュータルームAのCPU使用率チャート

フェーズ2: オフラインコロケーションのパブリッククラスタ

オンラインクラスターのピーク CPU 使用率が 50% に達しました。さらにコストを削減したい場合、オンラインサービスの展開密度を高めることで CPU 使用率を高めることはできますか?技術的な解決策、業界の慣行、収益への影響の観点から、このアイデアは実現可能ではありません。次の点が示されています。

オンライン展開密度がさらに高まると、リソースをめぐる競争が激化します。ピーク時には、CPU 使用率が 50%、60%、さらには 70% を超える場合があり、安定性に大きなリスクが生じます。皆さんご存知のとおり、現在使用している物理マシンはすべてハイパースレッディング (HT) が有効になっています。同じコア内の 2 つのハイパースレッド論理コアは、実際には基盤となるハードウェアリソースを共有するため、理論上は 50% が制限となります。さらに増加すると、リソースの競合によるさまざまな問題が増加し、ビジネスのサービス品質に大きな影響を与えることになります。
コスト削減のため、Didiの現在のオンラインサービスの展開密度と過剰販売は比較的高くなっています。業界のオンラインサービスの過剰販売率は基本的に比較的低いレベルに制御されており、これはオンラインサービス自体の CPU 使用率がそれほど高くないことを意味します。
展開密度をさらに高めても、CPU のピーク使用率が向上するだけです。 CPU が完全に使用されていない低ピーク時間が長く続くため、コスト削減のメリットは限られます。

上記の分析に基づくと、業界ではオンラインサービスとオフラインサービスを共存させることがより一般的な方法であり、これにより、オフラインタスクはオンラインのオフピーク期間中に CPU コンピューティング能力を最大限に活用でき、平均 CPU 使用率が向上し、全体的なコストが削減されます。次の図に示すように、網掛け部分の計算能力をどのように活用するかが、オフラインコロケーションで解決すべき中心的な課題になります。

写真

オフラインコロケーションは、実際には、複数の制約があるシナリオでグローバルな最適ソリューションを見つけることです。以下の目標を達成することを目指します。

オンラインクラスタの平均CPU使用率を上げる
オンラインサービス運用の品質がオフライン運用の影響を受けないようにする
オフライン操作の品質要件を考慮すると、オフラインタスクを無条件に抑制することはできない。

上記の目標を達成するには、オフラインコロケーションの中核となる以下の問題に対処する必要があります。

スタンドアロン容量:

コンテナQoS保証: 単一マシンのリソース分離を提供し、オンラインサービスの動作品質を保証します。

干渉検出機能: 干渉インジケーターの構築により、オフラインタスクがオンラインサービスに与える影響をリアルタイムで把握し、リソースの抑制や排除などの必要なアクションを実行できます。

コンテナプロファイリング機能: ホストの実際の使用率に基づいて、完全なコロケーションシナリオにスケジュールプロファイリング機能が組み込まれ、さまざまな時点でホストが持つさまざまなディメンションのコロケーションリソースをガイドします。
K8s ハイブリッドスケジューリング機能: 静的潮汐スケジューリングと動的スケジューリングを含む。潮汐スケジューリングは時間帯に基づいており、動的スケジューリングはコロケーションプロファイルに基づいています。コロケーションタスクは適格なホストにスケジュールされ、安定性を確保しながらホストの使用率が向上します。

スタンドアロンのQoSおよび干渉チェック機能

単一マシン QoS 保護の主な目的は、CPU、メモリ、ディスク IO、ネットワーク、キャッシュなどの共有リソースをカーネルレベルで分離し、オフラインタスクがオンラインタスクに与える影響を軽減することです。ただし、すべてのオフラインタスクは共有環境で一緒に実行されるため、リソースの競合は弱められるだけで、完全に回避することはできません。そのため、さまざまなリソースレベルでインジケータシステムを確立して干渉の発生を感知し、単一マシンおよびクラスタースケジューリングレベルで何らかの処理を実行する必要があります。次の図は、リソース分離ソリューション、競合指標の構築、リソースの動的調整戦略などに関して、単一マシンレベルで実行される内容を示しています。

写真

上図では主にランタイム部分に焦点を当てており、メカニズムと戦略に分かれています。このメカニズムはカーネルレベルで提供される一般的な機能であり、さまざまなシナリオでユーザーモードでこれらの機能を使用する戦略です。この設計は、メカニズムと戦略の分離の原則にも準拠しています。リソース分離および干渉インジケーターには、さまざまなリソースとカーネルサブシステムが関係しており、コンテンツは膨大です。 CPU 分離戦略に焦点を当てます。

一般に、CPU 分離戦略は 2 つあります。cpuset (多くの場合、大規模フレームコアバインディングと呼ばれます) と cpushare (CPU リソースをオフラインで共有し、洗練されたスケジュール設定によってオンラインを確保する) です。これら 2 つの分離戦略についての私の考えと、それらがどのような具体的なシナリオに適しているかについてお話ししたいと思います。

cpuset の利点は、この戦略により、CPU レベルで 2 つのエンティティ間の強力な分離を実現できることです (LLC キャッシュは引き続き共有されるため、他の手段で分離する必要があります)。これにより、オンラインサービスの動作品質をより適切に保証できます。しかし、欠点は、構成があまり柔軟ではなく、場合によってはオンラインサービスに適さないことです。したがって、この戦略は主にオフラインコロケーションシナリオや、Redis コロケーションなどのレイテンシに特に敏感な一部のシナリオで使用されます。現在、このソリューションはビッグデータのコロケーションと一部のオフラインタスクに使用しています。

cpushare の利点は、この戦略により、ユーザーモードエージェントがリソースを調整する必要なく、カーネル CPU スケジューリングレベルから優先度の高いサービスのリソースが保証されることです。カーネルのスケジューリングレベルでは、ミリ秒レベルの CPU プリエンプションを保証でき、オンラインサービスはすべての CPU を使用できます。これにより、上記で説明した一定期間内に生成される多数のスレッドの同時実行の問題も回避できます。 cpushare ソリューションは、リソースをより有効に活用し、CPU 使用率をさらに向上させることができます。ただし、欠点としては、カーネル開発が必要であり、ロジックが比較的複雑で、カーネルコアコードが関係し、安定性リスクが比較的高く、オンライン実装サイクル全体が比較的長いことが挙げられます。

K8s ハイブリッド展開スケジュール機能

静的潮汐調節

Elastic Cloud コロケーションは現在、オンラインサービスの全体的な潮汐現象に基づいて、潮汐期間を通じてコロケーションによって提供されるオフラインコンピューティング能力を制限しています。エラスティッククラウドコロケーションは、オフラインクラスターのピーク期間を設定し、エラスティック API を通じてビジネスにフィードバックを提供して、オフラインコンテナーが実行できるかどうかをビジネスに通知します。たとえば、hxy データセンターでのオフラインサービスのコロケーションを例にとると、コロケーションの期間は次のようになります。

オフピーク期間（2 つのオフラインコンテナを実行可能）: 00:00-07:00 10:00-15:00 23:00:00-24:00:00
ミッドピーク期間（オフラインコンテナ1個実行可能）: 15:00-17:00 20:00-23:00
ピーク時間帯（オフラインコンテナは0個まで実行可能）: 07:00-10:00 17:00-20:00

次の図は、異なる期間に共存できるオフラインコンテナーを示しています。

グリーンライン 2023-07-02 (日曜日) / ブルーライン 2023-07-03 (月曜日)

潮汐スケジュール戦略はシンプルですが、いくつか問題があります。

各ホストの使用率は期間ごとに異なるため、グローバル潮流戦略では、ホストの残りのリソースを十分に活用して、ビジネスにさらに多くのコンピューティング能力を提供することはできません。
一方、静的スケジューリングでは、利用可能なコロケーションスペースに基づいて実行可能なオフラインコンテナーの数を調整するのではなく、オフラインコンテナーの数を固定します。これにより、オフラインコンテナーの CPU 使用率が実際のコロケーションスペースを超え、安定性に一定のリスクが生じる可能性があります。

初期の頃は、Tidal スケジューリングは主にオフラインコロケーションシナリオで使用されていました。現在、オンラインシナリオは動的スケジューリングソリューションに切り替わっています。

動的スケジューリング

動的スケジューリングは静的スケジューリングと比較されます。各ホストのリソース使用率や変更に基づいて、各ホストでスケジュールできるオフラインリソースを動的に調整することを指します。既存の静的スケジューリングの制限と比較して、動的スケジューリングの利点は次のとおりです。

各ホストの残りのリソースを最大限に活用して、オフラインコロケーションの価値を最大限に高めることができます。
ホスト内のホットスポットなどの安定性リスクは、ソリューションレベルで回避できます。

動的スケジューリングの目標は次のとおりです。

オフラインスケジューリングは、オンラインクォータやスケジューリングの品質に影響を与えることなく、ホストリソースの使用率に基づいて実行されます。
オフラインの動的スケジューリングにより、コロケーションホストの使用率が安定した範囲に維持され、リソースの使用率が向上します。

動的スケジューリングは、以下に説明するコンテナプロファイルに依存します。このプロファイルでは、任意の期間に物理マシン上に共存できるコンピューティング能力のスペースを予測できます。実装の観点からは、オフライン水平スケーリングとオフライン垂直スケーリングの 2 つの方法があります。

水平スケーリング: ホストのオンライン使用率とプロファイルデータに基づいて、オフラインポッドの動的なエラスティックスケーリングを通じて定期的にスケジューリングが実行されます (ホスト上のオフラインコンテナーの数をスケジュールします)。
垂直スケーリング: 各ホストにオフラインポッドがデプロイされます。ホストのオンライン使用率とプロファイルデータに基づいて、オフラインポッドの「仕様」が定期的に調整され、ホストの残りのリソースを最大限に活用します。

写真

実装の観点から、これら 2 つを比較します。

垂直スケーリングに対する水平スケーリングの主な利点は、オフライン仕様と既存のユーザーエクスペリエンスの確実性を維持できることです。ただし、水平スケーリングの主な問題は、現在のオフラインポッドのライフサイクルがオフラインタスクのライフサイクルと一致していないため、頻繁なスケーリングによってキル率が高くなり、ビジネスの運用効率に影響を及ぼす可能性があることです。
リソース利用の観点から見ると、垂直スケーリングはコンテナ仕様によって制限されず、フラグメントの生成を回避するため、より効率的です。同時に、この方法では、ワークロードとオフラインコンテナーを調整する必要がないため、キル率も発生しません。

現在の水平スケーリングソリューションは主にオフラインタスクコロケーションシナリオで使用され、垂直スケーリングソリューションは主にビッグデータコロケーションシナリオで使用されます。もちろん、オフラインサービスのさまざまなニーズに応じて調整することもできます。

コンテナプロファイリング機能

動的スケジューリングソリューションでは、オフラインで使用可能なリソース = コロケーションのターゲット使用リソース量 - ホストオンラインサービスによって使用されるリソースです。コロケーションの動的スケジューリング中、スケジューラは各ノード上のオフラインで利用可能なリソースに基づいてオフラインコンテナをスケジュールします。ホストのオンラインリソースの使用率は絶えず変化するため、オフラインで利用可能なリソースも絶えず変化します。オフラインタスクの観点からは、オフラインタスクの実行中に、オフラインで利用可能なリソースがリソース要件を満たすことができることを確認する必要があります。したがって、ポートレートでは将来的にオフラインで利用可能なリソースを提供する必要があります。

予測アルゴリズムは、今後 1 時間のホストオンラインサービスの最大リソース使用率を予測するために使用されます。このようにして、目標コロケーション利用率を前提としてコロケーションできるリソースの量は、次の図に示すように得られます。

写真

予測アルゴリズムには、7 日間の前年比アルゴリズムと加重前年比アルゴリズムが含まれます。

7 日間の前年比アルゴリズムは、オンラインサービスの 7 日間の周期に基づいて、7 日前の前年比値を予測値として使用します。誤差が比較的大きいため、オンラインでは使用されなくなりました。

加重前年比アルゴリズムは、全体の利用率が増加または減少すると誤差が大きくなるため、7 日間前年比アルゴリズムに基づいて設計された改良アルゴリズムです。このアルゴリズムは、7日前、1日前、1時間前の履歴値を総合的に考慮し、予測の精度を大幅に向上させることができます。現在、すべてのオンラインコンピュータルームでは加重前年比アルゴリズムが使用されており、実際の誤差は 7 日間の前年比アルゴリズムと比較して大幅に減少しています。

オンラインコロケーションの現状

単一マシンの分離、干渉検出、コンテナのプロファイリング、動的スケジューリングなど、前述の機能は、オンラインコロケーションシナリオで広く使用されています。現在、ビッグデータコロケーションとオフラインタスクコロケーションは数年間安定して稼働しています。以下は、コロケーション後のリソース使用例です。黄色の線は、オフラインコロケーション後の CPU 使用率の増加を示しています。オフラインコロケーションは、CPU 使用率の谷を埋めるのに非常に効果的であることがわかります。

コロケーションクラスターの CPU 使用率グラフ

フェーズ 3: 分離されたクラスタのコロケーション

前のセクションでは、Elastic Cloud パブリッククラスターのオンプレミスとオフプレミスのデプロイメントについて説明しました。オンプレミス展開のこれら 2 つのシナリオにより、パブリッククラスターの CPU 使用率が大幅に向上し、コストが削減されます。ただし、パブリッククラスターリソースは、エラスティッククラウドの全体的なリソースプールの一部のみを占めます。分離されたクラスターも多数存在し、分離されたクラスターの利用率は一般的に非常に低いです。そのため、このエリアは共同配置と削減の焦点となっています。

まず、分離されたクラスターを紹介します。パブリッククラスターは、さまざまなビジネスが一緒に運営されるパブリックリソースプールです。ただし、ストレージ Redis、MQ、アクセスレイヤーサービスなどの一部のサービスは、レイテンシの影響を非常に受けやすいです。パブリッククラスター環境はサービス品質要件を満たすことができません。そのため、特定のサービスが単独で使用できるようにリソースプールを特別に分離することで、サービスのサービス品質を保証できます。ただし、これらのサービスは個別に展開されるため、リソースの使用率が非常に低く、リソースとコストが無駄になります。分離されたクラスターの典型的な CPU 使用率を以下に示します。

写真

分離されたクラスターの CPU 使用率は非常に低いレベルにあり、コロケーションの余地が十分にあることがわかります。これを見て、コロケーションスペースがたくさんあるのに、なぜもっと早くやらないのかと疑問に思う学生もいるかもしれません。ここでは、分離されたクラスタービジネスオペレーションの特徴から始める必要があります。一般的に、孤立したクラスタービジネスは非常に繊細であり、高い安定性が求められます。たとえば、Redis サービスはレイテンシに非常に敏感で、干渉に対する許容度はほぼゼロです。さらに、業界では一般的に Redis サービスにコロケーションを使用せず、運用の品質と安定性を確保するためにいくらかのコストを犠牲にしています。 Redis リソースは、分離されたクラスターリソースの大部分を占めます。私たちはこの分野でコロケーションを検証し、実装しようとしていますが、常に慎重な姿勢を保っています。

今年はコスト削減と効率化のさらなる深化の段階に入りました。また、これまでの技術蓄積と検証を、分離されたクラスターのコロケーションで実装し始めました。分離されたクラスターサービスの特性により、分離されたクラスターコロケーションを複数の段階に分割します。

オンラインサービスとストレージサービスの共存: パブリッククラスターの比較的優先度の低いオンラインサービスを、分離されたクラスターとストレージ物理マシンクラスターにスケジュールして、ピーク時の CPU 使用率がパブリッククラスターのレベルに達するようにします。
完全なコロケーション: すでにコロケーションされている分離されたクラスターにオフラインタスクをさらにスケジュールし、平均 CPU 使用率をさらに改善して、最終的に無差別な完全なコロケーションを実現します。

現在は前段階です。この段階の主な目標は、分離されたクラスターのピーク CPU 使用率を向上させることです。次の図に示すように、赤いボックス内のリソースは、コロケーションを通じてオンラインサービスによって利用されます。

写真

技術的な観点から見ると、分離されたクラスターのコロケーションには、以下で紹介する k8s スケジューリング、単一マシン保護、安定性保護ソリューションも含まれます。

k8s スケジューリングサポート

分離されたクラスターのコロケーションシナリオでは、k8s スケジューリングの主な目標は次のとおりです。

コロケーション内のオンラインサービスを分離されたクラスターにスケジュールし、使用率が設定されたコロケーションターゲットを超えないように、使用率に基づいてクラスター全体をスケジュールします。
コロケーションスケジューリングは、パッキングレートや元の分散戦略など、分離されたクラスターの元のサービスのスケジューリング容量と品質に影響を与えることはできません。

コアスケジューリング戦略

真の利用スケジュール
コロケーション側は、コロケーションターゲットの使用率とプロファイルに基づいて各ノード上の「常駐コロケーション」リソースを計算し、カスタムリソースmix-mid-cpuを書き込みます。
過去 7 日間の最大使用率の履歴に基づいて、ポッドが占有する可能性のあるリソースをポッドに注入します。
mix-mid-cpuなどのカスタムリソースによるスケジュール制限

写真

単一マシンのコンテナ数量制限問題の解決
Redis などの一部の分離されたクラスターでは、マシンあたりのコンテナ数に上限があります。これらの制限は、コロケーションコンテナーの追加によって破られる可能性があります。スケジューリング側では、さまざまな状況に応じてコロケーションサービスの単一マシンコンテナ数制限をバイパスしたり、コロケーションコンテナの予測数に基づいて現在の単一マシンコンテナ数制限を調整したりできます。
ルールエンジンポリシーの挿入のスケジュール
スケジューリングルールは普遍的であるため、通常の状況ではパブリッククラスター内のサービスを分離されたクラスターにスケジュールすることはできません。強制的なスケジューリングを実行しても、普遍的なボトルネックが多数発生します。これらのボトルネックは分離されたクラスターには適用されないため、何らかの適応が必要です。典型的なシナリオとしては、分離されたクラスターの汚れを許容し、これらのサービスのためにパブリッククラスターと分離されたクラスター間のチャネルを開くことなどが挙げられます。パブリッククラスターのいくつかのデフォルトのボトルネックをスキップします。物理マシンの実際の使用率プロファイルを占有しない。コロケーションに関するラベルの設定など

スケジュール変更

分離されたクラスターサービスは一般に優先度の高いサービスであるため、基本的なバックアップを提供するために、オンラインサービスとの共存後に再スケジュールする必要があります。再スケジュールするには、コロケーション内の分離されたクラスターに基本的なホットスポット処理機能を追加する必要があります。再スケジュールの要件は次のとおりです。

分離されたクラスターサービスのネイティブの再スケジュール戦略を維持して、コロケーションが分離されたクラスターに対して透過的であることを保証します。
コロケーションサービスの場合、CPU、メモリ、ディスクの使用率しきい値 (構成可能) に基づいて再スケジュールする必要があり、必要なホットスポットドリフトが実行されます。

単一機械サービス品質保証

スタンドアロンサービスの品質保証は、主にカーネルリソースの分離から実行されます。一般的に、単一マシンの分離は、基本的にコロケーションおよびオフサイトコロケーションのシステムにあります。現在の分離されたクラスターコロケーションはコロケーションオンラインサービスであるため、CPU はデフォルトで cpusare メカニズムを使用して、階層的な保証システムを通じてサービスの品質を確保します。ただし、Redis などの特に機密性の高いサービスについては、より保守的な CPU 大規模フレームソリューションも採用し、Redis インスタンスを過剰販売しないという全体的な原則を確保します。

同時に、コロケーションコンテナの使用率が急激に増加してマシン全体のCPU使用率がコロケーション目標を超え、分離クラスタの本来のサービスの動作品質に影響が出るのを防ぐため、単一マシンレベルでの単一マシン抑制機能も導入されています。コロケーションコンテナが原因で物理マシンの CPU 使用率が異常であることが検出された場合、全体的な制御性を確保するためにコロケーションコンテナが抑制されるか、または排除されます。

安定性の保証

Didi は初めてクラスターを分離し、機密性の高いビジネスを同じ場所に配置しようとしていたため、多くのソリューションが段階的に進化しており、安定性を保証するソリューションが特に重要でした。ここでは、安定性保証ソリューションであるハイブリッドコンテナ削除ロジックに焦点を当てます。全体的な立ち退きプロセスを次の図に示します。

写真

主に以下の部分が含まれます。

立ち退きのきっかけ
ビジネス指標: 分離されたクラスターのネイティブビジネスのビジネス指標が異常である場合、それは重要なシグナルです。もちろん、ビジネス指標の問題がコロケーションによって引き起こされるというわけではありません。ここでは、判断を支援するためのリソースレベルのインジケーターも多数あります。
コロケーション水位: リソース使用率が事前に設定されたコロケーション水位を超えた場合、コンテナを削除する必要があります。
干渉検出: コロケーションコンテナーによって発生する明らかな干渉を検出するためにカスタム干渉インジケーターが使用されている場合、対応するコンテナーを削除する必要があります。
手動による強制トリガー: 一部のシナリオでは強制的な削除が必要であり、そのようなシナリオのサポートも必要です。
立ち退きコアロジック管理
地元の立ち退き：この場合、ノード上のすべてのポッドを立ち退かせる必要はありません。代わりに、最も適切な立ち退きターゲットを正確に見つける必要があります。一般に、次の要因が考慮されます：ポッドの優先順位、ポッド利用、ポッド干渉指数など。
Node Veviction：物理マシンで深刻な問題が発生し、ノード上のすべての共同配置コンテナライブラリをすばやく追い出す必要があります。
サービスの立ち退き：たとえば、コロケーションサービスに問題がある場合、このサービスのすべてのインスタンスをIDCまたはパブリッククラウドに追放する必要があります。
国外追放の目的地
コロケーションクラスター：この場合、コロケーション容器が追い出された後、コロケーションクラスター内の他のノードにスケジュールされます。
自己構築されたIDCパブリッククラスター：この場合、コロケーションコンテナは、追い出された後、IDCパブリッククラスターにスケジュールされます。
パブリッククラウド：この場合、コロケーションコンテナは追い出された後、パブリッククラウドにスケジュールされます。

将来の自己構築されたIDCパブリッククラスターの能力は限られており、パブリッククラウドはコストを増やすリソースを追加購入する必要があるため、立ち退き先の全体的な優先順位は次のとおりです。それがグローバルな問題でない場合は、できるだけ早くコロケーションクラスター内でそれを追い出す方が良いです。

弾性雲コロケーションの将来の展望

将来の定常状態の雲の移行計画の促進により、パブリッククラスターの規模は同じままであるか、適切に削減される可能性があります。将来的には、さまざまな孤立したクラスターがコロケーションの重要なコンピューティング電源になります。ここでは、上記の写真を使用して、弾性雲コロケーションの将来の見通しを説明しています。

写真

この図では、各コロケーションエンティティが独自の立場を見つけることができます。

合計：物理マシンの総リソースを示します
制限：コロケーションで利用可能なリソースの量を示します。制限と合計の間のバッファーは、予約された安定性バッファーです。
MID：この部分は、ハイブリッド展開でオンラインサービスで使用されます。それらは主にピークCPU使用量を増やすために使用されます。
バッチ：この部品はオフラインサービスに使用されます。それらは主に平均CPU使用を改善するために使用されます。
Prod：この赤い線は、分離されたクラスターサービス自体のCPU使用です。サービスの特性により、全体的な使用法は高くありません。

これは、完全なコロケーションという私たちの将来のアイデアです。より多くの種類のサービスが一緒に実行されるにつれて、それは技術的な能力に対してより大きな挑戦をもたらします。将来的には、クラスタースケジューリング、サービスプロファイリング、単一マシン分離、干渉検出、異常知覚およびその他の側面をさらに強化します。

<<: Docker を使用した Spring Boot アプリケーションのコンテナ化

>>: ワンストップのクラウドネイティブ FinOps プラットフォーム - KubeFin