クラウドネイティブハイブリッド展開の最後の防衛線: ノードウォーターマーク設計

1. はじめに

アリババグループでは、2014年にオフラインコロケーション技術が導入されました。双十一ショッピングフェスティバルでの7年間のテストを経て、社内で広く導入され、アリババグループは毎年数十億ドルのリソースコストを節約しています。全体のリソース利用率は約70％に達し、業界をリードしています。過去2年間、当グループのコロケーション技術を製品化した形で業界に輸出し始めました。標準のネイティブ k8s クラスターにプラグイン方式でシームレスにインストールでき、コロケーション管理や運用保守機能と組み合わせることで、クラスター リソースの使用率と製品の全体的なユーザー エクスペリエンスが向上します。

コロケーションは、K8s スケジューリング、OS 分離、可観測性などのさまざまなテクノロジーを含む複雑なテクノロジーと運用保守システムであるため、前の 2 つの記事「7 年間の Double 11 実践を経て、アリババはクラウドネイティブ コロケーションのスケジューリング優先順位とサービス品質をどのように定義していますか?」を参照してください。クラウドネイティブ ハイブリッド展開シナリオでリソース クォータを使用してクラスター リソースを効率的に割り当てる方法は?今日は、単一マシンで実行する場合のコロケーションの最後の防御線である、単一マシンのウォーターライン設計に焦点を当てます。

2. 単一の機械水位ラインが必要なのはなぜですか?

上の図に示すように、Pod のランタイムの 3 つのライフサイクル ステージでは、クォータのチェックとスケジュール設定の後、異なる QoS レベルの Pod が最終的に同じノードで実行されます。このとき、高優先度および中優先度の Pod はノード上のコンテナ割り当ての総量を使用し、低優先度の Pod は高優先度および中優先度の Pod の実際のリソース使用量に基づいてスケジューラによってノード上で実行されるようにスケジュールされます。下の図からわかるように、ノード上にまだ多くの空きリソースがある場合、それらは低優先度のリソースに完全に提供されます。ただし、高優先度/中優先度 Pod の実際のリソース使用量が一定値を超え、リソースの競争が非常に激しい場合、ノード上で低優先度 Pod を実行すると、高優先度/中優先度 Pod のサービス品質が損なわれるだけです。したがって、現時点では、このノード上で優先度の低いポッドを実行することは許可されません。ノード リソースの競争の激しさを識別または判断するには、このノードのリソース使用率が高すぎるかどうかを確認するのが非常に論理的な設計です。使用率が一定レベルを超えた場合、優先度の低いポッドに対して対応するアクションを実行する必要があります。この判断の重要な閾値は、単一の機械の水位です。

ここで確認できるもう 1 つのポイントは、ウォーターマークが優先度の低い Pod に対してのみ設定されていることです。高優先度および中優先度のポッドはウォーターマークを認識しません。マシン全体のすべてのリソースを自由に使用でき、すべてのシステム動作はコロケーションが有効になっていない場合と同じです。

3. 水位の分類

リソースが飽和状態に近づいているノードの場合、さまざまな方法を使用して優先度の低いポッドを操作できます。優先度の低いポッドを単純に削除するだけで、コロケーション システム全体が機能するようになります。このアクションを「立ち退き」と呼びます。ただし、一定時間が経過してマシン上のリソース競合が再び減少すると、低優先度 Pod は強制終了され、別のマシンで再起動されるため、低優先度 Pod の単一タスクの実行時間が大幅に長くなります。したがって、シングルマシン ウォーターマークを設計する場合、許容される時間の範囲内で、優先度の低い Pod を可能な限り「ダウングレード」できるようにする必要があります。したがって、優先度の低いポッドに対しては、CPU 供給を減らすという 2 番目の操作を実行します。この操作を「抑制」と呼びます。同時に、ノード上のリソースが飽和状態になった場合、別の論理的なシステム動作として、優先度の低い新しいポッドがスケジュールされないようにすることになります。

したがって、ノード上の優先度の低いポッドには、抑制、削除、スケジュール禁止という 3 つの動作があります。したがって、透かしは 3 つあります。同時に、CPU などの圧縮可能なリソースとメモリなどの非圧縮可能なリソースでは動作に違いがあります。

注: 圧縮可能なリソース (CPU サイクル、ディスク I/O 帯域幅など) はレートに敏感であり、タスクを強制終了せずに再利用できます。また、圧縮できないリソース (メモリ、ディスク領域など) は、通常、タスクを強制終了しない限り再利用できません。記事「Google 5-6 での大規模クラスタの管理に Borg を使用する」より - 6.2 パフォーマンス分離 [1]

これらの透かしの一般的なリストは次のとおりです。

これらの水位の適切な設定値は、排除＞抑制＞スケジュールの禁止となるはずです。ただし、実際のコロケーション運用においては、システム運用保守担当者の理解コストと設定作業負荷を軽減するため、スケジューリング禁止ウォーターマークと抑制ウォーターマークには同じ設定値を使用することが一般的です。統合後は、CPU に 2 つのウォーターマーク、メモリに 1 つのウォーターマークが存在することになります。

4. 立ち退き条件:満足度に基づく立ち退きモード

この図は、単一のマシンでの実際のシステム動作例を示しています。

• 時刻 t1 に、リソース使用率の合計が抑制ウォーターラインに達すると、全体のリソース使用率が抑制ウォーターラインを下回るように、優先度の低いタスクが抑制されます。この時点で、優先度の低いタスクはスケジュールされなくなります。
• t3 では、総リソース使用率がさらに上昇し始めます。排除ウォーターラインに達すると、優先度の低いタスクは削除され、排除されて、優先度の高い/中程度のリソースの使用率が確保されます。

検討しやすい設計としては、優先度の低いタスクを削除する前に遅延を設定することが挙げられます。これにより、優先度の低いポッドは、システムが実行を継続するのに十分なリソースを持つまで待機する機会が増えます。ただし、この設計ではいくつかの問題が発生します。

• ノード上のメモリが不足すると、高/中優先度のタスクでメモリ不足が発生し、OOM が発生するため、メモリの削除はリアルタイムで行う必要があります。
• この遅延時間を設定するのは簡単ではありません。短すぎると効果がありません。長すぎると、低優先度の Pod が長時間「飢餓状態」になり、低優先度の Pod の実行時間が長くなります。
• 複数の低優先度ポッドがノード上で実行されている場合、それらすべてを削除する必要がありますか?できるだけ少ない数のポッドを排除することは可能ですか?

そこで、満足度に基づいて低優先度の Pod の CPU リソースを排除する方法を考案し、次の概念を定義しました。

• ウィンドウ期間: CPU 使用率を取得する時間ウィンドウ (例: 5 分)。ウィンドウ内の平均 CPU 使用率がエビクション ウォーターマークを超えると、ジッターを回避するためにエビクションが開始されます。
• 低優先度ポッドのリソース満足度: = 低優先度ポッドの実際のリソース使用量 / 低優先度ポッドの要求リソース
• 低優先度ポッド満足度の下限: 低優先度ポッドのリソース供給が不十分とみなされるパーセンテージ値

このようにして、優先度の低いポッドの削除条件は次のようになります。

• ウィンドウ期間中: 低優先度ポッドリソースの平均満足度 < 低優先度ポッド満足度の下限
• ウィンドウ期間中: 低優先度ポッドの平均CPU使用率は100%に近い(90%や80%など)
• 現在時刻: 低優先度 Pod リソースの平均満足度 < 低優先度 Pod 満足度の下限
• 最近: BE CPU 使用率が 100% に近い (90% や 80% など)

優先度の低いポッドを削除する順序は次のとおりです。

• スケジューリング優先度の低いポッドの排除を優先します (優先度の低いポッドであっても、数値に応じて異なるスケジューリング優先度を細分化できます)
• 2 つの Pod のスケジュール優先度が同じ場合、より多くのリソースを解放できる Pod が計算され、より多くのリソースを解放できる Pod が優先されます。

メモリ追い出し方法はCPUと同様ですが、満足度はありません。削除ウォーターマークに達すると、優先度とメモリ サイズに基づいて削除が実行されます。

注: 他のノード上の低優先度 Pod の再構築は、依然として低優先度 Pod の管理システム (オフライン コンピューティング フレームワークの Spark/Flink など) に依存します。この再構築プロセスには、一時的にキャッシュされたファイルまたはデータの移行と一貫性の検証が含まれることがよくあります。この再構築操作は、K8s レイヤーでのアクティブな操作には適しておらず、上位レベルの管理システムまたはオペレーターに引き渡す方が適切です。

5. 展望: より良いデザインはあるでしょうか?

この記事の冒頭で、システム リソースの競争の激しさを測定する最も簡単で直感的な方法は、リソースの使用率を確認することだと説明しました。もちろん、実際の大規模クラスターの運用プロセスでは、高いリソース使用率と激しいリソース競争が完全に一対一で対応しているわけではないこともわかりました。一部のアプリケーションは、CPU 使用率が非常に高い場合でも安定して動作しますが、他のアプリケーションは、CPU 使用率が低いと動作が非常に遅くなります。つまり、システム使用率を測定するための新しい、より優れた指標があれば、対応するワークロードの「マイクロ管理」をさらに強化し、アプリケーションの SLO を確保しながらクラスター リソースの使用率を向上させることができます。

6. 関連ソリューションの紹介

2022年を迎えるにあたり、コロケーションはAlibaba内で非常に成熟した技術となり、Alibabaは毎年数十億ドルのコストを節約しており、Alibabaのデータセンターの基本的な機能となっています。 Alibaba Cloud は、これらの成熟したテクノロジーをコロケーション製品として開発するのに 2 年を費やし、さまざまな業界にサービスを提供し始めています。クラウドネイティブのコロケーション関連機能には、多数の独立した知的財産権が申請されています。

Alibaba Cloudの製品群では、ACK Agile EditionとCNStack（CloudNative Stack）製品群を通じてコロケーション機能を公開し、OpenAnolisオペレーティングシステムと組み合わせて、クラウドネイティブデータセンターにおけるコロケーションの完全な統合ソリューションを形成し、お客様に提供します。

参考資料:

[1] 「Borg を使って Google 5-6 の大規模クラスタを管理する」: https://my.oschina.net/HardySimpson/blog/517283​