Apache Mesos だよ〜

これは、 Distributed computing (Apache Hadoop, Spark, ...) Advent Calendar 2016 - Qiita の13日目の記事である。

AMPLab発のなかでも屈指の地味さを誇る、データセンタースケジューラとかデータセンターOSと言われるソフトウェア、 Apache Mesos を紹介しよう。この記事も5分ほどで読めるはずだが、その5分が惜しい人は 忙しい人の5分で分かるMesos入門 - Mesos って何だ? をご覧いただきたい。はい、なんというか、非常にわかりやすい。要するに、Mesosを利用するプログラムはMesos APIを叩いていろんなタスクを分散環境で起動、管理できるようになっているわけだ。これ以上のMesosそのものの紹介はもうあちこちでされているので、ここでは違った角度から紹介したい。

  • 他製品との比較
  • 個人の感想
  • 海外のコミュニティ
  • 日本での取り組み

A benevolent social hack

他製品との比較

機能や利用目的がもっとも似ているのは、Apache Hadoop YARN や、 Google の Borg である。ていうか、シリコンバレーではMesosを紹介するときに「GoogleのBorgみたいなもんだよ」と実しやかに言われていたそうである。Borg、オプソでもねーのに論文なんか読んでられねーよっていう人は Borg Paper 感想 - steps to phantasien をざっと読んでいただければ何となく分かるのではないかと思う。MesosとYARNの比較は Hadoop YARNとApache Mesosの違いって何? - 夢とガラクタの集積場 という記事があるが、ちょっと内容が古いのでいくつかアップデートしておこうと思う。

  1. YARNはJava, MesosはC++ 、かわってない
  2. 8日目の記事にもあるとおり、YARNはCPUもリソースとして扱えるようになった。一方でMesosは従来のCPU, RAMに加えてディスク容量、GPU数、ポート番号を標準のリソースとして扱えるようになった。さらに、任意のリソースも追加で設定できるようになった ( Apache Mesos - Attributes and Resources )
  3. YARNは3.0でDockerをサポートするようになるらしい。一方MesosはLXC実装を削除し、独自のコンテナ実装上でDockerイメージおよびAppCイメージをサポートしている。OCIイメージのサポートも開発が進んでいるようだ ( [MESOS-5011] Support OCI image spec. - ASF JIRA )
  4. リソースの要求モデルは…変わっていない。YARNはリクエストベースだが、MesosはResource Offerという仕組み。
  5. 今日のmasterでYARNは17万行(ただし hadoop-commonが35万行)、Mesosはレポジトリ内だけで35万行。これは結局「Hadoopとは何なのか」という古くて新しい問題に帰着するのではないか。
  6. YARNは自動的にデータ局所性をサポート…ってどういうことなんだろう?アプリケーションが近い場所にデプロイされるってことかな?そもそもMesosはデータ持たないんだが…いちおう、Mesosは1.0 からKubernetesのPods用にTask Groupというのが実装されて、複数のコンテナを同じノードにデプロイして生死を共にさせることができるようになっている。
  7. ドキュメントは…わたしはYARNのドキュメントは追ってないが、半年前はちょっとお察しであった。変化の速いソフトウェアにありがちなことなので仕方がないだろう。一方、Mesosのドキュメントは基本的な考え方だけきっちり書くようにしてあって、変化に強いドキュメントだと思う(細かいところはコード見ろ、MLで訊けもという)。
  8. YARNも3.0でより広範なアプリケーションをサポート(Native Service? というやつ)しようとしているらしい。一方MesosはWindows Serverで動くようにもなった(ホントに動くのかね…)。
  9. オマケ: HadoopはCDHやHDPなどのディストリビューションあってのものだというのはその通りで、Mesosはそれがなくて不便だったのだけど、最近はDC/OSというのが出ていて、この上でHadoopでもCassandraでも何でも便利に動くようになっているらしい。

コード量比較

Mesos

$ git clone git://github.com/apache/mesos && cd mesos
$ find include src -type f | egrep "(pp|js|java|py|sh)$" |  xargs wc
(snip)
    1056    3681   30466 src/zookeeper/group.cpp
     710    1885   17320 src/zookeeper/zookeeper.cpp
  351467 1067690 11037544 total
$ git log -1 -n 1
commit ea45930db15143ca25ef114a5cb68f86af2d1eb7
Author: Vinod Kone <vinodkone@gmail.com>
Date:   Mon Dec 12 17:07:58 2016 -0800
(snip)

YARN

$ git clone https://github.com/apache/hadoop
$ find include src -type f | egrep "(pp|js|java|py|sh)$" |  xargs wc
(snip)
      26     152     998 ./hadoop-yarn/hadoop-yarn-ui/src/main/webapp/tests/unit/utils/sorter-test.js
      62     256    2350 ./hadoop-yarn/shellprofile.d/hadoop-yarn.sh
  174426  566283 6884187 total
$ git log -1
commit 754f15bae61b81ad3c2e3f722d1feaebf374e2c4
Author: Mingliang Liu <liuml07@apache.org>
Date:   Mon Dec 12 17:36:52 2016 -0800

    HDFS-11226. cacheadmin, cryptoadmin and storagepolicyadmin should support generic options. Contributed by Brahma Reddy Battula

個人の感想

Mesosにはいくつか設計で筋のよい点があって、

  • アプリケーションの状態を管理しない(冗長化フレームワークとかアプリでやってね)
  • 最低限のことしか保証しない(タスクの起動、状態遷移、最終的な回収、etc)
  • プリミティブで切れのよいAPI(Resource OfferやEvent streamなど)
  • たいていの故障では、システム全体が落ちることはまずない

あたりだ。順に説明していきたい。

まず、Mesosを利用するのはフレームワークという仕組みで、Mesosを利用するMarathonとかユーザー手製のフレームワークとかがある。MesosのScheduler APIを使っている限り、これらの状態や永続データをMesosが管理することは基本的にない。非常に原始的な永続化機能として、Persistent VolumesやReplicated Logがあるが、これは永続化する仕組みの典型的なトレードオフ(データ量 vs 耐障害性/可用性 vs 性能)のどれかを正しく選んでねというに留まっていて、「ここにとにかく何でも突っ込んでおけばOK!」ということにはならない。こういう設計思想は、分散システムとかコンピュータの中身とトレードオフを正しく理解している人からしか出てこない。

当然、始めからできることを限定しているので、難しいことはやらない。ひとつのことを上手くやるというやつである。Mesosが保証しているのは、Masterの可用性 *1の範囲でクラスタ全体の動作保証だ。それから、いくつかLinuxの機能を使いながらタスクのIsolationや最終的なタスクの回収、フレームワーク間でのDRFに基づいたFairnessなどだ。

それから、いろいろなAPI呼び出しなどは基本的に at-most-once セマンティクスであり、成功するまで利用側がリトライするものだ。Mesosからの通知は「いつでも欠落するよ〜、自分でちゃんと状態確認してネ」といった具合である。これは、フレームワーク側やアプリ側もいつでもノードが落ち得るわけだから、メッセージの通知側が配送保証しても意味がないという割り切りである。

YARNとの比較でいうと、感想を聞いた感じでは、YARNは「とにかく起動に時間がかかる」ということのようだ。重量級のフレームワークで、MapReduceやSparkを動かすのに多くのパスを通っているのだから仕方がない。一方でHadoop系のプロダクトとの相性の良さは折り紙つきだ。3.0ではサービスディスカバリやら何やら、何でも入りになっていきそうな感じである。

一方でMesosはUnix的なミニマリズムが根底にあって、ちょっと何か動かしたいときはサクッと動く(個人の感想です)。ただしこれは拙作のMesos フレームワーク Retz をうまく使ったときであり、他のフレームワークは目的が違うものも多く一概にはいえない。それでも、Retzはそういうレスポンスのよさに気を遣って開発していて、コンテナで動かすときは本当に1秒〜数秒でサクッと起動できるように作ってある(もちろんコンテナがFetch済とか、いろいろ条件はつくが)。

海外のコミュニティ

MesosCon Europe / US / Asia

MesosはLinux Foundationがバックについているので、年三回、世界3箇所でMesosConというカンファレンスが開催される。もちろん最大のものは MesosCon North America だが、 MesosCon Europe もそれなりに盛り上がっているようだ。

MesosCon Asiaはまだ一回しか開催されていないが、シングルトラックながら二日間もずっと話が続いていて、中国やインドの大規模ユーザーがボコボコいるだけの勢いを感じさせる。日本みたいな老人の島国と違って、人口がモリモリ増えている大国は勢いが違う。わたしも何か引っさげて登壇したいところであるが、いかんせん海外のカンファレンスはハイレベルである。今みたらAsiaはスライドもビデオもあまり公開されていないっぽいので、やはり一度行ってみる必要があるのかしら。。。

主要プレイヤー

コミット数やMLの参加量などをみると、 Mesosphere, Twitter, Apple, IBM などが大きな割合を占めていることがわかる。それぞれ紹介しておこう。

  • Mesosphere - 最初の開発者Benjamin Hindmanが設立したMesosとDC/OSの開発会社
  • Twitter - 最初の企業ユーザー。以降、多くのエンジニアがMesosphereに移籍した模様
  • Apple - Siriのバックエンドに採用 *2
  • IBM - 外から観測しているだけだと Powered-by のページにも入っていないし、よくわからない。Linux Foundationからの流れから使っているのか、それとも中で使っているのかな?

また、MSとHPEがMesosphereに$73.5Mという巨額の投資をしている。MSはAzure Container Serviceを出しているので分かりやすいが、HPEは果たしてどういうつもりなのか興味深い。OpenStackを手放しながらクラウドではMSと協業するということだが、Mesosにどう関わっていくのか(それとも関わらないのか)ちょっと想像つかなくて興味深い。

日本での取り組み

Mesosの論文が出たのは2010年で、2011年にはいちど目を通していた(気がする、内容は忘れた)が、日本で最初に観測していたのは3年ほど前の sonots さんの記事と、 yuukiさんの記事だ。論文の話とはちょっとコンテキストが違っていて、いわゆるウェブサービス on Docker の文脈でどうクラスタにアプリケーションをデプロイしていくかという問題に対して、パーツのひとつとして取り上げられている。当時はAnsibleやChefをEC2上で使うのが一般的で、Kubernetesもなかったのでオンプレやホスティングでどうすんの〜まさかOpenStackですか?!という残念な状況だったからMesosが多少期待されたのも仕方がないと思う。それから1年くらいして 第1回 Apache Mesos勉強会 - connpass も開催されたようだ。

で、時は流れて2016年、私が適当に紹介したのが最初の、新しい文脈ではないかと思う。つまりApache Sparkも動くし、他のいろんなアプリもひとつのクラスタ上で仮想化なしでAPI化させていろいろな大規模データ処理を動かすことができる便利なシロモノという文脈だ。MapReduceはたぶんかなり頑張らないと動かない(というか、実装があるというだけでオドロキ)。

というわけで Mesos勉強会 - connpass を開催して、200人近く人が集まるという驚異の事態になった。これはいけるかもしれない、 Mesosソースコードリーディング - connpass というのも始めてみた。第1回が明後日開催されるので、さらに中身を詳しく追ってみたい方は参加していただくとよい。

*1:Quorum/Paxosと、ZooKeeperが正しく動作している限り

*2:一方、某社はEC2で頑張った