O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

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

108.736 visualizações

Publicada em

NTT Tech Conference #2 にて話した資料
時間が足りなかったので全部は話せなかった。

Publicada em: Engenharia
  • Girls for sex in your area are there: tinyurl.com/areahotsex
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • Dating direct: ❤❤❤ http://bit.ly/2F4cEJi ❤❤❤
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • Follow the link, new dating source: ♥♥♥ http://bit.ly/2F4cEJi ♥♥♥
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • Dating for everyone is here: ❶❶❶ http://bit.ly/2LaDVgK ❶❶❶
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • Dating direct: ❤❤❤ http://bit.ly/2LaDVgK ❤❤❤
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui

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

  1. 1. Copyright©2016 NTT Corp. All Rights Reserved. 分散システムについて 語らせてくれ 日本電信電話株式会社 ソフトウェアイノベーションセンタ 熊崎 宏樹 (@kumagi)
  2. 2. Copyright©2016 NTT Corp. All Rights Reserved. 2 1.分散自体を目的にしない事 2.論文を読んでそのまま実装しない事 3.Two Phase Commitを使わない事 4.手を動かす事 目次 分散システムを作る際に気をつけて欲しい事
  3. 3. Copyright©2016 NTT Corp. All Rights Reserved. 3 • よくわかってない人でもCloudera Managerをダウンロードして1時間後 には巨大なHadoopクラスタを立ち上げてYARN, HDFS, Spark, HBase などで遊ぶ事ができる。 • 世の中では分散システムが必要以上に喧伝されている • 「コンピュータ1台よりも2台の方が高速」という直感に対して反論するの は意外と難しい • あなたのそのシステム、本当に分散システムじゃないとダメ? 分散自体を目的にしない事
  4. 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. 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. 6. Copyright©2016 NTT Corp. All Rights Reserved. 6 分散システム化すると基本的に遅くなる。 大抵はネットワークが遅延の支配項になる。 速くなる場合のほうがむしろ例外的と思ったほうが良い。 ワークロードと照らし合わせてマイクロベンチを取った 後で分散システム化を検討して欲しい(頼むから実装上 の重要な意思決定で分散ミドルウェアを使用する事を目 的にしないで欲しい) システムの肌感覚を掴め とにかく測れ 測らずに分散システム化するのは Early Optimizationの一種
  7. 7. Copyright©2016 NTT Corp. All Rights Reserved. 7 • 分散システムの論文は多く出ているがその大半は「やってみたレポート」 「作ってみた」→「動いたっぽい」→「測った」→「Yappy!」 • 分散システム界隈の研究は過去の研究の蓄積が蓄積扱いされにくい分野の 一つであり、論文を真に受けてはならない • 他にそう感じる研究分野はHCI分野 • 故障モデルなどが実は結構厳しく規定されており、そこを読み飛ばすと痛 い目に遭う 論文を読んでそのまま実装しない事
  8. 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. 9. Copyright©2016 NTT Corp. All Rights Reserved. 9 • 次に見かけるレプリケーションプロトコル • バケツリレーのように受け取ったものを即座に次のサーバに渡していく • データを全部受け取る前から次のサーバにリレーできるので大容量のデータ転送に強 くメッセージの飛び交う回数はサーバ台数+1で最小だがサーバ台数に比例するメッ セージ遅延がかかる • 故障したサーバはスキップする • HDFSでデータの複製に使われているのはこれ ケーススタディ:Chain-Replication Client Server1 Server2 Server3 Server4 Read Write
  10. 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. 11. Copyright©2016 NTT Corp. All Rights Reserved. 11 ちょっと待った
  12. 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. 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. 14. Copyright©2016 NTT Corp. All Rights Reserved. 14 • サーバが壊れた場合の挙動をどうするかは論文に書いてあるけれど、何が 起きたらサーバが壊れたと認識するかは書いてない • これらのプロトコルはサーバの故障情報を天から与えられる物として設計している • プログラマ「そっか、じゃあ通信がタイムアウトしたら故障ね」←バグの温床 • プログラマ「タイムアウトの閾値を大きくすれば誤検知が減って安心だね」←低速化 • プログラマ「タイムアウトの閾値をどうすればいいのさ??」←決定解はない • 分散システムの論文ではシステムに対して前提を置いていることが多いが、 なぜその前提を置いているのかは知識がないとわからない • Primary-BackupとChain-ReplicationはFail-Stop故障モデルを前提 としている • それより厳しい故障モデルの上では容易に壊れる • その故障モデルの解説はこれからする そのプロトコル、凶暴につき
  15. 15. Copyright©2016 NTT Corp. All Rights Reserved. 15 故障なし • サーバが壊れる状況のしんどさを段階的に切り分けたモデルのこと • より楽な故障モデルで動かないプロトコルは、しんどい故障モデルでは 「絶対に」動かない • Fail-Stop: 壊れたサーバはいずれ全部のサーバから故障として観測される。壊れてい ないサーバを壊れたと誤認する事や、壊れたサーバを壊れていないと誤認する事は発 生しない。壊れたサーバは二度と復活しない。 • Crash-Recover: サーバは壊れるかも知れないが復活する事もある。つまりいつまで も故障したと断言できない。 故障モデル し ん ど い Fail-Stop(同期通信) Fail-Stop(非同期通信) Crash-Recovery Byzantine
  16. 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. 17. Copyright©2016 NTT Corp. All Rights Reserved. 17 • Fischer,Lynch,Pattersonの3人が提唱したのでその頭文字から取って FLP不可能性と呼ぶ • 端的に言うと、下の図の赤線より下の世界では「全ての壊れていないサー バが有限の時間で確実に合意に至るアルゴリズムは存在しえない」という 事を理論的に証明した • 比較的緩い故障モデルでもダメということはそれより下では絶対に無理という事 FLP不可能性 故障なし Fail-Stop(同期通信) Fail-Stop(非同期通信) Crash-Recovery Byzantine
  18. 18. Copyright©2016 NTT Corp. All Rights Reserved. 18 • 個々のサーバ内の時間の流れを操って絶対に合意を終わらせようとしない 悪魔が存在したと仮定する • 昼ごはんの行き先について合意を取る例 FLP不可能性を簡単に 状態を変更しうる通信と、状態の変更のタイミングとの間が悪ければ 非決定的な状態(bivalent)な状態が無限に続きうる カレー 牛丼 牛丼 カレー 牛丼いいな カレーいいな カレーいいな 牛丼いいな
  19. 19. Copyright©2016 NTT Corp. All Rights Reserved. 19 • 分散システムの問題が複数ある中、それぞれはお互いに「帰着」しあう事 ができる • 合意問題が解ければリーダー選出ができる(リーダーを誰にするかに合意する) • リーダー選出ができれば合意問題が解ける(リーダーが決めた値に全員従う) • 合意問題が解ければアトミックブロードキャストができる(順序について合意する) • アトミックブロードキャストができれば合意問題が解ける(最初の値で合意する) • 合意問題が解ければState Machine Replicationが解ける(Multi Paxos的な) • Replicated State Machineが解ければ合意問題が解ける(合意するステートマシン を作ればよい) などなど • その中で「合意問題が解けない」は他の全ての問題も有限の時間では解けな い事を意味する • みんな無限の時間が掛かりうるから適当に迂回するなり諦めるなりしている FLP不可能性の意味する大事な所
  20. 20. Copyright©2016 NTT Corp. All Rights Reserved. 20 •全員の参加者から「同じ順序」が観測できるブロード キャスト • 単一のリーダーから全員に送る、というのも立派な一つの解 • 参加者がそれぞれバラバラの順序で受信したブロードキャスト メッセージを、同一の順序で観測し直すように合意する、という 方法もある 個々のアルゴリズムは詳しくないのでまた今度 補足:アトミックブロードキャスト ZooKeeperはZookeeper Atomic Bloadcast(ZAB)プロトコル を使っている。
  21. 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. 22. Copyright©2016 NTT Corp. All Rights Reserved. 22 • 合意→リーダー選出→アトミックブロードキャスト→State Machine Replicationの順で問題は難しくなるが、組み合わせて解く事ができる • 問題を分解して代替可能な部品(モジュール)にするのでモジュラーアプローチ • 解どのレイヤーまでをどう解くと効率が良いか未だに決定解はない 分散システムのモジュラーアプローチ State Machine Replication アトミックブロードキャスト リーダー選出 合意 ZAB ZK Raft Paxos Multi Paxos Chubby
  23. 23. Copyright©2016 NTT Corp. All Rights Reserved. 23 •まともな論文であれば分散システムの歴史に立脚してい るはず •その歴史の中でそのアプローチはどの立ち位置なのか、 問題をどう分解しているのかを理解してから実装する (尺が足りないから話せないFailure Detectorとか Syncronizationとかの問題の話はまた今度) 論文を読んでそのまま実装しない事
  24. 24. Copyright©2016 NTT Corp. All Rights Reserved. 24 Phase 2 Two Phase Commit •分散合意プロトコルの金字塔 •誰が最初の発明者かも明白でないほど古い •故障時の挙動に大量の亜種がある prepare ok commit ok coordinator worker worker Phase 1
  25. 25. Copyright©2016 NTT Corp. All Rights Reserved. 25 Two Phase Commit • prepare完了前にworkerが故障したらabort • これはいい prepare ok abort ok coordinator worker worker
  26. 26. Copyright©2016 NTT Corp. All Rights Reserved. 26 Two Phase Commit prepare ok coordinator worker worker Phase 1 •Commit前にcoordinatorが故障したら
  27. 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. 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. 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. 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. 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. 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. 33. Copyright©2016 NTT Corp. All Rights Reserved. 33 •「Paxosっていうアルゴリズムがあるんですが…説明す るには難しいのでまた今度にします」←分散システムに ついて語る人あるある •Paxos怖くないよ!合意しかできないだけだよ! 分散システムあるある
  34. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 45. Copyright©2016 NTT Corp. All Rights Reserved. 45 •分散システムエアプ勢多すぎる • ポンチ絵とにらめっこし続ける会議をヤメロ •既成品を使うだけではなく、一緒に血反吐吐き ながらコード書きましょう • コードを書かないと見えてこないものはいっぱいある • システムの肌感覚を掴んでこそエンジニア 手を動かせ

×