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

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台でも稼動はする

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とかの問題の話はまた今度）論文を読んでそのまま実装しない事

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

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はバグっている

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+の布教にお熱

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)

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の中に折りたたんでいるのがかっこいい。

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

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

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(20)

More from Kumazaki Hiroki

More from Kumazaki Hiroki(15)

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