Apache Mesosの論文メモ
こんにちは。
前回でApache Mesos自体の機構は大体わかりました。
そのため、次は論文を読んでみようとしたのですが、Sparkの時と違い、概要とポイントさえわかっていれば
今後特に問題にならないため、流し読みしてポイントだけまとめてみました。
読んだ論文は以下です。
「Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center」
（http://mesos.berkeley.edu/mesos_tech_report.pdf）
では、読んでみて重要だと思ったり、Mesos自体を理解するのに有用だと思った内容を挙げます。
一応、流れとして読んでいけばわかりやすいものにはなっているはず。
尚、Mesosがどんなものか、という前回の投稿を読んだ上での内容になっています。
＝＝＝＝＝
Mesosが開発された背景は大規模クラスタ上で分散システムを運用する際、リソースの利用効率が非常に悪いということ。
当初は仮想マシン群上で複数の分散システムを運用していたが、
仮想マシンという単位で静的にリソースを区切るのは個々のアプリケーションが要求するリソースの粒度より荒く、効率が悪い。
加えて静的にリソースを区切った結果データ局所性を満たすのも困難となった。
Mesosを開発するにあたって対処する必要があったメイン課題は以下の３つ。
１．幅広い分散アプリケーションに対する対応
２．万単位のマシンに対するスケーラビリティ
３．リソース配分のスケジューラの高耐障害性＆高可用性確保
Mesosは当初マスターとなるスケジューラが能動的にリソースを配分することを考えていたが、
「各アプリケーションが管理ＡＰＩを持つことが前提」「そもそも今開発途上のアプリケーションもある」
「各アプリケーションは自前でスケジューラを持っており、それを各々置き換えるのは困難」という理由により断念。
Mesos側のAPIを公開し、アプリケーション側でMesosに対するリクエストを出す方針に変更になった。
結果、アプリケーションをMesos上で運用する際にはアプリケーション側でスケジューラの実装が必須となったが、
Mesos自体は幅広いアプリケーションに対応可能になった。
尚、Mesosは10000行程のC++コードで実装され、
ZooKeeperによる冗長化を込みで仮想50000ノードまでスケールすることの確認を行っている。
Mesosは以下の狙いを持って設計を行っている。
１．アプリケーション側にシンプルなAPIを公開し、リソースの管理を可能とする
２．リソースの管理／コントロールはアプリケーション側に任せる
→ 結果、アプリケーション側は最適化した管理が可能になり、Mesos側はシンプルさが保たれる
Mesosにおけるリソースの分離はLinuxではLinuxコンテナ、SolarisではSolaris Projectsを用いて
行っているが、これはプラグイン機構化してある。（現状対応しているのはLinux、Solaris、Mac OS-X）
分離／配分可能なリソースはCPU、メモリ、ネットワーク帯域、ディスクIO。
耐障害性確保のための方針として、以下の対処を行っている。
１．Slaveノードとアプリケーションとやり取りするメッセージから内部状態を復旧可能
２．ZooKeeperによるMasterノードのホットスタンバイ
Mesosにおいてはスケジューリングは個々のアプリケーションが行っており、分散スケジューリングを行う形になっている。
だが、そのために以下のような制約も発生している。
１．タスクの管理が断片化され、必ずしも最適にはならない。特に、大きなタスクが大量に存在する場合
２．アプリケーション同士に依存性がある場合、扱えない
３．Mesosを用いたスケジューリングは一部複雑な個所があり、それを理解しないと扱えない
Mesosの上でジョブを実行させた場合、Mesosを使わなかった場合に比べて、
レスポンスタイムで4%前後のオーバーヘッドが発生する。
（MPIジョブが50.9[s]→51.8[s]、Hadoopジョブが160[s]→166[s]）
＃ただ、より多くのジョブを動作可能になるためリソースは有効活用できる模様。
＝＝＝＝＝
と、上記のような感じでした。
実装の詳細（今回ここには載せていません）あたりを除けばそれほど目新しい情報があるわけではありませんでした。
もちろん、詳細まできちんと読めば話は違うとは思いますが、
Mesosをとりあえず扱う分にはこれで十分そうです。
では、次はSparkのローカル実行を行い、それができたらMesosクラスタ上での動作・・・となりますね。
