Meituan Cluster スケジューリングシステムのクラウドネイティブ実践

著者 |タン・リン

この記事では、大規模クラスター管理の難しさを解決し、優れた合理的なクラスタースケジューリングシステムを設計する Meituan の実践を紹介します。また、Kubernetes に代表されるクラウドネイティブテクノロジーを実装する際に Meituan が特に懸念する問題、課題、および対応するプロモーション戦略についても説明します。同時に、この記事では、Meituan のビジネス需要シナリオに対するいくつかの特別なサポートも紹介しています。この記事がクラウドネイティブ分野に興味のある学生の役に立ち、刺激を与えることができれば幸いです。

導入
クラスタスケジューリングシステムの概要
大規模クラスターの管理の課題
大規模クラスターの運用における課題
クラスタスケジューリングシステムを設計する際のトレードオフ
美団のクラスターディスパッチシステムの進化
複数のクラスタの統合スケジューリング: データセンターのリソース利用率の向上
スケジューリングエンジンサービス：PaaSサービスのクラウドネイティブ実装を実現
将来の展望: クラウドネイティブオペレーティングシステムの構築

導入

クラスタースケジューリングシステムは、エンタープライズデータセンターで重要な役割を果たします。クラスターのサイズとアプリケーションの数が急増するにつれて、開発者のビジネス上の問題の複雑さが大幅に増加しました。大規模クラスター管理の問題を解決し、安定性を確保し、コストを削減し、効率を向上させる優れた合理的なクラスタースケジューリングシステムを設計するにはどうすればよいでしょうか。この記事では、これらの質問に一つずつ答えていきます。 | ※この記事は「新人プログラマー003」のクラウドネイティブ時代の開発者コラムに初掲載されました。

クラスタスケジューリングシステムの概要

クラスタースケジューリングシステムは、データセンターリソーススケジューリングシステムとも呼ばれ、データセンターのリソース管理とタスクスケジューリングの問題を解決するためによく使用されます。データセンターのリソースを有効活用し、リソースの使用率を向上させるとともに、ビジネス関係者に自動化された運用・保守機能を提供して、サービスの運用・保守管理コストを削減することを目標としています。業界でよく知られているクラスタースケジューリングシステムには、オープンソースの OpenStack、YARN、Mesos、Kubernetes のほか、Google の Borg、Microsoft の Apollo、Baidu の Matrix、Alibaba の Fuxi、ASI などの有名なインターネット企業のシステムもあります。さまざまなインターネット企業の中核となる IaaS インフラストラクチャとして、クラスタースケジューリングシステムは過去 10 年間で複数のアーキテクチャ上の進化を遂げてきました。ビジネスがモノリシックアーキテクチャから SOA (サービス指向アーキテクチャ) やマイクロサービスの開発へと進化するにつれ、基盤となる IaaS 機能も物理マシンのベアメタル時代からコンテナ時代へと徐々に移行してきました。私たちが対処しなければならない中核的な問題は進化の過程で変化していませんが、クラスターのサイズとアプリケーションの数の急速な拡大により、問題の複雑さも指数関数的に増加しています。この記事では、大規模クラスタ管理の課題とクラスタスケジューリングシステムの設計思想について説明します。 Meituan のクラスタースケジューリングシステムの実装を例に、複数のクラスターの統合スケジューリングサービスの作成、リソース使用率の継続的な改善、PaaS コンポーネントを強化する Kubernetes エンジンサービスの提供、ビジネス向けのより優れたコンピューティングサービスエクスペリエンスの提供など、一連のクラウドネイティブプラクティスについて説明します。

大規模クラスターの管理の課題

ご存知のとおり、ビジネスの急速な成長により、サーバーの規模とデータセンターの数が急増しました。開発者にとって、大規模クラスタスケジューリングシステムのビジネスシナリオでは、解決しなければならない問題が 2 つあります。

特にクロスデータセンターのシナリオにおいて、データセンターの大規模クラスターの展開とスケジューリングを管理する方法、リソースの弾力性とスケジューリング機能を実現する方法、アプリケーションサービスの品質を確保しながらリソースの使用率を最大化する方法、およびデータセンターのコストを完全に削減する方法。
基盤となるインフラストラクチャを変革し、ビジネス関係者向けのクラウドネイティブなオペレーティングシステムを作成し、コンピューティングサービスのエクスペリエンスを向上させ、自動化された災害復旧対応やアプリケーションの展開アップグレードなどを実現し、基盤となるリソース管理に関するビジネス関係者の精神的負担を軽減し、ビジネス関係者がビジネスそのものにさらに集中できるようにする方法。

大規模クラスターの運用における課題

上記 2 つの問題を実際の運用環境で解決するためには、さらに次の 4 つの大規模クラスターの運用および管理の課題に分類できます。

ユーザーの多様なニーズをいかに解決し、迅速に対応するか。ビジネススケジューリングの要件とシナリオは豊富で動的です。クラスタスケジューリングシステムのようなプラットフォームサービスとしては、機能を迅速に提供し、ビジネスニーズにタイムリーに対応できることが求められます。一方で、ビジネスの個別化されたニーズを、プラットフォーム上に実装して長期間にわたって反復できる一般的な機能に抽象化できるほど汎用性の高いプラットフォームを構築することも必要です。これは、プラットフォームサービスチームの技術進化計画にとって大きなテストです。注意しないと、チームはビジネス機能の開発に終わりのないまま陥ってしまうからです。ビジネスニーズを満たしますが、チーム作業の低レベルの繰り返しが発生します。
アプリケーションサービスの品質を確保しながら、オンラインアプリケーションデータセンターのリソース使用率を向上させる方法。リソースのスケジューリングは、業界では常に認識されている問題です。クラウドコンピューティング市場の急速な発展に伴い、クラウドコンピューティングベンダーはデータセンターへの投資を増やし続けています。データセンターのリソース使用率が非常に低いという事実によって、問題はさらに悪化します。ガートナーの調査によると、世界のデータセンターサーバーの CPU 使用率はわずか 6% ～ 12% です。 Amazon の Elastic Compute Cloud (EC2) プラットフォームでさえ、リソース使用率はわずか 7% ～ 17% であり、リソースの浪費がいかに深刻であるかがわかります。その理由は、オンラインアプリケーションはリソース使用率に非常に敏感であり、業界では重要なアプリケーションのサービス品質 (QoS) を確保するために追加のリソースを予約する必要があるからです。クラスタスケジューリングシステムでは、複数のアプリケーションが混在して実行されている場合にアプリケーション間の干渉を排除し、異なるアプリケーション間のリソースの分離を実現する必要があります。
アプリケーション、特にステートフルアプリケーションのインスタンスの例外の自動処理を提供し、データセンター間の違いを遮断し、基盤となるレイヤーに対するユーザーの認識を軽減する方法。サービスアプリケーションの規模が拡大し続け、クラウドコンピューティング市場が成熟するにつれて、分散アプリケーションは異なる地域のデータセンターに、または異なるクラウド環境に展開されることが多くなり、マルチクラウドまたはハイブリッドクラウドの展開が実現します。クラスタースケジューリングシステムは、ビジネスパーティに統一されたインフラストラクチャを提供し、ハイブリッドマルチクラウドアーキテクチャを実装し、基盤となる異種環境を保護する必要があります。同時に、アプリケーションの運用と保守管理の複雑さが軽減され、アプリケーションの自動化の度合いが向上し、ビジネスに優れた運用と保守のエクスペリエンスが提供されます。
単一のクラスターが大きすぎるか、クラスターの数が多すぎるために発生するクラスター管理に関連するパフォーマンスと安定性のリスクをどのように解決しますか?クラスターのライフサイクル管理の複雑さは、クラスターのサイズと数に応じて増大します。 Meituan を例にとると、当社が採用した 2 サイトのマルチセンターマルチクラスターソリューションは、クラスターの規模が大きすぎることによる潜在的な危険性をある程度回避し、ビジネスの孤立や地域的な遅延などの問題を解決しました。エッジクラスターシナリオの出現と、データベースなどのクラウドベースの PaaS コンポーネントの需要により、小規模クラスターの数は明らかに増加傾向にあると予測されます。これにより、クラスター管理の複雑さ、監視構成コスト、運用および保守コストが大幅に増加します。現時点では、クラスタスケジューリングシステムは、より効果的な動作仕様を提供し、運用の安全性、アラームの自己修復、変更効率を確保する必要があります。

クラスタスケジューリングシステムを設計する際のトレードオフ

上記の課題に対処するには、優れたクラスタースケジューラが重要な役割を果たします。しかし、現実には完璧なシステムは存在しません。したがって、クラスタースケジューリングシステムを設計するときは、実際のシナリオに基づいていくつかの矛盾の間でトレードオフを行う必要があります。

クラスタースケジューリングシステムのシステムスループットとスケジューリング品質。システムスループットは、システムの品質を評価するための重要な基準です。ただし、オンラインサービスのクラスタースケジューリングシステムでは、スケジューリングの品質がより重要になります。各スケジュール結果の影響は長期的（数日、数週間、または数か月）であるため、異常でない状況では調整は行われません。したがって、スケジューリング結果が間違っていると、サービス遅延の増加に直接つながります。スケジューリング品質が高いほど、考慮する必要があるコンピューティング制約が多くなり、スケジューリングパフォーマンスが悪ければ、システムスループットは低くなります。
クラスタースケジューリングシステムのアーキテクチャの複雑さとスケーラビリティ。システムが上位レベルの PaaS ユーザーに公開する機能や構成が増えるほど、またユーザーエクスペリエンスを向上させるためにサポートされる機能が増えるほど (アプリケーションリソースのプリエンプションとリカバリ、アプリケーションインスタンスの自己修復のサポートなど)、システムは複雑になり、サブシステム間で競合が発生する可能性が高くなります。
クラスタースケジューリングシステムの信頼性と単一クラスターのスケール。単一のクラスターのサイズが大きいほど、スケジュール可能な範囲は広くなりますが、爆発半径が大きくなり、障害の影響が大きくなるため、クラスターの信頼性に対する課題も大きくなります。単一のクラスタが小さい場合、スケジューリングの同時実行性は向上しますが、スケジュール可能な範囲が狭くなり、スケジューリングが失敗する確率が高くなり、クラスタ管理の複雑さが増します。

現在、業界におけるクラスタスケジューリングシステムは、アーキテクチャによって、単一型スケジューラ、2 レベルスケジューラ、共有状態スケジューラ、分散スケジューラ、ハイブリッドスケジューラの 5 つの異なるアーキテクチャに分類できます (下の図 1 を参照)。各アーキテクチャは、各シナリオのニーズに基づいて異なる選択を行い、絶対的に良い、または悪いというものはありません。

図 1 クラスタスケジューリングシステムアーキテクチャの分類 (Malte Schwarzkopf - クラスタスケジューラアーキテクチャの進化より)

モノリシックスケジューラは、クラスターのグローバル情報と組み合わせた複雑なスケジューリングアルゴリズムを使用して高品質の配置ポイントを計算しますが、レイテンシは高くなります。 Google の Borg システムやオープンソースの Kubernetes システムなど。
2 レベルスケジューラは、リソーススケジューリングとジョブスケジューリングを分離することで、単一スケジューラの制限を解決します。 2 レベルスケジューラでは、異なるジョブ間でクラスターリソースを共有する機能を維持しながら、特定のアプリケーションに基づいて異なるジョブスケジューリングロジックを実行できますが、優先度の高いアプリケーションのプリエンプションを実現することはできません。代表的なシステムはApache MesosとHadoop YARNです。
共有状態スケジューラは、2 レベルスケジューラの制限を半分散方式で解決します。共有状態の各スケジューラにはクラスター状態のコピーがあり、スケジューラはクラスター状態のコピーを個別に更新します。ローカル状態のコピーが変更されると、クラスター全体の状態情報が更新されますが、リソースの競合が継続するとスケジューラのパフォーマンスが低下します。代表的なシステムは、Google の Omega と Microsoft の Apollo です。
分散スケジューラは、比較的単純なスケジューリングアルゴリズムを使用して、大規模な高スループット、低レイテンシの並列タスク配置を実現します。しかし、スケジューリングアルゴリズムが単純で、リソースの使用に関する全体的な視点が欠如しているため、高品質のジョブ配置を実現することは困難です。代表的なシステムとしては、カリフォルニア大学の Sparrow などがあります。
ハイブリッドスケジューラは、長時間実行されるタスクには複雑なアルゴリズムを使用し、短時間実行されるタスクには分散レイアウトを利用して、集中型コンポーネントと分散型コンポーネント全体にワークロードを分散します。 Microsoft Mercury はこのアプローチを採用しました。

したがって、スケジューリングシステムの品質を評価する方法は、主に実際のスケジューリングシナリオによって異なります。業界で最も広く使用されているシステムである YARN と Kubernetes を例に挙げると、どちらのシステムも一般的なリソーススケジューラですが、実際には YARN は短いタスクを処理するオフラインバッチに重点を置いているのに対し、Kubernetes はオンラインで長時間実行されるサービスに重点を置いています。アーキテクチャ設計と機能の違い ( Kubernetes はモノリシックスケジューラですが、YARN は 2 レベルスケジューラです) に加えて、両者には設計哲学と視点も異なります。 YARN はよりタスクに重点を置き、リソースの再利用に注意を払い、リモートデータの複数のコピーを回避します。その目標は、より低コストかつより高速にタスクを実行することです。 Kubernetes は、サービス品質の確保を目的として、サービスステータス、ピークシフト、サービスプロファイリング、リソースの分離に重点を置いています。

美団のクラスターディスパッチシステムの進化

コンテナ化の実装プロセスにおいて、Meituan はビジネスシナリオの要件に基づいて、クラスタースケジューリングシステムのコアエンジンを OpenStack から Kubernetes に変換し、2019 年末までにオンラインビジネスのコンテナ化カバレッジを 98% 超えるという目標を達成しました。ただし、リソース使用率が低い、運用および保守コストが高いなどの問題がまだ残っています。

クラスターの全体的なリソース使用率は高くありません。たとえば、CPU リソースの平均使用率は依然として業界平均レベルですが、他の一流インターネット企業と比較すると大きな差があります。
ステートフルサービスのコンテナ化率は、特にコンテナを使用しない MySQL や Elasticsearch などの製品では十分に高くありません。業務の運用・保守コストやリソースコストには、最適化の余地がまだ多くあります。
ビジネスニーズを考慮すると、VM 製品は今後も長く存在し続けるでしょう。 VM スケジューリングとコンテナスケジューリングは 2 つの環境セットであり、チームの仮想化製品の運用および保守コストが高くなります。

そこで、クラスタースケジューリングシステムのクラウドネイティブ化を開始することにしました。マルチクラスター管理と自動化された運用および保守機能を備え、スケジューリング戦略の推奨とセルフサービス構成をサポートし、クラウドネイティブの基盤拡張機能を提供し、アプリケーションサービスの品質を確保しながらリソース使用率を向上させる、大規模で高可用性のスケジューリングシステムを構築します。中核となる業務は、安定性の維持、コストの削減、効率性の向上という3つの主要な方向性を軸にディスパッチシステムを構築することです。

安定性の確保:スケジューリングシステムの堅牢性と観測可能性を向上します。システムモジュール間の結合を減らし、複雑さを軽減します。マルチクラスタ管理プラットフォームの自動運用・保守機能を向上させる。コアシステムコンポーネントのパフォーマンスを最適化します。大規模クラスターの可用性を確保します。
コストの削減:スケジューリングモデルを徹底的に最適化し、クラスタースケジューリングと単一マシンスケジューリング間のリンクを開きます。静的リソーススケジューリングから動的リソーススケジューリングに移行し、オフラインビジネスコンテナーを導入して、自由競争と強力な制御の組み合わせを形成しました。これにより、リソースの使用率が向上し、IT コストが削減されると同時に、高品質なビジネスアプリケーションサービスの品質が確保されました。
効率の向上:ユーザーが独自のスケジュール戦略を調整して個別のビジネスニーズに対応できるようにサポートし、クラウドネイティブ分野を積極的に採用し、オーケストレーション、スケジュール設定、クラスター間、高可用性などのコア機能を備えた PaaS コンポーネントを提供して、運用と保守の効率を向上させます。

図2 Meituanクラスタスケジューリングシステムアーキテクチャ

最後に、Meituan クラスタースケジューリングシステムアーキテクチャは、分野に応じて、スケジューリングプラットフォームレイヤー、スケジューリングストラテジーレイヤー、およびスケジューリングエンジンレイヤーの 3 つのレイヤーに分かれています (上記の図 2 を参照)。

プラットフォーム層は、ビジネスアクセス、Meituan のインフラストラクチャの接続、ネイティブインターフェイスとロジックのカプセル化、コンテナ管理インターフェイス (拡張、更新、再起動、縮小) などの機能の提供を担当します。
ポリシーレイヤーは、複数のクラスターに統合されたスケジューリング機能を提供し、スケジューリングアルゴリズムとポリシーを継続的に最適化し、ビジネスのサービスレベルや機密リソースなどの情報に基づいたサービス分類を通じて CPU 使用率と割り当て率を向上させます。
エンジン層は、複数の PaaS コンポーネントのクラウドネイティブクラスターの安定性を確保するための Kubernetes サービスを提供し、共通機能をオーケストレーションエンジンにシンクして、クラウドネイティブビジネス実装のアクセスコストを削減します。

運用の洗練と製品機能のブラッシュアップにより、Meituanの約100万のコンテナ/仮想マシンインスタンスの管理を一元化し、一方でリソース利用率を業界平均から一流レベルに向上させ、PaaSコンポーネントのコンテナ化とクラウドネイティブ実装もサポートしています。

複数のクラスタの統合スケジューリング: データセンターのリソース利用率の向上

クラスタースケジューリングシステムの品質を評価する場合、リソース使用率は最も重要な指標の 1 つです。そのため、2019年にコンテナ化は完了しましたが、コンテナ化は目的ではなく、あくまで手段に過ぎません。私たちの目標は、VM テクノロジースタックからコンテナテクノロジースタックに切り替えることで、ユーザーのコンピューティングコストを全面的に削減するなど、ユーザーにさらなるメリットをもたらすことです。リソース使用率の向上は、クラスター内の個々のホットホストによって制限されます。容量が拡張されると、ビジネスコンテナーがホットホストに拡張される可能性があり、TP95 時間などのビジネスパフォーマンス指標が変動します。その結果、業界の他の企業と同様に、サービス品質を確保するにはリソースの冗長性を高めるしかありません。その理由は、Kubernetes スケジューリングエンジンの割り当て方法が、単純に Request/Limit Quota (Kubernetes がコンテナに対してユーザーが適用するリソースクォータとして、コンテナに対するリクエスト値 Request と制約値 Limit を設定する) を考慮しており、静的なリソース割り当てとなっているためです。その結果、異なるホストに同じ量のリソースが割り当てられているにもかかわらず、ホストのリソース使用率はサービスの違いにより大きく異なります。学界と産業界では、リソース利用効率とアプリケーションサービス品質の矛盾を解決するために、一般的に 2 つの方法が使用されています。最初の方法は、効率的なタスクスケジューラを使用してグローバルな観点から解決することです。 2 番目の方法は、単一マシンのリソース管理を通じてアプリケーション間のリソース分離を強化することです。どちらの方法を使用する場合でも、クラスターの状態を完全に把握する必要があるため、次の 3 つのことを行いました。

クラスタ状態、ホスト状態、サービス状態間の関連性を体系的に確立し、スケジューリングシミュレーションプラットフォームと組み合わせることで、ピーク使用率と平均使用率を総合的に考慮し、ホストの履歴負荷とビジネスのリアルタイム負荷に基づいた予測とスケジューリングを実現します。
自社開発の動的負荷調整システムとクラスタ間再スケジューリングシステムにより、クラスタスケジューリングと単一マシンスケジューリングのリンクが連携され、業務分類に応じて異なるリソースプールのサービス品質保証戦略が実装されます。
3 回の反復を経て、独自のクラスター連合サービスを実現しました。これにより、リソースの事前占有と状態データの同期の問題が効果的に解決され、クラスター間のスケジューリングの同時実行性が向上し、コンピューティングの分離、クラスターマッピング、負荷分散、およびクラスター間のオーケストレーション制御が実現されました (下の図 3 を参照)。

図3 クラスタフェデレーションV3アーキテクチャ

クラスタフェデレーションサービスの 3 番目のバージョンは、モジュールに応じてプロキシレイヤーとワーカーレイヤーに分割され、独立して展開されます。

プロキシ層は、クラスターの状態の要因と重みに基づいて、スケジュールに適切なクラスターを選択し、リクエストを分散するために適切なワーカーを選択します。プロキシモジュールは、サービス登録、リーダー選出、検出に etcd を使用します。リーダーノードは、スケジュール中にタスクをプリエンプトする責任があり、すべてのノードがクエリタスクを担当できます。
ワーカー層は、クラスターのクエリ要求の一部を処理します。クラスタータスクがブロックされた場合、対応するワーカーインスタンスをすばやく拡張して問題を軽減できます。単一のクラスターが大きい場合、複数の Worker インスタンスに対応します。プロキシは、スケジューリング要求を複数のワーカーインスタンスに分散して処理するため、スケジューリングの同時実行性が向上し、各ワーカーの負荷が軽減されます。

最終的には、複数のクラスターの統一されたスケジューリングを通じて、静的リソーススケジューリングモデルから動的リソーススケジューリングモデルへの移行を実現し、ホットスポットホストの割合を減らし、リソースの断片化の割合を減らし、優先度の高いビジネスアプリケーションのサービス品質を確保し、オンラインビジネスクラスターの平均サーバー CPU 使用率を 10 パーセントポイント向上させました。クラスターリソースの平均使用率は、次のように計算されます: Sum(nodeA.cpu.現在使用されているコア数 + nodeB.cpu.現在使用されているコア数 + xxx) / Sum(nodeA.cpu.合計コア数 + nodeB.cpu.合計コア数 + xxx)。計算は 1 分ごとに 1 ポイントずつ行われ、その日のすべての値が平均化されます。

スケジューリングエンジンサービス：PaaSサービスのクラウドネイティブ実装を実現

クラスタースケジューリングシステムは、リソーススケジューリングの問題を解決するだけでなく、コンピューティングリソースのサービス使用の問題も解決します。書籍「Google のソフトウェアエンジニアリング」で述べられているように、Compute as a Service の主要コンポーネントの 1 つであるクラスタスケジューリングシステムは、リソーススケジューリング (物理マシンの分解から CPU/Mem などのリソースディメンションまで) とリソース競合 ( 「ノイジーネイバー」の解決) だけでなく、アプリケーション管理 (自動インスタンス展開、環境監視、例外処理、サービスインスタンス数の確保、ビジネスに必要なリソース量の決定、さまざまな種類のサービスなど) も解決する必要があります。さらに、アプリケーション管理は、ビジネス開発と運用の効率、サービスの災害復旧効果に直接影響するため、ある程度、リソースのスケジュール設定よりも重要です。結局のところ、インターネットの人件費は機械費よりも高いのです。複雑なステートフルアプリケーションのコンテナ化は、業界では常に難しい問題となっています。これは、さまざまなシナリオの分散システムでは通常、独自のステートマシンが維持されるためです。アプリケーションシステムを拡張、縮小、またはアップグレードする場合、既存のインスタンスサービスの可用性とそれらの間の接続性をどのように確保するかは、ステートレスアプリケーションよりもはるかに複雑で困難な問題です。すべてのステートレスサービスをコンテナ化しましたが、優れたクラスタースケジューリングシステムの価値はまだ十分には実現されていません。コンピューティングリソースを適切に管理するには、サービスの状態を管理し、リソースとサービスを分離し、サービスの回復力を向上させる必要がありますが、これは Kubernetes エンジンが優れている点でもあります。 Meituan の最適化およびカスタマイズされた Kubernetes バージョンに基づいて、Meituan Kubernetes Engine Service MKE を作成しました。

クラスターの運用および保守機能を強化し、クラスターの自己修復、アラームシステム、イベントログ分析などのクラスターの自動運用および保守機能を向上させて、クラスターの可観測性を継続的に向上させます。
当社は主要なビジネスベンチマークを設定し、いくつかの重要な PaaS コンポーネントと緊密に連携し、Sidecar アップグレード管理、Operator グレースケール反復、アラーム分離などのユーザーの問題点を迅速に最適化して、ユーザーの要求に応えました。
当社は、製品エクスペリエンスの向上と Kubernetes エンジンの最適化を継続して行っています。ユーザーがカスタムオペレーターを使用できるようにサポートするだけでなく、一般的なスケジューリングおよびオーケストレーションフレームワーク (図 4 を参照) も提供し、ユーザーが低コストで MKE にアクセスし、技術的なメリットを得られるよう支援します。

図4 Meituan Kubernetes Engineのサービススケジューリングとオーケストレーションフレームワーク

クラウドネイティブの実装を推進する中で、広く関心を集めている疑問は、「Kubernetes クラウドネイティブアプローチに基づいてステートフルアプリケーションを管理することと、管理プラットフォームを独自に構築することの違いは何か?」ということです。この問題については、問題の根本的な原因である保守性を考慮する必要があります。

Kubernetes をベースとするということは、システムが閉ループであることを意味し、2 つのシステム間で頻繁に発生するデータの不整合を心配する必要はありません。
例外応答を数ミリ秒単位で実現できるため、システムの RTO (Recovery Time Objective、主に許容可能な最長時間のサービス停止を指し、災害発生から業務システムによるサービス機能の復旧までの最短時間) が短縮されます。
システムの運用・保守の複雑さも軽減され、災害復旧の自動化も実現しました。サービス自体に加えて、サービスが依存する構成と状態データも一緒に復元できます。
従来のさまざまな PaaS コンポーネントの「煙突型」管理プラットフォームと比較して、一般的な機能をエンジンサービスに集約して、開発および保守コストを削減できます。エンジンサービスを利用することで、基盤となる異機種環境を保護し、データセンターやマルチクラウド環境にわたるサービス管理を実現できます。

将来の展望: クラウドネイティブオペレーティングシステムの構築

クラウドネイティブ時代のクラスタ管理は、これまでのハードウェアやリソースなどを管理する機能から、アプリケーション中心のクラウドネイティブオペレーティングシステムへと進化していくと考えています。この目標を達成するために、Meituan のクラスターディスパッチシステムは次の側面に取り組む必要があります。

アプリケーションリンク配信管理。ビジネスの規模とリンクの複雑さが増すにつれ、ビジネスが依存する PaaS コンポーネントと基盤インフラストラクチャの運用と保守の複雑さは、一般の認識をはるかに超えるものとなり、プロジェクトを引き継いだばかりの新人にとってはさらに困難になります。したがって、宣言的な構成を通じて企業がサービスを提供し、自己運用と保守を実現できるようにサポートし、企業に優れた運用と保守のエクスペリエンスを提供し、アプリケーションの可用性と観測性を向上させ、基盤となるリソース管理に対する企業の負担を軽減する必要があります。
エッジコンピューティングソリューション。 Meituan のビジネスシナリオが拡大し続けるにつれて、エッジコンピューティングノードの需要は予想よりもはるかに速いペースで増加しています。業界のベストプラクティスを参考にして、Meituan での実装に適したエッジソリューションを開発し、必要なサービスにエッジコンピューティングノード管理機能をできるだけ早く提供し、クラウドエッジエンドの連携を実現します。
オフラインコロケーション機能を構築します。オンラインビジネスクラスターのリソース利用率の向上には上限があります。 Googleが論文「Borg: the Next Generation」で公開した2019年のデータセンタークラスタデータによると、オフラインタスクを除くと、オンラインタスクのリソース使用率はわずか30％程度に過ぎない。これは、さらなる改善にはリスクがあり、投入産出比率が高くないことも示しています。その後、Meituan のクラスタースケジューリングシステムは、オフラインコロケーションの検討を継続します。ただし、Meituan のオフラインデータセンターは比較的独立しているため、実装パスは業界の一般的なソリューションとは異なります。まず、オンラインサービスとほぼリアルタイムのタスクの共存から始め、基盤となる機能の構築を完了し、次にオンラインタスクとオフラインタスクの共存を検討します。

要約する

Meituan のクラスタースケジューリングシステムを設計する際、全体として適切性の原則に従いました。基本的なビジネスニーズを満たし、システムの安定性を確保した後、アーキテクチャを段階的に改善し、パフォーマンスを強化し、機能を充実させました。したがって、私たちは次のことを選択しました。

システムスループットとスケジューリング品質の観点から、システムスループットに対するビジネスの需要を満たすことを優先します。一度のスケジュールの品質を過度に追求するのではなく、再スケジュールすることで調整し、改善していきます。
アーキテクチャの複雑さとスケーラビリティの観点から、システムモジュール間の結合を減らし、システムの複雑さを軽減し、拡張機能はダウングレード可能であることを選択します。
信頼性と単一クラスターのサイズの間で、システムの信頼性を確保し、爆発半径を縮小するために、複数のクラスターの統一されたスケジュール設定を通じて単一クラスターのサイズを制御することを選択しました。

今後も、同じロジックに基づいて Meituan のクラスタースケジューリングシステムを最適化および反復し、アプリケーション中心のクラウドネイティブオペレーティングシステムへと完全に変革していきます。