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

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

内容来自

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

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 のメモリを必要とし、1 つのノードに残り 1GB がある場合、この 1GB のメモリをそのタスクに割り当てると、ノードがもう 1GB のメモリを解放するのを待たなければなりません。この方式は「incremental placement」と呼ばれ、Hadoop YARN はこの増分リソース割り当て方式を採用しています。
一方、タスクに対して残りのノードのメモリが 2GB を超えるノードを選択し、他は考慮しない場合、これは「all-or-nothing」と呼ばれ、Mesos と Omega はこの方式を採用しています。

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

まとめ#

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

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

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

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

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

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