大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか？
•Download as PPTX, PDF•
29 likes•7,013 views
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to 大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか？
Similar to 大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか？ (20)
More from maruyama097
More from maruyama097 (20)
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか？
- 2. Agenda 大規模分散システムの成立 すべては、ここから始まった GFS, MapReduce, BigTable GFSからGFS2へ Caffeine 新しい検索システム Dremel インタラクティブなデータ分析 Spanner 新しい分散データベース Knowledge Graph 新しい検索技術 資料編
- 4. Google
- 5. Amazon
- 6. Apple
- 7. Facebook
- 8. Microsoft
- 10. Google
- 11. Google
- 12. Facebook
- 14. Microsoft
- 15. クラウドとクラウド・デバイスの時代 クラウドの時代は、21世紀になってから本格的に 始動した。すぐ後を追って、クラウド・デバイスの 時代が始まった。 2004年 Google上場 2004年 Google GFS,MapReduce,BigTable の論文公表 2006年 Amazon EC2, S3 2007年 Apple iPhone 2008年 Microsoft Azure 2008年 Google Android 2012年 Facebook上場
- 16. Googleの社是とスタンス 全世界の情報を、組織し、アクセス可能にすると いう夢は、ほとんど達成可能なところにまで来て いる! “我々は、検索を人々の役に立つようにするという ビジネスをしている。インフラを売るビジネスをし ている訳ではない。” --- Lipkovitz, Google
- 19. Googleの検索エンジンが 処理するデータの量 Googleの検索システムCaffeineが、一秒間に 処理するデータの量は、紙に印刷すると、3マイ ル（4.8km）の高さになる A4の用紙に2KBの情報が入るとして、紙の厚さを0.2mmとすれば、 情報の量は、2KB x 4.8km x 5 = 48 x KB x K x K = 48GB Googleの検索システムで使われているストレー ジの情報を、iPadに入れようとすれば、625,000 個のiPadが必要になる。このiPadを積み上げれ ば、40マイル(72Km)以上になる 64GB x 625,000 = 40,000GB x K = ４0PB
- 20. Facebook 毎月のアクティブ・ユーザ 8億4500万人 一日の投稿 25億 一日の「いいね」 27億 一日にアップロードされる写真 3億枚 Facebook上の友人関係 1000億 30分ごとに105TBのデータがスキャンされる。
- 21. Big Dataは、大きいか小さいか？ 1K 1,000人 千人 1M 1,000,000人 百万人 1G 1,000,000,000人 十億人 世界人口 ７G人 世界の一人一人に、2バイトコードで、1000字程 度の個人情報のプロファイルを与えるとすると、 2 x 8 x 1K x 7G = 2 x 7TBのディスクがあれ ばいい。 日本人一億人なら、200GBで十分。今なら2Tの ディスクが、秋葉原で一万円で買える。
- 22. Windows Azure SQL データベース の最大容量は、150G
- 23. Amazon DB インスタンス
- 26. なぜ、大規模分散システムに 注目する必要があるのか？ 重要なことは、こうした技術的な探求が、新しい サービスの開発をめぐる、ビジネスの競争によっ てドライブされていることである。 サービス利用者から見て”Publicクラウド”と言わ れるものは、ビジネスの主体からみれば、 Google、Amazon、Microsoft...らが「所有」す る”Privateクラウド”であると考えることも出来る。 彼らのビジネスの力の一つは、大規模分散シス テムを開発し運用し、新しいサービスを提供し続 ける技術的な力にある。
- 31. すべては、ここから始まった 2003年 The Google File System 2004年 MapReduce 2006年 BigTable
- 32. The Google File System GFSは、安価なPCサーバからなるクラスタ上に構築 された分散ファイルシステムである。クラスタは、 2,000台以上のchunkserverからなり、Googleに は、30以上のClusterがある。 GFSは、ペタバイトサイズのファイルシステムであり、 read/write 2,000MB/s 以上の性能がある http://209.85.163.132/papers/gfs-sosp2003.pdf
- 33. Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung The Google File System Gobioff氏は、2008年3月11日、悪性リンパ腫で亡くなった。
- 34. GFS Architecture Application (file name,chunk index) GFS Master /foo/bar Chunk 2ef0 File NameSpace GFS Client (chunk handle, chunk location) Instruction to chunkserver Chunkserver state (chunk handle,byte range) GFS chunkserver GFS chunkserver Linux File System Linux File System chunk data ・・・・ ・・・・ ・・・・
- 35. MapReduce: Simplified Data Processing on Large Clusters MapReduce は、関数型のプログラミン グ・モデルに基づいた、大規模なデー タ・セットの処理・生成を行う http://209.85.163.132/papers/mapreduce-osdi04.pdf
- 36. Jeffrey Dean and Sanjay Ghemawat MapReduce: Simplied Data Processing on Large Clusters
- 37. Master Worker Partition0 Partition1 Split 0 Split 1 Split 2 Worker Worker Worker 入力ファイルと その分割 Output file1 Partition0 Partition1 Split 3 Split 4 Output file0 Worker Partition0 Partition1 Mapの フェーズ Local Disk上の 中間出力ファイル Reduceの フェーズ 最終出力 ファイル
- 38. Bigtable: A Distributed Storage System for Structured Data Bigtable は、数千台のサーバ上のペタ バイト単位の非常に大きなサイズにまで スケールするようにデザインされた、構 造化されたデータを管理する、分散スト レージ・システムである。 http://209.85.163.132/papers/bigtable-osdi06.pdf http://video.google.com/videoplay? docid=7278544055668715642&q=bigtable
- 39. Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, Robert E. Gruber Bigtable: A Distributed Storage System for Structured Data
- 40. Bigtable Client BigTableシステム構成 Bigtable Client Library Open Bigtable セル Bigtable Master メタデータのオペレーションを実行 ロードバランシング Bigtable Tablet Server Bigtable Tablet Server Bigtable Tablet Server サーバデータ サーバデータ サーバデータ Cluster Sheduling System フェイルオーバのハンドリング モニタリング Google File System タブレットデータの 保持 ログ Chubby Lock Service メタデータ保持、 マスター選定のハンドリング
- 43. 2009年７月、Google大規模障害 2009年7月2日, 6:45 AM から12:35 PM ま で、Google App Engineに大規模な障害発生。 この障害の根本的な原因は、データセンタ内の ノードが、サーバー側できちんとしたチェックを行 わずに、不適切に構成されたFileHandleを送り つけたことに起因するGFS Master serverのバ グであった。これを処理しようとして、Masterは、 スタック・オーバーフローを起こした。
- 44. Transactions Across Datacenters （Weekend Project） この障害事故の少し前、2009年5月27日 Google IO で、Ryan Barrettは、自らのWeekend Projectとして、 データセンターをまたいだシステムを提案していた。 http://www.google.com/intl/ja/events/io/2009/ sessions/TransactionsAcrossDatacenters.html what if your entire datacenter falls off the face of the earth? This talk will examine how current large scale storage systems handle fault tolerance and consistency, with a particular focus on the App Engine datastore. We'll cover techniques such as replication, sharding, two phase commit, and consensus protocols (e.g. Paxos), then explore how they can be applied across datacenters.
- 45. Post-mortem for February 24th, 2010 outage After further analysis, we determine that although power has returned to the datacenter, many machines in the datacenter are missing due to the power outage, and are not able to serve traffic. Particularly, it is determined that the GFS and Bigtable clusters are not in a functioning state due to having lost too many machines, and that thus the Datastore is not usable in the primary datacenter at that time.
- 46. 2009年9月、Bigtableの見直し 2009年9月14日、Ryan Barrettは、“Migration to a Better Datastore”を発表 http://googleappengine.blogspot.jp/2009/09/mig ration-to-better-datastore.html Megastore replication saves the day! Megastore is an internal library on top of Bigtable that supports declarative schemas, multi-row transactions, secondary indices, and recently, consistent replication across datacenters.
- 47. 2011年1月 Megastore: Providing Scalable, Highly Available Storage for Interactive Services http://www.cidrdb.org/cidr2011/Papers/CIDR1 1_Paper32.pdf cf. 日本 2012年6月20日 ファースト・サーバー社事故
- 48. Megastore
- 50. HDFSのAvatar Node ちなみに、Facebookが、HDFSのMaster Nodeの二重化、いわゆ、Avatar Nodeの実装 の次の論文を発表したのは、2011年の SIGMODでのことであった。 “Apache Hadoop goes Realtime at Facebook” http://dl.acm.org/citation.cfm?id=19894 38&bnc=1
- 54. GFS: Evolution on Fast-forward GFSの単一マスターで行くという決定は、実際に は、設計の非常に早い段階でなされたものだ。主 要には、デザインをシンプルなものにするというの が、その理由だ。 ただ、問題は、すぐに起きていた。ストレージの容 量が、数百テラからペタバイトに、さらには数十ペ タに増大するにつれて、マスターが維持しなけれ ばならないメタデータの割合は、増えていった。
- 55. GFS: Evolution on Fast-forward 同様に、データのボリュームとともに、リカバリー のデータを探す為にメタデータをスキャンするとい うような操作がリニアなスケールで増えていく。こ うして、マスターに要求される仕事の量は、本質 的に増大する。
- 56. GFS: Evolution on Fast-forward GFSが、いまや、多くの挑戦にさらされているの は、疑問の余地はない。一例を挙げれば、不断に 増大するユーザーの大群と直面していて遅延が 大きな問題となるアプリケーションを、本来は、 バッチ・システムの効率を上げる為にデザインさ れたシステムの上でサポートしていることの、不 格好さは、誰の目にも明らかである。
- 57. GFS: Evolution on Fast-forward BigTableの登場は、この点では、いくらかの助け にはなった。ただ、明らかになったのは、 BigTableは、実際には、GFSとは、最良の組み 合わせではなかったということだ。事実、この組み 合わせは、GFSシステムの単一マスターのデザ インのボトルネックとしての限界を、他の場合より も、はるかに明らかなものとしただけだった。
- 58. GFS: Evolution on Fast-forward これした理由から、Googleの技術者達は、過去 2年間というもの、BigTableの利点を最大限生 かしながら、現GFSに取っては特に困難であると 証明されているいくつかの問題を攻略する、新し い分散マスターシステムのデザインに取り組んで きた。
- 61. 現在の実装 複数のGFSマスター chunk サーバー群の上に、複数のGFSサー バーを置く。 配下のストレージ・プールが、複数のGFSマス ターを持つように設定出来る。 異なったCellをまたいだデータの分割には、アプ リケーションが責任を持つ。
- 62. 現在の実装 Name Space それぞれのアプリケーションが、マスターを持つと しよう。（一つか、少数のマスターを） Name Spaceが、これらを全てをアプリケーショ ンから隠す。namespaceを分割する静的な方法 ログ処理システムでは、いったん一つのCellのロ グを使い果たすと、複数のGFS Cell に移動する。 Namespaceファイルは、ログ・データが、異なる Cellをまたがって分割されているかを記述する。
- 65. ふりかえり GFSは、記録的な短期間で製品化された。 3人 のチームが、一年足らずで配備にまでこぎ着けた。 GFSが稼働している最大級のファイル・システム であることを想起してほしい。 開発スピードの優位性は、Googleに、巨大な成 長を可能にした。
- 66. GFSの機能を最初に利用したのは、 大規模なク ローリングとindexシステムだった。 GFSの利用の第二の波は、大規模なデータを格 納することだった。GFSは、この新しいユースケー スにも適応出来るように調整された。 様々なアプリケーションが、GFSをイメージして開 発されるようになった。
- 67. Additional problems 急速な成長の中で、64MBのチャンク・サイズが 問題になった。Googleが扱うデータが巨大な為 になされたものであったが、Ｇmａｉｌのように、多く のファイルは、64MB以下で十分だった。 ファイル数のカウントは、また、別の問題になった。 ログの数が増え続けた。フロントエンドのサー バーはログを書き出すのだが、それがクラッシュ すると、更に大量のログを吐き出す。それは、想 定よりはるかに大きなデータだった。
- 68. Additional Improvements ファイル数の増大が問題だった。マスターのメモ リーが枯渇する前に、調整可能なのは、高々限ら れた数のファイルだ。 それぞれのファイルについて、メモリーに格納さ れるメタデータが必要になった。ファイル名とチャ ンクの情報。 もし、平均的なファイルサイズが、６４MB以下で あれば、ストレージに対するマスター上のオブジェ クトの数の比率は低下する。
- 70. Additional Improvements 全面的に新しいデザインの作業を始める。 分散マルチ・マスター・モデル。 1MBの新しいファイルサイズ。 ファイル数問題への対応 一万個の10KBのファイルを読む方が、100個の1MB のファイルを読むより、シークに時間がかかる。 一つのマスターに100M個のファイル。数百のマス ターという構成。
- 71. BigTable 構造化されたデータの分散ストレージ ファイル数の増大に対する対応策–小さなものを集約する 数千台のマシンをまたぎ、ペタバイトまでスケールする。 GFS上に構築され、GFS上で稼働し、GFSの原理と矛盾が ないように設計された。 アプリケーションにも見られるが、実際には、インフラの一 部 システムのエラーに非常に敏感に対応 クローリングとindexシステムに利用された 沢山の小規模なデータを利用するアプリは、BigTable を使う BigTableは、単にファイル数問題を扱うために設計さ れたものではない。それ以上の意図があった
- 72. BigTable もともとのアイデアは、SSTableとログ、たった二 つだけの基本構造を持つというものだった。 SSTables– Stored String Tables (key-value pair) BigTableは、mutableなログと、データを圧縮し たimmutableなSSTableの上に構築された。 GFSには、どんなデータでも書き込みが出来る。 しかし、大部分のユーザーは、結局、BigTable の二つのデータ構造、SSTableとログを使うよう になった。
- 73. More initial GFS limitations/ improvements 初期のGFSは、低い遅延の上に、高帯域（高ス ループット）を実現するようにデザインされていた。 バッチのアプリケーションでは、Single point of failureも許される。 ただ、ビデオのサービスでは、そうはいかない。
- 74. GFSでは三重化されたファイルに書き出すのだ が、もし、chunkserverが死んだり、調子が悪く なると、一つのchunkのレプリカを作る。この作業 に10秒から一分かかる。 大規模なMapReduceの処理ならそれでもいい が、Gmailでは、一分の遅れは受け入れられな い。 初期のマスターのフェイル・オーバーには、数分 かかっていたが、今では、それは数十秒に短縮さ れた。
- 75. More initial GFS limitations/ improvements MapReduceベースの世界から、BigTableのよ うなものに依存したインタラクティブな世界に移行 すること。 バッチ志向の処理用にデザインされたファイルシ ステムの上に、インタラクティブなDBを構築する ことは、挑戦的な課題だ。
- 76. Bigtable – トランザクション・ログがボトルネック。 二つのログファイルを同時に開いて、一つに書き込む。 それがいっぱいになったら、もう一つに書き出し、最後 にマージする。 Gmail は、マルチ・ホーム Gmailアカウントの一つのインスタンスが不調になっ たら、他のデータセンターに移る。（これは、可用性を 高めるのを助ける）
- 77. Compatibility issues: ドライバーとドライブのミスマッチが、データ破壊を 引き起こした（全てのIDEプロトコルのバージョン をサポートしていなかった） 厳格なチェックサムの実行が必要 でも、少しデータの読み込みが遅れるのはOKである これらの対策は、マスターに新しいデータを追加 して、もっと沢山の状態を管理することで可能に なった。
- 78. Consistency Issues あるファイルを複数回読むと、異なるデータが返 ることがある。 GFSは、全てのデータが全てのレプリカに書き出 されないと、次に進まない。問題は、クライアント がクラッシュした時に起きる。
- 79. Consistency Issues RecordAppend 複数のライターがログに追加 出来る。ゆるい整合性。 全てのレプリカが書き込まれたという保証がない。 データは、チャンクに一度以上、違った順序で、違った チャンクに書き込まれうる。等々。 問題があれば、新しいプライマリーが新しいオフ セットを取り出す。 ファイルを指定出来ない ゆるい整合性は、価値があるというより苦痛になる ファイルあたり単一の書き込み、順番付けされた書き 込みが、整合性の為には必要である。
- 80. Initial GFS aspect that still works Snapshot of chunk レプリカを置き換える クライアントが書き込めないロックを取り消す GFSは、snapshot機能もサポートしている – clone 非常に強力なのに、広くは利用されていない 実装が難しい。ただ、本当のsnapshotとして、実装を 試みた。
- 81. 結論 GFSの成績表は、10年経った今でも、ポジティブ である。 成功によってではなく、まだ力を発揮しているとい う点で。 スケールもアプリケーションも、1990年代後半の 想像をはるかに超えている。
- 82. チャレンジなのは、ユーザーを前にした、遅延に 敏感なアプリケーションを、バッチのスループット の為にデザインされたシステムの上でサポートす ること。 BigTableは助けになった。しかしそれは、GFSと ぴったりあっていた訳ではない。むしろそれは、ボ トルネックの限界を、明らかにした。 BigTableの利点を最大限生かした、分散マス ターのシステムをデザインすること。
- 84. Our new search index: Caffeine 2010年6月8日 Google Webmaster Central Blog http://googlewebmastercentral.blogs pot.jp/2010/06/our-new-searchindex-caffeine.html
- 94. Google Caffeine jolts worldwide search machine 2010年6月9日 Interview with Matt http://www.theregister.co.uk/2010/0 6/09/google_completes_caffeine_sea rch_index_overhaul/
- 97. Google search index splits with MapReduce Welds BigTable to file system 'Colossus’ 2010年9月9日 Interview with Lipkovitz http://www.theregister.co.uk/2010/0 9/09/google_caffeine_explained/
- 98. 新しい検索のインフラは、GFS分散ファイルシス テムの改修版を使用している。これは、Google File System 2、GFS2と呼ばれていたのだが、 Googleの内部では、Lipkovitzがいうように Colossusとして知られているという。 「Caffeineはデータベース・ドリブンで、BigTable を変化させたインデックス・システムである。 Googleは、このシステムを論じた論文を、来月 行われるUSENIX Symposium on Operating Systems Design and Implementation (OSDI) で発表する。」
- 100. 過去数年の間、MapReduceは、MITのデータ ベースの権威 Mike Stonebraker のような 人々から批判を受けてきた。Lipkovitzによれば、 Google自身、大分前から「同じような認識」に到 達していたという。 「MapReduceは、リアルタイムに近い出来事に 必要な計算には、向いていない。MapReduceは、 一連のバッチ処理からなる。一般的には、最初の 処理が終わるまでは、次のフェーズあるいは次の 処理を始めることは出来ない。」
- 103. 「開発者が、BigTable上でコードを実行するのを 助ける “計算フレームワーク” もある。このシステ ムは、Clossusで土台を支えられている。 Clossusは、GFS2としても知られている分散スト レージプラットフォームだ。元のGFSは、Google が望むようにはスケールしなかった。」
- 106. 2004年に、GoogleはGFSとMapReduceにつ いての研究論文を発表した。これが、オープン ソースのHadoopプラットフォームの基礎になっ た。それは、Yahoo, Facebook, Microsoftに よって利用されている。しかし、GoogleはGFSと MapReduceを超えて進もうとしている。 「世界の残りの部分が、我々より遅れていると主 張するつもりはない。我々は、検索を役に立つも のにするビジネスをしている。インフラを売るビジ ネスをしている訳ではない。」
- 107. Incrementally Indexing the Web with Percolator 2010年10月4日 Frank Dabek and Daniel Peng at OSDI, 2010 https://docs.google.com/presentation/d/1gKD4FbaUIGtoi mP6-ZB0iiW8V0KZt8fVET-Cfu5KiG8/present#slide=id.i0
- 108. 問題：Webにインデックスをつける 出力: サービス用のドキュメント 入力: 元の生ドキュメント times.co m URL mit.ed u indexing In Links Body PageRank nyt.co m g.cn ... 1 ... 1 fark.com times.com ... 3 g.cn fark.co m times.co mit.edu m mit.edu times.com .... 7 fark.com, times.com
- 110. MapReduceでのインデックスの更新 repository Map refresh • 新しいドキュメントにインデックスつけるべきか？ o 新しいドキュメントは、以前にクロールした文書のコ ピーかもしれない。 o 全てのレポジトリーの再マップが要求される。
- 111. インデックス・システムの目標 理想的なインデックス・システムに何を望むか？ 大量のデータのレポジトリー インデックスのサイズの上限まで インデックスのより高い質（沢山のリンクとか） クロールとインデックスの間の遅延の小ささ 「新鮮さ」 MapReduceのインデックス・システムは、クロール からインデックスまで、数日かかる。
- 112. インクリメンタルなインデックス付け • ランダム・アクセス可能なレポジトリーを、 BigTableに保持する • グローバル・スキャンを避けるインデックス •インクリメンタルに複製可能な状態が、URLとして、 クロールされる URL Contents http://usenix.org/osd <html>CFP, i10 .... http://nyt.com/ <html>Lede ... Pagerank Checksum Language 6 0xabcdef01 ENGLISH 9 0xbeefcafe ENGLISH
- 113. BigTable上のインクリメンタルな インデックス付け URL Checksum PageRank nyt.com 0xabcdef01 6 nytimes.com 0xabcdef01 9 IsCanonical? no yes Checksum Canonical 0xabcdef01 nytimes.com nyt.com 二つのURLを同時に処理すると、何が起きる？
- 114. Percolator: インクリメンタルなインフラ BigTableに分散トランザクションを追加 (0) Transaction t; (1) string contents = t.Get(row, "raw", "doc"); (2) Hash h = Hash32(contents); ... // Potential conflict with concurrent execution (3) t.Set(h, "canonical", "dup_table", row); ... (4) t.Commit(); // TODO: add retry logic Simple API: Get(), Set(), Commit(), Iterate
- 115. Bigtableの構造 Bigtableは整列された (row, column, timestamp) のストアである Column1 3: 2: RowOne 1: "I'm at timestamp 1" 3: RowTwo 2: 1: Column2 3: 2: "I'm at timestamp 2" 1: 3: 2: 1: Column3 3: 2: 1: 3: 2: 1: • データは行範囲でtabletに分割される • Tabletは、沢山のマシンに分散されている
- 116. 分散トランザクションの実装 • snapshot isolation semanticsを与える • Multi-version protocol (Bigtableのtimestampにmap) • Two phase commit クライアントが調整する • Locksは、Bigtableの特別なカラムに入れられる "balance" Alice balance:data 5: 4: 3: $10 balance:commit 5: 4: data @ 3 3: balance:lock 5: 4: 3:
- 117. Transaction Commit Transaction t; int a_bal = t.Get("Alice", "balance"); int b_bal = t.Get("Bob", "balance"); t.Set("Alice", "balance", a_bal + 5); t.Set("Bob", "balance", b_bal - 5); t.Commit(); balance:data balance:data 5: $15 5: $15 Alice Alice 4: 4: 3: $10 3: $10 Ben Bob5: 5: $5 4: $5 3: $10 4: 3: $10 balance:commit balance:lock balance:commit balance:lock 6: data @ 5 6: 6: data @ 5 5: 5: lock 5: data @ 3 4: 4: 5: 3: 3: 4: 4: data @ 3 3: 3: 6: 6: data @ 5 5: lock 4: 4: 5: 5: data @ 3 3: 3: 4: data @ 3 4: 3: 3:
- 118. Notifications: tracking work ユーザーは、"observer" をカラムに登録する カラム中の行に書き込みが起きると実行される それぞれのobserverは、新しいトランザクション で走る 書き込みごとに最大で一回実行される：メッセー ジの畳み込み Document • • • RawDocument RawDocumen Loader tLoader Document DocumentPr Processor ocessor DocumentPr Exporter ocessor DocumentPr LinkInverter ocessor アプリケーションは、一連のobserverのつながりと して構造化される
- 119. Notificationsの実装 Dirty column: もしobserversが走るべき行なら設定 ランダム分散スキャン 中断している仕事を見つけ、observerをスレッドプール で走らせる スキャンは効率的である。数ビットをみるだけ • • No shards or work units: nothing to straggle Dirty? balance:data Alice Yes 5: $15 Bob No 5: $5 ...
- 120. Running Percolator Each machine runs: Worker binary linked with observer code. Bigtable tablet server GFS chunkserver • • • Observer Code xN Percolator::RunWorker() Tablet Server GFS Tablet ... Server GFS Tablet Server GFS
- 121. MR v. Percolator: Performance Operating Point Fraction of Repository refreshed / hour
- 122. MR v. Percolator: Experience 我々は、MRベースのパイプラインをPercolatorに 変換した。 Pros: 新鮮さ: インデックスの遅延は数日から数分にまで落ちた スケーラビリティ: o 一層のスループット: もっと沢山のCPUを買えばいい o より大きなレポジトリー: ディスクスペースの制限のみ 運用面: 「落ちこぼれ」に耐性がある Cons: 並列性を考える必要がある ドキュメントあたりの処理コストが高価である(~2x) • • • • •
- 123. Running 1000 threads on Linux Percolatorは、thread-per-request モデル Pros: アプリケーションの開発者は、ストレートなコードを書ける スタックトレースが重要 デバッグ、プロファイルが容易 メニーコア・マシンに容易にスケールする Cons: カーネルのスケーラビリティ：プロセスがexitする間、1000 個のスレッドが働いている時、カーネルロックが保持される ローカルスレッドのストレージの検出がライブラリーにない キャッシュ等とのロックの競合 • • • • • •
- 124. System Building by D. Rumsfeld There are known unknowns. That is to say We know there are some things We do not know. But there are also unknown unknowns, The ones we don't know We don't know. — Sec. Donald Rumsfeld
- 125. Unknown unknowns CPUs that get XOR wrong periodically: checksum "failures” Bigtable scaling: can't delete files fast enough >50% of seeks going to useless readahead and metadata. Incorrect resistor value: our workload powers off machine Advice: Push performance debugging through all layers of system Expected weirdness proportional to machine count • •
- 127. Large-scale Incremental Processing Using Distributed Transactions and Notifications Daniel Peng and Frank Dabek Presented by Nick Radcliffe http://courses.cs.vt.edu/cs5204/fall11butt/lectures/perculator.pdf
- 129. Tradeoffs Percolator trades efficient use of resources for scalability. Caffeine (the Percolator-based indexing system) uses twice as many resources as the previous system to process the same crawl rate. Roughly 30 times more CPU per transactions than a standard DBMS.
- 130. Overview of Percolator design Percolator is built on top of Bigtable. A percolator system consists of three binaries that run on every machine in the cluster: Percolator worker Bigtable tablet server GFS chunkserver.
- 131. Overview of Percolator design Data is organized into Bigtable rows and columns, with Percolator metadata stored alongside in special columns. The Percolator library largely consists of Bigtable operations wrapped in Percolatorspecific computation. Percolator adds multirow transactions and observers to Bigtable.
- 132. Overview of Percolator design An observer is like an event-handler that is invoked whenever a userspecified column changes. Percolator applications are structured as a series of observers. Each observer completes a task and creates more work for “downstream” observers by writing to the table.
- 133. Large-scale Incremental Processing Using Distributed Transactions and Notifications 2010年10月4日 D Peng, F Dabek - OSDI, 2010 https://www.usenix.org/legacy/event s/osdi10/tech/full_papers/Peng.pdf
- 135. c:data c:lock データ自身を格納 コミットされていないトランザクションは、 このCellに書き込む。PrimaryLock の場所を含んでいる。 c:write コミットされた現在のデータ。 データのタイムスタンプを格納。 c:notify ヒント: observerが走る必要がある かもしれない c:ack O Observer “O”が走った。最後に 成功した実行のタイムスタンプを格納。
- 136. 初期状態： Joeの口座には2ドル、Bobの口座には、10 ドルが、はいっている。 bal:writeに、データのタイムスタンプが書き込まれること によって初めて、そのデータは外部から見えるようになる。
- 137. 送金のトランザクションは、Lockカラムに書き込むことで Bobの口座の残高をロックすることから始まる。このロック は、このトランザクションのprimaryである。 このトランザクションは、また、その開始タイムスタンプ 7 にデータを書き込む。
- 138. トランザクションは、次にJoeの口座をロックして、ふたた び開始タイムスタンプ 7に、Joeの新しい残高を書き込む。 このロックは、このトランザクションのsecondaryである。 primaryロック（”Bob”行の”bal”カラム）への参照を含ん でいる。 クラッシュでこのロックが立ち往生して、トランザクションが ロックを解消したいと思った時、このロックの解消を同期す るためにprimaryの場所が必要になる。
- 139. トランザクションは、コミットのポイントに到達する。 primaryロックを消して、それをコミットタイムスタンプと呼 ばれる新しいタイムスタンプ 8の下で、新しい書き込みレ コードと置き換える。この書き込みレコードは、データが格 納されているタイムスタンプへのポインターを含んでいる。 これ以降、”Bob”行の”bal”カラムを読むものは、値 $3 を見ることになる。
- 140. トランザクションは、secondary セルに書き込みデータを 追加し、ロックを消去することで完了する。 この例の場合には、ただ一つのsecondary Joeがあるだ けである。
- 141. Transaction in BigTable 詳細
- 142. 1 2 3 4 5 6 7 class Transaction { struct Write { Row row; Column col; string value; }; vector<Write> writes_ ; int start_ts_ ; Transaction() : start_ts_(oracle.GetTimestamp()) {} void Set(Write w) { writes_.push_back(w); } クラスTransactionの働きを見てみよう。 まず、Transactionのインスタンスの生成時に、 start_ts_には、その時点のタイムスタンプが 入れられる。 ６行目。
- 143. データの読み込み：bool Get(Row row, Column c, string* value) の働き row中の、コンカレントなwriteを通知するロック c:lockを、過去からstart_ts_まで、チェックする。 ペンディングされたロックがあれば、クリーンを試 みて待つ。なければ、次に進む。 c:writeをチェックして、過去からstart_ts_まで にコミットされた、書き込みをみつける。なければ、 データはない。 c:writeからコミットされたタイムスタンプを取得。 c:dataから、コミット・タイムスタンプ時点での値 を読み出す。
- 144. 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 bool Get(Row row, Column c, string* value) { while (true) { bigtable::Txn T = bigtable::StartRowTransaction(row); // コンカレントなwriteを通知するロックをチェックする if (T.Read(row, c+"lock", [0, start_ts_])) { // ペンディングされたロックがあれば、クリーンを試みて待つ BackoffAndMaybeCleanupLock(row, c); continue; } // スタート・タイムスタンプ以下の最新の書き込みをみつける。 latest write = T.Read(row, c+"write", [0, start ts_]); if (!latest write.found()) return false; // データなし int data_ts = latest_write.start_timestamp(); *value = T.Read(row, c+"data", [data ts, data ts]); return true; } }
- 145. 書き込み前処理：bool Prewrite(Write w, Write primary) の働き Prewriteは、セルcをロックしようとする。競合が あるとfalseを返し、Abortする。 c:writeをチェックし、スタート・タイムスタンプの 後にコミットされたものであれば、Abortする c:lockをチェックし、どんなタイムスタンプでもＬｏ ｃｋされていれば、Abortする。 c:dataに値を書き込む。 c:lockに、スタート・タイムスタンプと、primary lockの場所を書き込む。 コミットする。
- 146. 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 //Prewriteは、セルcをロックしようとする。競合があるとfalseを返す。 bool Prewrite(Write w, Write primary) { Column c = w.col; bigtable::Txn T = bigtable::StartRowTransaction(w.row); // スタート・タイムスタンプの後にコミットされたものであれば、Abortする if (T.Read(w.row, c+“write”, [start ts , ∞])) return false; // . . . あるいは、どんなタイムスタンプでもＬｏｃｋされていれば、Abortする if (T.Read(w.row, c+"lock", [0, ∞])) return false; T.Write(w.row, c+"data", start ts_, w.value); T.Write(w.row, c+"lock", start ts_, {primary.row, primary.col} ); // プライマリーの場所 return T.Commit(); }
- 147. コミット：bool Commit() の働き writes_ベクターの先頭がprimary、それ以降を secondariesとする。 primary、secondariesへのPreWriteが失敗 すれば、コミット失敗。 コミット・タイムスタンプを取得する。 まず、primaryをコミット c:lockのスタート・タイムスタンプ時点での値を読み込 む。なければ、コミット失敗。 コミット・タイムスタンプのc:writeに、 スタートタイムス タンプに書かれたデータへのポインターを書き込む。
- 148. コミット：bool Commit() の働き コミット・タイムスタンプのc:lockを消す。 コミットする。 続いて、secondariesをコミット。secondaries の各Writeごとに、 コミット・タイムスタンプのc:writeに、 スタートタイムス タンプに書かれたデータへのポインターを書き込む。 コミット・タイムスタンプのc:lockを消す。 コミット成功
- 149. 41 bool Commit() { 42 Write primary = writes_[0]; 43 vector<Write> secondaries(writes_.begin()+1, writes_.end()); 44 if (!Prewrite(primary, primary)) return false; 45 for (Write w : secondaries) 46 if (!Prewrite(w, primary)) return false; 47 48 int commit_ts = oracle .GetTimestamp(); 49 50 // Primaryを、まずコミットする 51 Write p = primary; 52 bigtable::Txn T = bigtable::StartRowTransaction(p.row); 53 if (!T.Read(p.row, p.col+"lock", [start_ts_, start_ts_])) 54 return false; // 動作中にabort 55 T.Write(p.row, p.col+"write", commit ts, 56 start_ts_); // スタートタイムスタンプに書かれたデータへのポインター 57 T.Erase(p.row, p.col+"lock", commit ts); 58 if (!T.Commit()) return false; // コミットポイント 59 // 第二フェーズに進む
- 150. 60 // 第二フェーズ セカンダリーセルにレコードを書き出す 61 for (Write w : secondaries) { 62 bigtable::Write(w.row, w.col+"write", commit_ts, start_ts_); 63 bigtable::Erase(w.row, w.col+"lock", commit ts); 64 } 65 return true; 66 }
- 151. bool UpdateDocument(Document doc) { Transaction t(&cluster); t.Set(doc.url(), "contents", "document", doc.contents()); int hash = Hash(doc.contents()); // dups table maps hash --> canonical URL string canonical; if (!t.Get(hash, "canonical-url", "dups", &canonical)) { // No canonical yet; write myself in t.Set(hash, "canonical-url", "dups", doc.url()); } // else this document already exists, ignore new copy } return t.Commit();
- 153. Dremel: Interactive Analysis of Web-Scale Datasets Proc. of the 36th Int'l Conf on Very Large Data Bases (2010), pp. 330339 http://static.googleusercontent.com/ external_content/untrusted_dlcp/rese arch.google.com/ja//pubs/archive/36 632.pdf
- 156. Google Dremel
- 157. Dremelが利用されている領域 クロールされたWebドキュメントの解析 Androidマーケットで、インスロールされたアプリの追跡 Google製品のクラッシュ報告 Google BooksのOCRの結果. スパムの解析 Google Mapのmapタイルのデバッグ BigtableインスタンスのTabletマイグレーションの管理 Googleの分散ビルドシステム上での実行テスト結果 数十万のディスクのDisk I/O 統計 Googleデータセンターで実行されているジョブの、リソー ス・モニタリング Googleのコードベースの、シンボルと従属性
- 158. message Document { required int64 DocId; optional group Links { repeated int64 Backward; repeated int64 Forward; } repeated group Name { repeated group Language { required string Code; optional string Country; } optional string Url; }} Protocol Buffer Document DocID Links? Backward* Name* Forward* サンプルのスキーマ Language* Code Url? Country?
- 159. Document Repetetion Level Definition Level DocID ０ Links? 1 Names* 1 1 Backward* 1 Forward* 1 Language* 2 Url? 2 2 2 2 Code 2 Country? 3
- 160. DocId: 10 Links Forward: 20 Forward: 40 Forward: 60 Name Language Code: 'en-us‘ Country: 'us' Language Code: 'en' Url: 'http://A' Name Url: 'http://B' Name Language Code: 'en-gb' Country: 'gb' DocId: 20 Links Backward: 10 Backward: 30 Forward: 80 Name Url: 'http://C‘
- 161. DocId: 10 Links Forward: 20 Forward: 40 Forward: 60 Name Language Code: 'en-us‘ Country: 'us' Language Code: 'en' Url: 'http://A' Name Url: 'http://B' Name Language Code: 'en-gb' Country: 'gb' DocId: 20 Links Backward: 10 Backward: 30 Forward: 80 Name Url: 'http://C‘
- 162. DocId: 10 Links Forward: 20 Forward: 40 Forward: 60 Name Language Code: 'en-us‘ Country: 'us' Language Code: 'en' Url: 'http://A' Name Url: 'http://B' Name Language Code: 'en-gb' Country: 'gb' DocId: 20 Links Backward: 10 Backward: 30 Forward: 80 Name Url: 'http://C‘
- 163. サンプルの格納状態 Document DocID 10 0 0 20 0 0 Links? Backward* NULL 0 1 10 02 30 12 Name* Forward* 20 40 60 80 0 1 1 0 2 2 2 2 Language* Url? http://A 0 2 Code Country? http://B 1 2 NULL 11 http://C 0 2 en-us 0 2 us 03 en 2 2 NULL 2 2 NULL 1 1 NULL 1 1 en-gb 1 2 gb 13 NULL 0 1 NULL 0 1
- 164. Dremelの検索言語 SELECT DocId AS Id, COUNT(Name.Language.Code) WITHIN Name AS Cnt, Name.Url + ',' + Name.Language.Code AS Str FROM t WHERE REGEXP(Name.Url, '^http') AND DocId < 20; 出力結果 Id: 10 Name Cnt: 2 Language Str: 'http://A,en-us' Str: 'http://A,en' Name Cnt: 0 出力のスキーマ message QueryResult { required int64 Id; repeated group Name { optional uint64 Cnt; repeated group Language { optional string Str; }}}
- 165. 検索の木構造 SELECT A, COUNT(B) FROM T GROUP BY A SELECT A, SUM(c) FROM (R11 UNION ALL ...R1n) GROUP BY A R1i = SELECT A, COUNT(B) AS c FROM T1i GROUP BY A T1iは、レベル1のサーバーiで処理される、テーブルTの Tabletの分割
- 167. MapReduceとDremel numRecs: table sum of int; numWords: table sum of int; emit numRecs <- 1; emit numWords <- CountWords(input.txtField); Q1: SELECT SUM(CountWords(txtField)) / COUNT(*) FROM T1 3000 nodes, 85 billion records
- 168. 結論 スキャンベースの検索は、一兆個以上のディスク上の データセットに対して、インタラクティブなスピードで実行出 来る。 数千ノードを含むシステムで、カラムとサーバーの数に関 して、ほとんどリニアーなスケーラビリティーを達成出来る。 DBMSとまったく同様に、MapReduceは、カラム型のス トレージの恩恵を受ける。 レコードの収集とパージングは、コストがかかる。ソフト ウェアの層は（検索実行の層を超えて）、直接カラム指向 のデータを利用出来るようになる必要がある。
- 170. Spanner: Google’s Globally-Distributed Database Wilson Hsieh representing a host of authors OSDI 2012 http://static.googleusercontent.com/external_content/untrusted_dlcp/ research.google.com/ja//archive/spanner-osdi2012.pdf http://research.google.com/archive/spanner.html Video: https://www.usenix.org/conference/osdi12/elmo-building-globallydistributed-highly-available-database
- 171. Spannerとは何か？ 分散マルチバージョンデータベース 汎用のトランザクション(ACID) SQL言語のサポート スキーム化されたテーブル Semi-relationalなデータモデル 既に、製品として稼働している Googleの広告データのストレージとして sharded MySQL を置き換えている OSDI 2012 171
- 172. Example: Social Network x1000 x1000 San Francisco Brazil Seattle User posts Arizona Friend lists US x1000 Spain OSDI 2012 Sao Paulo Santiago Buenos Aires London Paris Berlin Madrid Lisbon x1000 Moscow Berlin Krakow Russia 172
- 173. Spanner概観 特徴: Lock-freeな、分散readトランザクション 特質: 分散トランザクションの外的整合性保証 グローバルなスケールでは、最初のシステム 実装: Concurrency controlとReplication と2PCの統合 正当性とパフォーマンス 可能にした技術: TrueTime Interval-basedなグローバル時間 OSDI 2012 173
- 174. 読み込みのトランザクション 友達の最近のポストのページを生成する 友達のリストとそのポストの整合的なビュー 何故、整合性が重要なのか？ 1. 不審な人物を友達から削除する 2. Post P: “我々の政府は、抑圧的である…” OSDI 2012 174
- 175. 単一のマシン マイページの生成 Friend1 post Friend2 post … Friend999 post Friend1000 post OSDI 2012 User posts Friend lists 175
- 177. 複数のマシン Friend1 post Friend2 post User posts Friend lists … Friend999 post Friend1000 post OSDI 2012 マイページの生成 User posts Friend lists 177
- 179. 複数のデータセンター Friend1 post US User posts x1000 Friend lists Friend2 post Spain … User posts x1000 Friend lists マイページの生成 Friend999 post Brazil User posts x1000 Friend lists Friend1000 post Russia User posts x1000 Friend lists OSDI 2012 179
- 181. 書き込みとバージョン管理 書き込みのトランザクションには、厳密なTwo-PhaseLockを使う。 それぞれのトランザクションTには、タイムスタンプsが割り当 てられる。 トランザクションTによって書き込まれたデータは、タイムスタ ンプｓを持つ。 Time <8 My friends [X] My posts X’s friends [me] OSDI 2012 8 15 [] [P] [] 181
- 183. タイムスタンプとグローバル・クロック 書き込みのトランザクションについては、厳密な two-phase lockingを適用する。 ロックが保持されている間、タイムスタンプを割り当 てる。 Acquired locks Release locks T Pick s = now() OSDI 2012 183
- 184. タイムスタンプの不変量 • タイムスタンプの順序 == コミットの順序 T 1 T 2 • タイムスタンプの順序は、グローバルな壁時計 の順序を尊重する T 3 T 4
- 186. タイムスタンプとTrueTime Acquired locks Release locks T Pick s = TT.now().latest s Wait until TT.now().earliest > s Commit wait average ε OSDI 2012 average ε 186
- 187. コミットのWaitとレプリケーション Achieve consensus Start consensus Notify slaves Acquired locks Release locks T Pick s Commit wait done
- 188. Commit Wait and 2-Phase Commit Start logging Done logging Acquired locks Release locks TC Acquired locks Committed Notify participants of s Release locks TP1 Acquired locks TP2 Release locks Prepared Send s Compute s for each Commit wait done Compute overall s OSDI 2012 188
- 189. Example Remove X from my friend list Risky post P TC T2 sC=6 TP s=8 s=15 Remove myself from X’s friend list sP=8 s=8 Time 8 My friends My posts X’s friends OSDI 2012 <8 [X] 15 [] [P] [me] [] 189
- 190. 我々がカバー出来たことは何か？ データセンター間の、ロックフリーな、read トラ ンザクション 外的整合性 タイムスタンプの割り当て TrueTime 時間の不確実性は、待つことでしのぐことが出来る OSDI 2012 190
- 191. 我々がカバーしなかったこと 現在の時刻を、どうよむのか。 アトミックなスキーマの変更 大部分は、ノン・ブロッキングである 未来のタイムスタンプでコミットする 過去のノン・ブロッキングな読み込み レプリカの効率的な更新 OSDI 2012 191
- 192. TrueTime Architecture GPS timemaster GPS timemaster GPS timemaster GPS timemaster Atomicclock timemaster GPS timemaster Client Datacenter 1 Datacenter 2 … Datacenter n Compute reference [earliest, latest] = now ± ε OSDI 2012 192
- 193. TrueTime implementation now = reference now + local-clock offset ε = reference ε + worst-case local-clock drift ε +6ms reference uncertainty 0sec OSDI 2012 200 μs/sec time 30sec 60sec 90sec 193
- 194. 時計が狂うとどうなるか？ タイムスタンプの割り当てが、外的整合性を破 ることになるだろう。 一年間のデータに基づけば、そういうことはあ りそうにない。 時計が狂うより、CPUがおかしくなる可能性の方 が、６倍以上ありそうである。 OSDI 2012 194
- 195. 将来の課題 TrueTimeの改善 Lower ε < 1 ms データベースの諸特徴をきちんと構築する 基本的な特徴の実装を終える 多様な検索パターンを効果的にサポートする OSDI 2012 195
- 196. 結論 時計の不確実性を time APIで具体化する 知らないことを知ることは、知らないことを知らない より、いいことである 不確実性を利用した、アルゴリズムを再考すること 強いセマンティックは達成可能である 大規模なスケール != 弱いセマンティックス OSDI 2012 196
- 199. Google Knowledge Graph 新しい検索の三つの特徴 正しい「もの」を見つける。（Find the right thing） 最良の要約を得る。（Get the best summary） さらに深く、さらに広く。（Go deeper and broader）
- 200. 検索結果のパーソナライズ
- 201. Googleの 検索結果の「パーソナライズ」 人々は、コンテキストとパーソナライズを混同して いる。この２つは別のものだ。コンテキストには、 言語、場所、年度等が因子として含まれる。 過去の検索の履歴は、パーソナライズに利用さ れている。もし、「ローマ」を検索して次に「ホテル」 を検索すれば、検索結果のいくつかは、ローマの ホテルのものになるだろう。 履歴上の過去のクリックも、一つの因子となる。も し、検索結果中の一つのサイトに対してクリックし て、明らかな嗜好を示せば、次の検索では、その サイトは上位にランクされるかもしれない。
- 202. Googleの 検索結果の「パーソナライズ」 URLの最後の部分に、&pws=0 を追加すると機 能する。ただ、パーソナライズを消すだけで、コン テキスト（言語、場所、年度）は消さない。 全てのパーソナライズをオフにする方法はある。 Googleの立場は、ユーザーは自分のデータを所 有するというものだ。ただ、その場合でも、コンテ キストは、依然として、有効になっている。 "How Google Does Personalization with Jack Menzel” http://www.stonetemple.com/ how-google-does-personalization-with-jack-menzel/
- 206. まとめ
- 213. Google
- 214. Google
- 217. 資料編 Snapshot Isolation “A Critique of ANSI SQL Isolation Levels” Spanner: Google’s GloballyDistributed Database
- 218. Snapshot Isolation “A Critique of ANSI SQL Isolation Levels” http://t.co/2HBae9l5gK
- 219. Start-Timestamp Snapshot Isolationでは、それぞれのトランザ クションは、Start-Timestampと呼ばれる、トラ ンザクションを開始した時刻のデータのスナップ ショット（コミットされた）からデータを読み込む。こ の時刻は、トランザクションの最初の読み込みの 時刻の前の時刻になる。 トランザクションのStart-Timestamp以降にア クティブになった他のトランザクションによる更新 は、このトランザクションからは見えない。
- 220. ReadとWrite Snapshot Isolationの中のトランザクションは、 そのStart-Timestampからのスナップショットの データが維持可能である限り、読み込みがブロッ クされることはない。 トランザクションでの書き込み(updates, inserts, deletes)もまた、このスナップショットに 反映される。もしトランザクションが、このデータに 二度目のアクセス（reads あるいは updates）を するなら、ふたたび、読み出される。
- 221. Commit-Timestamp トランザクションT1が、コミットの準備ができた時、 それはCommit-Timestampを取得するのだが、 それは、既に存在するStart-Timestampあるい は Commit-Timestampより、大きな値を持つ。 トランザクションは、T1の実行間隔 [StartTimestamp, Commit-Timestamp] 内にCommit-Timestampを持つ他のトランザ クションT2が、 T1が書き出したデータと同じデー タを書き出していない場合に限り、コミットに成功 する。
- 223. Spanner: Google’s GloballyDistributed Database James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, JJ Furman, Sanjay Ghemawat et al. http://static.googleusercontent.com/external_conten t/untrusted_dlcp/research.google.com/ja//archive/sp anner-osdi2012.pdf
- 224. Abstract
- 225. Abstract Spannerは、スケーラブルで、マルチ・バージョン、 グローバルに分散し、レプリカの同期を行う、 Googleのデータベースである。 それは、グローバルなスケールでのデータの分散 と外的整合的な分散トランザクションをサポートし た、初めてのシステムである。 この論文は、Spannerがどのような構造を持つ か、その諸特徴、様々なデザインの決定の基礎 にある理論的な根拠、時計の不確実性を明らか にする全く新しい time APIについて述べたもの である。
- 227. 1 Introduction
- 228. 概観 Spannerは、Googleで、デザイン・構築・配備さ れたスケーラブルでグローバルな分散データベー スである。 もっとも高い抽象のレベルでは、 それは、全世界 に広がっているデータセンター内の沢山のPaxos 状態マシン群をまたいで、データを分割したデー タベースである。 Spannerは、数百のデータセンターをまたいだ数 百万のマシンと、数兆行のデータベースにスケー ルアップするように設計されている。
- 229. ReplicaとResharding データの複製は、グローバルな可用性と地理的な局所性 の為に利用されている。クライアントは、レプリカ間で自動 的にフェール・オーバーする。 Spannerは、データの量やサーバーの数が変化するに 応じて、マシン間でデータを再分割する。それは、マシン 間で（データセンター間でさえ）、自動的にデータを移動し て、負荷のバランスを取り、マシンの失敗に対応する。 アプリケーションは、広域の自然災害に直面しても、内部 で、あるいは大陸をまたいでも、データを複製することに よって、高い可用性の為に、Spannerを利用出来る。
- 230. ReplicaとAvailability 我々のシステムの最初の利用者は、Googleの広告シス テムのバックエンドを書き換えたF１であった。F1は、アメ リカ全土に広がった5つのレプリカを利用した。 他のアプリの大部分は、相対的には独立な事故のモード を想定してではあるが、一つの地理的な領域内で、3から 5のデータセンターに、データを複製するだろう。というの は、大部分のアプリケーションは、一つか二つのデータセ ンターで事故が起きても、生き残ることが出来る限りは、 高い可用性の上の低い遅延の方を選ぶだろう。 Spannerの主なフォーカスは、データセンターをまたいだ 複製データの管理に置かれている。
- 235. グローバルに分散したデータベースとしての Spannerの、興味深い特徴 第二に、Spannerは、分散データベースでは実 装するのが難しい二つの特徴を持つ。 読み書きについての外的整合性 ある時点での、データベースをまたいだグローバルに 整合的な読み込み こうした特徴は、グローバルなスケールで、たとえ 実行中のトランザクションがあったとしても、整合 的なバックアップ、整合的なMapReduceの実行、 アトミックなスキーマの更新を、Spannerに可能 とする。
- 236. Timestamp こうした特徴は、たとえトランザクションが分散していたとし ても、Spannerがトランザクションにグローバルに意味の あるコミット・タイムスタンプを割り当てるという事実によっ て可能になった。 このタイムスタンプは、シリアル化された順序を反映して いる。それに加えて、シリアル化された順序は、外的整合 性（あるいは、それと等価だが、線形化可能性）を満たし ている。すなわち、あるトランザクションT1が、別のトラン ザクションT2が始まる前にコミットするなら、T1のコミット・ タイムスタンプは、T2のそれよりも小さい。 Spannerは、グローバルなスケールで、こうした保証を与 えた最初のシステムである。
- 237. TrueTime API こうした性質を可能にした重要なものは、TrueTime API とその実装である。 このAPIは、直接に、時計の不確実さを、あらわに示すも のである。そして、Spannerのタイムスタンプは、実装が 提供する不確実さの範囲にディペンドしている。もし、不確 実さが大きければ、Spannerは、この不確実さを待つ為 に、スピードを落とす。 この実装は、複数の現代的な時計（GPSと原子時計）へ の参照を利用することで、不確実性を小さなもの（一般的 には、10ms以下）にとどめようとする。
- 238. 2 Implementation 2.1 Spanserver Software Stack 2.2 Directories and Placement 2.3 Data Model
- 239. Implementation この節では、Spannerの構造とその実装の基礎 にある理論的な根拠を述べる。 その後、複製と局所性を管理するのに利用され、 データ移動の単位である、「ディレクトリー」という 抽象について述べる。 最後に、我々のデータモデルと、なぜSpanner がキー・バリュー・ストアではなくリレーショナル・ データベースのように見えるのか、また、アプリ ケーションは如何にしてデータの局所性をハンド ルすることが出来るのかについて述べる。
- 240. UniverseとZone Spannerの配備は、「ユニバース」と呼ばれる。 Spannerがデータをグローバルに管理している としても、ほんの少数の稼働しているユニバース があるだけだろう。 我々は現在、テスト/プレイグラウンド・ユニバース と、開発/生産・ユニバースと、生産専用・ユニ バースの三つを走らせている。 Spannerは、一群の「ゾーン」で組織されている。 それぞれのゾーンは、大まかにいって、 BigTableのサーバーに相当するものである。
- 241. Zone ゾーンは、管理上の配備の単位である。一群のゾーンは、 また、その上にデータの複製を置くことが出来る、場所群 でもある。 新しいデータセンターがサービスを開始したり、逆に、古 いデータセンターがサービスを停止したりした場合、ゾー ンを稼働中のシステムに追加したり取り除くことが出来る。 ゾーンは、物理的な隔離の単位でもある。データセンター には、一つかそれ以上のゾーンがあるかもしれない。例え ば、異なったアプリのデータが同じデータセンター内の異 なったサーバー群にまたがって分割されなければいけな いような場合である。
- 243. ZonemasterとLocationProxy 図1は、Spannerユニバースのサーバーを図示 したものである。 ゾーンは、一つのゾーン・マスターと、百から数千 の間のスパンサーバーを持っている。前者は、ス パンサーバーにデータを割り当てる。後者は、 データをクライアントにサービスする。 ユーザーのデータに割り当てられたスパンサー バーの場所を特定する為に、そのゾーンのロケー ション・プロキシーが利用される。
- 244. UniverseMasterとPlacementDriver ユニバース・マスターとプレスメント・ドライバーは、現在のと ころ、一つしかない。 ユニバース・マスターは、第一義的には、全てのゾーンにつ いてのステイタス情報が表示され、インタラクティブなデバッ グの為に利用される、コンソールである。 プレスメント・ドライバーは、数分の単位のタイムスケールで の、ゾーンをまたいだデータの自動的な移動をハンドルする。 プレスメント・ドライバーは、定期的にスパンサーバーと通信 して、レプリカの更新条件に合致した、あるいは、負荷をバラ ンスさせる為、移動すべきデータを見つける。 スペースの関係で、スパンサーバーについてのみ、詳しく述 べることになろう。
- 245. 2.1 Spanserver Software Stack この節では、スパンサーバーの実装にフォー カスして、我々のBigTableをベースにした実 装の上に、どのように、複製と分散トランザク ションが、実現されたかを示す。
- 246. Spanserver Software Stack ソストウェア・スタックは、次の図2に示されている。 スタックの一番下では、スパンサーバーが、100 個から1000個の間のタブレットと呼ばれるデータ 構造のインスタンスに責任を持っている。 タブレットは、BigTableのタブレットという抽象と 同様のもので、その中では、次のようなマッピング のバッグを実装している。 (key:string, timestamp:int64) → string
- 248. Bigtableとは異なって、Spannerは、タイムスタンプを データに割り当てる。ここが、Spannerがキー・バリュー・ ストアよりは、マルチ・バージョン・データベースにずっと似 ている重要なポイントである。 タブレットの状態は、Bツリーに似た一群のファイルと write-aheadログに格納されている。これらは全て Colossusと呼ばれる分散ファイルシステム（Google File Systemの後継である）上にある。 複製をサポートする為に、それぞれのスパンサーバーは、 それぞれのタブレット上に、一つのPaxos状態マシンを実 装している。
- 249. (初期のSpannerの具体化では、タブレットごと に複数のPaxos状態マシンをサポートしていた。 それによって、もっと柔軟な複製の設定が可能と なるのだが、そのデザインの複雑さの為に、我々 は、それを放棄した。） それぞれの状態マシンは、そのメタデータとログ を対応するタブレットに格納する。 我々のPaxosの実装は、時間ベースのリーダー のリースで、デフォルトの長さが10秒の、長い期 間のリーダーをサポートしている。
- 257. 2.2 Directories and Placement
- 258. 2.2 Directories and Placement キー・バリュー・マッピングのバッグの上で、 Spannerの実装は、「ディレクトリー」と呼ばれる 「バケット化」の抽象をサポートしている。それは、 共通の接頭辞を共有する連続的なキーの集まり である。（ディレクトリーという言葉の選択は、歴史 的な事情によるもので、もっと良い言葉は、「バ ケット」だったかもしれない。） 次のセクション2.3で、この接頭辞の起源を説明 しよう。ディレクトリーのサポートは、キーを注意深 く選ぶことによって、データの局所性をコントロー ルすることを可能にする。
- 259. ディレクトリーは、データの配置の単位である。 ディレクトリー内の全てのデータは、同じ複製設定 を持つ。 データがPaxosグループ間を移動する時、それ は図3が示すように、ディレクトリーからディレクト リーへと移動する。 Spannerは、ディレクトリーを、あるPaxosグルー プから負荷を軽減する為に移動するかもしれない。 よくアクセスされるディレクトリーを同じグループに まとめたり、アクセスする人に近いグループにディ レクトリーを移動したり。
- 263. Movedirは、大きなかたまりのデータ移動の際に 実行される、読み出し・書き込みのブロックを避け る為に、単一のトランザクションとしては、実装さ れていない。 その代わりに、 movedirは、データ移動が始 まったという事実を登録し、データをバックグラウ ンドで移動する。 名目的なデータの量以外の全てのデータを移動 し終わったら、movedirは、この名目的な量をア トミックに移動する為にトランザクションを利用し、 二つのPaxosグループのメタデータを更新する。
- 264. ディレクトリーは、また、その複製の地理的なプロ パティ（短く、「配置」という）が、アプリによって指 定される最小の単位である。 配置指定の言語は、複製の設定を管理する責任 とは分離されている。 管理者は、二つの次元をコントロールする。レプリ カの数と型、そして、これらのレプリカの地理的な 配置である。管理者は、これらの二つの次元で、 名前でオプションのメニューを作る。（例えば、 North America, replicated 5 ways with 1 witness というような).