夢とガラクタの集積場

落ちこぼれ三流エンジニアである管理人の夢想=『夢』と、潰えた夢=『ガラクタ』の集積場です。

Apache Mesosのアーキテクチャ

こんにちは。

とりあえず前回Apache Mesosの環境構築は出来たのですが構造がさっぱりだったため、
一度アーキテクチャ資料を読んでみます。
https://github.com/apache/mesos/blob/master/docs/Mesos-Architecture.md
=======

1.Mesosの基本構造

下記の図はMesosの主要なコンポーネントを示したものである。

MesosはMasterデーモンと各クラスタ上のサーバで実行されるSlaveデーモン、
後はSlaveノード上で実行されるMesosアプリケーション(Frameworksとも呼ばれる)から構成される。

Masterデーモンはアプリケーション間でのきめ細やかなリソース(CPU、メモリ等)の共有を可能にし、リソース要求に応える。
各リソース要求は以下のようなリストから構成される。
.
Masterデーモンは各アプリケーションに対してどれだけのリソースを割り振るかを与えられたポリシーに従い決定する。
ここで、「ポリシー」にはFair Sharing、Strict Sharing等が提供されている。

様々なポリシーセットに対応するために、Masterデーモンはプラグイン機構を備え、
新たな割り当てモジュールを追加することが容易なモジュラー型アーキテクチャを採用している。

Mesos上で実行されるアプリケーションは以下の2つの要素で構成されている。
(尚、下記の要素の詳細についてはApp/Framework開発ガイドを参照のこと。)
・Scheduler
Masterデーモンに対して必要になるリソース要求を登録する。
・Executor
Slaveノード上で起動し、アプリケーションのタスクを実行する。

Masterデーモンが各アプリケーションに対してどれだけのリソースを割り振るかを決めると同時に、
各アプリケーションのSchedulerは提供されたリソースの内どれを使用すかを決定する。
アプリケーションが提供されたリソースを受領した場合、
アプリケーションはMesosに対してどのようなタスクを実行したいかの実行情報を渡す。
Mesosはアプリケーションから受け取った実行情報を基にSlaveノード上でタスクを起動する。

2. Mesosを用いたリソース要求/応答の例

以下の図はアプリケーションがどのようにしてタスクを実行するかの例を示したものである。

#図と一致させるために以後はアプリケーションをFrameworkと呼称します。

図の流れを説明する。
1.Slave1は自分が4CPUと4GBのメモリを利用可能であることをMasterデーモンに対して通知する。
Masterデーモンはリソース配分ポリシーを実行し、Framework1に対してすべての利用可能なリソースを割り振ることを決定する。

2.MasterデーモンはSlave1が4CPUと4GBのメモリを利用可能であることをFramework1に通知する。

3.Framework1のSchedulerはMasterに対してSlave上で実行したい2個のTaskの情報について通知する。
1タスク目は2CPU&1GBメモリ、2タスク目は1CPU&2GBメモリを必要とする旨を通知する。

4.最終的に、MasterデーモンはSlave1に対してタスクを送信し、Executorに適切なリソースを割り当て、2個のタスクを起動させる。
その状態で1CPU&1GBメモリが残っているため、リソース配分モジュールはFramework2に対して割り振りを行うこととなる。

リソース配分モジュールはタスクが実行完了し、リソースが解放されたら再度配分処理を実行する。

Mesosが提供する「薄い」インタフェースは各Frameworkが個別に拡張することが可能となっている。
だが、ここで1つの疑問が残る。
「各Frameworkには制約が存在するが、Mesosは個々のFrameworkの制約を知らなくてもこれらのFrameworkを満足させられるのか?」
例えば、MesosがFrameworkが要求するデータがどこに保存されているかをわからないままデータ局所性を満たせるのか?

Mesosはこれらの疑問に対してはFramework側がリソース要求を却下可能とすることで対応している。
FrameworkはMesosから受け取ったリソース配分が自分自身の制約を満たさない場合却下し、満たす場合だけ受領する。

尚、私たちは遅延スケジューリングと呼ばれるシンプルなポリシーを確立している。
これはFramework側が入力データを格納するノードを取得までの待ち時間を一定時間許容するもので、
これを利用することでFramework側のデータ局所性をほぼ最適な状態で満たすことが出来る。
======
・・・と、大体どんな感じかはわかりましたね。
ですが、Mesos上で動作するFrameworkがどのような挙動を示すかの概要についても確認しておきたいため、
Framework開発ガイドか、論文の一部をこの後読んでみようと思います。
どちらにするかは・・・とりあえず、両方見てみてからで^^;

それでは。