分散型リソース管理とスケジューリング

分散型リソース管理とスケジューリング#

内容来自

極客時間コラム:《分散型技術原理とアルゴリズム解析》

Google クラスター管理システム Omega 解析

分散型アーキテクチャ#

集中型構造#

1 台または複数のサーバーで構成される中央サーバーがあり、システム内のすべてのデータは中央サーバーに保存され、システム内のすべての業務も中央サーバーによって処理され、中央サーバーがリソースとタスクのスケジューリングを統一して行います。

Google Borg
Kubernetes
Mesos

非集中型構造#

サービスの実行とデータの保存が異なるサーバークラスターに分散され、サーバークラスター間はメッセージ伝達によって通信と調整を行います。集中型構造に比べて、非集中型構造は特定のコンピュータクラスターの負荷を軽減し、単一障害点やボトルネックの問題を解決しつつ、システムの同時実行性を向上させ、大規模クラスターの管理に適しています。

Akka クラスター
Redis クラスター
Cassandra クラスター

スケジューリングアーキテクチャのモノリシックスケジューラー#

モノリシックスケジューラーの特徴は、リソースのスケジューリングとジョブの管理機能がすべて 1 つのプロセスで完了することです。オープンソース界の典型的な代表はHadoop JobTrackerの実装です。

欠点
拡張性が低い：まず、クラスターの規模が制限され、次に、新しいスケジューリング戦略を既存のコードに統合することが難しいです。例えば、以前は MapReduce ジョブのみをサポートしていたが、今はストリーミングジョブをサポートする必要があり、ストリーミングジョブのスケジューリング戦略をモノリシックスケジューラーに組み込むのは非常に難しい作業です。

最適化案
各スケジューリング戦略を別々のパス（モジュール）に配置し、異なるジョブは異なるスケジューリング戦略によってスケジュールされます。この方法は、ジョブの量とクラスターの規模が比較的小さい場合、ジョブの応答時間を大幅に短縮できますが、すべてのスケジューリング戦略が依然として 1 つの集中型コンポーネントにあるため、全体のシステムの拡張性は改善されません。

スケジューリングアーキテクチャのデュアルレイヤースケジューラー#

デュアルレイヤースケジューラーは、簡略化された中央集権型スケジューラーを保持しつつ、スケジューリング戦略を各アプリケーションスケジューラーに委譲します。このようなスケジューラーの典型的な代表は Mesos と YARN です。

デュアルレイヤースケジューラーの役割は次のとおりです：第一層スケジューラーはリソースを管理し、フレームワークにリソースを割り当て、第二層スケジューラーは分散クラスター管理システム内の第一層スケジューラーから割り当てられたリソースを受け取り、タスクと受け取ったリソースに基づいてマッチングを行います。

欠点

各フレームワークは、全クラスターのリアルタイムリソース使用状況を把握できません。
悲観的ロックを使用し、同時実行粒度が小さい
Mesos を見てみると、Mesos のリソーススケジューラーはすべてのリソースを任意のフレームワークにプッシュするだけで、そのフレームワークがリソース使用状況を返すまで、他のフレームワークにリソースをプッシュできません。したがって、Mesos のリソーススケジューラーには実際にはグローバルロックが存在し、これがシステムの同時実行性を大幅に制限します。

スケジューリングアーキテクチャの共有状態スケジューラー#

このスケジューラーは、デュアルレイヤースケジューラー内の集中型リソーススケジューリングモジュールをいくつかの永続的な共有データ（状態）とそれらのデータに対する検証コードに簡略化しました。ここでの「共有データ」とは、実際には全クラスターのリアルタイムリソース使用情報です。典型的な代表には Google の Omega、Microsoft の Apollo、Hashicorp の Nomad コンテナスケジューラーがあります。

共有データを導入した後、共有データの同時アクセス方式がこのシステム設計の核心となります。例えば、Omega は従来のデータベースにおけるマルチバージョンの同時アクセス制御方式（MVCC）を採用しており、これにより Omega の同時実行性が大幅に向上しました。

リソース割り当て方式#

2 つのリソース割り当て方式

incremental placement
all-or-nothing

例を挙げると、あるタスクが 2GB のメモリを必要とし、あるノードに残り 1GB がある場合、この 1GB のメモリをそのタスクに割り当てると、ノードが別の 1GB のメモリを解放するのを待たなければならず、この方式は“incremental placement”と呼ばれます。Hadoop YARN はこの増分リソース割り当て方式を採用しています。
一方、タスクのために残りのノードが 2GB 以上のメモリを持つノードを選択し、他は考慮しない場合、これは“all-or-nothing”と呼ばれ、Mesos と Omega はこの方式を採用しています。

2 つの方式にはそれぞれ利点と欠点があり、all-or-nothingはジョブの飢餓を引き起こす可能性があります（大きなリソース要求のタスクが常に必要のないリソースを得られない）、一方でincremental placementはリソースが長時間アイドル状態になる可能性があり、同時にジョブの飢餓を引き起こすこともあります。例えば、あるサービスが 10GB のメモリを必要とし、現在あるノードに残り 8GB がある場合、スケジューラーはこれらのリソースをそのサービスに割り当て、他のタスクが 2GB を解放するのを待ちます。しかし、他のタスクの実行時間が非常に長く、短期間では解放されない可能性があるため、そのサービスは長時間実行されないことになります。

まとめ#

モノリシックスケジューリング
中央スケジューラーが全クラスターのリソース情報とタスクスケジューリングを管理します。つまり、すべてのタスクは中央スケジューラーを通じてのみスケジュールされます。
このスケジューリングアーキテクチャの利点は、中央スケジューラーが全クラスターのノードリソース情報を持っているため、グローバル最適スケジューリングを実現できることです。しかし、その欠点は、スケジューリングの同時実行性がなく、中央サーバーに単一障害点のボトルネック問題が存在し、サポートされるスケジューリング規模とサービスタイプが制限され、クラスターのスケジューリング効率も制限され、小規模クラスターに適しています。

デュアルレイヤースケジューリング
リソース管理とタスクスケジューリングを 2 層に分けてスケジュールします。第一層スケジューラーはクラスターリソース管理を担当し、利用可能なリソースを第二層スケジューラーに送信します。第二層スケジューラーは第一層スケジューラーから送信されたリソースを受け取り、タスクスケジューリングを行います。
このスケジューリングアーキテクチャの利点は、モノリシックスケジューリングの単一障害点のボトルネック問題を回避でき、より大きなサービス規模とより多くのサービスタイプをサポートできることです。しかし、その欠点は、第二層スケジューラーが全体のリソース情報を部分的にしか観察できないため、タスクマッチングアルゴリズムがグローバル最適を実現できないことです。中規模クラスターに適しています。

共有状態スケジューリング
複数のスケジューラーがあり、各スケジューラーはクラスターのグローバルリソース情報を確認でき、その情報に基づいてタスクスケジューリングを行います。他の 2 つのスケジューリングアーキテクチャに比べて、共有状態スケジューリングアーキテクチャは適用可能なクラスター規模が最大です。

このスケジューリングアーキテクチャの利点は、各スケジューラーがクラスター内のグローバルリソース情報を取得できるため、タスクマッチングアルゴリズムがグローバル最適性を実現できることです。しかし、各スケジューラーがグローバル範囲でタスクマッチングを行えるため、複数のスケジューラーが同時にスケジュールを行うと、同じノードにマッチする可能性が高く、リソース競合や衝突を引き起こすことがあります。

Omega の論文では楽観的ロックメカニズムを通じて衝突を回避できると主張していますが、実際のエンジニアリング実践では、リソース競合の問題を適切に処理しない場合、リソース競合が発生し、タスクスケジューリングが失敗する可能性があります。この場合、ユーザーはスケジューリング失敗のタスクを処理する必要があり、再スケジューリングやタスクスケジューリング状態の維持などを行う必要があり、タスクスケジューリング操作の複雑さがさらに増します。

まとめ分析は以下の表に示します