大規模分散システムの現在 -- Twitter

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

大規模分散システムの現在
@maruyama097
丸山不二夫

Most of our systems are big “Future transformers”
- Marius Eriksen

predictable performance is difficult to achieve. In a predictable system,
worst-case performance is crucial; average perfo...

predictable performance is difficult to achieve. In a predictable system,
worst-case performance is crucial; average perfo...

はじめに
 Twitterの大規模分散システムが、世界有数のものであ
ることは論を待たない。2億人以上のユーザーが、このプ
ラットフォームを利用し、彼らのシステムは、毎秒100万以
上のtweetに耐えられることを目指している。
 Twit...

はじめに
 Twitterのアプローチのもう一つの特徴は、彼らが彼らの
大規模分散システムの心臓部分の実装を、オープンソー
スで公開していることである。GoogleもAmazonも
Microsoftも、そういうことはしていない。
 Mes...

Agenda
 Twitterのシステムの変化
 Finagle 関数型言語による分散処理の記述
 Manhattan 多機能分散データベース
 Mesos データセンターOSとその影響の拡大

Overview
Twitterのシステムの変化
ここでは、Twitterのシステムの変化を概観し
よう。

2009年
 MySQLを使った純粋なRuby-on-Railsアプリ。
 たくさんのmemcacheを使い、投稿されたタイムラインを
memcacheに積む。
 ソーシャル・グラフはサービスで扱う。
 遅延は、queueで吸収。

 monolithicなアプリ
ケーション
 サービス・インフラの
欠如
 新しいサービス・新し
い特徴追加が困難
 スピード、効率性、信
頼性で勝る大規模イン
フラへ
 関心の分離
 チームの独立性
“Real-time syst...

2010年 - 2011年 - 2012年
 2010年：タイムラインを、独自のサービス・システムに移
行開始する。 ruby on railsから離れるためのプロジェク
トgodwit開始。サービス・インフラの共有化に取り組む。
 201...

2011
2012
“Real-time systems at Twitter”
http://goo.gl/EaYyZA

2012年末のアーキテクチャー
多くのオープンソース・コンポーネントの導入
 Memcache, redis, MySQL, etc.
 必然的にヘテロなシステムに
サービス中心に組織化
 異なった責任を持つ
 相互に分離されている
...

2013年 Twitter stack
 Finagle
 Ostrich
 Zipkin
 Mesos
 Iago
 ZooKeeper
 Scalding
 jvmgcprof
http://goo.gl/Ax9LVw

2013年 Finagle
 Twitterのサービスの中心部分には、Finagle ライブラリ
ーがある。RPCシステムの基本的な土台の部分を抽象化
することによって、Finagleは、サービス開発者が扱わな
ければいけなかった複雑さを大幅...

2013年 Mesos
 Mesos は、自分を次のように規定している。
「分散アプリケーション、すなわち、フレームワークをまた
いで、効果的なリソースの分離と共有を提供するクラスタ
ー・マネージャー」
 Mesosの中心プロジェクトは、オ...

2014年 Manhattan
 Twitterが、パブリックな自己表現と会話のグローバルな
プラットフォームに成長するにつれ、我々のストレージに
対する要請も増大した。この数年間にわたって、我々は、
リアルタイムの環境の中で、非常に低い遅延...

2014年 Manhattan
 何年にもわたって、我々は、多くのオープンソースのデー
タベースを利用してきたし、それらに重要な貢献もしてき
た。しかし、Twitterのリアルタイムの本性は、既存のオー
プンソース製品が提供しているものより、...

Finagle
関数型言語による分散処理の記述
 シーケンシャルな処理を考える
 改めて、シーケンシャルな処理を考え
 Futureの利用
 パラレルな処理を考える
 サービスのモジュールへの分割
 Finagle: RPCシステム

計算処理を関数と考える
処理
関数 f
入力出力
関数の引数 x 関数の返り値 y
y = f（x）
引数の型がAで、その返り値の型がBなら、この処理は
次のような型を持つ関数 f で定義される。
def f(x:A):B

シーケンシャルな処理
処理1
入力出力
二つの処理 fとgが、シーケンシャルに連続して行われる時、
その処理 h は、関数 f と関数 gの合成になる。これを、
h = g ・ f と表す。
処理2
入力出力
関数 f
引数 x
返り値
f...

シーケンシャルな処理
処理1
入力出力
シーケンシャルな処理が、f1, f2, ... , fn と連続して行われる時、
その処理 h は、h = fn ・ ... ・ f2 ・ f1 と表わすことができる。。
処理2
入力出力
y = h...

シーケンシャルな処理の特徴
h = fn ・ ... ・ f2 ・ f1
 関数の合成で、シーケンシャルな処理が記述できたのだ
が、それだけではシーケンシャルな処理の特徴を捉えたこ
とにはならない。そこには、次のような問題がある。
 f1の...

出力に時間がかかる場合
f
f
入力出力
入力出力がない！待機！
出力がすぐ返ればいいのだが、処理に時間がかかる
場合には、出力がない状態が生まれる。

非同期処理
f
g
入力出力がない状態
入力出力
こうした場合には、出力がない状態で待機せずに、別の
処理に制御を写すのが好ましい。f は、呼び出されると、
出力の有無にかかわらず、すぐに制御を返すのがいい。
非同期処理である。ただ、それに...

Future
 Futureは、関数が返すものを入れる「箱」である。
 この「箱」は、空の場合もあれば、中身を一つ持っている
場合もある。Futureは、ゼロ個か1個の中身を持つ。
 中身は、関数が返した値が入っているか、あるいは、関数
...

Futuresが必要とされる場合
出力を得るのに、待機する必要がある場合
 長い時間を要する計算
 ネットワークの呼び出し
 ディスクからの読み出し
計算は失敗することがある。
 接続の失敗
 時間切れ
 ゼロでの除算

Futureと関数の非同期化
f
g
入力
入力
別の処理 g
Futureが返ったら、別の
処理にただちに、制御を移す。
Futureが返る
Futureが返る
h
入力
別の処理 h
Futureが返る
Futureが返ったら、別の
処理に...

Futuresの値の取得 get
Futureは、ある種のコンテナーである。 trait Future[A]
それは、empty, full, failedの三つの状態を取る。我々
は、それを待つことができる。その値は getで取得できる。
v...

scala> import com.twitter.util.{Future,Promise}
import com.twitter.util.{Future, Promise}
// すでに解決済みのFutureを作る。
scala> val...

// 解決されていないPromiseを作る
scala> val pr7 = new Promise[Int]
pr7: com.twitter.util.Promise[Int] = Promise@1994943491(...)
scala...

Futureのコールバック
「私に電話するな。私がかける。」とMr. Futureはいう。
( Hollywood principle )
val f: Future[String]
f onSuccess {
s => log.info(s...

Promises
Futures はread-onlyだが（初期化の時に、一回だけ、書
かれる）、Promiseは、何回でも書き込み可能である
val p: Promise[Int]
val f: Future[Int] = p
Succes...

改めて、シーケンシャルな処理を考える
Futureの利用
Futureの準備はできた。ここでは、Futureを返すこと
で非同期化された関数の、シーケンシャルな合成を考
えてみよう。

サンプルのシナリオ
getThumbnail
 ここでは、与えられたURLから Webページを取得し、つ
づいて、そのWebページの最初の画像リンクから画像を
取得する処理 getThumbnail を考えてみよう。
 基本的なデータ型とし...

同期型のシナリオ
getThumbnailSync
 Futureを使わない同期型では、こんな感じになる。
def fetchSync(url: String): Webpage = { ... }
def firstImageURLSync...

非同期型のシナリオ
getThumbnail
 Futureを使った同期型では、こんな感じになる。中間の
部分の処理は、大して時間かからなそうなので、内部に組
み込んだ。
def fetch(url: String):Future[Webpa...

非同期型のシナリオ
getThumbnail のコード
def getThumbnail(url: String): Future[Webpage] = {
val promise = new Promise[Webpage]
fetch(ur...

getThumbnailをflatMapで実装
def getThumbnail(url: String): Future[Webpage] =
fetch(url) flatMap {
page => fetch(page.imageLink...

回り道
Collectionのmap
こうしたコンビネーターを、おそらく、毎日使っているかもしれ
ない。例えば、collectionに働く “map” は、コンビネーター
である。
val l = Seq(1,2,3,4)
val mult2 ...

回り道
CollectionのflatMap
flatMapコンビネーターは、非常に汎用的なツールである。
trait Seq[A] {
def flatMap[B](f: A => Seq[B]): Seq[B] ...
その名前が示唆する様...

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
== Se...

FutureのflatMap
trait Future[A] {
def flatMap[B](f: A => Future[B]): Future[B] ...
Future[Future[T]]を、Future[T]に変える

flatMapが助けになる？
我々は、次のような関数を定義しようとしている。
def getThumbnail(url: String): Future[Webpage]
最初にページを取り込んで、最初のイメージのリンクを見つけ、
そのリンクか...

page.
imageLi
nks(0)
fetch fetch
url
getThumbnail
page
onSuccess onSuccess
onFailure onFailure
url
fetch
page.
imageLin
ks...

flatMapurl
fetch
page.
imageLin
ks(0)
fetch
flatMap ... エラー
flatMappage
page.
imageLin
ks(0)
fetch
エラー
page

flatMappage
page.
imageLin
ks(0)
fetch
page
map . flattenpage
page.
imageLin
ks(0)
fetch
page
page.
imageLin
ks(0)
fetch
....

page.
imageLin
ks(0)
fetch
. flatten
. flatten
. flatten
エラー
エラー
Image
page

. flatten
Image
page
Image
page
Future flatmap 非同期関数
で、新しいFutureが返る
flatMapで、Future[Future[T]]
が、Future[T]に変わる

getThumbnailをflatMapで実装
def getThumbnail(url: String): Future[Webpage] =
fetch(url) flatMap {
page => fetch(page.imageLink...

失敗はどうなるのか？
これらは、合成も上手く行く。また、それは、回復可能でなければな
らない。flatMap には、その双対が必要である。flatMapは、成功
した値の上に働き、rescueは、例外を処理する。
trait Future[A]...

flatMapの利用
 flatMap シーケンスは二つのFutureを持つ。それは、
Futureと非同期関数を引数にとって別のFutureを返す。
 このメソッドのシグニチャーは、次のようなストーリーを語
っている。
 与えられた成功...

flatMapの利用
 この暗黙のエラーの織り込みは、エラーが意味的に重要
な場所で起きた場合にのみそれらを処理することを可能
にする。flatMapは、こうしたセマンティックを持つ
combinatorの標準的な名前である。
 もし、Fu...

flatMapの利用もう一つの例
 例えば、Future[User]があったとしよう。そして、特定の
ユーザーが失格になっていることを示す
Future[Boolean]が必要だとしよう。あるユーザーが失
格になっているかどうかを決めるis...

scala> import com.twitter.util.{Future,Promise}
import com.twitter.util.{Future, Promise}
scala> class User(n: String) { v...

シーケンシャルな処理の非同期化
h = fn ・ ... ・ f2 ・ f1
 シーケンシャルな処理は、時間やエラーの問題を無視す
れば、h = fn ・ ... ・ f2 ・ f1 のように、「関数の合成」で
モデル化できた。
 Futu...

パラレルな処理を考える
 パラレルな処理が、計算上で意味を持つのは、独立に計
算されたそれらの結果が、別の一つの処理で利用される
場合だけである。
処理
出力
処理1
処理2
処理n
入力
パラレルな処理

パラレルな処理の合成を関数で考える
 この複数の処理を一つに束ねる処理の、もっとも簡単な
関数での解釈の一つは、複数の引数を持つ関数を考える
ことである。
f(x1, x2, ... , xn)
f
返り値
p1
p2
pn
引数
パラレルな...

「複数の引数」の問題
 パラレルに走っている、引数を与える方の関数がエラーを
起こして、引数が、一つでも揃わないことが確定すると、そ
の時点で、複数の引数を受け取る関数は、失敗する。
 複数の引数が、同時に与えられる保証はない。複数の引
数...

パラレルな処理の合成を
非同期関数とFutureで考える
 複数の引数を持つ関数を考える代わりに、複数のFuture
のListを、複数のListの一つのFutureに変換する
combinatorを考えよう。
collect
p1
p2
p...

パラレルな処理の合成を
非同期関数とFutureで考える
 このcombinatorが成功するのは、左のListの要素のす
べてのFutureが成功する場会のみである。逆に、この時
、すべての要素は揃っている。
collect
p1
p2
p...

 Futureは、ある種の並列処理のcombinatorを提供して
いる。一般的には、これらは、Futureのリストを、少し違っ
たやり方で、リストのFutureに変換する。これは、本質的
には、複数のFutureを一つのFutureにパッケ...

先の、ページから最初の画像ページを取り出すプログラムを、少
し修正して、あるページの全ての画像ページを取り出すプログラ
ムを作ることができる。
def getThumbnails(url: String):
Future[Seq[Webpage...

単純な Web Crawler
def crawl(url: String): Future[Seq[Webpage]] =
fetch(url) flatMap { page =>
Future.collect(
page.links map...

Services
futureが、いかに並行プラグラミングに利用できるかを見てき
た。ここでは、ネットワーク・プログラミングが、いかに、この図式
に当てはまるかを見ることにしよう。
RPCは、どうだろうか？
 リクエストを送る
 しばらく待...

単純なサービス
A server:
val multiplier = { i =>
Future.value(i*2)
}
A client:
multiplier(123) onSuccess { res =>
println(“result...

Server
 同様に Finagle serverはServiceをネットワークに
“exports”する。serverは、二つの部分を持つ。
1. Serviceを実装した関数：Reqを受け取り、Future[Rep]
を返す。
2. 入...

Client
Finaglのclientは、ネットワークからServiceを “imports”
する。概念的には、Finagle clientは、二つの部分からなる。
1. Serviceを利用する関数: リクエスト Req を送り、帰って
...

Filters
サービスに共通の振る舞いの多くは、サービスに固有の特徴
とは無関係である。つぎのようなものがある。
 繰り返し
 時間切れ
 例外処理
 統計情報
Filterは、サービスの上で合成される。概念的に言えば、我
々は、サー...

Filter
 Finagle filterは、次のようなものである。filterは、サー
ビスの間に入って、その中を通るデータを変換する。filter
は、サービスとうまく合成できる。例えば、rate-limiterフ
ィルターとtwee...

Filterは、serviceを変形する。それらは、service generic な機能
を提供できる。例えば、rate-limitingをサポートすべき複数のサー
ビスがあったとする。一つのrate-limitingフィルターを書けば、そ...

filterの例
与えられたrequestとserviceに対して、それを実行するが、
１秒後にタイムアウトする。
val timeout = {
(req, service) => service(req).within(1.second)
...

Filterは、積み重ねられる。
val timeout: Filter[…]
val auth: Filter[…]
val service: Service[…]
timeout andThen auth andThen service
d...

Finagle: RPCシステム

Finagle
Finagle は、次のことを可能にする
 クライアントがサービスを提供して、サーバーがそれを消費
する
 コンフィグ可能な振る舞いを追加する：
ロードバランシング、コネクション・プーリング、再実行、タイ
ムアウト、割合の制...

Clients
val client = ClientBuilder()
.name("loadtest")
.codec(Http)
.hosts("google.com:80,..")
.build()
client は、 Service[...

Servers
val service = { req =>
Future.value(HttpRes(Code.OK, "blah"))
}
ServerBuilder()
.name("httpd")
.codec(Http)
.bindT...

それらをまとめると
新しい処理を追加したくなったとしよう。それは簡単である。
val backupReq: Filter[…] = { (req, service) =>
val reqs = Seq(
service(req),
timer....

[昔話]
SOAとRPCを振り返る
SOA「サービス指向アーキテクチャー」やRPCやモジ
ュラーなコンポーネントの歴史は古い。ここでは、
2002年に筆者が行った講演の一部を紹介する。「サ
ービス」概念の抽象化と実装の変化を振り返るのは、
興味...

2002年6月マルレク「WebコンポーネンとWebサービス」から
https://goo.gl/wLGyYe

https://goo.gl/4f4Hos
Manhattan,
our real-time, multi-tenant
distributed database for Twitter scale
https://goo.gl/MROsMq

Manhattan
 開発の背景と要請
 大規模システムでの信頼性
 Storage System
 Storage Service
 Storage as a Service

Data Platform Landscape Map
 次の電車の路線図みたいのは、必見。拡大して、よく見て
欲しい。世の中のデータストアの地図だ！！
 真ん中右の白いエリアがリレーショナル・データベース、
右下のグリーンのエリアが、Gr...

Manhattan, our real-time,
multi-tenant distributed
database for Twitter scale
April 2, 2014 By Peter Schuller,
Core Storag...

Manhattan 開発の背景
 Twitterが、パブリックな自己表現と会話のグローバルな
プラットフォームに成長するにつれ、我々のストレージに
対する要請も増大した。この数年間にわたって、我々は、
リアルタイムの環境の中で、非常に低い遅延...

データベースに対する要請
 Reliability: Twitterのサービスは、予測可能なパフォ
ーマンスを持った耐久性のあるデータストアを必要として
いる。それは、失敗やスピード低下や急拡大や負荷集中
その他、想定できるあらゆる事態を通じ...

 Extensibility: 我々の構築するテクノロジーは、我々
の要請の変化に応じて、発展することが可能でなければ
ならない。それゆえ、新しいストレージ・エンジンから強い
整合性にいたる、あらゆるものがその上に構築される、強
固でモジュー...

 Low latency: リアルタイムのサービスとして、Titter
の製品は、整合性をもった低遅延を要求する。低遅延の
パフォーマンスを保証するために、Twitter固有のトレー
ドオフを行わなければならない。
 Real-world ...

大規模システムでの信頼性
Manhattanの構築を始めた時、Twitterには、すで
に沢山の大規模なストレージ・クラスターがあった。
それで、我々は、大規模なシステムを走らせることか
らくる挑戦を理解していた。それは、新しいシステムで
は、...

最悪ケースのパフォーマンス
 信頼できるストレージシステムというのは、運用のあらゆ
る場面でうまく稼働することを信用できるシステムである。
そして、予測可能なパフォーマンスは、達成するのは難し
いのだ。予測可能なシステムでは、最悪ケースのパフ...

 予測可能であることの、この優先順によって、いかなる潜
在的な問題、失敗のモードのあいだでも、いいパフォーマ
ンスのためにプランが必要となる。顧客は、我々の実装の
詳細にも、言い訳にも興味がない。我々のサービスが、彼
らとTwitterにとっ...

ストレージ・システムの構築
次世代のストレージシステムを構築する際、我々は、
システムを幾つかの階層に分割することを決めた。そ
うすることで、システムは、十分なモジュラー性を持ち
我々がその上で構築できるものに、強固な基礎を提
供する。また、大...

Manhattanの階層
 我々は、Manhattanを、以下の四つの階層に分離した。
interfaces, storage services, storage
engines、coreである。

Core
 coreは、ストレージシステムの最もクリティカルな側面で
ある。それは、高度に安定していて頑健である。coreは、
失敗、結果整合性、ルーティング、トポロジーの管理、デ
ータセンター内・データセンター間の複製の作成、衝突の
解決を...

整合性のモデル
 Twitterのアプリケーションの多くは、 eventually
consistent モデルに、非常によくフィットする。我々は、
ほとんどすべてのユースケースで、整合性より高可用性
を好む。それで、Manhattanを、 ...

整合性の追求
 eventually consistent なシステムで整合性を達成す
るためには、我々がレプリカの調停と呼んでいる、要求さ
れたメカニズムが必要になる。このメカニズムは、
incrementalでなければならず、また、常にレ...

Storage engines
 我々は、現在、三つのストレージ・エンジンを持っている。
 seadb： Hadoopからのバッチ処理のデータのための読
み取り専用のファイル・フォーマット。
 sstable：重い書き込み処理のための、...

二つの整合性モデル
三つのStorage Engine
二つの整合性モデル、三つのStorage Engine

ストレージ・サービス
我々は、Manhattanのcoreの上に、開発者が伝統
的なデータベースから期待するようになるかもしれな
い特徴を、もっと頑健なものにすることを可能にする、
追加のサービスを作り出した。

Batch Hadoop importing
 もともとの、Manhattanのユースケースの一つは、
Hadoopで生み出されるデータ上で、効率的にサービス
を提供する層というものだった。
 我々は、顧客がHDFS上に単純なフォーマットの...

binary diffs
 このインポート用のパイプラインは、ストリーム・ライン化さ
れて扱いが容易なので、我々は、成長を続けるデータセッ
ト上で、開発者が、直ちに開発を繰り返し行えるようにす
ることにフォーカスした。顧客から我々が学んだ一つ...

強い整合性のサービス
 強い整合性のサービスは、顧客がある一群の操作を行う
ときに、強い整合性を持つことを可能にする。我々は、コ
ンセンサス・アルゴリズムと複製されたログをペアで利用
して、すべてのレプリカにイベントが順番どうりに到達する
こ...

Timeseries Counters service
 我々は、Manhattanで、大きな容量を持つ時系列のカウ
ンターを扱う、極めて特殊なサービスを開発した。このサ
ービスを要請した顧客は、一秒あたり数百万のカウンター
・インクリメント...

ツール
 我々は、host groupとweightの入ったファイルを編集
するだけで、システム全体のトポロジーを変更させ、再起
動のような共通の操作を、ノード全体で一つのコマンドで
実行できることを可能にするようなツールから始めた。こう
し...

Storage as a service
 既存のデータベースで我々が見てきた共通の問題は、そ
れが、ユースケースのある特別な集まりに対して、設定さ
れ管理されるようにデザインされていることだった。
Twitterの新しい内部サービスが成長す...

Storage as a service
 エンジニアは、彼らのアプリケーションが必要とするもの（
ストレージのサイズ、一秒あたりのクエリー等）を与え、ハ
ードウェアがインストールされスキーマが設定されるのを
待つことなしに、瞬時にストレージ...

Storage as a service
 我々は顧客に、データと処理を、見える形で提供した。
quotaの機能強化とrate制限を組み込んで、エンジニア
が、彼らの定義された制限を超えた時には警告を受け取る
ようにした。我々のすべての情報は...

マルチ・テナンシーとQoS
 マルチ・テナンシーをサポートすることは、多くの異なった
アプリケーションが、同じリソースを共有することを意味す
るのだが、それは、当初からキーとなる重要な要請だった
。それ以前のシステムを我々はTwitterで管...

マルチ・テナンシーとQoS
 顧客に可視性を与えることに加えて、顧客は良き市民で
あることが求められる。我々は、我々自身のrate制限サ
ービスを、顧客のリソースやquotaの利用を強制するた
めにデザインした。我々は、モニターし、必要であれ...

マルチ・テナンシーとQoS
 我々は、すべての顧客からデータを抽出して、それを
Capacityチームに送るという必要からAPIを構築した。
Capacityチームは、（Twitterの標準によれば）小規模
ないしは中規模の要求をもった顧客...

将来展望
 我々は、将来に、まだ多くの仕事を残している。挑戦は、
増え続いており、Manhattan上で内部的にローンチされ
る特徴の数も、速いペースで増え続けている。我々自身を
、より良いよりスマートなものへと強く押しているのは、
Core...

Mesos
データセンターOSとその影響の拡大
 Mesos
 Aurora
 Docker Containerizer
 Mesosphere
 Mesosの影響の拡大

Mesos
Datacenter Operation System
“Program against your datacenter like
it’s a single pool of resources”
http://mesos.apac...

Mesosとは何か？
 Mesos は、自分を次のように規定している。
「分散アプリケーション、すなわち、フレームワークをまた
いで、効果的なリソースの分離と共有を提供するクラスタ
ー・マネージャー」
 Mesosの中心プロジェクトは、オー...

Mesosとは何か？
 数万のノードへのScalability
 ZooKeeper を使った、Fault-tolerantなマスターとスレ
ーブのレプリカ管理
 Dockerコンテナーのサポート
 Linuxコンテナーでの、タスク間の...

Mesos のアーキテクチャー
http://mesos.apache.org/documentat
ion/latest/mesos-architecture/

Mesosの主要なコンポーネント
 次の図は、Mesosの主要なコンポーネントを表している。
 Mesosは、それぞれのクラスター上のノードで走るスレー
ブ・デーモンと、それを管理するマスター・デーモン、これ
らのスレーブ上でタスクを走らせ...

マスターとリソース・オファー
 マスターは、アプリケーションがリソースのオファーを行う
ことで、アプリケーション間の細かな粒度でのリソース（
CPU, RAM等）の共有を可能にする。
 それぞれのリソース・オファーは、それらのリストを含んで...

schedulerとexecutor
 Mesosの上で走っているフレームワークは、二つのコンポ
ーネントからなる。一つは、フレームワークのscheduler
（スケジューラー）で、マスターに提供されるべきリソースを
登録する。もう一つは、 ...

リソース・オファーの例
フレームワーク
Mesos
マスター
Mesos
スレーブ

リソース・オファーのプロセス
① Slave 1は Masterに、自分には 4 CPUあって4 GBの
メモリーが空いていると報告する。報告を受けるとMaster
は、Allocation Policy Moduleを呼び出す。
Alloca...

リソース・オファーのプロセス
④ 最後に、Master は、Slave 1 にタスクを送る。それは、
Slave1 の Framework1 の実行エンジンに適切なリソ
ースを割り当てる。こうして、二つのタスクが起動される（
図での、Slave...

フレームワークの制約条件と
delay scheduling
 Mesosによって提供される薄いインターフェースは、フレ
ームワークが独立に、スケールし発展することを許すのだ
が、一つの疑問が残る。すなわち、フレームワークの制約
条件は、Me...

フレームワークの制約条件と
delay scheduling
 特に、入力データを格納するノードを見つけるまで、制限
時間のあいだは、フレームワークは待機するという、
delay schedulingと呼ばれている単純なポリシーが、
ほとんど...

http://aurora.apache.org/
Apache Aurora
長時間走るサービスと
cronジョブのためのフレームワーク

Apache Aurora
Apache Auroraは、Mesos上で走るサービス・ス
ケジューラーである。それは、Mesosのスケーラ
ビリティ、耐障害性、リソース隔離の利点を生か
して、長時間走るサービスを走らせることを可能
にする。Ap...

Aurora: Job
 Aurora は、Mesos上でjobをスケジュールするために
利用されるMesosのフレームワークである。Mesosは、
個々のtaskを面倒見るのだが、典型的なjobは、数百に
も昇るtaskのレプリカを持つ。A...

Aurora: taskとprocess
 taskは、一つのコマンドラインの命令（例えば、
my_script.py のような）に対応した、一つのprocess
にすぎないこともある。ただし、taskは、その全てが一つ
のsandbox上で...

Auroraの階層
 Auroraは、taskからなるjobを管理する。
 Mesosは、processからなるtaskを管理する。
 Thermosは、processを管理する。
 全ては、 .aurora 設定ファイルで定義される。

Sandbox
 それぞれのTaskは、Taskが起動した時に生成され、そ
れが終了した時に、ガーベージコレクトされるSandbox
を持つ。
 全てのTaskのProcessは、このsandboxの中で走る。
だから、processは、共...

AuroraでHello World!
Auroraで、Hallo World! を実行してみよう
Auroraで

import sys
import time
def main(argv):
SLEEP_DELAY = 10
# Python ninjas - ignore this blatant bug.
for i in xrange(100):
p...

pkg_path = '/vagrant/hello_world.py'
# ファイルの中身に応じて設定を変える。ここでは、バージョン番号に、
# ファイルのchekusumを使う。
import hashlib with open(pkg_p...

# taskの記述
# installとhello_worldをシーケンシャルに実行する。
hello_world_task = SequentialTask(
processes = [install, hello_world],
resou...

Auroraの設定ファイルがしていること
 まず、二つのprocess、installとhello_worldを定義。
install = Process( ... )
hello_world = Process( ... )
 ついで、こ...

Auroraの設定ファイルがしていること
 最後に、Jobの定義。Jobは、利用可能なマシン上に
Taskをスケジュールする。この例では、JobはJobリスト
の唯一のメンバーだが、configファイルでは、一つ以上の
Jobを指定できる。
...

Auroraの設定ファイルがしていること
 Process レベルでは、この設定ファイルは、コードが走る
ローカルのsandboxに、どのようにコードをインストール
するのかを指定している。
install = Process( ... )
...

Jobの生成と実行
aurora job create ...
 実際に、我々のjobを走らせる Auroraクライアント・コマン
ドは、 aurora job create である。それは、job keyと、
configファイルを引数に取...

job key の構成
 job key は、“/” で区切られた四つの部分からなる。四つの部分
は、次のような部分から構成される。
<cluster>/<role>/<environment>/<jobname>
 先のコマンドの例で言う...

job keyとjobの一意な指定
 Cluster：clusterの名前。
 Role：そのslaveマシン上に存在する、ユーザーのアカ
ウント名。
 Environment：名前空間。”prod” （製品版）、
“devel”（開発版...

clusterの定義
 このjob keyの指定は、よく見ると、この例では、
*.aurora のAurora設定ファイルが、
jobs = [
Service( ... )
...
]
の中で、Serviceのパラメータに設定されたものと重...

clusterの設定
/etc/aurora/clusters.json
 clusterの設定は、/etc/aurora/clusters.json というファ
イルの中で行われている。こんな中身だ。
[{ “name”: “devclus...

MarathonとChronos

MarathonとChronos
 Marathon:
長時間走るアプリのためのApache Mesosのフレームワ
ーク。Mesosがデータセンターのkernelだとすれば、
Marathonは、init デーモンにあたる。
https:/...

Marathonによって
起動されたTaskと、
Chronosによって
起動されたTask。
Chronosは、
Marathonによって
起動されている。
Chronosによって
定期的に、dump-
dbや、rake email
send...

Scale out
Server Error
再配置
Marathonの仕事

Apache Mesos 0.20/Apache Aurora 0.7で、Dockerサポート

Docker Containerizer
http://mesos.apache.org/documentat
ion/latest/docker-containerizer/

Docker Containerizer
 Mesos 0.20.0 は、Dockerイメージを含んだtaskの実
行のサポートを追加した。また、Dockerでサポートされて
いるオプションのいくつかを、将来的には追加していく。
 ユーザー...

Docker Containerizerを
どのように利用するか？
 0.20.0以前のTaskInfoは、bashコマンドを走らせる
CommandInfo を設定するか、taskを起動する特別の
Executorを起動するExecutor...

 Dockerイメージをtaskとして実行するためには、
TaskInfoの中で、コマンドとともに、Docker
Containerizerが Dockerイメージを起動するために、そ
れに伴って利用するコマンドのコンテナー・フィールドの、
...

Docker Containerizerは、
何をしているのか？
 Docker Containerizer は、 Task/ExecutorのLaunch
とDestroy呼び出しを、 Docker CLI コマンドへ変換して
いる。
 ...

Docker Containerizerは、
何をしているのか？
3. Docker executorは、
 dockerイメージを実行し、
 sandboxのディレクトリーをDocker コンテナーにマッ
プし、
 ディレクトリー・マッ...

 Docker Containerizerは、先頭に”mesos-”がつき、
その後ろにslaveのidが続く（例えば、 mesos-slave1-
abcdefghji のような）名前を持つ、すべてのコンテナー
を起動する。そして、”mes...

 dockerイメージを実行する時、現時点では、デフォールト
では、ホストのネットワークに繋がっていることに留意する
こと。それは、 Executorとしてdockerイメージの実行を
サポートするのを容易にするためである。
 contai...

プライベート Docker レポジトリー
 イメージをプライベート・レポジトリーから実行するために、
ログイン情報を含んでいる .dockercfgをポイントしてい
る uriを含めることができる。この .dockercfgファイル
は s...

Dockerイメージを実行する
CommandInfo
 dockerイメージは、現時点では、entrypointとデフォー
ルト・コマンドをサポートしている。
 docker run imageのように、デフォールト・コマンドで
dock...

slaveのrecoveryで、Dockerコンテ
ナーを回復する
 Docker containerizerは、slaveが再起動した時、
Dockerコンテナーのrecoveryをサポートしている。それ
は、slaveがdockerコンテ...

Mesosphere DCOS と
Apache Mesos の違い
 Mesosphere DCOSは、オープンソースのMesos上に
構築された、商用サポートのあるソフトウェア製品。
コマンドライン、Webインターフェース、パッケージング...

The Mesosphere Datacenter
Operating System
「自分のデータセンターやクラウドを、Mesosphere
データセンター・オペレーティング・システムで、自動
運転させる。時間とお金を節約して、ソフトウェアは...

A New Kind of Operating
System
 Mesosphere データセンター・オペレーティング・システ
ム (DCOS)は、新しい種類のオペレーティング・システム
である。それは、物理サーバー、クラウド・ベースのデータ...

特徴
 キラー・アプリ：どんなLinuxのアプリケーションも、簡単
にデプロイする。一つのコマンドで、データセンターのサー
ビスをインストールできる。その中には、Hadoopや
SparkやCassandraやKubernatesが含まれる...

Mesosphere DCOS
 Mesosphere DCOS は、すべてのマシン、VM、クラウド
上のインスタンスを、インテリジェントで動的な共有リソー
スの単一のプールに組織する、新しいタイプのオペレーテ
ィング・システムである。それは...

データセンターでしたいと思うことは、
なんでも、我々がカバーする.
 新しいアプリケーションを、書いてデプロイすることが、個
々のマシンと静的なパーティションを管理することを意味し
ていた時代は、過ぎ去った。データセンターとクラウドのリ
ソー...

 Never Fail
Mesosphereは、リソースを再バランスしながら、走り続
け、失敗したタスクは自動的に再スタートされる。
 Optimize Resources
Mesosphere は、それぞれのサーバーに、複数のアプリ
を...

Mesosphere データセンターOSは、
全ての主要なプラットフォームで走る

Mesos
データセンターOSとその影響の拡大
Apache Mesosだけでなく、そのデータセンター
OSへの機能強化版のApache Aurora, Aurora
相当の商業製品Mesosphereといった「Mesos文
化圏」ともいうべき...

PaaS and
Long Running Big data processing Batch scheduling Data storage
“Framework on Mesos” https://goo.gl/1oDvTc

Mesos利用の拡大
-- Mesosphere Blog タイトルから --
 The Mesosphere Datacenter Operating System
is now generally available
 Get Meso...

Mesos利用の拡大
-- Mesoshere Blog タイトルから --
 Launching thousands of Docker containers
with DCOS on Azure
 Join the DCOS publi...

“Mesosphereは、Googleスケールの計算能力を万
人にもたらす。”
Abdur Chowdhury, Former Chief Scientist, Twitter
“Mesosphereは、クラウド・コンピューティングの避
けられ...

[余談]
大規模分散システムのパワーを、
誰が、どのように利用するのか？
21世紀初頭のGoogleの登場は、大規模分散システ
ムが、そのパワーを現した画期だった。あれから、もう
15年がたつ。ただ、その当時には、Googleだけしか
それがで...

MesosとBorg
 Mesosは、GoogleのBorgにインスパイアされて生まれ
た、オープンソース・プロジェクトである。
 Borgは、以前から、その存在は知られていたが、GFS,
MapReduce, BigTable とは異なっ...

Google, Borgの情報公開
 今年の4月、Googleは、Borgの情報を初めて公開した。
“Large-scale cluster management at Google
with Borg” https://goo.gl/aN0...

Google Borg
Google’s Borg system
is a cluster manager
that runs hundreds of
thousands of jobs,
from many thousands
of diff...

大規模分散システムとクラウド
-- いくつかの視点
 概念的には、大規模分散システムの方が、クラウドより広
い。ただ、2006年のAWSのサービス開始に始まるクラウ
ドの成立は、大規模分散の第二の画期である。
 「作る人」と「使う人」：大...

大規模分散システムとクラウド
-- いくつかの視点
 クラウドを「使う人」であると同時に、クラウド上のサービス
を「作る人」が、現在のクラウドの活況の中心にいる。それ
はそれで結構なことである。
 それでは、彼らのエネルギーは、これからどこ...

資料編
 Aurora 実行例
https://github.com/apache/aurora/blob/master
/docs/tutorial.md
 Aurora + Thermos Configuration Reference...

$ vagrant ssh
Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic
x86_64)
Documentation: https://help.ubuntu.com/ Welc...

schedulerの状態を見る
 http://$scheduler_hostname:$scheduler_port/sc
heduler にアクセスするとschedulerの状態を見ることが
できる。この例では、
http://192.1...

role(ユーザー)ごとのjobを見る
 先の状態で、ユーザー名（この場合、www-data）をクリ
ックする。Environment devlで、hello_world Jobが
走っていることがわかる。

Jobの実行を見る
 hello_worldをクリックすると、jobの実行状態が見える。
 あれ、Taskが失敗して、終了している。

Taskの状態をチェックする
 hostをクリックして、Taskの状態を見る

バグを修正して、再実行
 実行プログラムにバグがあったようだ。バグを修正して、
再実行すると、今度は、上手くいく。

processの出力を見る
 processのstdoutをクリックすると、その出力が確認でき
る。

jobを殺す
aurora job killall ...
 次のようにして、投入したjobを殺せる。
vagrant@precise64:~$ aurora job killall
devcluster/www-data/devel/hel...

jobページで、結果を確認する
 Hello_world プロセスは、killされている。

Aurora + Thermos
Configuration Reference
https://github.com/apache/aurora/bl
ob/master/docs/configuration-
reference.md

Attribute Name Type Description
name String プロセス名（必須）
cmdline String コマンドライン（必須）
max_failures Integer プロセス失敗最大数(Default: 1...

param_ type description
name String
プロセス名（必須）
(Default: processes0.name)
processes
List of Process
objects
このtaskに結びつけられてい...

name type description
task Task このjobにバインドするTaskオブジェクト。必須。
name String Job名。 (Default: taskの属性名から継承)
role String Job roleの...

cron_schedule String
cronフォーマットでのCronスケジュール。サー
ビスではないjobにのみ利用されるだろう。詳細
な情報は、Cron Jobs を参照されたい。
Default: None (cron jobではない...

constraints dict
taskのスケジューリングの制約条件。
constraint specification languageを参照。
service Boolean
もし真ならば、成功・失敗に関わりなくtaskを再
起動する。 ...

production Boolean
これがproduction taskであろうとなかろうと、
quotaでbackされる。 (Default: False).
Production jobsは、どんな non-
production job...

データセンターOS API
“Building & Deploying Applications to
Apache Mesos” http://goo.gl/Iwkn9u の一部
抜粋

FrameworkInfo
https://github.com/apache/mesos/blob/master/include/mes
os/mesos.proto
message FrameworkInfo {
required stri...

$TaskInfo message TaskInfo { required string name = 1; required TaskID task_id = 2; required SlaveID slave_id = 3; repeated...$

TaskState
可能なタスクの状態を記述する。Mesosは、終了状態に入った
タスクは、もはや実行されていないとみなす。そして、この
タスクに関連したすべてのものを片付ける。（最終的には、
このタスクで消費されていたリソースは、他のタスクに...

Scheduler
registered
スケジューラーがMesosマスターへの登録が成功した時に
起動される。ユニークなID（マスターによって生成され
る）は、このフレームワークを他のフレームワークと区
別するために利用される。現在のマスター...

Scheduler
reregistered
新しいMesosマスターが選出された、スケジューラーが
登録された時起動される。これは、スケジューラーが以
前に登録されていた場合にのみ呼び出される。
MasterInfoは、新しく選出されたマスタ...

Scheduler
resourceOffers
スクジューラは、リソースがこのフレームワークにオファーされた時
に起動される。単一のオファーは、単一のスレーブからのリソース
だけを含んでいるだろう。オファーに関連したリソースは、次の条
件を満...

Scheduler
resourceOffers
(あるいは、フレームワークが、すでにこれらのリソース
を使ってタスクを起動していたとすれば、これらのタス
クは、TASK_LOSTの状態で失敗するだろう。メッセー
ジを見て欲しい)
def re...

Scheduler
offerRescinded
/**
* オファーが、もはや有効でない場合に呼び出される。
* （例えば、スレーブが失われたり、他のフレームワークがリソースを
* オファーにつかった場合とか）どんな理由であれ、オファーが撤...

Scheduler
statusUpdate
/**
* タスクのステータスが変わった時に呼び出される。
* 例えば、スレーブが失われ、タスクも消えた時。executorは
* ステータスが更新されたというメッセージを送る。このステータスの
•...

Scheduler
frameworkMessage
/**
* executorが、メッセージを送った時に呼び出される。これらの
* メッセージは、best effortである。フレームワークが、なんらかの
* 信頼できるやり方で、メッセージ...

Scheduler
disconnected
/**
* schedulerが“disconnected” になった時にマスターから呼び出される。
* （例えば、マスターが落ちた時）
*/
def disconnected(driver: Sc...

Scheduler
slaveLost
/**
* スレーブがunreachableになった時呼び出される。
* （マシンの失敗、ネットワークの分断等）ほとんどのフレームワーク
* は、このスレーブで起動されたタスクは、他のスレーブに
* リス...

Scheduler
executorLost
/**
* executorが、exited/terminated になった時に呼び出される。
* 実行中のすべてのタスクは、TASK_LOSTのステータスになり、
* 自動的に（魔法のように）更新...

Scheduler
error
/**
* schedulerあるいはそのドライバーに、修復不可能なエラーが
* 起きた時に呼び出される。ドライバーは、これが呼び出される以前に
* 中止する。
*/
def error(driver: Sche...

Executor
registered
/**
* executorのドライバーが、成功裏にMesosに接続できた時に
* 呼び出される。特に、schedulerはexecutorにExecutorInfoの
* データ・フィールドを使って、デ...

Executor
reregistered
/**
* executorが再起動されたスレーブで再登録された時、呼び出される。
*/
def reregistered(
driver: ExecutorDriver,
slaveInfo: Sl...

Executor
launchTask
/**
* Scheduler.launchTasksで始められたタスクが、このexecutorで
* 起動された時、呼び出される。このタスクは、thread, process,
* あるいは、単純な計算...

Executor
killTask
/**
* このexecutorの中で、タスクが殺された時に呼び出される。
* ( SchedulerDriver.killTask を通じて) このexecutorのためには、
* ステータスの更新は往診さ...

Executor
frameworkMessage
/**
* このexecutorに、フレームワークのメッセージが届いた時に
* 呼び出される。これらのメッセージは best effort である。これらが、
* なんらかの信頼できるスタイル...

Executor
shutdown
/**
* このexecutorが、現在実行中のすべてのタスクを終了すべき時に
* 呼び出される。Mesosが executor が最終ステータス(例えば、
* TASK_KILLED, TASK_FINIS...

Executor
error
/**
* executorあるいはそのドライバーに、致命的ななエラーが
* 起きた時に呼び出される。ドライバーは、これが呼び出される以前に
* 中止する
*/
def error(driver: Executor...

Hosting Environment
これまでのContainer技術。マルレク2003から。
https://goo.gl/MnjtqO
 CORBA
 J2EE
 Web Service
 Grid

大規模分散システムの現在 -- Twitter

大規模分散システムの現在 -- Twitter

大規模分散システムの現在 -- Twitter

大規模分散システムの現在 -- Twitter

大規模分散システムの現在 -- Twitter

Share Slideshare

LinkedIn
Facebook
Twitter

Embed

Size (px)

Show related Slideshows at end

WordPress Shortcode

Link

Share
Email

クラウドセキュリティ基礎 #seccamp by Masahiro NAKAYAMA 25477 views
Spc2014 44 by Kaigi Senden 243274 views
Spc2014 30 by Kaigi Senden 233911 views
Rancher command line interface by Masahito Zembutsu 3555 views
DeNA_Techcon2017_DeNAでのチート・脆弱性診断への取り組み by Toshiharu Sugiyama 7946 views
捕鯨！詳解docker by 雄哉吉田 21770 views

View on Slideshare

1 of 244 Ad

View on Slideshare

1 of 244 Ad