Submit Search
Upload
普通の人でもわかる Paxos
•
32 likes
•
12,102 views
T
tyonekura
Follow
Paxos Made Simpleをさらに簡単に説明するよう試みてみました。
Read less
Read more
Engineering
Report
Share
Report
Share
1 of 64
Download now
Download to read offline
Recommended
Paxos
Paxos
Preferred Networks
Raft
Raft
Preferred Networks
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
分散システムの限界について知ろう
分散システムの限界について知ろう
Shingo Omura
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法
Kumazaki Hiroki
トランザクションの設計と進化
トランザクションの設計と進化
Kumazaki Hiroki
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
Recommended
Paxos
Paxos
Preferred Networks
Raft
Raft
Preferred Networks
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
分散システムの限界について知ろう
分散システムの限界について知ろう
Shingo Omura
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法
Kumazaki Hiroki
トランザクションの設計と進化
トランザクションの設計と進化
Kumazaki Hiroki
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Yoshiyasu SAEKI
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
地理分散DBについて
地理分散DBについて
Kumazaki Hiroki
冬のLock free祭り safe
冬のLock free祭り safe
Kumazaki Hiroki
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
Yahoo!デベロッパーネットワーク
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
Tetsutaro Watanabe
Elasticsearch as a Distributed System
Elasticsearch as a Distributed System
Satoyuki Tsukano
[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは? by Taichi Umeda
[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは? by Taichi Umeda
Insight Technology, Inc.
CRDT in 15 minutes
CRDT in 15 minutes
Shingo Omura
できる!並列・並行プログラミング
できる!並列・並行プログラミング
Preferred Networks
関数型プログラミングのデザインパターンひとめぐり
関数型プログラミングのデザインパターンひとめぐり
Kazuyuki TAKASE
がっつりMongoDB事例紹介
がっつりMongoDB事例紹介
Tetsutaro Watanabe
Transactional Information Systems入門
Transactional Information Systems入門
nobu_k
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Akihiro Suda
初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!
Tetsutaro Watanabe
忙しい人の5分で分かるMesos入門 - Mesos って何だ?
忙しい人の5分で分かるMesos入門 - Mesos って何だ?
Masahito Zembutsu
Apache Avro vs Protocol Buffers
Apache Avro vs Protocol Buffers
Seiya Mizuno
Consistent hash
Consistent hash
paulowniaceae
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
More Related Content
What's hot
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Yoshiyasu SAEKI
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
地理分散DBについて
地理分散DBについて
Kumazaki Hiroki
冬のLock free祭り safe
冬のLock free祭り safe
Kumazaki Hiroki
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
Yahoo!デベロッパーネットワーク
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
Tetsutaro Watanabe
Elasticsearch as a Distributed System
Elasticsearch as a Distributed System
Satoyuki Tsukano
[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは? by Taichi Umeda
[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは? by Taichi Umeda
Insight Technology, Inc.
CRDT in 15 minutes
CRDT in 15 minutes
Shingo Omura
できる!並列・並行プログラミング
できる!並列・並行プログラミング
Preferred Networks
関数型プログラミングのデザインパターンひとめぐり
関数型プログラミングのデザインパターンひとめぐり
Kazuyuki TAKASE
がっつりMongoDB事例紹介
がっつりMongoDB事例紹介
Tetsutaro Watanabe
Transactional Information Systems入門
Transactional Information Systems入門
nobu_k
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Akihiro Suda
初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!
Tetsutaro Watanabe
忙しい人の5分で分かるMesos入門 - Mesos って何だ?
忙しい人の5分で分かるMesos入門 - Mesos って何だ?
Masahito Zembutsu
Apache Avro vs Protocol Buffers
Apache Avro vs Protocol Buffers
Seiya Mizuno
Consistent hash
Consistent hash
paulowniaceae
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
What's hot
(20)
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
地理分散DBについて
地理分散DBについて
冬のLock free祭り safe
冬のLock free祭り safe
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
Elasticsearch as a Distributed System
Elasticsearch as a Distributed System
[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは? by Taichi Umeda
[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは? by Taichi Umeda
CRDT in 15 minutes
CRDT in 15 minutes
できる!並列・並行プログラミング
できる!並列・並行プログラミング
関数型プログラミングのデザインパターンひとめぐり
関数型プログラミングのデザインパターンひとめぐり
がっつりMongoDB事例紹介
がっつりMongoDB事例紹介
Transactional Information Systems入門
Transactional Information Systems入門
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!
忙しい人の5分で分かるMesos入門 - Mesos って何だ?
忙しい人の5分で分かるMesos入門 - Mesos って何だ?
Apache Avro vs Protocol Buffers
Apache Avro vs Protocol Buffers
Consistent hash
Consistent hash
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
普通の人でもわかる Paxos
1.
普通の人でもわかるPaxos @tyonekura
2.
前提 • 一番シンプルなPaxosプロトコル (Paxos Made Simple)を紹介します。
3.
Paxosとは • ある値を、過半数のノードに書き込むプロトコ ル。もうちょっと正確には、過半数のノードに 書き込まれた時点で合意したとみなせるプロ トコル。 • 途中でネットワークが途切れたり、ノードが死 んだり、生き返ったり、色々しても大丈夫。
4.
登場人物 • クライアント – プロポーザに、書き込みをお願いする人 –
登場人物といっておきながら、話はプロポーザが値を 持ってから始めればいいので、以下登場しません。 • プロポーザ – アクセプタの過半数に同じ値を書き込むよう頑張る • アクセプタ – プロポーザから来た値をよきにはからう(後述) • リスナ – 最後に、過半数のアクセプタから値をゲット。
5.
基本的な動き(フェーズ1) • フェーズ1a (プロポーザ側) – アクセプタにお伺いをたてる。その際、メッセージ IDを添える。 • フェーズ1b (アクセプタ側) – 初めてのお伺いや、これまで約束したお伺いより 高いIDだったら、約束を返す。もし今までアクセプ トをしていたら、その値も返す。 – これまで約束したお伺いより低いIDは無視する。 オレンジのキーワードは、送られるメッセージの種類を指しています。
6.
基本的な動き(フェーズ2) • フェーズ2a(プロポーザ側) – 過半数のアクセプタから約束が返ってこなかったら、 どこかで諦めて、メッセージIDを増やして最初からや りなおし。 –
過半数のアクセプタから約束が返ってきたら、メッ セージIDと値を添えてアクセプタにプロポーズを送る。 – プロポーズを送る際に、もしも約束に(ID, 値)の組が ついて返ってきたら、自分の値を、返ってきた約束の 中で一番高いIDの値で書き換えてプロポーズを送る。 (IDは自分の。なぜなら、約束が返ってきたということ は、その時点で自分のIDが一番高い。)
7.
基本的な動き(フェーズ2) • フェーズ2b(アクセプタ側) – プロポーズのIDが最後に約束したIDか、それより 大きい場合、アクセプトする。 – プロポーズのIDが最後に約束したIDより小さい場 合、お断りする。
8.
基本的な動き(終わり) • フェーズ2c? (プロポーザ側) – 過半数からアクセプトが返ってきたら終了 – 過半数に達せずタイムアウトするか、過半数から お断りされたらメッセージIDを増やして最初に戻 る。 • リスナーは、アクセプタに聞いて回って、過半 数のアクセプタが同じ値を持っていたらその 値を信じる。
9.
と、こう書くと • よくわからなくなる。 •
たぶん、例が少ないのでわからないのだと思 う。 • なので、以下パラパラ漫画
10.
一番単純なケース アクセプタ1 アクセプタ2 アクセプタ3 プロポーズしていいですか?(1) プロポーズしていいですか?(1) プロポーズしていいですか?(1) お伺い お伺い お伺い 0 0 0 プロポーザ
11.
一番単純なケース アクセプタ1 アクセプタ2 アクセプタ3 いいですよ(1) いいですよ(1) いいですよ(1) 約束 約束 約束 1 1 1 プロポーザ
12.
一番単純なケース アクセプタ1 アクセプタ2 アクセプタ3 鈴木です。(1) 鈴木です(1) 鈴木です(1) プロポーズ プロポーズ プロポーズ 1 1 1 プロポーザ
13.
一番単純なケース アクセプタ1 アクセプタ2 アクセプタ3 プロポーザ アクセプト(1) アクセプト(1) アクセプト(1) 1 1 1 鈴木 鈴木 鈴木
14.
一番単純なケース アクセプタ1 アクセプタ2 アクセプタ3 リスナー 1 1 1 鈴木 鈴木 鈴木 鈴木ね
15.
アクセプタ一台故障 アクセプタ1 アクセプタ2 アクセプタ3 プロポーズしていいですか?(1) プロポーズしていいですか?(1) プロポーズしていいですか?(1) お伺い お伺い お伺い 0 0 0 プロポーザ
16.
アクセプタ一台故障 アクセプタ1 アクセプタ2 アクセプタ3 いいですよ(1) いいですよ(1) 約束 約束 1 0 1 プロポーザ
17.
アクセプタ一台故障 アクセプタ1 アクセプタ2 アクセプタ3 鈴木です。(1) 鈴木です(1) プロポーズ プロポーズ 1 0 1 プロポーザ
18.
アクセプタ一台故障 アクセプタ1 アクセプタ2 アクセプタ3 プロポーザ アクセプト(1) アクセプト(1) 1 0 1 鈴木 鈴木
19.
アクセプタ一台故障 アクセプタ1 アクセプタ2 アクセプタ3 リスナー 1 0 1 鈴木 鈴木 鈴木ね
20.
アクセプタ一台故障と思ったら生き 返った アクセプタ1 アクセプタ2 アクセプタ3 プロポーズしていいですか?(1) プロポーズしていいですか?(1) プロポーズしていいですか?(1) お伺い お伺い お伺い 0 0 0 プロポーザ
21.
アクセプタ一台故障と思ったら生き 返った アクセプタ1 アクセプタ2 アクセプタ3 いいですよ(1) いいですよ(1) 約束 約束 1 1 1 プロポーザ
22.
アクセプタ一台故障と思ったら生き 返った アクセプタ1 アクセプタ2 アクセプタ3 鈴木です。(1) 鈴木です(1) プロポーズ プロポーズ 1 1 1 プロポーザ プロポーズ 鈴木です(1) 約束返ってきてなくてもとりあえずプロポーズする。
23.
アクセプタ一台故障と思ったら生き 返った アクセプタ1 アクセプタ2 アクセプタ3 プロポーザ アクセプト(1) アクセプト(1) 1 1 1 鈴木 鈴木 アクセプト(1) いままでで一番IDが大きいのでアクセプトする。 鈴木
24.
アクセプタ一台故障と思ったら生き 返った アクセプタ1 アクセプタ2 アクセプタ3 リスナー 1 1 1 鈴木 鈴木 鈴木ね 鈴木
25.
プロポーザ2人 アクセプタ1 アクセプタ2 アクセプタ3 プロポーズしていいですか?(1) プロポーズしていいですか?(1) プロポーズしていいですか?(1) お伺い お伺い お伺い 0 0 0 プロポーザ
26.
プロポーザ2人 アクセプタ1 アクセプタ2 アクセプタ3 いいですよ(1) いいですよ(1) 約束 約束 1 1 1 プロポーザ いいですよ(1) 約束
27.
プロポーザ2人 アクセプタ1 アクセプタ2 アクセプタ3 プロポーズしていいですか?(2) プロポーズしていいですか?(2) プロポーズしていいですか?(2) お伺い お伺い お伺い 1 1 1
28.
プロポーザ2人 アクセプタ1 アクセプタ2 アクセプタ3 いいですよ(2) いいですよ(2) 約束 約束 2 2 2 いいですよ(2) 約束
29.
プロポーザ2人 アクセプタ1 アクセプタ2 アクセプタ3 鈴木です。(1) 鈴木です(1) プロポーズ プロポーズ 2 2 2 プロポーザ プロポーズ 鈴木です(1)
30.
プロポーザ2人 アクセプタ1 アクセプタ2 アクセプタ3 プロポーザ リジェクト(2) リジェクト(2) 2 2 2 リジェクト(2)
31.
プロポーザ2人 アクセプタ1 アクセプタ2 アクセプタ3 佐藤です。(2) 佐藤です(2) プロポーズ プロポーズ 2 2 2 プロポーズ 佐藤です(2)
32.
プロポーザ2人 アクセプタ1 アクセプタ2 アクセプタ3 プロポーザ アクセプト(2) アクセプト(2) 2 2 2 佐藤 佐藤 アクセプト(2) 佐藤
33.
プロポーザ2人 アクセプタ1 アクセプタ2 アクセプタ3 リスナー 2 2 2 佐藤 佐藤 佐藤ね 佐藤
34.
もしリスナーが選ぶ前にリトライしたら 敗者復活? アクセプタ1 アクセプタ2 アクセプタ3 プロポーズしていいですか?(3) プロポーズしていいですか?(3) プロポーズしていいですか?(3) お伺い お伺い お伺い 2 2 2 佐藤 佐藤 佐藤
35.
おや?約束に、他人の名前が。。 アクセプタ1 アクセプタ2 アクセプタ3 いいですよ(佐藤、2) いいですよ(佐藤、2) 約束 約束 いいですよ(佐藤、2) 約束 3 3 3 佐藤 佐藤 佐藤
36.
なぜ他人の名前で。。せつない。。 アクセプタ1 アクセプタ2 アクセプタ3 佐藤です。(3) 佐藤です(3) プロポーズ プロポーズ 2 2 2 プロポーズ 佐藤です(3) 2 2 2 佐藤 佐藤 佐藤 この後の処理は結果が変わらないので、実装依存
37.
プロポーザ3人 アクセプタ1 アクセプタ2 アクセプタ3 プロポーズしていいですか?(1) プロポーズしていいですか?(1) プロポーズしていいですか?(1) お伺い お伺い お伺い 0 0 0 プロポーザ
38.
プロポーザ3人 アクセプタ1 アクセプタ2 アクセプタ3 いいですよ(1) いいですよ(1) 約束 約束 1 1 1 プロポーザ いいですよ(1) 約束
39.
プロポーザ3人 アクセプタ1 アクセプタ2 アクセプタ3 プロポーズしていいですか?(2) プロポーズしていいですか?(2) お伺い お伺い 1 1 1 二人目の時、1台不調
40.
プロポーザ3人 アクセプタ1 アクセプタ2 アクセプタ3 いいですよ(2) 約束 1 2 2 いいですよ(2) 約束
41.
プロポーザ3人(1台目復活) アクセプタ1 アクセプタ2 アクセプタ3 鈴木です。(1) 鈴木です(1) プロポーズ プロポーズ 1 2 2 プロポーザ プロポーズ 鈴木です(1)
42.
プロポーザ3人 アクセプタ1 アクセプタ2 アクセプタ3 プロポーザ アクセプト(1) リジェクト(2) 1鈴木 2 2 リジェクト(2)
43.
2人目がアクセプタ2にプロポーズし たところで。。 アクセプタ1 アクセプタ2 アクセプタ3 佐藤です(2) プロポーズ 1鈴木 2 2佐藤 まだとどいてない。 まだとどいてない。 アクセプト(2)
44.
3人目が登場。 アクセプタ1 アクセプタ2 アクセプタ3 1鈴木 2 2佐藤 プロポーズしていいですか?(3) プロポーズしていいですか?(3) お伺い お伺い プロポーズしていいですか?(3) お伺い
45.
3人目が登場。 アクセプタ1 アクセプタ2 アクセプタ3 3鈴木 3 3佐藤 いいですよ(1, 鈴木) 約束 いいですよ(3) 約束 いいですよ(2, 佐藤) 約束
46.
3人目は佐藤を推す。 アクセプタ1 アクセプタ2 アクセプタ3 3鈴木 3 3佐藤 佐藤です。(3) プロポーズ プロポーズ プロポーズ 佐藤です(3) 佐藤です(3) もしこの前に佐藤さんのプロポーズが届いたら、 それはID2なので無視される。
47.
プロポーザ3人 アクセプタ1 アクセプタ2 アクセプタ3 プロポーザ アクセプト(3) アクセプト(3) 3 3 3 佐藤 佐藤 アクセプト(3) 佐藤
48.
プロポーザ3人 アクセプタ1 アクセプタ2 アクセプタ3 リスナー 3 3 3 佐藤 佐藤 佐藤ね 佐藤
49.
その他 • 色んなパターンを試しても、過半数のアクセプ タといずれかのプロポーザが生きているなら、 いずれは合意が取れるようになっています。 • よくできてますね。。
50.
ライブロック アクセプタ1 アクセプタ2 アクセプタ3 プロポーズしていいですか?(1) プロポーズしていいですか?(1) プロポーズしていいですか?(1) お伺い お伺い お伺い 0 0 0 プロポーザ
51.
ライブロック アクセプタ1 アクセプタ2 アクセプタ3 いいですよ(1) いいですよ(1) 約束 約束 1 1 1 プロポーザ いいですよ(1) 約束
52.
ライブロック アクセプタ1 アクセプタ2 アクセプタ3 プロポーズしていいですか?(2) プロポーズしていいですか?(2) プロポーズしていいですか?(2) お伺い お伺い お伺い 1 1 1
53.
ライブロック アクセプタ1 アクセプタ2 アクセプタ3 いいですよ(2) いいですよ(2) 約束 約束 2 2 2 いいですよ(2) 約束
54.
ライブロック アクセプタ1 アクセプタ2 アクセプタ3 鈴木です。(1) 鈴木です(1) プロポーズ プロポーズ 2 2 2 プロポーザ プロポーズ 鈴木です(1)
55.
ライブロック アクセプタ1 アクセプタ2 アクセプタ3 プロポーザ リジェクト(2) リジェクト(2) 2 2 2 リジェクト(2)
56.
ライブロック アクセプタ1 アクセプタ2 アクセプタ3 プロポーズしていいですか?(3) プロポーズしていいですか?(3) プロポーズしていいですか?(3) お伺い お伺い お伺い 2 2 2 プロポーザ
57.
ライブロック アクセプタ1 アクセプタ2 アクセプタ3 いいですよ(3) いいですよ(3) 約束 約束 3 3 3 プロポーザ いいですよ(3) 約束
58.
ライブロック アクセプタ1 アクセプタ2 アクセプタ3 佐藤です。(2) 佐藤です(2) プロポーズ プロポーズ 3 3 3 プロポーズ 佐藤です(2)
59.
ライブロック アクセプタ1 アクセプタ2 アクセプタ3 プロポーザ リジェクト(3) リジェクト(3) 3 3 3 リジェクト(3) 以下、永遠につづくかも。 (ランダムでsleep入れるとか、工夫する。)
60.
以下、混乱しやすい点を
61.
これらはPaxosの範疇じゃない • トランザクション – Paxosは、過半数にある値を届けて合意を取るも のであって、広い意味での(DB的な)トランザクショ ンではない。 • クラスタメンバーシップ – とりあえず、メンバーは固定。アクセプタが増えた り減ったりする場合は実装側で。(メンバーシップ 情報をPaxosで同期したりとか。)
62.
これらはPaxosの範疇じゃない • プロポーザ選択 – 適当にどれか1台をプロポーザにする。 – クライアントが複数のプロポーザを選んで同時に 別々の提案をしても、大丈夫。 • 過半数に達した後の少数側の扱い – 実装上はデータ同期させたほうがいいと思うけど、 それはPaxosの範疇外
63.
これらはPaxosの範疇じゃない • ビザンチン障害 – 具体的には、 –
メッセージID偽装 • 約束されてないIDでプロポーズを投げる • 一意じゃないIDというのも、これに含まれると思う。 – アクセプタがアクセプトしてない値を捏造 – アクセプタが約束してないIDを返す – 等等 • 過半数を超える障害 – 例:9台5台のアクセプタがアクセプトした、と思ったら、その5台のう ち1台が壊れた。 – 実用上は過半数、というところを変えてあげればOK. – 例:9台中5台に書き込めたらOKではなく、9台中7台に書き込めた らOKにして、アクセプトまでは2台障害に耐え、リスナーがチェック するときは5台でOKにするとか。
64.
これらはPaxosの範疇じゃない • メッセージIDをどうやって一意にするか • Macアドレス + シーケンス番号とか。 •
ノードID + シーケンス番号とか。 – シーケンス番号同士を比べて、同じだったらノードID を比べる。 – ノード番号同士を比べて、同じだったらシーケンス番 号を比べる。 – 普通は前者。後者は、複数プロポーザケースに必ず 1台が勝つことになるが、別にそれでもPaxos的には 問題ない。
Download now