SlideShare a Scribd company logo
Copyright©2016 NTT Corp. All Rights Reserved.
分散システムについて
語らせてくれ
日本電信電話株式会社
ソフトウェアイノベーションセンタ
熊崎 宏樹 (@kumagi)
Copyright©2016 NTT Corp. All Rights Reserved.
2
1.分散自体を目的にしない事
2.論文を読んでそのまま実装しない事
3.Two Phase Commitを使わない事
4.手を動かす事
目次
分散システムを作る際に気をつけて欲しい事
Copyright©2016 NTT Corp. All Rights Reserved.
3
• よくわかってない人でもCloudera Managerをダウンロードして1時間後
には巨大なHadoopクラスタを立ち上げてYARN, HDFS, Spark, HBase
などで遊ぶ事ができる。
• 世の中では分散システムが必要以上に喧伝されている
• 「コンピュータ1台よりも2台の方が高速」という直感に対して反論するの
は意外と難しい
• あなたのそのシステム、本当に分散システムじゃないとダメ?
分散自体を目的にしない事
Copyright©2016 NTT Corp. All Rights Reserved.
4
L1 キャッシュ参照
分岐予測ミス
L2 キャッシュ参照
Mutexのlock/unlock
メモリ参照
1KBをZIP圧縮
1Gbpsで2KB送る
メモリから1MB連続で読む
同一のデータセンタ内のマシンと通信1往復
HDDシーク
HDDから1MB読み出し
カリフォルニアとオランダ間で通信1往復
システムの肌感覚を掴め
0.5 ns
5 ns
7 ns
25 ns
100 ns
3,000 ns
20,000 ns
250,000 ns
500,000 ns
10,000,000 ns
20,000,000 ns
150,000,000 ns
みんなが知っているべき数値 by Jeff Dean
Copyright©2016 NTT Corp. All Rights Reserved.
5
L1 キャッシュ参照
分岐予測ミス
L2 キャッシュ参照
Mutexのlock/unlock
メモリ参照
1KBをZIP圧縮
1Gbpsで2KB送る
メモリから1MB連続で読む
同一のデータセンタ内のマシンと通信1往復
HDDシーク
HDDから1MB読み出し
カリフォルニアとオランダ間で通信1往復
システムの肌感覚を掴め
0.5 ns
5 ns
7 ns
25 ns
100 ns
3,000 ns
20,000 ns
250,000 ns
500,000 ns
10,000,000 ns
20,000,000 ns
150,000,000 ns
みんなが知っているべき数値 by Jeff Dean
Copyright©2016 NTT Corp. All Rights Reserved.
6
分散システム化すると基本的に遅くなる。
大抵はネットワークが遅延の支配項になる。
速くなる場合のほうがむしろ例外的と思ったほうが良い。
ワークロードと照らし合わせてマイクロベンチを取った
後で分散システム化を検討して欲しい(頼むから実装上
の重要な意思決定で分散ミドルウェアを使用する事を目
的にしないで欲しい)
システムの肌感覚を掴め
とにかく測れ
測らずに分散システム化するのは
Early Optimizationの一種
Copyright©2016 NTT Corp. All Rights Reserved.
7
• 分散システムの論文は多く出ているがその大半は「やってみたレポート」
「作ってみた」→「動いたっぽい」→「測った」→「Yappy!」
• 分散システム界隈の研究は過去の研究の蓄積が蓄積扱いされにくい分野の
一つであり、論文を真に受けてはならない
• 他にそう感じる研究分野はHCI分野
• 故障モデルなどが実は結構厳しく規定されており、そこを読み飛ばすと痛
い目に遭う
論文を読んでそのまま実装しない事
Copyright©2016 NTT Corp. All Rights Reserved.
8
• レプリケーションプロトコルとして典型的に見かけるパターン
• 一番IDが小さいServerをPrimaryとして、MasterがBackupへのレプリケーション
を担当する
• ReadもWriteもPrimaryが受け取ることによって一貫性の問題を回避
• Primaryが壊れたらBackupのうち一番IDが小さい奴がPrimaryへ昇格する
• HDFSでメタデータの複製に使われているのはこれ
ケーススタディ:Primary-Backup
Client
Server1
Server2
Server3
Server4
Read Write
Copyright©2016 NTT Corp. All Rights Reserved.
9
• 次に見かけるレプリケーションプロトコル
• バケツリレーのように受け取ったものを即座に次のサーバに渡していく
• データを全部受け取る前から次のサーバにリレーできるので大容量のデータ転送に強
くメッセージの飛び交う回数はサーバ台数+1で最小だがサーバ台数に比例するメッ
セージ遅延がかかる
• 故障したサーバはスキップする
• HDFSでデータの複製に使われているのはこれ
ケーススタディ:Chain-Replication
Client
Server1
Server2
Server3
Server4
Read Write
Copyright©2016 NTT Corp. All Rights Reserved.
10
プロトコル名 通信遅延数 メッセージ数
Primary-Backup 4回 2N個
Chain-Replication N+1回 N+1個
ケーススタディ: Primary-Backup と Chain-Replication
• 通信の特性を見極めて最適なプロトコルを使おう
• Primary-Backupは「細かくて素早い」特性
• Chain-Replicationは「時間が掛かっても通信効率が良い」特性
• どちらもサーバが故障する場合は縮退運転していき、最小1台でも稼動は
する
Copyright©2016 NTT Corp. All Rights Reserved.
11
ちょっと待った
Copyright©2016 NTT Corp. All Rights Reserved.
12
• これは容易にバグる
• Readを常に全体に伝える必要があるかは実装次第だが典型例として
• みんながカジュアルに生死判断を行うと食い違ったときに容易に世界が壊れる
いわゆるSplit-Brain
ケーススタディ:Primary-Backupの故障
Client
Server1
Server2
Server3
Server4
Write(x=2) Read(x) -> 0
Server2の
応答が遅かったので
死んでると想定して
無視
Server1の
応答が遅かったので
死んでると想定して
Server2へリトライ
Copyright©2016 NTT Corp. All Rights Reserved.
13
間違った実装が世界を揺るがす
• 「Redis Sentinelという自動レプリケーションの仕組みを作りました。
最強です(キリッ」
• しかし特定の実行パターンによって内容物の半分以上が失われる
• Jepsen Testが築く屍の山
• 様々な分散ミドルウェアで
意図的にSplit-Brain状態を引き起こして挙動を確認する一連のブログポス
ト群:Call me maybe
• 面白いぐらい多くのシステムが次々と壊れていく
(生き残ったのはZK, Riak, etcd, consulぐらい?
• 興味のある人はぜひURL参照
https://aphyr.com/tags/jepsen
Copyright©2016 NTT Corp. All Rights Reserved.
14
• サーバが壊れた場合の挙動をどうするかは論文に書いてあるけれど、何が
起きたらサーバが壊れたと認識するかは書いてない
• これらのプロトコルはサーバの故障情報を天から与えられる物として設計している
• プログラマ「そっか、じゃあ通信がタイムアウトしたら故障ね」←バグの温床
• プログラマ「タイムアウトの閾値を大きくすれば誤検知が減って安心だね」←低速化
• プログラマ「タイムアウトの閾値をどうすればいいのさ??」←決定解はない
• 分散システムの論文ではシステムに対して前提を置いていることが多いが、
なぜその前提を置いているのかは知識がないとわからない
• Primary-BackupとChain-ReplicationはFail-Stop故障モデルを前提
としている
• それより厳しい故障モデルの上では容易に壊れる
• その故障モデルの解説はこれからする
そのプロトコル、凶暴につき
Copyright©2016 NTT Corp. All Rights Reserved.
15
故障なし
• サーバが壊れる状況のしんどさを段階的に切り分けたモデルのこと
• より楽な故障モデルで動かないプロトコルは、しんどい故障モデルでは
「絶対に」動かない
• Fail-Stop: 壊れたサーバはいずれ全部のサーバから故障として観測される。壊れてい
ないサーバを壊れたと誤認する事や、壊れたサーバを壊れていないと誤認する事は発
生しない。壊れたサーバは二度と復活しない。
• Crash-Recover: サーバは壊れるかも知れないが復活する事もある。つまりいつまで
も故障したと断言できない。
故障モデル
し
ん
ど
い
Fail-Stop(同期通信)
Fail-Stop(非同期通信)
Crash-Recovery
Byzantine
Copyright©2016 NTT Corp. All Rights Reserved.
16
故障モデルと複製アルゴリズム
故障なし
Fail-stop
Crash-Recovery
Byzantine
2-Phase Commit
3-Phase Commit
Paxos
Raft
Primary-Backup
Chain-Replication
Viewstamped-Replication
Broker-Replication
Stake-Replication
PBFT
Copyright©2016 NTT Corp. All Rights Reserved.
17
• Fischer,Lynch,Pattersonの3人が提唱したのでその頭文字から取って
FLP不可能性と呼ぶ
• 端的に言うと、下の図の赤線より下の世界では「全ての壊れていないサー
バが有限の時間で確実に合意に至るアルゴリズムは存在しえない」という
事を理論的に証明した
• 比較的緩い故障モデルでもダメということはそれより下では絶対に無理という事
FLP不可能性
故障なし
Fail-Stop(同期通信)
Fail-Stop(非同期通信)
Crash-Recovery
Byzantine
Copyright©2016 NTT Corp. All Rights Reserved.
18
• 個々のサーバ内の時間の流れを操って絶対に合意を終わらせようとしない
悪魔が存在したと仮定する
• 昼ごはんの行き先について合意を取る例
FLP不可能性を簡単に
状態を変更しうる通信と、状態の変更のタイミングとの間が悪ければ
非決定的な状態(bivalent)な状態が無限に続きうる
カレー
牛丼
牛丼
カレー
牛丼いいな カレーいいな
カレーいいな 牛丼いいな
Copyright©2016 NTT Corp. All Rights Reserved.
19
• 分散システムの問題が複数ある中、それぞれはお互いに「帰着」しあう事
ができる
• 合意問題が解ければリーダー選出ができる(リーダーを誰にするかに合意する)
• リーダー選出ができれば合意問題が解ける(リーダーが決めた値に全員従う)
• 合意問題が解ければアトミックブロードキャストができる(順序について合意する)
• アトミックブロードキャストができれば合意問題が解ける(最初の値で合意する)
• 合意問題が解ければState Machine Replicationが解ける(Multi Paxos的な)
• Replicated State Machineが解ければ合意問題が解ける(合意するステートマシン
を作ればよい)
などなど
• その中で「合意問題が解けない」は他の全ての問題も有限の時間では解けな
い事を意味する
• みんな無限の時間が掛かりうるから適当に迂回するなり諦めるなりしている
FLP不可能性の意味する大事な所
Copyright©2016 NTT Corp. All Rights Reserved.
20
•全員の参加者から「同じ順序」が観測できるブロード
キャスト
• 単一のリーダーから全員に送る、というのも立派な一つの解
• 参加者がそれぞれバラバラの順序で受信したブロードキャスト
メッセージを、同一の順序で観測し直すように合意する、という
方法もある
個々のアルゴリズムは詳しくないのでまた今度
補足:アトミックブロードキャスト
ZooKeeperはZookeeper Atomic Bloadcast(ZAB)プロトコル
を使っている。
Copyright©2016 NTT Corp. All Rights Reserved.
21
• 「同じ命令列を受け取ったら同じ状態になる」という仮想的なマシンを想
定する。
• 意識としては、オブジェクト指向でいうところのクラスが仮想的なマシン、メンバメ
ソッド呼び出しとその引数のセットが命令、命令の羅列が命令列、と考えて良い
• 仮想的なマシンを複製し、同じ命令列を与える事で同じ状態を複数台作り
上げる事ができる
補足: State Machine Replication
Walk(5)
Beam
Jump
Walk(3)
Dash(1)
Walk(5)
Beam
Jump
Walk(3)
Dash(1)
Walk(5)
Beam
Jump
Walk(3)
Dash(1)
整列アルゴリズム
Copyright©2016 NTT Corp. All Rights Reserved.
22
• 合意→リーダー選出→アトミックブロードキャスト→State Machine
Replicationの順で問題は難しくなるが、組み合わせて解く事ができる
• 問題を分解して代替可能な部品(モジュール)にするのでモジュラーアプローチ
• 解どのレイヤーまでをどう解くと効率が良いか未だに決定解はない
分散システムのモジュラーアプローチ
State Machine Replication
アトミックブロードキャスト
リーダー選出
合意
ZAB
ZK
Raft
Paxos
Multi
Paxos
Chubby
Copyright©2016 NTT Corp. All Rights Reserved.
23
•まともな論文であれば分散システムの歴史に立脚してい
るはず
•その歴史の中でそのアプローチはどの立ち位置なのか、
問題をどう分解しているのかを理解してから実装する
(尺が足りないから話せないFailure Detectorとか
Syncronizationとかの問題の話はまた今度)
論文を読んでそのまま実装しない事
Copyright©2016 NTT Corp. All Rights Reserved.
24
Phase 2
Two Phase Commit
•分散合意プロトコルの金字塔
•誰が最初の発明者かも明白でないほど古い
•故障時の挙動に大量の亜種がある
prepare
ok
commit
ok
coordinator
worker
worker
Phase 1
Copyright©2016 NTT Corp. All Rights Reserved.
25
Two Phase Commit
• prepare完了前にworkerが故障したらabort
• これはいい
prepare
ok
abort
ok
coordinator
worker
worker
Copyright©2016 NTT Corp. All Rights Reserved.
26
Two Phase Commit
prepare
ok
coordinator
worker
worker
Phase 1
•Commit前にcoordinatorが故障したら
Copyright©2016 NTT Corp. All Rights Reserved.
27
Phase 2
Two Phase Commit
•Commit前にcoordinatorが故障したら、それを検
知したリカバリノードがabortを依頼してロールバッ
ク
• 1つもcommitが成功していない事を調べる
prepare
ok
recover
ycoordinator
worker
worker
Phase 1
check abort
Copyright©2016 NTT Corp. All Rights Reserved.
28
Phase 2
Two Phase Commit
•死んだと思っていたcoordinatorが生きていたら?
• 食い違って死ぬ
• Two Phase Commitは基本的に死ぬ
prepare
ok
coordinator
worker
worker
Phase 1
abort
commit
committed
aborted
check
Copyright©2016 NTT Corp. All Rights Reserved.
29
Phase 2
Two Phase Commit
•commit途中でcoordinatorが落ちたら
prepare
ok
commit
ok
coordinator
worker
worker
Phase 1
Copyright©2016 NTT Corp. All Rights Reserved.
30
Phase 2
Two Phase Commit
•commit途中でcoordinatorが落ちたら回復ノー
ドが表れて一つでもcommitしていたら全部を
commitさせる
prepare
ok
commit
coordinator
worker
worker
Phase 1
commitcheck
ok
Copyright©2016 NTT Corp. All Rights Reserved.
31
Phase 2
Two Phase Commit
•commit途中でcoordinatorが落ちたら一つでも
commitしているときリカバリノードが全部を
commitさせる
•その途中で一部のworkerが落ちて後で復活したら?→死
prepare
ok
commit
coordinator
worker
worker
Phase 1
abortcheck
ok
committed
aborted
Copyright©2016 NTT Corp. All Rights Reserved.
32
Two Phase Commit
•Two Phase Commitは故障したり復活したりするとす
ぐ壊れる
•回復中に壊れるパターンや回復ノードが壊れるパターンま
で挙げだすと壊せるシナリオは山ほど出てくる
•弱点を補強したという触れ込みの3 Phase Commitなん
てものもあるけどやはり壊れている
•GoogleのChubbyの開発者Mike Burrows「合意プロ
トコルは一つしかない。Paxosだ」(≒他の合意プロトコ
ルは全て合意不能)
覚えていただきたい事実:
2 Phase Commitはバグっている
Copyright©2016 NTT Corp. All Rights Reserved.
33
•「Paxosっていうアルゴリズムがあるんですが…説明す
るには難しいのでまた今度にします」←分散システムに
ついて語る人あるある
•Paxos怖くないよ!合意しかできないだけだよ!
分散システムあるある
Copyright©2016 NTT Corp. All Rights Reserved.
34
Paxos
•Lamport先生が「参加者の故障や復活がある場合絶対
に合意には至れない」ということを証明しようとして逆
に生み出してしまった合意プロトコル
• 実は故障に耐える合意プロトコルは他にもviewstamped replicationと
かstake replicationとかいろいろあるが、きっちり証明されたのは
Paxosが最初
出典:http://lamport.azurewebsites.net/pubs/pubs.html#lamport-paxos
Lamport先生
最近はTLA+の布教にお熱
Copyright©2016 NTT Corp. All Rights Reserved.
35
Paxos
• 複雑さに定評がある(とよく言われる)
• prepare, proposeがバージョン番号を持つ
prepare(n)
ok(n, v)
propose(n, v)
accept(n)
proposer
acceptor
acceptor
Copyright©2016 NTT Corp. All Rights Reserved.
36
Paxos
• Coordinator
• prepare(n)に対して過半数からok(n,v)が貰えたらその中で最大のnに対するvを全
workerに投げる
このvがnullなら自分自身のvを使う
nullでないならvは生死不明な他のCoordinatorのvである
• Acceptor
• 過去に見たprepare(n)のうち最大のnであればそれにok(n,v)を返す。そうでなけれ
ばng(n')
vは過去に一度も合意してない場合nullかも知れない
• Learner
• 確定した値を読みに来る。Acceptorに最新の値vを訊きに来る。
• 過半数のAcceptorが同じ値を返さない限り、値が読めた(確定した)事にならない
• Learnerが観測するフェーズまで含めるとPaxosはThree Phaseある事になる
25行で説明するPaxos: http://nil.csail.mit.edu/6.824/2015/notes/paxos-code.html
Copyright©2016 NTT Corp. All Rights Reserved.
37
Paxos
•2PCだと死んだシナリオ
• 蘇るcoordinator
•間に入った別のcoordinatorがバージョン番号を変
えるので間違った合意に至らなくなる
prepare(n)
ok(n,v)
proposer
acceptor
acceptor
propose(n',v)
propose(n)
prepare(n')
ng(n',v)
ng(n',v)
Copyright©2016 NTT Corp. All Rights Reserved.
38
Paxos
• 過半数にproposeが届いた時点でクラスタは合意した事になる
• workerが復活してもok
• 不完全な複製は後続のcoordinatorが複製し直してくれる
prepare(n)
ok(n, v)
propose(n, v1)
proposer1
acceptor
acceptor
coordinator2
prepare(x)
ok(x, v1)
propose(x, v1)
Copyright©2016 NTT Corp. All Rights Reserved.
39
Paxos
• 最後にLeanerが値を読みに来る
prepare(n)
ok(n, v)
propose(n, v)
accept(n)
proposer
acceptor
acceptor
learner
read()
ok(n, v)
ok(n, v)
Copyright©2016 NTT Corp. All Rights Reserved.
40
Multi-Paxos
• Paxosは一度合意した値は二度と覆らないので、まっさらな合意を
次々と新しく作り出していく事で命令列を複製し、State Machine
Replicationを成す
• Learnerが読んで合意の確認が取れた命令を実行していく
• 命令列に隙間ができたらスキップとかいろんな工夫があるので気になる人はRaftの論文を。
未実行命令
実行済命令x=10
x=10
x=10
1
y=3
y=3
y=3
2
z=2
z=2
z=2
3
a=8
a=8
a=8
4
b=5
5
c=9
6
Paxosの合
意1回分
Copyright©2016 NTT Corp. All Rights Reserved.
41
•In Search of an Understandable Consensus
Algorithmという衝撃的なタイトルで登場したRaft
• Understandableの価値を学会に認めさせるために苦労したのだとか
• Paxosが合意(Consensus)しか解いてないのに対し、Raftは
合意はもちろんState Machine Replicationも解ける(=多く
の分散アルゴリズム問題に帰着できる)
• Googlerは合意アルゴリズムに過ぎないPaxosをロックマネージャ等へ
帰着させるのに大変な苦労をしたが、SMRから帰着させるのはずっと楽
であるという目論見
• PaxosのProposerとLearnerの両方をRaftのLeaderが兼ね
ている点がすごい(Multi-Paxos的な高速化をしやすい)
RaftとPaxosの類似性
Copyright©2016 NTT Corp. All Rights Reserved.
42
• Candidate(候補者)のみの状態からスタート
• お互いがお互いを知っている
• 全員にRequestVoteに半数以上がOKを返してくれたらLeaderへ昇格
• RequestVoteを送るまでの時間を乱数で散らす事で収束を高速化
• LeaderがAppendEntriesを送る事でSMRを実現
Raftを手短に
RequestVote(t)
ok
AppendEntries(t,h)
ok(n)
candidate
candidate
candidate
Copyright©2016 NTT Corp. All Rights Reserved.
43
Raftを手短に
AppendEntries(t,h+1)
ok(n+1)
candidate
candidate
leader
• AppendEntriesの中にMulti-Paxosの重要な要素が詰まっている
• Entryが空ならheartbeat変わり
• candidateから返ってきたnの中の最小値を全員に送る事で「過去に合意に至ったロ
グのIDを共有」できる
Multi-Paxosでの合意済みIDの共有もこの中に入ってる
AppendEntries(t,h)
ok(n)
Copyright©2016 NTT Corp. All Rights Reserved.
44
Raftを手短に
•AppendEntries
• Leader「みんなー、Team 13番のリーダーだよ。前回のログの
IDは同じTerm13の38だったね。39のログの内容はXXXだよ。
過去にみんなに合意してもらえたIDの最小値は36までだからス
テートマシンは36まで進めて良いよ。」
•RequestVote
• Candidate「Leader死んでる気がするから僕が立候補します。
前回のログはTerm13の46だったよ。」
•これら2つのRPCだけでMulti-Paxosに相当する事が実
現できるように練りこまれたのがRaft
• 過去の合意の観測(PaxosでいうLearnerの仕事)を、Leaderが同
時に行ってRPCの中に折りたたんでいるのがかっこいい。
Copyright©2016 NTT Corp. All Rights Reserved.
45
•分散システムエアプ勢多すぎる
• ポンチ絵とにらめっこし続ける会議をヤメロ
•既成品を使うだけではなく、一緒に血反吐吐き
ながらコード書きましょう
• コードを書かないと見えてこないものはいっぱいある
• システムの肌感覚を掴んでこそエンジニア
手を動かせ

More Related Content

What's hot

Raft
RaftRaft
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
 
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
NTT DATA OSS Professional Services
 
普通の人でもわかる Paxos
普通の人でもわかる Paxos普通の人でもわかる Paxos
普通の人でもわかる Paxos
tyonekura
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Akihiro Suda
 
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2
Takashi Hoshino
 
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
Etsuji Nakai
 
Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編
Yuki Morishita
 
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajpAt least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
 
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
NTT DATA Technology & Innovation
 
DockerとPodmanの比較
DockerとPodmanの比較DockerとPodmanの比較
DockerとPodmanの比較
Akihiro Suda
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
 
BuildKitの概要と最近の機能
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
Kohei Tokunaga
 
DockerコンテナでGitを使う
DockerコンテナでGitを使うDockerコンテナでGitを使う
DockerコンテナでGitを使う
Kazuhiro Suga
 
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけRDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
Recruit Technologies
 
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
NTT DATA Technology & Innovation
 
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
NTT DATA Technology & Innovation
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
 
詳説データベース輪読会: 分散合意その2
詳説データベース輪読会: 分散合意その2詳説データベース輪読会: 分散合意その2
詳説データベース輪読会: 分散合意その2
Sho Nakazono
 

What's hot (20)

Raft
RaftRaft
Raft
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
 
普通の人でもわかる Paxos
普通の人でもわかる Paxos普通の人でもわかる Paxos
普通の人でもわかる Paxos
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2
 
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
 
Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編
 
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajpAt least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
 
DockerとPodmanの比較
DockerとPodmanの比較DockerとPodmanの比較
DockerとPodmanの比較
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
 
BuildKitの概要と最近の機能
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
 
DockerコンテナでGitを使う
DockerコンテナでGitを使うDockerコンテナでGitを使う
DockerコンテナでGitを使う
 
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけRDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
 
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
 
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
 
詳説データベース輪読会: 分散合意その2
詳説データベース輪読会: 分散合意その2詳説データベース輪読会: 分散合意その2
詳説データベース輪読会: 分散合意その2
 

Viewers also liked

エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)
エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)
エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)Takeshi HASEGAWA
 
Yahoo!ブラウザーアプリのプロダクトマネージャーが考えていること
Yahoo!ブラウザーアプリのプロダクトマネージャーが考えていることYahoo!ブラウザーアプリのプロダクトマネージャーが考えていること
Yahoo!ブラウザーアプリのプロダクトマネージャーが考えていること
Yahoo!デベロッパーネットワーク
 
行列ができるECサイトの悩み~ショッピングや決済の技術的問題と処方箋
行列ができるECサイトの悩み~ショッピングや決済の技術的問題と処方箋行列ができるECサイトの悩み~ショッピングや決済の技術的問題と処方箋
行列ができるECサイトの悩み~ショッピングや決済の技術的問題と処方箋
Yahoo!デベロッパーネットワーク
 
ヤフオク!の快適なカスタマー体験を支えるモバイルアプリのライブアップデート技術
ヤフオク!の快適なカスタマー体験を支えるモバイルアプリのライブアップデート技術ヤフオク!の快適なカスタマー体験を支えるモバイルアプリのライブアップデート技術
ヤフオク!の快適なカスタマー体験を支えるモバイルアプリのライブアップデート技術
Yahoo!デベロッパーネットワーク
 
Yahoo! JAPANのサービス開発を10倍早くした社内PaaS構築の今とこれから
Yahoo! JAPANのサービス開発を10倍早くした社内PaaS構築の今とこれからYahoo! JAPANのサービス開発を10倍早くした社内PaaS構築の今とこれから
Yahoo! JAPANのサービス開発を10倍早くした社内PaaS構築の今とこれから
Yahoo!デベロッパーネットワーク
 
Serverlessconf Tokyo 2017 Biz serverless お客様のビジネスを支える サーバーレスアーキテクチャーと開発としてのビジ...
Serverlessconf Tokyo 2017 Biz serverless お客様のビジネスを支えるサーバーレスアーキテクチャーと開発としてのビジ...Serverlessconf Tokyo 2017 Biz serverless お客様のビジネスを支えるサーバーレスアーキテクチャーと開発としてのビジ...
Serverlessconf Tokyo 2017 Biz serverless お客様のビジネスを支える サーバーレスアーキテクチャーと開発としてのビジ...
Hiroyuki Hiki
 
Software Productivity and Serverless
Software Productivity and ServerlessSoftware Productivity and Serverless
Software Productivity and Serverless
Nick Gottlieb
 
[serverlessconf2017]FaaSで簡単に実現する数十万RPSスパイク負荷試験
[serverlessconf2017]FaaSで簡単に実現する数十万RPSスパイク負荷試験[serverlessconf2017]FaaSで簡単に実現する数十万RPSスパイク負荷試験
[serverlessconf2017]FaaSで簡単に実現する数十万RPSスパイク負荷試験
Takahiro Moteki
 
now
nownow
Pythonと機械学習によるWebセキュリティの自動化
Pythonと機械学習によるWebセキュリティの自動化Pythonと機械学習によるWebセキュリティの自動化
Pythonと機械学習によるWebセキュリティの自動化
Isao Takaesu
 
BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyo
BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyoBluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyo
BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyo
Masahiro NAKAYAMA
 
Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤
Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤
Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤
Yu Yamada
 
Cassandra Explained
Cassandra ExplainedCassandra Explained
Cassandra Explained
Eric Evans
 
データテクノロジースペシャル:Yahoo! JAPANにおけるメタデータ管理の試み
データテクノロジースペシャル:Yahoo! JAPANにおけるメタデータ管理の試みデータテクノロジースペシャル:Yahoo! JAPANにおけるメタデータ管理の試み
データテクノロジースペシャル:Yahoo! JAPANにおけるメタデータ管理の試み
Yahoo!デベロッパーネットワーク
 
Lecture univ.tokyo 2017_okanohara
Lecture univ.tokyo 2017_okanoharaLecture univ.tokyo 2017_okanohara
Lecture univ.tokyo 2017_okanohara
Preferred Networks
 
Docker最新動向2017秋+セキュリティの落とし穴
Docker最新動向2017秋+セキュリティの落とし穴Docker最新動向2017秋+セキュリティの落とし穴
Docker最新動向2017秋+セキュリティの落とし穴
Masahito Zembutsu
 
CPUから見たG1GC
CPUから見たG1GCCPUから見たG1GC
CPUから見たG1GC
Kenji Kazumura
 

Viewers also liked (20)

エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)
エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)
エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)
 
Google Dremel
Google DremelGoogle Dremel
Google Dremel
 
Yahoo!ブラウザーアプリのプロダクトマネージャーが考えていること
Yahoo!ブラウザーアプリのプロダクトマネージャーが考えていることYahoo!ブラウザーアプリのプロダクトマネージャーが考えていること
Yahoo!ブラウザーアプリのプロダクトマネージャーが考えていること
 
行列ができるECサイトの悩み~ショッピングや決済の技術的問題と処方箋
行列ができるECサイトの悩み~ショッピングや決済の技術的問題と処方箋行列ができるECサイトの悩み~ショッピングや決済の技術的問題と処方箋
行列ができるECサイトの悩み~ショッピングや決済の技術的問題と処方箋
 
ヤフオク!の快適なカスタマー体験を支えるモバイルアプリのライブアップデート技術
ヤフオク!の快適なカスタマー体験を支えるモバイルアプリのライブアップデート技術ヤフオク!の快適なカスタマー体験を支えるモバイルアプリのライブアップデート技術
ヤフオク!の快適なカスタマー体験を支えるモバイルアプリのライブアップデート技術
 
市場で勝ち続けるための品質とテストの技術①
市場で勝ち続けるための品質とテストの技術①市場で勝ち続けるための品質とテストの技術①
市場で勝ち続けるための品質とテストの技術①
 
市場で勝ち続けるための品質とテストの技術②
市場で勝ち続けるための品質とテストの技術②市場で勝ち続けるための品質とテストの技術②
市場で勝ち続けるための品質とテストの技術②
 
Yahoo! JAPANのサービス開発を10倍早くした社内PaaS構築の今とこれから
Yahoo! JAPANのサービス開発を10倍早くした社内PaaS構築の今とこれからYahoo! JAPANのサービス開発を10倍早くした社内PaaS構築の今とこれから
Yahoo! JAPANのサービス開発を10倍早くした社内PaaS構築の今とこれから
 
Serverlessconf Tokyo 2017 Biz serverless お客様のビジネスを支える サーバーレスアーキテクチャーと開発としてのビジ...
Serverlessconf Tokyo 2017 Biz serverless お客様のビジネスを支えるサーバーレスアーキテクチャーと開発としてのビジ...Serverlessconf Tokyo 2017 Biz serverless お客様のビジネスを支えるサーバーレスアーキテクチャーと開発としてのビジ...
Serverlessconf Tokyo 2017 Biz serverless お客様のビジネスを支える サーバーレスアーキテクチャーと開発としてのビジ...
 
Software Productivity and Serverless
Software Productivity and ServerlessSoftware Productivity and Serverless
Software Productivity and Serverless
 
[serverlessconf2017]FaaSで簡単に実現する数十万RPSスパイク負荷試験
[serverlessconf2017]FaaSで簡単に実現する数十万RPSスパイク負荷試験[serverlessconf2017]FaaSで簡単に実現する数十万RPSスパイク負荷試験
[serverlessconf2017]FaaSで簡単に実現する数十万RPSスパイク負荷試験
 
now
nownow
now
 
Pythonと機械学習によるWebセキュリティの自動化
Pythonと機械学習によるWebセキュリティの自動化Pythonと機械学習によるWebセキュリティの自動化
Pythonと機械学習によるWebセキュリティの自動化
 
BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyo
BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyoBluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyo
BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyo
 
Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤
Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤
Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤
 
Cassandra Explained
Cassandra ExplainedCassandra Explained
Cassandra Explained
 
データテクノロジースペシャル:Yahoo! JAPANにおけるメタデータ管理の試み
データテクノロジースペシャル:Yahoo! JAPANにおけるメタデータ管理の試みデータテクノロジースペシャル:Yahoo! JAPANにおけるメタデータ管理の試み
データテクノロジースペシャル:Yahoo! JAPANにおけるメタデータ管理の試み
 
Lecture univ.tokyo 2017_okanohara
Lecture univ.tokyo 2017_okanoharaLecture univ.tokyo 2017_okanohara
Lecture univ.tokyo 2017_okanohara
 
Docker最新動向2017秋+セキュリティの落とし穴
Docker最新動向2017秋+セキュリティの落とし穴Docker最新動向2017秋+セキュリティの落とし穴
Docker最新動向2017秋+セキュリティの落とし穴
 
CPUから見たG1GC
CPUから見たG1GCCPUから見たG1GC
CPUから見たG1GC
 

More from Kumazaki Hiroki

An overview of query optimization in relational systems 論文紹介
An overview of query optimization in relational systems 論文紹介An overview of query optimization in relational systems 論文紹介
An overview of query optimization in relational systems 論文紹介
Kumazaki Hiroki
 
トランザクション入門
トランザクション入門 トランザクション入門
トランザクション入門
Kumazaki Hiroki
 
Cache obliviousの話
Cache obliviousの話Cache obliviousの話
Cache obliviousの話
Kumazaki Hiroki
 
Jubatus hackathon2
Jubatus hackathon2Jubatus hackathon2
Jubatus hackathon2
Kumazaki Hiroki
 
キャッシュコヒーレントに囚われない並列カウンタ達
キャッシュコヒーレントに囚われない並列カウンタ達キャッシュコヒーレントに囚われない並列カウンタ達
キャッシュコヒーレントに囚われない並列カウンタ達
Kumazaki Hiroki
 
What is jubatus (short)
What is jubatus (short)What is jubatus (short)
What is jubatus (short)
Kumazaki Hiroki
 
What is jubatus? How it works for you?
What is jubatus? How it works for you?What is jubatus? How it works for you?
What is jubatus? How it works for you?
Kumazaki Hiroki
 
よくわかるHopscotch hashing
よくわかるHopscotch hashingよくわかるHopscotch hashing
よくわかるHopscotch hashingKumazaki Hiroki
 
冬のLock free祭り safe
冬のLock free祭り safe冬のLock free祭り safe
冬のLock free祭り safeKumazaki Hiroki
 
Bloom filter
Bloom filterBloom filter
Bloom filter
Kumazaki Hiroki
 
SkipGraph
SkipGraphSkipGraph
SkipGraph
Kumazaki Hiroki
 
Lockfree Priority Queue
Lockfree Priority QueueLockfree Priority Queue
Lockfree Priority Queue
Kumazaki Hiroki
 
Lockfree Queue
Lockfree QueueLockfree Queue
Lockfree Queue
Kumazaki Hiroki
 

More from Kumazaki Hiroki (15)

An overview of query optimization in relational systems 論文紹介
An overview of query optimization in relational systems 論文紹介An overview of query optimization in relational systems 論文紹介
An overview of query optimization in relational systems 論文紹介
 
トランザクション入門
トランザクション入門 トランザクション入門
トランザクション入門
 
Cache obliviousの話
Cache obliviousの話Cache obliviousの話
Cache obliviousの話
 
Jubatus hackathon2
Jubatus hackathon2Jubatus hackathon2
Jubatus hackathon2
 
キャッシュコヒーレントに囚われない並列カウンタ達
キャッシュコヒーレントに囚われない並列カウンタ達キャッシュコヒーレントに囚われない並列カウンタ達
キャッシュコヒーレントに囚われない並列カウンタ達
 
What is jubatus (short)
What is jubatus (short)What is jubatus (short)
What is jubatus (short)
 
What is jubatus? How it works for you?
What is jubatus? How it works for you?What is jubatus? How it works for you?
What is jubatus? How it works for you?
 
よくわかるHopscotch hashing
よくわかるHopscotch hashingよくわかるHopscotch hashing
よくわかるHopscotch hashing
 
冬のLock free祭り safe
冬のLock free祭り safe冬のLock free祭り safe
冬のLock free祭り safe
 
MerDy
MerDyMerDy
MerDy
 
Bloom filter
Bloom filterBloom filter
Bloom filter
 
SkipGraph
SkipGraphSkipGraph
SkipGraph
 
Lockfree list
Lockfree listLockfree list
Lockfree list
 
Lockfree Priority Queue
Lockfree Priority QueueLockfree Priority Queue
Lockfree Priority Queue
 
Lockfree Queue
Lockfree QueueLockfree Queue
Lockfree Queue
 

分散システムについて語らせてくれ

  • 1. Copyright©2016 NTT Corp. All Rights Reserved. 分散システムについて 語らせてくれ 日本電信電話株式会社 ソフトウェアイノベーションセンタ 熊崎 宏樹 (@kumagi)
  • 2. Copyright©2016 NTT Corp. All Rights Reserved. 2 1.分散自体を目的にしない事 2.論文を読んでそのまま実装しない事 3.Two Phase Commitを使わない事 4.手を動かす事 目次 分散システムを作る際に気をつけて欲しい事
  • 3. Copyright©2016 NTT Corp. All Rights Reserved. 3 • よくわかってない人でもCloudera Managerをダウンロードして1時間後 には巨大なHadoopクラスタを立ち上げてYARN, HDFS, Spark, HBase などで遊ぶ事ができる。 • 世の中では分散システムが必要以上に喧伝されている • 「コンピュータ1台よりも2台の方が高速」という直感に対して反論するの は意外と難しい • あなたのそのシステム、本当に分散システムじゃないとダメ? 分散自体を目的にしない事
  • 4. Copyright©2016 NTT Corp. All Rights Reserved. 4 L1 キャッシュ参照 分岐予測ミス L2 キャッシュ参照 Mutexのlock/unlock メモリ参照 1KBをZIP圧縮 1Gbpsで2KB送る メモリから1MB連続で読む 同一のデータセンタ内のマシンと通信1往復 HDDシーク HDDから1MB読み出し カリフォルニアとオランダ間で通信1往復 システムの肌感覚を掴め 0.5 ns 5 ns 7 ns 25 ns 100 ns 3,000 ns 20,000 ns 250,000 ns 500,000 ns 10,000,000 ns 20,000,000 ns 150,000,000 ns みんなが知っているべき数値 by Jeff Dean
  • 5. Copyright©2016 NTT Corp. All Rights Reserved. 5 L1 キャッシュ参照 分岐予測ミス L2 キャッシュ参照 Mutexのlock/unlock メモリ参照 1KBをZIP圧縮 1Gbpsで2KB送る メモリから1MB連続で読む 同一のデータセンタ内のマシンと通信1往復 HDDシーク HDDから1MB読み出し カリフォルニアとオランダ間で通信1往復 システムの肌感覚を掴め 0.5 ns 5 ns 7 ns 25 ns 100 ns 3,000 ns 20,000 ns 250,000 ns 500,000 ns 10,000,000 ns 20,000,000 ns 150,000,000 ns みんなが知っているべき数値 by Jeff Dean
  • 6. Copyright©2016 NTT Corp. All Rights Reserved. 6 分散システム化すると基本的に遅くなる。 大抵はネットワークが遅延の支配項になる。 速くなる場合のほうがむしろ例外的と思ったほうが良い。 ワークロードと照らし合わせてマイクロベンチを取った 後で分散システム化を検討して欲しい(頼むから実装上 の重要な意思決定で分散ミドルウェアを使用する事を目 的にしないで欲しい) システムの肌感覚を掴め とにかく測れ 測らずに分散システム化するのは Early Optimizationの一種
  • 7. Copyright©2016 NTT Corp. All Rights Reserved. 7 • 分散システムの論文は多く出ているがその大半は「やってみたレポート」 「作ってみた」→「動いたっぽい」→「測った」→「Yappy!」 • 分散システム界隈の研究は過去の研究の蓄積が蓄積扱いされにくい分野の 一つであり、論文を真に受けてはならない • 他にそう感じる研究分野はHCI分野 • 故障モデルなどが実は結構厳しく規定されており、そこを読み飛ばすと痛 い目に遭う 論文を読んでそのまま実装しない事
  • 8. Copyright©2016 NTT Corp. All Rights Reserved. 8 • レプリケーションプロトコルとして典型的に見かけるパターン • 一番IDが小さいServerをPrimaryとして、MasterがBackupへのレプリケーション を担当する • ReadもWriteもPrimaryが受け取ることによって一貫性の問題を回避 • Primaryが壊れたらBackupのうち一番IDが小さい奴がPrimaryへ昇格する • HDFSでメタデータの複製に使われているのはこれ ケーススタディ:Primary-Backup Client Server1 Server2 Server3 Server4 Read Write
  • 9. Copyright©2016 NTT Corp. All Rights Reserved. 9 • 次に見かけるレプリケーションプロトコル • バケツリレーのように受け取ったものを即座に次のサーバに渡していく • データを全部受け取る前から次のサーバにリレーできるので大容量のデータ転送に強 くメッセージの飛び交う回数はサーバ台数+1で最小だがサーバ台数に比例するメッ セージ遅延がかかる • 故障したサーバはスキップする • HDFSでデータの複製に使われているのはこれ ケーススタディ:Chain-Replication Client Server1 Server2 Server3 Server4 Read Write
  • 10. Copyright©2016 NTT Corp. All Rights Reserved. 10 プロトコル名 通信遅延数 メッセージ数 Primary-Backup 4回 2N個 Chain-Replication N+1回 N+1個 ケーススタディ: Primary-Backup と Chain-Replication • 通信の特性を見極めて最適なプロトコルを使おう • Primary-Backupは「細かくて素早い」特性 • Chain-Replicationは「時間が掛かっても通信効率が良い」特性 • どちらもサーバが故障する場合は縮退運転していき、最小1台でも稼動は する
  • 11. Copyright©2016 NTT Corp. All Rights Reserved. 11 ちょっと待った
  • 12. Copyright©2016 NTT Corp. All Rights Reserved. 12 • これは容易にバグる • Readを常に全体に伝える必要があるかは実装次第だが典型例として • みんながカジュアルに生死判断を行うと食い違ったときに容易に世界が壊れる いわゆるSplit-Brain ケーススタディ:Primary-Backupの故障 Client Server1 Server2 Server3 Server4 Write(x=2) Read(x) -> 0 Server2の 応答が遅かったので 死んでると想定して 無視 Server1の 応答が遅かったので 死んでると想定して Server2へリトライ
  • 13. Copyright©2016 NTT Corp. All Rights Reserved. 13 間違った実装が世界を揺るがす • 「Redis Sentinelという自動レプリケーションの仕組みを作りました。 最強です(キリッ」 • しかし特定の実行パターンによって内容物の半分以上が失われる • Jepsen Testが築く屍の山 • 様々な分散ミドルウェアで 意図的にSplit-Brain状態を引き起こして挙動を確認する一連のブログポス ト群:Call me maybe • 面白いぐらい多くのシステムが次々と壊れていく (生き残ったのはZK, Riak, etcd, consulぐらい? • 興味のある人はぜひURL参照 https://aphyr.com/tags/jepsen
  • 14. Copyright©2016 NTT Corp. All Rights Reserved. 14 • サーバが壊れた場合の挙動をどうするかは論文に書いてあるけれど、何が 起きたらサーバが壊れたと認識するかは書いてない • これらのプロトコルはサーバの故障情報を天から与えられる物として設計している • プログラマ「そっか、じゃあ通信がタイムアウトしたら故障ね」←バグの温床 • プログラマ「タイムアウトの閾値を大きくすれば誤検知が減って安心だね」←低速化 • プログラマ「タイムアウトの閾値をどうすればいいのさ??」←決定解はない • 分散システムの論文ではシステムに対して前提を置いていることが多いが、 なぜその前提を置いているのかは知識がないとわからない • Primary-BackupとChain-ReplicationはFail-Stop故障モデルを前提 としている • それより厳しい故障モデルの上では容易に壊れる • その故障モデルの解説はこれからする そのプロトコル、凶暴につき
  • 15. Copyright©2016 NTT Corp. All Rights Reserved. 15 故障なし • サーバが壊れる状況のしんどさを段階的に切り分けたモデルのこと • より楽な故障モデルで動かないプロトコルは、しんどい故障モデルでは 「絶対に」動かない • Fail-Stop: 壊れたサーバはいずれ全部のサーバから故障として観測される。壊れてい ないサーバを壊れたと誤認する事や、壊れたサーバを壊れていないと誤認する事は発 生しない。壊れたサーバは二度と復活しない。 • Crash-Recover: サーバは壊れるかも知れないが復活する事もある。つまりいつまで も故障したと断言できない。 故障モデル し ん ど い Fail-Stop(同期通信) Fail-Stop(非同期通信) Crash-Recovery Byzantine
  • 16. Copyright©2016 NTT Corp. All Rights Reserved. 16 故障モデルと複製アルゴリズム 故障なし Fail-stop Crash-Recovery Byzantine 2-Phase Commit 3-Phase Commit Paxos Raft Primary-Backup Chain-Replication Viewstamped-Replication Broker-Replication Stake-Replication PBFT
  • 17. Copyright©2016 NTT Corp. All Rights Reserved. 17 • Fischer,Lynch,Pattersonの3人が提唱したのでその頭文字から取って FLP不可能性と呼ぶ • 端的に言うと、下の図の赤線より下の世界では「全ての壊れていないサー バが有限の時間で確実に合意に至るアルゴリズムは存在しえない」という 事を理論的に証明した • 比較的緩い故障モデルでもダメということはそれより下では絶対に無理という事 FLP不可能性 故障なし Fail-Stop(同期通信) Fail-Stop(非同期通信) Crash-Recovery Byzantine
  • 18. Copyright©2016 NTT Corp. All Rights Reserved. 18 • 個々のサーバ内の時間の流れを操って絶対に合意を終わらせようとしない 悪魔が存在したと仮定する • 昼ごはんの行き先について合意を取る例 FLP不可能性を簡単に 状態を変更しうる通信と、状態の変更のタイミングとの間が悪ければ 非決定的な状態(bivalent)な状態が無限に続きうる カレー 牛丼 牛丼 カレー 牛丼いいな カレーいいな カレーいいな 牛丼いいな
  • 19. Copyright©2016 NTT Corp. All Rights Reserved. 19 • 分散システムの問題が複数ある中、それぞれはお互いに「帰着」しあう事 ができる • 合意問題が解ければリーダー選出ができる(リーダーを誰にするかに合意する) • リーダー選出ができれば合意問題が解ける(リーダーが決めた値に全員従う) • 合意問題が解ければアトミックブロードキャストができる(順序について合意する) • アトミックブロードキャストができれば合意問題が解ける(最初の値で合意する) • 合意問題が解ければState Machine Replicationが解ける(Multi Paxos的な) • Replicated State Machineが解ければ合意問題が解ける(合意するステートマシン を作ればよい) などなど • その中で「合意問題が解けない」は他の全ての問題も有限の時間では解けな い事を意味する • みんな無限の時間が掛かりうるから適当に迂回するなり諦めるなりしている FLP不可能性の意味する大事な所
  • 20. Copyright©2016 NTT Corp. All Rights Reserved. 20 •全員の参加者から「同じ順序」が観測できるブロード キャスト • 単一のリーダーから全員に送る、というのも立派な一つの解 • 参加者がそれぞれバラバラの順序で受信したブロードキャスト メッセージを、同一の順序で観測し直すように合意する、という 方法もある 個々のアルゴリズムは詳しくないのでまた今度 補足:アトミックブロードキャスト ZooKeeperはZookeeper Atomic Bloadcast(ZAB)プロトコル を使っている。
  • 21. Copyright©2016 NTT Corp. All Rights Reserved. 21 • 「同じ命令列を受け取ったら同じ状態になる」という仮想的なマシンを想 定する。 • 意識としては、オブジェクト指向でいうところのクラスが仮想的なマシン、メンバメ ソッド呼び出しとその引数のセットが命令、命令の羅列が命令列、と考えて良い • 仮想的なマシンを複製し、同じ命令列を与える事で同じ状態を複数台作り 上げる事ができる 補足: State Machine Replication Walk(5) Beam Jump Walk(3) Dash(1) Walk(5) Beam Jump Walk(3) Dash(1) Walk(5) Beam Jump Walk(3) Dash(1) 整列アルゴリズム
  • 22. Copyright©2016 NTT Corp. All Rights Reserved. 22 • 合意→リーダー選出→アトミックブロードキャスト→State Machine Replicationの順で問題は難しくなるが、組み合わせて解く事ができる • 問題を分解して代替可能な部品(モジュール)にするのでモジュラーアプローチ • 解どのレイヤーまでをどう解くと効率が良いか未だに決定解はない 分散システムのモジュラーアプローチ State Machine Replication アトミックブロードキャスト リーダー選出 合意 ZAB ZK Raft Paxos Multi Paxos Chubby
  • 23. Copyright©2016 NTT Corp. All Rights Reserved. 23 •まともな論文であれば分散システムの歴史に立脚してい るはず •その歴史の中でそのアプローチはどの立ち位置なのか、 問題をどう分解しているのかを理解してから実装する (尺が足りないから話せないFailure Detectorとか Syncronizationとかの問題の話はまた今度) 論文を読んでそのまま実装しない事
  • 24. Copyright©2016 NTT Corp. All Rights Reserved. 24 Phase 2 Two Phase Commit •分散合意プロトコルの金字塔 •誰が最初の発明者かも明白でないほど古い •故障時の挙動に大量の亜種がある prepare ok commit ok coordinator worker worker Phase 1
  • 25. Copyright©2016 NTT Corp. All Rights Reserved. 25 Two Phase Commit • prepare完了前にworkerが故障したらabort • これはいい prepare ok abort ok coordinator worker worker
  • 26. Copyright©2016 NTT Corp. All Rights Reserved. 26 Two Phase Commit prepare ok coordinator worker worker Phase 1 •Commit前にcoordinatorが故障したら
  • 27. Copyright©2016 NTT Corp. All Rights Reserved. 27 Phase 2 Two Phase Commit •Commit前にcoordinatorが故障したら、それを検 知したリカバリノードがabortを依頼してロールバッ ク • 1つもcommitが成功していない事を調べる prepare ok recover ycoordinator worker worker Phase 1 check abort
  • 28. Copyright©2016 NTT Corp. All Rights Reserved. 28 Phase 2 Two Phase Commit •死んだと思っていたcoordinatorが生きていたら? • 食い違って死ぬ • Two Phase Commitは基本的に死ぬ prepare ok coordinator worker worker Phase 1 abort commit committed aborted check
  • 29. Copyright©2016 NTT Corp. All Rights Reserved. 29 Phase 2 Two Phase Commit •commit途中でcoordinatorが落ちたら prepare ok commit ok coordinator worker worker Phase 1
  • 30. Copyright©2016 NTT Corp. All Rights Reserved. 30 Phase 2 Two Phase Commit •commit途中でcoordinatorが落ちたら回復ノー ドが表れて一つでもcommitしていたら全部を commitさせる prepare ok commit coordinator worker worker Phase 1 commitcheck ok
  • 31. Copyright©2016 NTT Corp. All Rights Reserved. 31 Phase 2 Two Phase Commit •commit途中でcoordinatorが落ちたら一つでも commitしているときリカバリノードが全部を commitさせる •その途中で一部のworkerが落ちて後で復活したら?→死 prepare ok commit coordinator worker worker Phase 1 abortcheck ok committed aborted
  • 32. Copyright©2016 NTT Corp. All Rights Reserved. 32 Two Phase Commit •Two Phase Commitは故障したり復活したりするとす ぐ壊れる •回復中に壊れるパターンや回復ノードが壊れるパターンま で挙げだすと壊せるシナリオは山ほど出てくる •弱点を補強したという触れ込みの3 Phase Commitなん てものもあるけどやはり壊れている •GoogleのChubbyの開発者Mike Burrows「合意プロ トコルは一つしかない。Paxosだ」(≒他の合意プロトコ ルは全て合意不能) 覚えていただきたい事実: 2 Phase Commitはバグっている
  • 33. Copyright©2016 NTT Corp. All Rights Reserved. 33 •「Paxosっていうアルゴリズムがあるんですが…説明す るには難しいのでまた今度にします」←分散システムに ついて語る人あるある •Paxos怖くないよ!合意しかできないだけだよ! 分散システムあるある
  • 34. Copyright©2016 NTT Corp. All Rights Reserved. 34 Paxos •Lamport先生が「参加者の故障や復活がある場合絶対 に合意には至れない」ということを証明しようとして逆 に生み出してしまった合意プロトコル • 実は故障に耐える合意プロトコルは他にもviewstamped replicationと かstake replicationとかいろいろあるが、きっちり証明されたのは Paxosが最初 出典:http://lamport.azurewebsites.net/pubs/pubs.html#lamport-paxos Lamport先生 最近はTLA+の布教にお熱
  • 35. Copyright©2016 NTT Corp. All Rights Reserved. 35 Paxos • 複雑さに定評がある(とよく言われる) • prepare, proposeがバージョン番号を持つ prepare(n) ok(n, v) propose(n, v) accept(n) proposer acceptor acceptor
  • 36. Copyright©2016 NTT Corp. All Rights Reserved. 36 Paxos • Coordinator • prepare(n)に対して過半数からok(n,v)が貰えたらその中で最大のnに対するvを全 workerに投げる このvがnullなら自分自身のvを使う nullでないならvは生死不明な他のCoordinatorのvである • Acceptor • 過去に見たprepare(n)のうち最大のnであればそれにok(n,v)を返す。そうでなけれ ばng(n') vは過去に一度も合意してない場合nullかも知れない • Learner • 確定した値を読みに来る。Acceptorに最新の値vを訊きに来る。 • 過半数のAcceptorが同じ値を返さない限り、値が読めた(確定した)事にならない • Learnerが観測するフェーズまで含めるとPaxosはThree Phaseある事になる 25行で説明するPaxos: http://nil.csail.mit.edu/6.824/2015/notes/paxos-code.html
  • 37. Copyright©2016 NTT Corp. All Rights Reserved. 37 Paxos •2PCだと死んだシナリオ • 蘇るcoordinator •間に入った別のcoordinatorがバージョン番号を変 えるので間違った合意に至らなくなる prepare(n) ok(n,v) proposer acceptor acceptor propose(n',v) propose(n) prepare(n') ng(n',v) ng(n',v)
  • 38. Copyright©2016 NTT Corp. All Rights Reserved. 38 Paxos • 過半数にproposeが届いた時点でクラスタは合意した事になる • workerが復活してもok • 不完全な複製は後続のcoordinatorが複製し直してくれる prepare(n) ok(n, v) propose(n, v1) proposer1 acceptor acceptor coordinator2 prepare(x) ok(x, v1) propose(x, v1)
  • 39. Copyright©2016 NTT Corp. All Rights Reserved. 39 Paxos • 最後にLeanerが値を読みに来る prepare(n) ok(n, v) propose(n, v) accept(n) proposer acceptor acceptor learner read() ok(n, v) ok(n, v)
  • 40. Copyright©2016 NTT Corp. All Rights Reserved. 40 Multi-Paxos • Paxosは一度合意した値は二度と覆らないので、まっさらな合意を 次々と新しく作り出していく事で命令列を複製し、State Machine Replicationを成す • Learnerが読んで合意の確認が取れた命令を実行していく • 命令列に隙間ができたらスキップとかいろんな工夫があるので気になる人はRaftの論文を。 未実行命令 実行済命令x=10 x=10 x=10 1 y=3 y=3 y=3 2 z=2 z=2 z=2 3 a=8 a=8 a=8 4 b=5 5 c=9 6 Paxosの合 意1回分
  • 41. Copyright©2016 NTT Corp. All Rights Reserved. 41 •In Search of an Understandable Consensus Algorithmという衝撃的なタイトルで登場したRaft • Understandableの価値を学会に認めさせるために苦労したのだとか • Paxosが合意(Consensus)しか解いてないのに対し、Raftは 合意はもちろんState Machine Replicationも解ける(=多く の分散アルゴリズム問題に帰着できる) • Googlerは合意アルゴリズムに過ぎないPaxosをロックマネージャ等へ 帰着させるのに大変な苦労をしたが、SMRから帰着させるのはずっと楽 であるという目論見 • PaxosのProposerとLearnerの両方をRaftのLeaderが兼ね ている点がすごい(Multi-Paxos的な高速化をしやすい) RaftとPaxosの類似性
  • 42. Copyright©2016 NTT Corp. All Rights Reserved. 42 • Candidate(候補者)のみの状態からスタート • お互いがお互いを知っている • 全員にRequestVoteに半数以上がOKを返してくれたらLeaderへ昇格 • RequestVoteを送るまでの時間を乱数で散らす事で収束を高速化 • LeaderがAppendEntriesを送る事でSMRを実現 Raftを手短に RequestVote(t) ok AppendEntries(t,h) ok(n) candidate candidate candidate
  • 43. Copyright©2016 NTT Corp. All Rights Reserved. 43 Raftを手短に AppendEntries(t,h+1) ok(n+1) candidate candidate leader • AppendEntriesの中にMulti-Paxosの重要な要素が詰まっている • Entryが空ならheartbeat変わり • candidateから返ってきたnの中の最小値を全員に送る事で「過去に合意に至ったロ グのIDを共有」できる Multi-Paxosでの合意済みIDの共有もこの中に入ってる AppendEntries(t,h) ok(n)
  • 44. Copyright©2016 NTT Corp. All Rights Reserved. 44 Raftを手短に •AppendEntries • Leader「みんなー、Team 13番のリーダーだよ。前回のログの IDは同じTerm13の38だったね。39のログの内容はXXXだよ。 過去にみんなに合意してもらえたIDの最小値は36までだからス テートマシンは36まで進めて良いよ。」 •RequestVote • Candidate「Leader死んでる気がするから僕が立候補します。 前回のログはTerm13の46だったよ。」 •これら2つのRPCだけでMulti-Paxosに相当する事が実 現できるように練りこまれたのがRaft • 過去の合意の観測(PaxosでいうLearnerの仕事)を、Leaderが同 時に行ってRPCの中に折りたたんでいるのがかっこいい。
  • 45. Copyright©2016 NTT Corp. All Rights Reserved. 45 •分散システムエアプ勢多すぎる • ポンチ絵とにらめっこし続ける会議をヤメロ •既成品を使うだけではなく、一緒に血反吐吐き ながらコード書きましょう • コードを書かないと見えてこないものはいっぱいある • システムの肌感覚を掴んでこそエンジニア 手を動かせ