このエントリーについて
このエントリーを書き始めた経緯は下記にあります。
今回は前回の続きでセクション7からです！前回のエントリーはこちらです。
7. 関連研究(Related work)
リソーススケジューリングは、Wide-area HPC supercomputing Grids、Networks of Workstations、Large-Scale Server Clustersなど、さまざまな状況で数十年にわたって研究されてきました。ここでは、大規模なサーバークラスターのコンテキストで最も関連性の高い作業のみに焦点を当てます。
最近のいくつかの研究では、Yahoo!、Google、およびFacebookのクラスタートレースを分析しており[20, 52, 63, 68, 70, 80, 82]、これらの最新のデータセンターとワークロードに固有の規模と、それぞれ異なる課題を示します。[69]にはクラスターマネージャーアーキテクチャの分類が含まれています。
Apache Mesos [45]は、offer-basedなメカニズムを使用して、中央のリソースマネージャー(Borgmasterからスケジューラを除いたもの)とHadoop [41]やSpark [73]などの複数の「フレームワーク」の間でリソース管理および配置機能を分割します。Borgは、リクエストベースなメカニズムを使用して、これらの機能をほぼ一元管理します。DRF [29、35、36、66]はMesos用に最初に開発されました。代わりに、Borgは優先度とアドミッションクォータを使用します。Mesosの開発者は、投機的なリソースの割り当てと回収を含むようにMesosを拡張し、[69]で特定された問題のいくつかを修正するという野望を発表しました。
YARN [76]は、Hadoopを中心としたクラスターマネージャーです。各アプリケーションには、中央のリソースマネージャーと必要なリソースをネゴシエートするマネージャーがあります。これは、2008年頃からGoogle MapReduceジョブがBorgからリソースを取得するために使用していたスキームとほぼ同じです。YARNのリソースマネージャーは最近になってフォールトトレラントになりました。関連するオープンソースの取り組みとして、Hadoop Capacity Scheduler[42]があります。これは、キャパシティ保証、階層型キュー、エラスティック共有、および公平性を備えたマルチテナントサポートを提供します。YARNは最近、複数のリソースタイプ、優先度、プリエンプション、および高度なアドミッションコントロールをサポートするように拡張されました[21]。Tetrisの研究プロトタイプ[40]は、makespan対応ジョブパッキングをサポートしています。
FacebookのTupperware [64]は、クラスター上のcgroupコンテナをスケジュールするためのBorgのようなシステムです。いくつかの詳細のみが開示されていますが、ある種のリソース回収を提供しているようです。Twitterには、オープンソースのAurora[5]があります。これは、Mesos上で実行されるBorgのようなスケジューラーであり、Borgに似た構成言語と状態マシンを備えた、長期実行サービス用のスケジューラです。
Microsoft[48]のAutopilotシステムは、Microsoftのクラスターに「ソフトウェアのプロビジョニングと展開の自動化、システム監視、および欠陥のあるソフトウェアとハードウェアに対処するために修復アクションの実行環境を」提供します。Borgのエコシステムは同様の機能を提供しますが、ここでの議論は不可能です。Isaard[48]が私たちが順守している多くのベストプラクティスについても概説しています。
Quincy[49]は、ネットワークフローモデルを使用して、数百ノードのクラスターでデータ処理DAGの公平性とデータの局所性を考慮したスケジューリングを提供します。Borgはクォータと優先度を使用してユーザー間でリソースを共有し、数万台のマシンに拡張します。Quincyは実行グラフを直接処理しますが、これはBorgの上に個別に構築されます。
Cosmos[44]は、ユーザーがクラスターに寄付したリソースに公平にアクセスできるようにすることに重点を置いて、バッチ処理に焦点を当てています。ジョブごとのマネージャーを使用してリソースを取得します。詳細はほとんど公開されていません。
MicrosoftのApolloシステム[13]は、短命のバッチジョブにジョブごとのスケジューラを使用して、Borgセルに匹敵するサイズのクラスターで高いスループットを実現します。Apolloは、優先度の低いバックグラウンドワークの日和見的実行を使用して、(場合によっては)複数日にわたるキューイング遅延を犠牲にして、使用率を高いレベルに高めます。Apolloノードは、2つのリソースディメンションのサイズの関数としてタスクの開始時間の予測マトリックスを提供します。スケジューラは、スタートアップコストとリモートデータアクセスの推定値と組み合わせて、衝突を減らすためにランダムな遅延によって調整された配置決定を行います。Borgは、以前の割り当てに関する状態に基づいて配置決定に中央スケジューラを使用し、より多くのリソースディメンションを処理でき、高可用性で長時間実行されるアプリケーションのニーズに焦点を当てています。Apolloはおそらくより高いタスク到着率を処理できます。
AlibabaのFuxi[84]は、データ分析ワークロードをサポートしています。このシステムは2009年から稼働しています。Borgmasterと同様に、中央のFuxiMaster(耐障害性のためにレプリケーションされています)は、ノードからリソースの可用性情報を収集し、アプリケーションからのリクエストを受け入れ、一方を他方に一致させます。Fuxiの増分スケジューリングポリシーは、Borgの同等クラスの逆です。各タスクを適切なマシンセットのいずれかに一致させる代わりに、Fuxiは保留中の作業のバックログに対して新しく利用可能なリソースを一致させます。Mesosと同様に、Fuxiでは「仮想リソース」タイプを定義できます。合成ワークロードの結果のみが公開されています。
Omega[69]は、Borgmasterから永続ストアとリンクの断片を差し引いたものとほぼ同等の、複数の並列の特殊な「垂直」をサポートしています。Omegaスケジューラーは、オプティミスティックな同時実行制御を使用して、中央の永続ストアに格納されている望ましいセル状態と観測セル状態の共有表現を操作します。 Omegaアーキテクチャは、独自のアプリケーション固有のRPCインターフェイス、ステートマシン、およびスケジューリングポリシー(たとえば、長時間実行サーバー、さまざまなフレームワークからのバッチジョブ、クラスターストレージシステムなどのインフラストラクチャサービス、 Google Cloud Platform)。 一方、Borgは「すべてに適合する」RPCインターフェイス、ステートマシンのセマンティクス、およびスケジューラポリシーを提供します。これらは多くの異なるワークロードをサポートする必要があるため、時間とともにサイズと複雑さが増しますが、スケーラビリティはまだ問題になっていません(§3.4)。
GoogleのオープンソースKubernetesシステム[53]は、Dockerコンテナ[28]のアプリケーションを複数のホストノードに配置します。ベアメタル(Borgなど)と、Google Compute Engineなどのさまざまなクラウドホスティングプロバイダーの両方で実行されます。Borgを構築した同じエンジニアの多くが積極的に開発しています。Googleでは、Google Container Engine [39]というマネージドサービスを提供しています。次のセクションでは、Borgでの教訓がKubernetesにどのように適用されるかについて説明します。
ハイパフォーマンスコンピューティングのコミュニティには、この分野での長い伝統があります(例: Maui, Moab, Platform LSF [2、47、50])。ただし、規模、ワークロード、フォールトトレランスの要件は、Googleのセルの要件とは異なります。一般に、このようなシステムは、保留中の作業の大きなバックログ(キュー)を保持することにより、高い使用率を実現します。
VMware [77]などの仮想化プロバイダーおよびHPやIBM [46]などのデータセンターソリューションプロバイダーは、通常O(1000)マシンに拡張できるクラスター管理ソリューションを提供します。さらに、いくつかの研究グループは、特定の方法([25、40、72、74]など)でスケジューリング決定の品質を改善するシステムのプロトタイプを作成しました。
最後に、先ほど示したように、大規模なクラスターを管理する上で重要なもう1つの部分は、自動化と「オペレーターのスケールアウト」です。[43]は、オペレーターごとに多数のマシンを実現するために、障害時のための計画、マルチテナンシー、ヘルスチェック、アドミッションコントロール、および再起動がどのように必要かを説明しています。Borgの設計哲学は似ており、オペレーター(SRE)あたり数万台のマシンをサポートできます。
ねむい
