More Related Content Similar to 大規模分散システムの現在 -- Twitter (20) More from maruyama097 (20) 大規模分散システムの現在 -- Twitter2. Most of our systems are big “Future transformers”
- Marius Eriksen
3. predictable performance is difficult to achieve. In a predictable system,
worst-case performance is crucial; average performance not so much.
... predictable performance is difficult to achieve.
In a predictable system, worst-case performance
is crucial; average performance not so much.
- Peter Schuller
4. predictable performance is difficult to achieve. In a predictable system,
worst-case performance is crucial; average performance not so much.
It’s with the intent of modeling a world where the
Twitters, Googles, and Facebooks are no longer
superpowers… just power
- Aurora
11. 2010年 - 2011年 - 2012年
2010年:タイムラインを、独自のサービス・システムに移
行開始する。 ruby on railsから離れるためのプロジェク
トgodwit開始。サービス・インフラの共有化に取り組む。
2011年:インフラの整備進む。無数のアプリのポーティ
ング。TFE(HTTP Proxy)オンライン稼働。
2012年:TFE が通年で全てのトラフィックを扱うようにな
る。ますます多くのAPIのトラフィックが新しいシステムで
動くようになる。
14. 2013年 Twitter stack
Finagle
Ostrich
Zipkin
Mesos
Iago
ZooKeeper
Scalding
jvmgcprof
http://goo.gl/Ax9LVw
15. 2013年 Finagle
Twitterのサービスの中心部分には、Finagle ライブラリ
ーがある。RPCシステムの基本的な土台の部分を抽象化
することによって、Finagleは、サービス開発者が扱わな
ければいけなかった複雑さを大幅に軽減した。
それは、分散システムの低レベルの詳細にこだわらねば
いけなかったかわりに、アプリケーションに固有のビジネ
ス・ロジックを書くことに集中することを可能にした。
最終的には、Webサイト自身も、運用を効率化でも、
HTMLを書き出すのに必要なデータの取り出しにも、この
サービスを使っている。Twitterでは内部のサービスは
Thriftを使っているのだが、Finagleでは、Protocol
bufferやHTTPのような他のプロトコルもサポートしている
。 http://goo.gl/Ax9LVw
16. 2013年 Mesos
Mesos は、自分を次のように規定している。
「分散アプリケーション、すなわち、フレームワークをまた
いで、効果的なリソースの分離と共有を提供するクラスタ
ー・マネージャー」
Mesosの中心プロジェクトは、オープンソースのApache
インキュベーター・プロジェクトである。Mesosの上に、例
えば、StormやHadoopといった特別の技術を扱うスケ
ジューラーを走らせることができる。そのアイデアは、同じ
ハードウェアは、複数の目的のために利用でき、リソース
の浪費を低減できるというものである。
http://goo.gl/Ax9LVw
25. シーケンシャルな処理の特徴
h = fn ・ ... ・ f2 ・ f1
関数の合成で、シーケンシャルな処理が記述できたのだ
が、それだけではシーケンシャルな処理の特徴を捉えたこ
とにはならない。そこには、次のような問題がある。
f1の処理が終わるまで、f2の処理は待たされる。
f2の処理が終わるまで、f3の処理は待たされる。
・・・
fnの処理は、それ以前のすべての処理が終わるまで待た
される。
h = fn ・ ... ・ fi ・ ... ・ f2 ・ f1
待たされるだけではない。途中の処理 fi の一つでも失敗
すれば、その時点で、全体の処理 h は、失敗する。
待つことや、エラーの処理に、うまい方法はないのだろう
か?
31. Futuresの値の取得 get
Futureは、ある種のコンテナーである。 trait Future[A]
それは、empty, full, failedの三つの状態を取る。我々
は、それを待つことができる。その値は getで取得できる。
val f: Future[A]
val result = f()
f.get() match {
case Return(res) => ...
case Throw(exc) => ...
}
ただ、いつ get するのか? せっかく非同期にしたのに、
get の利用は、あまり意味がない
32. scala> import com.twitter.util.{Future,Promise}
import com.twitter.util.{Future, Promise}
// すでに解決済みのFutureを作る。
scala> val f6 = Future.value(6)
f6: com.twitter.util.Future[Int] = com.twitter.util.ConstFuture@c63a8af
scala> f6.get()
res0: Int = 6
// 失敗となるFutureを作る
scala> val fex = Future.exception(new Exception)
fex: com.twitter.util.Future[Nothing] = com.twitter.util.ConstFuture@38dd
ab20
scala> fex.get()
java.lang.Exception
... stack trace ...
Futureのgetを実験する
33. // 解決されていないPromiseを作る
scala> val pr7 = new Promise[Int]
pr7: com.twitter.util.Promise[Int] = Promise@1994943491(...)
scala> pr7.get()
...console hangs, waiting for future to resolve... Ctrl-C Execution
interrupted by signal.
scala> pr7.setValue(7)
scala> pr7.get()
res1: Int = 7
scala>
Futureのgetを実験する
40. 非同期型のシナリオ
getThumbnail のコード
def getThumbnail(url: String): Future[Webpage] = {
val promise = new Promise[Webpage]
fetch(url) onSuccess { page =>
fetch(page.imageLinks(0)) onSuccess { p =>
promise.setValue(p)
} onFailure { exc =>
promise.setException(exc)
}
} onFailure { exc =>
promise.setException(exc)
}
promise
}
これは、よくあるCallback Hellのパターンだ。
44. flatMapで、何ができるか?
拡張:
Seq(1,2,3,4) flatMap { x => Seq(x, -x)}
== Seq(Seq(1,-1)),Seq(2,-2),Seq(3,-3),Seq(4,-4).flatten
== Seq(1,-1,2,-2,3,-3,4,-4)
条件:
Seq(1,2,3,4) flatMap { x =>
if (x%2 == 0) Seq(x)
else Seq()
}
== Seq(Seq(2),Seq(4)).flatten
== Seq(2,4)
Seq[Seq[int]]を、Seq[int]に変える
57. scala> import com.twitter.util.{Future,Promise}
import com.twitter.util.{Future, Promise}
scala> class User(n: String) { val name = n }
defined class User
scala> def isBanned(u: User) = { Future.value(false) }
isBanned: (u: User)com.twitter.util.Future[Boolean]
scala> val pru = new Promise[User]
pru: com.twitter.util.Promise[User] = Promise@897588993(...)
// apply isBanned to future
scala> val futBan = pru flatMap isBanned
futBan: com.twitter.util.Future[Boolean] = Promise@1733189548(...)
scala> futBan.get()
...REPL hangs, futBan not resolved yet... Ctrl-C Execution interrupted
by signal.
scala> pru.setValue(new User("prudence"))
scala> futBan.get()
res45: Boolean = false
scala>
58. シーケンシャルな処理の非同期化
h = fn ・ ... ・ f2 ・ f1
シーケンシャルな処理は、時間やエラーの問題を無視す
れば、h = fn ・ ... ・ f2 ・ f1 のように、「関数の合成」で
モデル化できた。
Futureで非同期化された関数の合成は、flatMapを使う
と次のように簡単に表現でき、かつ、より現実的なシーケ
ンシャルな処理のモデルを与える。
f1 flatMap f2 flatMap ... flatMap fn
67. 単純な Web Crawler
def crawl(url: String): Future[Seq[Webpage]] =
fetch(url) flatMap { page =>
Future.collect(
page.links map { u => crawl(u) }
) map { pps => pps.flatten }
}
(* Apocryphal ほんとかな?)
71. Server
同様に Finagle serverはServiceをネットワークに
“exports”する。serverは、二つの部分を持つ。
1. Serviceを実装した関数:Reqを受け取り、Future[Rep]
を返す。
2. 入ってくるReqをどう“listen”するかの設定。例えば、
HTTPのリクエストを、80番ポートで待つ等。
こうして、Serviceのロジックと、ネットワーク上どのようにデー
タが流れるかの設定は、分離される。
75. Filterは、serviceを変形する。 それらは、service generic な機能
を提供できる。例えば、rate-limitingをサポートすべき複数のサー
ビスがあったとする。一つのrate-limitingフィルターを書けば、それ
をすべてのサービスに適用できる。Filterは、また、サービスを異なっ
たフェーズに分解するのにいい働きをする。
単純なproxyは、次のような形をしているだろう。ここで、
rewriteReq と rewriteRes は、プロトコルの変換を提供する。
class MyService(client: Service[..]) extends
Service[HttpRequest, HttpResponse] {
def apply(request: HttpRequest) = {
client(rewriteReq(request)) map { res =>
rewriteRes(res)
}
}
}
77. Filterは、積み重ねられる。
val timeout: Filter[…]
val auth: Filter[…]
val service: Service[…]
timeout andThen auth andThen service
def andThen[A](g: (R) ⇒ A): (T1) ⇒ A
Composes two instances of Function1 in a new
Function1, with this function applied first.
def compose[A](g: (A) ⇒ T1): (A) ⇒ R
Composes two instances of Function1 in a new
Function1, with this function applied last.
80. Clients
val client = ClientBuilder()
.name("loadtest")
.codec(Http)
.hosts("google.com:80,..")
.build()
client は、 Service[HttpReq, HttpRep] である。
client(HttpRequest(GET, "/"))
81. Servers
val service = { req =>
Future.value(HttpRes(Code.OK, "blah"))
}
ServerBuilder()
.name("httpd")
.codec(Http)
.bindTo(":8080")
.build(service)
95. Data Platform Landscape Map
次の電車の路線図みたいのは、必見。拡大して、よく見て
欲しい。世の中のデータストアの地図だ!!
真ん中右の白いエリアがリレーショナル・データベース、
右下のグリーンのエリアが、Grid/Cacheのエリア。残り
のグレーの部分が、NonSQLのエリア。「エリア」内の「各
駅」が、General Purposeとか、Key Valueとか、
Graphといった「路線」でつながっている。571もある。
https://goo.gl/rQ6XHc
97. Manhattan, our real-time,
multi-tenant distributed
database for Twitter scale
April 2, 2014 By Peter Schuller,
Core Storage Team
https://blog.twitter.com/2014/manhattan-
our-real-time-multi-tenant-distributed-
database-for-twitter-scale
抄訳
101. Low latency: リアルタイムのサービスとして、Titter
の製品は、整合性をもった低遅延を要求する。低遅延の
パフォーマンスを保証するために、Twitter固有のトレー
ドオフを行わなければならない。
Real-world scalability: スケールの変化は、分散
システムでは、普遍的なものである。Twitterは、ある点
でだけスケールできるデータベースではなく、コストの効率
性や運用の容易さを犠牲にすることなく、すべてのメトリッ
ク -- クラスターのサイズ、一秒あたりのリクエスト、データ
のサイズ、地理的な拡大、顧客数 --等において、新しい
高みに成長を続けられるデータベースを必要とする。
Developer productivity: 会社の開発者は、サー
ビスを構築するために必要とされるものすべてを、セルフ・
サービス型のプラットフォームとして、ストレージの技術者
の干渉を必要としないで、蓄積できる必要がある。システ
ムは、彼らから見れば、「いつも動いている」ものである。
108. 整合性のモデル
Twitterのアプリケーションの多くは、 eventually
consistent モデルに、非常によくフィットする。我々は、
ほとんどすべてのユースケースで、整合性より高可用性
を好む。それで、Manhattanを、 coreの部分では、
eventually consistent なシステムとして構築したのは
、自然なことであった。
しかし、データについて、強い整合性を要求するアプリケ
ーションは、常にあり得る。そうしたシステムを構築するこ
とは、多くの顧客を得るために、高いプライオリティがあっ
た。
強い整合性は、opt-inモデルである。開発者は、そのトレ
ードオフをよく知っていなければならない。
109. 整合性の追求
eventually consistent なシステムで整合性を達成す
るためには、我々がレプリカの調停と呼んでいる、要求さ
れたメカニズムが必要になる。このメカニズムは、
incrementalでなければならず、また、常にレプリカ間の
データを調整するプロセスが走っている必要がある。それ
は、ビット落ちやソフトウェアのバグや書き込みの失敗(ノ
ードが長い期間ダウンした)、データセンター間の分離な
どに直面した時に役に立つ。
read-repair
hinted-handoff
110. Storage engines
我々は、現在、三つのストレージ・エンジンを持っている。
seadb: Hadoopからのバッチ処理のデータのための読
み取り専用のファイル・フォーマット。
sstable: 重い書き込み処理のための、ログ構造の
merge treeベースのフォーマット。
btree: 重い読み出し、軽い書き出しのためのbtreeベ
ースのフォーマット。
すべてのストレージエンジンは、ブロック単位の圧縮をサ
ポートしている。
113. Batch Hadoop importing
もともとの、Manhattanのユースケースの一つは、
Hadoopで生み出されるデータ上で、効率的にサービス
を提供する層というものだった。
我々は、顧客がHDFS上に単純なフォーマットのデータセ
ットを作り出すことを可能にする、インポート用のパイプラ
インを構築し、その場所をセルフサービスのインターフェ
ースに指定した。我々のWatcherが、自動的に新しいデ
ータセットをピックアップし、それをHDFSの中のseadbに
変換する、だから、それらは、SSDからでもメモリーからで
も、高速にクラスターにインポートされる。
116. Timeseries Counters service
我々は、Manhattanで、大きな容量を持つ時系列のカウ
ンターを扱う、極めて特殊なサービスを開発した。このサ
ービスを要請した顧客は、一秒あたり数百万のカウンター
・インクリメントを扱うことを必要としていた、我々の
Observability インフラであった。
このスケールのレベルでは、耐久性の課題、インクリメント
の前にそれが警報システムに見えるために必要とされる
遅延の問題、また顧客からのどのような種類の秒以下の
トタフィックのパターンなら耐えられるのかといった問題等
々、様々な事柄でのトレードオフのデザインについて合意
する必要があるのだが、合意に至るまで、我々の技術者
は、演習に駆り出された。
118. Storage as a service
既存のデータベースで我々が見てきた共通の問題は、そ
れが、ユースケースのある特別な集まりに対して、設定さ
れ管理されるようにデザインされていることだった。
Twitterの新しい内部サービスが成長するにつれ、我々
が認識したのは、そうしたことは、我々のビジネスには効
率的ではないということだった。
我々のソリューシンは、storage as a serviceという
ものだ。我々は、エンジニアと運用者のチームに、エンジ
ニアをコントロールする、完全なセルフサービスのストレー
ジ・システムを構築することによって、大きな生産性の改
善を提供してきた。
120. Storage as a service
エンジニアは、彼らのアプリケーションが必要とするもの(
ストレージのサイズ、一秒あたりのクエリー等)を与え、ハ
ードウェアがインストールされスキーマが設定されるのを
待つことなしに、瞬時にストレージの利用を開始すること
ができる。
会社内の顧客は、我々の運用チームが管理するマルチ・
テナントな環境で実行する。セルフサービスとマルチ・テナ
ントのクラスターを管理することは、ある種のチャレンジだ
った。それで、我々は、このサービス層を、第一級の特徴
として扱った。
121. Storage as a service
我々は顧客に、データと処理を、見える形で提供した。
quotaの機能強化とrate制限を組み込んで、エンジニア
が、彼らの定義された制限を超えた時には警告を受け取る
ようにした。我々のすべての情報は、分析と報告のため
Capacity and Fleet Managementチームに、直接送ら
れる。
エンジニアが新しい特徴をローンチすることを容易にするこ
とで、我々が見たのは、実験が活発に立ち上がり、新しい
ユースケースが急速に増えたということだった。これらをう
まくハンドルするために、これらのデータを、コスト分析に
結びつける内部のAPIを開発した。これによって、どのユー
スケースが最もビジネスにコストをかけ、また、どのユース
ケースがおきそうもないかを決定することができた。
130. Mesosとは何か?
数万のノードへのScalability
ZooKeeper を使った、Fault-tolerantなマスターとスレ
ーブのレプリカ管理
Dockerコンテナーのサポート
Linuxコンテナーでの、タスク間のネーティブな隔離
マルチ・リソース (memory, CPU, disk, ports)のスケ
ジューリング
新しいパラレル・アプリケーションを開発するための
Java, Python, C++ APIs
クラスターの状態を見るWeb UI
137. リソース・オファーのプロセス
① Slave 1は Masterに、自分には 4 CPUあって4 GBの
メモリーが空いていると報告する。報告を受けるとMaster
は、Allocation Policy Moduleを呼び出す。
Allocation Moduleは、Framework 1が、利用できる
リソースを求めていると伝える。
② Masterは、Slave 1にこれだけの利用可能なリソースが
あるとFramework 1にリソース提供を申し出る。
③ Framework 1のスケジューラは、Masterに二つのタス
クをSlave 1 で走らせて欲しいと応答する。一つ目のタス
クは <2 CPUs, 1 GB RAM> で、二つ目のタスクは<1
CPUs, 2 GB RAM>でという情報と一緒に。
138. リソース・オファーのプロセス
④ 最後に、Master は、Slave 1 にタスクを送る。それは、
Slave1 の Framework1 の実行エンジンに適切なリソ
ースを割り当てる。こうして、二つのタスクが起動される(
図での、Slave 1の点線で囲まれた部分)。Slave 1の、
1 CPUと 1 GBのメモリーは、アロケートされていないの
で、Framework 2のタスクに使われるかもしれない。
このリソース提供のプロセスは、タスクが終了して、新しいリソ
ースがフリーになった時には、繰り返される。
143. Aurora: Job
Aurora は、Mesos上でjobをスケジュールするために
利用されるMesosのフレームワークである。Mesosは、
個々のtaskを面倒見るのだが、典型的なjobは、数百に
も昇るtaskのレプリカを持つ。Auroraは、Mesosの上
に、jobという抽象の層を提供する。
Auroraのjobは、taskのテンプレートと、そのtaskとほと
んど等しいtaskのレプリカ(”instance id”が違うとか、マ
シンごとにポート番号が違うとか。それ以外は、ほぼ同じ。
)を生成する命令からなる。
いくつのtaskがjobを構成するかは、複雑である。基本的
には、一つのjobは、一つのtaskテンプレートとそのtask
とほとんど等しいtaskのレプリカ(”インスタンス”とか
“shard”と呼ばれることもある)を生成する命令からなる。
144. Aurora: taskとprocess
taskは、一つのコマンドラインの命令(例えば、
my_script.py のような)に対応した、一つのprocess
にすぎないこともある。ただし、taskは、その全てが一つ
のsandbox上で走る沢山の別々のprocessから構成さ
れることもある。例えば、logrotate, installer,
master, slave というような複数のエージェントが協調し
て走ることがある。
こうした時、Thermosが登場する。AuroraがMesosの
Task上でJobの抽象を与えるように、Thermosは、
MesosのTaskの下で、Auroraフレームワークの
executorの一部としてサービスし、Processの抽象を
与える。
149. import sys
import time
def main(argv):
SLEEP_DELAY = 10
# Python ninjas - ignore this blatant bug.
for i in xrange(100):
print("Hello world! The time is now: %s. Sleeping for %d secs" % (
time.asctime(), SLEEP_DELAY))
sys.stdout.flush()
time.sleep(SLEEP_DELAY)
if __name__ == "__main__":
main(sys.argv)
hello_world.py
150. pkg_path = '/vagrant/hello_world.py'
# ファイルの中身に応じて設定を変える。ここでは、バージョン番号に、
# ファイルのchekusumを使う。
import hashlib with open(pkg_path, 'rb') as f:
pkg_checksum = hashlib.md5(f.read()).hexdigest()
# hello_world.py をローカルのsandboxにコピー
install = Process(
name = 'fetch_package',
cmdline = ‘cp %s . && echo %s && chmod +x hello_world.py’ %
(pkg_path, pkg_checksum))
# スクリプトの実行
hello_world = Process(
name = 'hello_world',
cmdline = 'python hello_world.py')
Auroraの設定ファイル
hello_world.aurora
151. # taskの記述
# installとhello_worldをシーケンシャルに実行する。
hello_world_task = SequentialTask(
processes = [install, hello_world],
resources = Resources (cpu = 1, ram = 1*MB, disk=8*MB))
# jobの記述
jobs = [
Service (
cluster = 'devcluster',
environment = 'devel',
role = 'www-data',
name = 'hello_world',
task = hello_world_task
)
]
Auroraの設定ファイル
hello_world.aurora (続き)
155. Jobの生成と実行
aurora job create ...
実際に、我々のjobを走らせる Auroraクライアント・コマン
ドは、 aurora job create である。それは、job keyと、
configファイルを引数に取り、それらで指定されたjobを生
成しそれを実行する。
aurora job create devcluster/www-data/devel/hello_world
/vagrant/hello_world.aurora
job key
Aurora Configuration File
156. job key の構成
job key は、“/” で区切られた四つの部分からなる。四つの部分
は、次のような部分から構成される。
<cluster>/<role>/<environment>/<jobname>
先のコマンドの例で言うと、次のようになる。
devcluster/www-data/devel/hello_world
cluster role environment jobname
157. job keyとjobの一意な指定
Cluster:clusterの名前。
Role:そのslaveマシン上に存在する、ユーザーのアカ
ウント名。
Environment:名前空間。”prod” (製品版)、
“devel”(開発版)、”test” (テスト用) の三つが用意され
ている。
Jobname:job名
二つのjob keyを比較して、四つの構成要素が対応する
要素と、一つでも違っていれば、二つのjob keyは、二つ
の別々のjobを指定していることになる。四つの値が全て
同じであれば、このjob keyは、同一のjobを指定する
158. clusterの定義
このjob keyの指定は、よく見ると、この例では、
*.aurora のAurora設定ファイルが、
jobs = [
Service( ... )
...
]
の中で、Serviceのパラメータに設定されたものと重複し
ている。(jobをTaskに結びつける、task = ... というパ
ラメータを除いては)
それぞれのパラメーターの説明は、これから、おいおいす
ることにして、まず、先頭のclusterは、どのように定義さ
れているのだろうか?
166. Docker Containerizer
Mesos 0.20.0 は、Dockerイメージを含んだtaskの実
行のサポートを追加した。また、Dockerでサポートされて
いるオプションのいくつかを、将来的には追加していく。
ユーザーは、Dockerのイメージを、Task あるいは
Excutor として実行できる。
slaveが、Docker Containerizer を実行可能にするた
めには、containerizerのオプションの一つとして、
”docker”を指定する必要がある。次のように。
mesos-slave –containerizers=docker,mesos
Docker containerizer を持つ、それぞれのslaveには
、Docker CLI client (version >= 1.0.0)がインスト
ールされる必要がある。
169. Docker Containerizerは、
何をしているのか?
Docker Containerizer は、 Task/ExecutorのLaunch
とDestroy呼び出しを、 Docker CLI コマンドへ変換して
いる。
現時点で、 Docker Containerizer はtaskとして起動さ
れた時、次のことをしている。
1. CommandInfo で指定されたファイルをすべて、
sandboxに取り込む。
2. リモート・リポジトリーからdockerイメージを取得。
170. Docker Containerizerは、
何をしているのか?
3. Docker executorは、
dockerイメージを実行し、
sandboxのディレクトリーをDocker コンテナーにマッ
プし、
ディレクトリー・マッピングをMESOS_SANDBOX環境
変数にセット
executorは、コンテナのログをsandboxの
stdout/stderrファイルに流し込む。
4. container exit あるいは、 containerizer destroyで
dockerコンテナーを stop、removeする。
173. プライベート Docker レポジトリー
イメージをプライベート・レポジトリーから実行するために、
ログイン情報を含んでいる .dockercfgをポイントしてい
る uriを含めることができる。 この .dockercfgファイル
は sandboxに引き出されて、 Docker Containerizer
は、HOME環境変数を、このsandboxをポイントするよう
に設定する。それで、dockerのcliは、自動的にconfigフ
ァイルをピックアップできる。
177. Mesosphere DCOS と
Apache Mesos の違い
Mesosphere DCOSは、オープンソースのMesos上に
構築された、商用サポートのあるソフトウェア製品。
コマンドライン、Webインターフェース、パッケージングや
インストールが強化されている。また、技術的なパートナ
ーとのエコシステムも拡大している。
Mesosphere DCOSは、オープンソースではない。ただ
それは、オープンソースのApache Mesos, Marathon,
Chronosに基づいている。
179. A New Kind of Operating
System
Mesosphere データセンター・オペレーティング・システ
ム (DCOS)は、新しい種類のオペレーティング・システム
である。それは、物理サーバー、クラウド・ベースのデータ
センターのサーバーをまたいで、その上で、あらゆるバー
ジョンのLinuxが走る。
Killer Apps User Interface Programmable
Datacenter
181. Mesosphere DCOS
Mesosphere DCOS は、すべてのマシン、VM、クラウド
上のインスタンスを、インテリジェントで動的な共有リソー
スの単一のプールに組織する、新しいタイプのオペレーテ
ィング・システムである。それは、あらゆるバージョンのモ
ダンなLinuxの上で走り、それを強化する。
Mesosphere DCOSは、高可用性と耐障害性を持ち、プ
ライベートなデータセンターでも、パブリックなクラウドの上
でも動く。それは、劇的に、利用率を高め、オペレーション
の複雑さを減少させ、開発者をもっと生産的にする。
Mesosphere DCOSは、Apache Mesosを中心に構成
されている。その分散システム・カーネルは、 UC
BerkeleyのAMP Labで発明され、TwitterやNetflixや
Airbnbのような会社で、大規模に利用されている。
183. Never Fail
Mesosphereは、リソースを再バランスしながら、 走り続
け、失敗したタスクは自動的に再スタートされる。
Optimize Resources
Mesosphere は、それぞれのサーバーに、複数のアプリ
をパックして、リソースの利用を高める。
Operate Automatically
Mesosphereは、クラスターを管理する高度な自動化を
もたらし、オペレーションの時間とお金を節約する。
Develop Quickly
Mesosphereで、開発者は、サーバーのことを考えずに、
コードだけを考えればいいので、ビルドとデプロイを高速
に行うことができる。
186. PaaS and
Long Running Big data processing Batch scheduling Data storage
“Framework on Mesos” https://goo.gl/1oDvTc
187. Mesos利用の拡大
-- Mesosphere Blog タイトルから --
The Mesosphere Datacenter Operating System
is now generally available
Get Mesos-DNS up and running in under 5
minutes using Docker
Building real-time data flows with Kafka on
Mesos
Cassandra on Mesos: Performance +
Reliability
Deploying Kubernetes on Mesos
It’s easier than ever to scale like Google
without being Google
https://mesosphere.com/blog/
188. Mesos利用の拡大
-- Mesoshere Blog タイトルから --
Launching thousands of Docker containers
with DCOS on Azure
Join the DCOS public beta on Microsoft Azure
and AWS
Apple details how it rebuilt Siri on Mesos
Making Kubernetes a first-class citizen on the
DCOS
MySQL on Mesos: today’s database meets
tomorrow’s datacenter
https://mesosphere.com/blog/
192. Google, Borgの情報公開
今年の4月、Googleは、Borgの情報を初めて公開した。
“Large-scale cluster management at Google
with Borg” https://goo.gl/aN03bI
この発表に対して、Auroraのアーキテクトのコメントを含
む記事が、出ている。“Google Lifts the Veil on
Borg, Revealing Apache Aurora’s
Heritage”http://goo.gl/Nv8ZIQ
僕には謎だったBorgの名前の由来だが、それは、Star Trekに
登場する「宇宙種族のひとつ。蜂や蟻をモチーフにした社会的集
合意識を持っているとされ、中央制御装置としてのQueenがいる
」とのこと。Facebookで友人から教えてもらった。納得。
193. Google Borg
Google’s Borg system
is a cluster manager
that runs hundreds of
thousands of jobs,
from many thousands
of different applications,
across a number of
clusters each with up
to tens of thousands of
machines
数十万のジョブ
数千のアプリケーション
数万のマシン
198. $ vagrant ssh
Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic
x86_64)
Documentation: https://help.ubuntu.com/ Welcome to your Vagrant-
built virtual machine.
Last login: Fri Jan 3 02:18:55 2014 from 10.0.2.2
vagrant@precise64:~$ aurora job create devcluster/www-
data/devel/hello_world /vagrant/hello_world.aurora
INFO] Creating job hello_world
INFO] Response from scheduler: OK (message: 1 new tasks pending
for job www-data/devel/hello_world)
INFO] Job url: http://precise64:8081/scheduler/www-
data/devel/hello_world
...
...
実行結果
205. jobを殺す
aurora job killall ...
次のようにして、投入したjobを殺せる。
vagrant@precise64:~$ aurora job killall
devcluster/www-data/devel/hello_world
INFO] Killing tasks for job: devcluster/www-
data/devel/hello_world
INFO] Response from scheduler: OK (message:
Tasks killed.)
INFO] Job url:
http://precise64:8081/scheduler/www-
data/devel/hello_world
vagrant@precise64:~$
209. Attribute Name Type Description
name String プロセス名(必須)
cmdline String コマンドライン(必須)
max_failures Integer プロセス失敗最大数(Default: 1)
daemon Boolean
真の時、daemonプロセスである
(Default: False)
ephemeral Boolean
真の時、ephemeralプロセスである
(Default: False)
min_duration Integer
プロセスが再起動する間の最小継続
秒 (Default: 15)
final Boolean
真の時、このプロセスは、最後に走る
finalizingプロセスである (Default:
False)
211. param_ type description
name String
プロセス名(必須)
(Default: processes0.name)
processes
List of Process
objects
このtaskに結びつけられているプロセス
のリスト (必須)
constraints
List of
Constraint
objects
プロセスを制約しているconstrainオブ
ジェクトのリスト
resources
Resource
object
リソースの詳細情報 (必須)
max_failures Integer
失敗したとみなされるプロセスの失敗の
最大回数 (Default: 1)
max_concurrency Integer
並列プロセスの最大数 (Default: 0, 並
列プロセス数に制限なしの意)
finalization_wait Integer
finalizingプロセスに割り当てられた時
間の総量。秒で。 (Default: 30)
213. name type description
task Task このjobにバインドするTaskオブジェクト。必須。
name String Job名。 (Default: taskの属性名から継承)
role String Job roleのアカウント。 必須。
cluster String
このjobが、その中でスケジュールされている
Cluster。必須。
environment String
Job環境。defaultは devel。prod, devel,
test, staging<number>のうちのひとつでな
ければならない。
contact String
jobのオーナーにリーチするのに最適のメール
アドレス。製品版のjobでは、通常は、開発チー
ムのメーリングリスト。
instances Integer
生成されたtask(場合によっては、レプリカある
いはshard)のインスタンスの数。(Default: 1)
215. constraints dict
taskのスケジューリングの制約条件。
constraint specification languageを参照。
service Boolean
もし真ならば、成功・失敗に関わりなくtaskを再
起動する。 (Default: False)
max_task_f
ailures
Integer
taskが失敗したとみなされるまでの失敗の数の
最大数。 (Default: 1)
無限回の失敗を許す場合には、-1をセットする。
priority Integer
taskに与えられるPreemption プライオリティ
(Default 0). 高いプライオリティのtaskは、低
いプライオリティのtaskより、優先的に実行され
る。
216. production Boolean
これがproduction taskであろうとなかろうと、
quotaでbackされる。 (Default: False).
Production jobsは、どんな non-
production jobよりも優先され、同じroleの
より高いプライオリティのproduction jobsに
よってのみ優先される。このレベルでjobを実
行するためには、job roleは、適当なquota
を持たなければならない。 productionの特
定のroleにquotaを認めるためには、オペ
レーターは、aurora_admin set_quotaコ
マンドを利用する。
health_che
ck_config
heath_check_
config object
HTTP経由でのtaskのヘルス・チェックをコン
トロールするパラメータ。ヘルス・ポートが、コ
マンドラインのワイルドカードで指定された時
にのみ利用される。
container
Container
object
全てのプロセスが、その中で走るオプショナル
なコンテナ。
219. TaskInfo
message TaskInfo {
required string name = 1;
required TaskID task_id = 2;
required SlaveID slave_id = 3;
repeated Resource resources = 4;
optional ExecutorInfo executor = 5;
optional CommandInfo command = 7;
optional ContainerInfo container = 9;
optional bytes data = 6;
optional HealthCheck health_check = 8;
optional Labels labels = 10;
optional DiscoveryInfo discovery = 11;
}