Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a paxos and megastore
Similar a paxos and megastore (20)
Último
Último (10)
paxos and megastore
- 2. 自己紹介 中田秀基 産業技術総合研究所勤務 http://d.hatena.ne.jp/hidemon 並列・分散計算システムが専門 グリッドとか クラウドっぽいのとか MapReduceっぽいのとか AppEngine すっきりわかる Google App Engine
- 3. 今日のお話 AppEngineのデータストアはバックアップされている そこではPaxosというアルゴリズムが使われている 普通にやるとかなり遅くなるPaxosをがんばって高速化したmegastoreというものを使っている
- 4. AppEngineのデータストア複製 Bigtableごと他のデータセンターにリアルタイムで複製されている データストア Bigtable GFS
- 5. AppEngineのデータストア複製の変遷 当初のデータストア複製は整合性を保証せず 結局マスタが再起動しないと復旧できない 2009年7月3日には数時間にわたって読み出しもできない状態に 2009年9月整合性のあるバックアップが導入 http://googleappengine.blogspot.com/2009/09/migration-to-better-datastore.html 拙訳http://d.hatena.ne.jp/hidemon/20090916/1253049589 ダウンした場合にも整合性は保証される 書き込んだはずのデータが消えることはあり得る 即座にSlave側を使ってサービスを再開することが可能（理論的には） 2011年1月 High-replication option が追加 http://googleappengine.blogspot.com/2011/01/announcing-high-replication-datastore.html メガストアを利用 同期的に複数箇所にコピー 整合性だけでなく、データが最新であることも保証
- 6. データストア複製想像図（１） 初期の非同期Bigtable複製 1)書き込み 2)Ack 複製がデータストアのトランザクションを認識していないので個別に複製が行われる。 マスタ スレーブ 3)個別に非同期複製
- 7. データストア複製想像図（2） 非同期Megastoreマスタ-スレーブ複製 1)書き込み 2)Ack アトミックに複製が行われるのでマスタとスレーブの状態が異なることがあっても、どちらも矛盾はない マスタ スレーブ 3)アトミックに非同期複製 2010/3 1.3.2 で導入されたeventual consistency read はマスタが読めないときにスレーブのほうを読みに行くらしい
- 8. データストア複製想像図（3） 同期Megastore Paxos複製 1)書き込み リクエスト 2)アトミックにPaxosで同期複製 3)Ack レプリカ レプリカ レプリカ 同期書き込みなので、レプリカは常に同じ状態。ずれが生じることはない。 マスタとスレーブの区別がないのでいずれかのレプリカが停止した場合でも処理を続行できる。
- 9. High Replication Datastore 2011年1月5日のBlogでアナウンス http://googleappengine.blogspot.com/2011/01/announcing-high-replication-datastore.html
- 10. (大半の)Queryはeventual consistent 一つのEntity Groupの中では問題ない Ancestor queryはStrong Consistency Entity Groupにまたがる場合は、Strongでない 最新でない内容を見てしまう可能性がある コンシステンシが必要な範囲をEntity Groupでくるむ 問題：1つのEntity Groupに対する書き込みは1秒に1度しかできない
- 11. GFS ー Google File System 2003年の論文で発表 他のシステムの基盤となるファイルシステム 数十〜 数百ノードから構成される 当初の目的は、クロールしてきたデータの保管 いわゆるPOSIX準拠のファイルシステムではない セマンティクスが異なる アクセスには専用のAPIを用いる 通常のファイルシステムは汎用 なんでもできるが、性能は限定的 GFSは特殊用途 大規模データのwrite once, read many 目的を限定するかわりに、スケーラビリティを確保
- 13. チャンク単位で複製され、分散して格納されるChunk Server Chunk Server Chunk Server Chunk Server Chunk Server
- 14. Bigtable データベース Relational Databaseではない 検索はほとんどできない キーに対するスキャンのみ GFS上にデータを保持 書き換えが苦手なGFSの特性に合わせて、データの書き換えが発生しないようにコントロール Chubbyを利用
- 15. Bigtableのデータ構造 Row, Column Column Family タイムスタンプによるバージョン ‘anchor’ カラムファミリ “contents:” “anchor:cnnsi.com” “anchor:my.look.ca” <html>.. t3 <html>.. “CNN” “CNN.com” “com.cnn.www” t8 t9 t5 <html>.. t6 Row キー
- 16. rowキー column column ABCDEFG row BCDEFG row “ＢＣＤ”によるプレフィックススキャン BCDPPP row BCDQQQ row BCESSS row CDEFGHI row “C”-”E“のレンジスキャン DEFGHIJ row EFGHIJK row インデックスに対するスキャンのみ
- 18. 分割は動的に行われる
- 20. タブレットの情報 タブレットを表現する情報は以下に分散される タブレットサーバのメモリ上に置かれたmemtable Memtableの更新情報はGFS上のコミットログに書き出される GFS上に置かれる複数のSSTableというファイル SSTableはリードオンリー テーブルへの書き込みはSSTableには反映されない タブレットサーバ memtable GFS SSTable SSTable コミットログ タブレットを構成する情報
- 21. SSTableとmemtable memtable SSTableはReadOnly なので変更はmemtable とコミットログに書かれる。 Commit log エントリの削除もmemtable とCommit Logに書くだけ。 SSTableのエントリはその まま SSTable 2 SSTable 1
- 22. データストア複製の何が難しいのか？ ノードが落ちる メッセージが消える ブロック可能性 あるプロセスがとまってしまうと先に進まなくなる性質 たとえば2相コミットはブロックする可能性がある 書き込み遅延、読み出し遅延 複製によっておそくなると困る
- 23. 2相コミット リーダー prepare agreement commit 書き込み 書き込み 書き込み
- 24. Lamport, Leslie SRI, DEC, Compaq, 2001年からMicrosoft Research Time, Clock, ordering of Events Byzantine Generals Problem Distributed Snapshots Part-time parliament LaTeX
- 25. The Part-Time parliament 「近年の考古学的発見により、Paxos島での議会はその議員がパートタイムであり、すぐいなくなってしまう性質を持っているにもかかわらず機能していたことがわかった。。。」 1990年にACM TOCSに投稿されたが、採録されたのは1998年 島の話を削除しろといわれてへそをまげて8年放置 掲載時にもわざわざ注をつけてキャビネットの裏から発見された、という体裁にしている。 パートタイム議会問題 議員が専業じゃなくて、議場に出たり入ったりするような場合に整合性のある議決を維持できるか？ インディアナ・ジョーンズスタイルでレクチャーを何度かしたらしい
- 26. Paxos島？ エーゲ海 イオニア海 イオニア海にPaxosもしくはPaxoiという島があるが、論文にはエーゲ海の島と書かれており、架空である。 - It should not be confused with the Ionian island of Paxoi, whose name is sometimes corrupted to Paxos.
- 27. Paxos島の議会 議員はみんなパートタイムなので、時々どこかに行ってしまう 会議場の音響はひどくメッセンジャーを介して通信するしかない メッセンジャーも（メッセージを持ったまま）ときどきどこかに行ってしまう 2度と帰ってこないこともある メッセージを壊すことはないが、2度以上配達することはあり得る 議員は、台帳を持っている。台帳とその内容はけして失われない 台帳は貴重な羊皮紙でできているので重要なことだけし書けない 紙の束も持っているがこちらは失われる
- 28. Paxos 前提条件 メッセージは壊れない（非ビザンチン問題） メッセージはいくらでも遅れる メッセージは二重に配達される可能性がある プロセスは停止し、復活する プロセスは停止しても、以前のことを忘れることはない 要請 過半数のプロセス（レプリカ）が生きている時間が十分長くあれば、多数決で議事をすすめることができるアルゴリズム
- 29. Paxosの基本 レプリカ レプリカ レプリカ prepare リーダの 立候補 と了承 過半数の 賛成があればすすんでよい promise accept accepted apply 書き込み 書き込み 書き込み
- 30. もうすこし細かく メッセージには必ず提案番号が付加 提案番号はユニークで昇順であることを保証する Promise メッセージは約束 受け取った提案番号よりも小さい提案番号に対してacceptしません、という約束 この際に、すでにacceptしたことのある値があれば、それも返信 Acceptメッセージには提案番号と値を付加 Promiseメッセージで値を返してきたレプリカがあれば（つまりレプリカがすでに別の提案番号に対してacceptしていれば）、その値のどれかを使う そのようなレプリカがなかったら、任意の値をリーダーが選んでよい Accepted Promiseメッセージでの約束に反しないAcceptメッセージに対してはAcceptedで承認
- 31. なぜブロックしないのか レプリカは任意の時点でリーダーとして立候補することができる 半数以下ならノードが死んでいても問題ない レプリカ レプリカ レプリカ レプリカ レプリカ prepare prepare accept
- 32. リーダーが競合したら？ リーダーに立候補する際にはこれまでの番号よりも大きく、かつユニークな番号を振る ユニークにするのは簡単でmod N を使えばいい 基本的に数が大きい方が勝つ 無限に競合し続けることはあり得るが、それは適当に解決する たとえば、ランダムの時間待ってから再度立候補する、など
- 33. Acceptしたあとにリーダーが死んだら レプリカ レプリカ レプリカ レプリカ レプリカ Prepare(n) Promise(n, -) Accept (n, 10) Prepare(n+1) Promise(n+1, 10) Accept（n+1, 10)
- 34. Paxosの問題点 コストが大きい メッセージ送信前にディスクに送信を記録してSyncしなければならない メッセージが必ず2往復するので高レイテンシ環境下では時間がかかる プロトコルが複雑で正しく実装するのが難しい
- 35. GoogleでのPaxos Chubby ロックサービス、設定ファイル置き場、プロセスのトラッキングなどなど 5ノード構成をPaxosで運用 データセンター内なのでレイテンシは小さい Apache ZooKeeperはこのコピー Megastore データセンター間をまたがって運用 レイテンシは大丈夫なのか！？
- 36. Megastore 随分前からGoogle社内ではつかっていたらしい 2008年のSIGMODで招待講演があったらしい 論文は今年が初出 Megastore: Providing Scalable, Highly Available Storage for Interactive Services Paxosを使って複製を行うデータベース Bigtableを足回りにしたテーブル指向のNoSQL – データストアとよく似てる 複数rowにまたがるACIDを保証 Entitiy Group 単位 注意：本質的にはGAEのEntityGroupとは概念がちがう、が現実には同じ AppEngineとは似て異なるデータモデル 100以上のアプリケーションで使われているらしい AppEngineはアプリケーションの一つという位置づけ （たぶん）AppEngineは複製の部分だけ使ってる？
- 37. Megastoreの技術的なポイント Entity Group を導入することで、データベースを多数のミニDBに分割、その単位でログを複製 ACIDの実現を容易に Coordinator を導入することでPaxosのコストを低減
- 38. Megastoreの構造 Megastore: Providing Scalable, Highly Available Storage for Interactive Services, Jason Baker, et al., CIDR, 2011
- 39. Megastoreの構造（２） Megastore: Providing Scalable, Highly Available Storage for Interactive Services, Jason Baker, et al., CIDR, 2011
- 40. Paxosの最適化（１） リーダ決定の省略 Paxosの1ラウンド目はリーダーの決定 Applyの際に次のリーダーを決めてしまうことで1ラウンド目を省略 そのEntity Groupに書き込むアプリに近い場所を自動的に選ぶ この最適化はよく知られている Chubbyもマスターリースという方法で同じように省略している
- 41. Paxosの最適化（２） Coordinator の導入 オンメモリで稼働する簡単なサーバ up to dateになっているEntity Groupを知っておく Up to dateになっていることがわかっていればそのまま読み出せる わからなければ一度多数ノードからの読み出しが必要 Coordinatorの状態が整合していることはクライアントライブラリが保証する Coordinatorが先に死ぬことは想定されていない ごく単純な状態をもたないデーモンなので死なないと言うことらしい 注意：PaxosプロトコルのリーダーのことをCoordinatorと呼ぶことも多いがこれは全く別物
- 42. Megastoreの構造 Megastore: Providing Scalable, Highly Available Storage for Interactive Services, Jason Baker, et al., CIDR, 2011
- 43. 読み込み時の挙動 Megastore: Providing Scalable, Highly Available Storage for Interactive Services, Jason Baker, et al., CIDR, 2011
- 44. 書き込み時の挙動 Megastore: Providing Scalable, Highly Available Storage for Interactive Services, Jason Baker, et al., CIDR, 2011
- 45. 可用性 Megastore: Providing Scalable, Highly Available Storage for Interactive Services, Jason Baker, et al., CIDR, 2011
- 46. 遅延 Megastore: Providing Scalable, Highly Available Storage for Interactive Services, Jason Baker, et al., CIDR, 2011
- 47. まとめ Paxosは架空のエーゲ海の島 AppEngineのデータストアはいい感じにバックアップされているので安心して使おう Paxosはわけわからないけど、すごくがんばればそれなりに低コストで運用できる 読み込みはローカル 書き込みは１RTT
- 48. 文献 Wikipedia – Paxos Algorithm http://en.wikipedia.org/wiki/Paxos_algorithm The Part-Time parliament - LesileLamport ACM Transactions on Computer Sytems 16,2 (May 1998) p. 133-169 http://research.microsoft.com/en-us/um/people/lamport/pubs/lamport-paxos.pdf 1990 年に同じ雑誌に投稿したのだが、ギリシャの話を削除しろといわれたので放置 Paxosmade Simple Leslie Lamport ACM SIGACT News 32, 4 (Dec. 2001), pages 18–25. http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf Paxos Made Live – An Engineering Perspective Tushar Chandra, Robert Griesemer, Joshua Redstone ACM PODC’07 Chubby の実装でわかったPaxosを実際に実装する際の困難だった点を列挙 Megastore: Providing Scalable, Highly Available Storage for Interactive Services Jason Baker, Chris Bond, James C. Corbett, JJ Furman, Andrey Khorlin, James Larson, Jean-Michel Le ́on, Yawei Li, Alexander Lloyd, Vadim Yushprakh Proceedings of 5th Conference on Innovative Data Systems Research, pages 223-234, 2011 Paxosを使ったデータセンター間複製の論文