cyber-physical systems とは何か？
Post on 24-May-2015
1.451 Views
Preview:
DESCRIPTION
TRANSCRIPT
Cyber-Physical Systems と自律分散システム
@maruyama097
丸山不二夫
Agenda
Cyber-Physical System とは、何か ? Cyber-Physical Systems の歴史での重要な
出来事 Cyber-Physical Systems が挑戦している課
題 Cyber-Physical Systems として情報システ
ムを捉え直す 自律分散というアプローチ これから考えるべきこと
Cyber-Physical Systemとは、何か ?
ここでは、 Cyber-Physical Systems の簡単な定義を与えて、共通部分の多い IoTやビッグデータ論との比較を行う
“Internet of Things” 最初の意味
“Internet of Things” という言葉は Kevin Ashton によって、 1999 年に提案された
“That ‘Internet of Things’ Thing” by Kevin Ashton 初出 “Internet of Things” というフレーズは、私
が 1999 年に Procter & Gamble (P&G) 社で行ったプレゼンのタイトルとして、初めて世に出た。 P&G 社のサプライチェインの新しいアイデアとしての RFID を、当時、最もホットなトピックであったインターネットに結びつけたことは、経営幹部の強い注意を引きつけるに十分だった。
“That 'Internet of Things' Thing” by Kevin Ashtonhttp://bit.ly/1bt4GBP
すべてのモノに ID を持たせるというアイデア
今日の情報技術は、人間によって生み出される情報にあまりに依存していて、我々のコンピュータは、モノについてより、人間の考えについての方をよく知っている。
もし、我々の助けなしに自分で集めたデータを使って、モノについて知りうる全てのことを知っているコンピュータがあったとすれば、我々は、すべてのモノを追跡しその数を数えることが出来、無駄や損失やコストを多いに削減することが出来るだろう。
“That 'Internet of Things' Thing” by Kevin Ashtonhttp://bit.ly/1bt4GBP
人が生み出す情報ではなく、モノについての情報
日本への影響 「ユビキタス」情報通信白書特集テーマの変遷
2004 年「世界に拡がるユビキタスネットワーク社会の構築」
2005 年「 u-Japan の胎動」 2006 年「ユビキタスエコノミー」 2007 年「ユビキタスエコノミーの進展とグ
ローバル展開」
2008 年「活力あるユビキタスネット社会の実現」
2009 「日本復活になぜ情報通信が必要なのか」
http://bit.ly/1n66E07
日本への影響 「ユビキタス」IT の世界で何が起きていたか？
2004 年「世界に拡がるユビキタスネットワーク社会の構築」 Google 上場
2005 年「 u-Japan の胎動」 CPS
2006 年「ユビキタスエコノミー」 Amazon EC2/S3
2007 年「ユビキタスエコノミーの進展とグローバル展開」 iPhone
2008 年「活力あるユビキタスネット社会の実現」
2009 「日本復活になぜ情報通信が必要なのか」
Microsoft AzureAndroid
http://bit.ly/1n66E07
丸山の「ユビキタス論」へのコメント2010 年 4 月マルレク「日本のクラウド」
それは、平面上にアモルファスに広がる構造を欠いたネットワーク。そして、それは、ネットワークやデバイスやチップの遍在でしかない。
クラウドとモバイルデバイスは、ネットワークに、ネットワークの背骨ともいうべき、明確な垂直構造をもたらす。そうした視点を欠く。
我々にとって重要なのはネットワーク自身の遍在ではなく経済活動と人間のコミュニケーションと情報共有の担い手としてのネットワークの遍在である。
Human Centric Sensor Networkhttp://bit.ly/1n66E07
SNS ・クラウドの基本構造：情報の涌き出し口としての個人（＋マシン）
Server Centric P2P
Cyber-Physical Systems とは何か
Cyber-Physical Systems とは何か？ Cyber-Physical Systems(CPS) とは、コン
ピュータの計算能力と物理的なシステムの能力が結びつけられて両者がしっかりと協調するシステムである。
組込み系を中心としたリアルタイムの処理技術と、機械の制御を中心とするディジタル・アナログのハイブリッド技術の二つが合流して生まれた。
2006 年にアメリカの NSF が大学や研究機関に Cyber-Physical Systems研究に大規模な資金提供を始めて、全世界にこのコンセプトは広まった。
Cyber と Physical の違い Cyber-Physical Systems のコンセプトで重
要なことは、コンピュータやネットワークのプログラムを中心とする Cyber な世界と、現実の機械を中心とする Physical な世界が、まったく異なる原理でドライブされているという認識である。
Cyber の世界は、論理的・数学的な「正しさ」が基本原理。その意味では、その原理は抽象的なもの。一方、 Physical な世界を動かしているのは、最終的には、物理法則。それは、具体的で現実的なもの。 Cyber-Physical Systems は、この異なる二つの世界が結びついたシステム。
単純な Cyber-Physical System の図式
Physicalsystem
Cyber
Physical
CSP は、 Physical Cyber と Cyber Physicalの二つのパスを持つことに留意しよう。
抽象化したCyber-Physical Systems の図式
Physical World
Cyber World数学的原理
物理法則
CPS と IoP
CSP と IoT のコンセプトは、共通部分を持つ。ただ、この二つのコンセプトには、違いも存在する。
IoT は、今日では、「多数のデバイスやセ ンサーが、（インター）ネットにつながること」と理解されることが多く、また、そこから発生するビッグデータの処理にも関心が向けられる。
CSP では、関心は、コンピュータによる物理系のリアルタイムの制御にも置かれる。インターネット接続を必ずしも前提としない自律型のロボットや、 3D プリンターは、 CPS の一つの例。
ビッグデータ論の特徴— Physical から Cyber へ IoT では、無数のセンサーから沸き出す巨大
な情報「ビッグデータ」の処理が中心的な課題になるという議論がよくある。そうした処理が必要な場合が存在し、それが技術的にチャレンジングな課題であるのは、確かである。
ただ、物理的な世界から発した情報が、全て一カ所にまとめられ、情報として処理されるというイメージは、少し狭いとも思う。なぜなら、そこでは、 Physical から Cyber へと、情報が一方的に流れるだけだけからである。
単純化したIoT とビッグデータの図式
Physical World
Cyber World
Big Data
3D プリンターとロボット — Cyber から Physical へ Cyber から Physical の情報の流れを代表す
る例は、何になるのだろう？ 現実を変えるという意味では、我々が用いる道具や機械は、全て、そうした役割を持つ。ただ、多くの道具や機械は、人間が直接にコントロールしている。
人間ではなくコンピュータによって制御される機械が、 Cyber から Physical の情報の流れの担い手になるというのなら、すぐに思いつくのは、 3D プリンターやロボットである。
単純化したロボットや 3D プリンターの図式
Physical World
Cyber World
Control
Physical と Cyber の相互作用の発展段階を考える IoT の最初期には、 Things は単なるモノ
（に付けられた RFID タグ）だったので、 CP の作用は望むべきも無かった。 Things が Sensors になっても、こうした事情はさして変わらない。
このレベルでは、センサー・レベルの IoT と3D プリンター / ロボットは、情報の流れに関して言えば、「相補的」な関係にある。
Things( こうした言い方が妥当なものか議論の余地がある ) が、センサーを備えたアクティブ・デバイスになったとき、 Cyber-Physical Systems の重要性が、もっと明らかになる。
Cyber-Physical Systems の歴史での、重要な出来事
ここでは、 Cyber-Physical Systems の歴史をふりかえって、いくつかの重要な出来事をピックアップしてみよう
Cyber-Physical Systems のコンセプトの始まり
Cyber-Physical Systems のコンセプトを始めて打ち出したのは、アメリカのNSF である。2006 年のことである。
NSF Workshop On Cyber-Physical Systems
2006/10/16-17 「 Cyber-physical systems は、インターネットが、我々人間が互いに関係しあうスタイルを変化させたのと、丁度同じように、我々と物理的世界との関係を変化させて行くだろう。」
http://varma.ece.cmu.edu/CPS/
http://varma.ece.cmu.edu/CPS/Presentations/Zhao.pdf
アメリカの国益にかなう
基礎研究にフォーカスする
境界横断的
なんでもが、 CPS なのではない！
http://varma.ece.cmu.edu/CPS/Presentations/Panel-1/Janos-Sztipanovits.pdf
2006 年の WorkShopAcademics Panel Session の冒頭でJanos が、プレゼンをしている
コンピュータ・システムと物理的なシステムが交わる領域
数学的領域物理法則
Cyber-Physical Systems (CPS)
2009/02/27PROGRAM SOLICITATION NSF 08-611http://www.nsf.gov/pubs/2008/nsf08611/nsf08611.htm
Synopsis of Program:
Cyber-Physical Systems という術語は、コンピュータ上のリソースと物理的なリソースの間の強い結合と協調をさしている。
我々は、未来の Cyber-Physical Systems は、今日、我々が、適合性、自律性、効率性、機能性、信頼性、安全性、可用性といった言葉で表すものを、はるかに超えて進むだろうと展望している。
Cyber-Physical Systems での研究の前進は、我々の世界を次のようなシステムを持つものに変えることを約束している。 より高速に反応するシステム（自律的な衝突回避
システム等） より精密な動作を行うシステム（ロボットによる外科手術、ナノ・スケールの工作機械等）
危険で近づけない環境での作業システム (捜索と救出、消火作業と探索）
大規模で分散したものの協調を行うシステム（交通制御の自動化等）、高度に効率的で（正味のエネルギーを消費しないビル等）
人間の能力を増大し社会福祉を拡大するシステム（介護支援技術、いつでもどこでも、健康状態のモニタリングと医療サービスの提供を可能とするシステム）
NFS の Cyber-Physical Systemsの取り組みに対するドイツの批判的評価
「アメリカでは既に 2006 年から、 NSFが、 Cyber-Physical System を、最重要な研究分野として位置づけていた。しかしながら、 CPS を、特に製造業の分野で利用するという点に関しては、実際には、ほとんど何もなされなかった。」
“Indusrie 4.0” 文書より
Advanced Manufacturing Partnership 設立の呼びかけをするオバマ大統領
2011 年 6 月
2011 年 AMP立ち上げ 2011 年 6 月、オバマ大統領
は、” Advanced Manufacturing Partnership (AMP)” を立ち上げる。
AMP Steering Commitee の構成工学系トップの大学 (MIT, UC Berkeley, Stanford, CMU, Michigan, GIT) の学長アメリカのトップ企業 (Caterpillar, Corning, Dow Chemical, Ford, Honeywell, Intel, Johnson & Johnson, Northrop Grumman, Procter & Gamble, United Technologies) の CEO
オバマ演説「アメリカで発明しアメリカで製造する」 “本日、私は、我々の全て -- 私的企業・大学・政府機関 -– に、アメリカ製造業のルネッサンスをスパークさせ、我が国の製造業が世界のいかなる国とも競争するために必要な最先端のツールを開発するのを助ける為に、一緒になるよう呼びかける。 ... これらの重要な投資によって、我々は、合衆国が「ここで発明し、ここで製造する」国にとどまり、アメリカの労働者に、高品質・高賃金の仕事を作り出すことを保証する事が出来る”http://www.whitehouse.gov/the-press-office/2011/06/24/
president-obama-launches-advanced-manufacturing-partnership
2012 年 NNMII の設立 2012 年 7 月、 AMP は 16 の勧告をレポート
する。その中には、”National Network of Manufacturing Innovation Institutes (NNMII)” の設立が含まれていた。
NNMII は、官民連携組織で、アメリカの企業の国際的競争力を高め、アメリカの製造施設への投資を増加させる為に、「優れた製造技術の地域のハブ」になる事が期待された。
オバマ演説“Made in America”
“我々は、地域を助ける為に、その地域を、世界の先端技術の仕事のセンターに変える事を助ける為に、進んで一緒にパートナーを組もうとする企業と大学を求めている。というのも、我々は、製造業の次の革命が、「 Made in America 」になる事を望んでいるからだ。 "
-- President Obama, May 9, 2013
http://manufacturing.gov/nnmi_overview.html
2013 年度予算では、 advanced manufacturing に対する研究開発予算は、19%増えて 22億ドル (2,200億円 ) に。
この予算で、 National Institute of Standards and Technology (NIST) は、国内の製造業に研究施設とノウハウを提供する施策に 1億ドル (100億円 ) を支出。
NIST は、また Advanced Manufacturing Portal を運営している。これは、 AMI の勧告に基づいたもの。
“Recommendations for implementing the strategic initiative INDUSTRIE
4.0” 2013 年４月
http://www.plattform-i40.de/sites/default/files/Report_Industrie%204.0_engl_1.pdf
”INDUSTRIE 4.0” のビジョンCyber-Physical へ 第一次産業革命： 機械
18 世紀末の蒸気機関の導入 第二次産業革命： 電気
20 世紀に始まる電気を動力とする大規模工場生産
第三次産業革命： IT 1970 年代に始まり今日まで続いている、電子技
術・ IT を利用した生産の自動化
第四次産業革命： Cyber-Physical ネットワークのサイバー空間と物理的な生産の世
界が結びつく
Cyber-Physical システム：製造環境とInternet of Things and Services
Things と Services のインターネットの製造環境への導入が、第四次産業革命への道を開く。
将来、ビジネスは、 Cyber-Physical システムの形で、機械と倉庫と製造機能を一つに合体させるグローバルなネットワークを確立するだろう。
Cyber-Physical システムは、スマートマシンとストレージと、自律的に情報を交換しそれぞれが独立に動作を起動しコントロールする能力を持った生産施設から構成される。
Cyber-Physical System (CPS)
この Cyber-Physical システムは、製造工程、生産工学、物質資源の利用、サプライ・チェイン、そして、ライフサイクルの管理に含まれている産業の全過程に対して、根本的な改良を容易にする。
スマート自動車 スマート流通
スマートビルディングスマートグリッド
スマートプロダクト
Smart Factory
CPS
Smart Factory : CPS の中核
Cyber-Physical System と二重のネットワーク・システム Cyber-Physical システムに組み込まれた製
造システムは、工場と企業のビジネス・プロセスに垂直方向にネットワークで接続され、水平方向には、注文がなされた時からロジスティックに送り出されるまさにその時まで、リアルタイムに管理可能な多様なバリュー・ネットワークに接続される。
それに加えて、水平・垂直双方のネットワークは、ともに、バリュー・チェイン全体を横断した、 end-to-end のエンジニアリングを可能にし、また、それを要求する。
垂直方向のネットワーク：工場内の統合されたネットワーク化された製造システム
水平方向のネットワーク：多数の企業を結んだバリュー・ネットワーク
水平方向のネットワーク：多数の企業を結んだバリュー・ネットワークそれはグローバルなものかもしれない
end-to-end:製品の開発・設計から、消費者個人へのサービスの提供まで
製品のデザインと開発
生産計画
生産エンジニアリング
生産サービス
Project Ara -- CPS 開発ツールの無償提供
2014/04/15-16Project Ara は、自己を Cyber-Physical System(CPS) と規定している。重要な事は、 Project Ara の中心的な柱として、 CPS 開発の為のツール群Metamorphosys がオープンソースの形で無償提供されている事である。
http://www.projectara.com/
http://www.projectara.com/ara-developers-conference/
Project Ara Conference 2014/04/15-16Day 2 “Metamorphosys design tools ”
Project Ara Conference 2014/04/15-16Day 2 “Metamorphosys design tools ”
自分のモデルとその結果をどのように組織するか？
回路をどう設計するか？
Ara のモジュールに収まる？
電波の干渉は起きないか？
ソフトはうまく動くか？
動作のスピードは？
発熱しないか？
「関心の分離」は、必ずしもうまく機能しない
Ara: Cyber-Physical システム
デザインの挑戦
Tool Chain Metamorphosysを構成する三つのプラトフォーム モデル統合プラットフォーム ツール統合プラットフォーム 実行統合プラットフォーム
Project Ara のエコシステムの基礎モジュール開発ツールの共有 誰もが「ものづくり」のツールを持つことが
出来る：オープンソースでの無償提供。 誰もが容易に使える：これらのツールは、ハードウェア設計の専門家でなくても、 Araのモジュールをデザインする事を助ける事が出来る。
誰もが簡単にデータを交換・共有出来る：グローバルでオープンな「ものづくり」コミュニティとデータのネットワーク・マーケットの拡大。
誰もが簡単に「ものづくり」出来る：データを 3D プリンターにいれれば、その場で、ものが出来る。部品の輸送コストは大幅に削減出来る。
3D プリンターによるモジュールの製造
Google は、 3D プリンターの最大手 3D Systems と共同で、 2015 年までに、次のようなAra モジュールを製造する 3D プリンターを作ろうとしている。
再利用可能な Ara コンポーネントをデザイン・アプリとドライバーの開発・ハードウェア・モジュールの開発
Ara システムの設定と統合・個人向けの設定・変更可能
ユーザーの期待に応えながら、安全性と操作性の基準を保証する
Ara プラットフォームで定義されたデザインの制約を満たしながら、デザインツール Metamorphosysが提供するデザイン手法を利用
モジュール開発ツール、 3D プリンターを使った開発サイクル
Cyber-Physical Systems が挑戦している課題
ここでは、 Edward Lee のプレゼンに基づいて、 Cyber-Physical Systems が、どのような課題に挑戦しようとしているかを見てみよう。Cyber と Physical の統合では、「時間」の問題が、重要な問題であることが分かる。
http://wwwdi.supelec.fr/fb/SeminaireLee2013
地図をドリルしても石油は出ない。
我々は、モデルについては、決定論的な言明を行うことが出来る。それから、実現されたシステムの、いくつかの特徴を推論出来る。この推論の妥当性は、モデルの忠実さに依存する。そして、その忠実さというのは、常に近似でしかないのだ。
決定論的なモデル
同期的なディジタル論理回路
決定論的なモデル
単一スレッドの命令的なプログラム
決定論的なモデル
微分方程式
ただし、決定論的なものの組み合わせは、非決定論的なものになる
単純な Cyber-Physical Systems の図式
インターネットのプロトコルは、そのままでは、 Best Effortのプロトコルであることを忘れずに。（丸山注）
計算は、無時間的な命令言語で行われる。物理的なプラントは、常微分方程式で、モデルが与えられる。
このコードは、タイミングをコントロールしようとしている。しかし、本当にそうなっているか？
タイミングの振る舞いは、そのプログラムとハードウェア・プラットフォームの組み合わせで生まれてくる
タイミングがシステムの振る舞いに影響を与える時には、設計はもろいものになる。ハードウェア、ソフトウェア、あるいは、環境の小さな変化が大きな、予期しない、タイミングの変化を引き起こす。テストを、やりなおさなければならない。
重要な挑戦タイミングは、ソフトウェアのセマンティックスの一部ではない
C, C#, Java, Haskel, OCaml 等でのプログラムの正しい実行は、何を計算するにしても、それがどれくらい時間がかかるかということとは、何の関係も無い。ほとんど全ての計算とネットワークの抽象は、この前提の上に立っている。
プログラマーは、タイミングの振る舞いを特定する為には、プログラミングの抽象の外に踏み出さなければならない。
プログラマーは、依拠すべき地図を持っていない！
コンピュータ・サイエンスが、タイミングを無視してきた訳ではないが ...
今日では、コンピュータにとっては、タイミングは、単なる、パフォーマンスの尺度にすぎない。
タイミングは、正確性の規範である必要がある。
正確性の規範
我々は、ソフトウェアに絶対的な信頼を持つことが出来る。そこでは、ハードウェアのエラーだけが唯一の問題となる。
しかし、タイミングに関しては、そうではないのだ。
我々が、それからコンピュータを組み立てているハードウェアには、「正確」な計算とタイミングを提供する能力を持っている。
同期的なディジタル論理回路図という抽象は、トランジスターの細かな動作を考える必要を無くす。
... しかし、その上のソフトウェアの抽象は、タイミングの正確さを無視している。
CPS の挑戦 その１
我々は、プログラムの正確な実行が、サブシステムの IO で、常に、同じ（ある正確さの範囲で）時間的な振る舞いをするように、プログラミング・モデルを変更出来るか？
我々は、決定論的な CPS モデルを必要としている
CPS の挑戦 その２
いかにしたら、我々は、既存の言語・ツール・方法論によって生み出される強力な惰性を克服して、本質的な抽象を変更するかもしれないイノベーションを可能に出来るか？
我々は、オープン・マインドである必要がある
CPS にとって、まさに「時間」の概念は、微妙である
理想化されたニュートン力学の時間概念
コンピュータのプラットフォームでは、 t にアクセスしない。代わりに、ローカルな時間の測定が利用される。
理想化されたニュートン力学の時間概念
いろいろ、微妙な問題がある。 時間同期？ その正確性は？その表現形式は？ Superdense Time ？ HyperdenseTime ？ 多形式時間？ 同時性の意味論？
重要な技術が、まさに、登場しつつある時計同期の技術である
時計同期は、世界を変えようとしている
1500 年代日単位
1800 年代秒単位
2000 年代ナノセカンド単位
グレゴリー暦 グリニッジ標準時 IEEE 1588
GPS は、 100ns 単位の正確な時間を、戸外のアクセスで、デバイスに与えることが出来る
時計同期は、次のことを可能にする
エネルギーの効率化 通信なしでさえも、協調動作が可能にセキュリティーリソース管理決定論的振る舞い
CPS の挑戦 その３
我々は、いかにしたら、現実界のリアルな時間の測定や時間同期、また、物理的なシステムで利用されている工学的モデルと整合的な、時間のモデルを開発出来るか？
我々は、時間の意味論を必要としている
工学的抽象と工学的方法論
こうしたシステムの構成要素は、異なる専門領域の専門家のもとで、多様な工学的原理に基づいて、複数のべンダーから提供されている。、
航空機用の「電力供給システム」を考えてみよう
物理的には、発電機大容量リレー配電系統負荷機器 ...
小さなサブシステムでも、実際は、巨象である
CPS の挑戦 その４
我々は、いかにしたら、工学的原理と橋渡しをしつつ、要求や期待を明確にする、システムの構成要素間のインターフェースを定義出来るか？
我々は、「モデル工学」の原理を必要としている
四つの大きな挑戦1. 決定論的な CPS モデル
2. 言語とツールについてオープンマインドであること3. 時間の意味論4. 「モデル工学」の原理
Cyber-Physical Systems として情報システムを捉え直す
最初に見た CPS システムの図式では、 Cyber システムを、情報の世界にのみ閉じるシステムとして特徴付けてきた。ただ、こうした描像も一面的なものである。ここでは、 Cyber-Physical Systems として、あらためて、情報システムを捉え直してみよう
Cyber-Physical Systems としての大規模分散データベース
Spanner: Google’sGlobally-Distributed Database
Wilson Hsieh representing a host of authorsOSDI 2012
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/ja//archive/spanner-osdi2012.pdfhttp://research.google.com/archive/spanner.htmlVideo:https://www.usenix.org/conference/osdi12/elmo-building-globally-distributed-highly-available-database
Spanner での正確な「時計」の利用 Spanner のアプローチのポイントは、「正確
なタイムスタンプ」をグローバルな規模に広がった分散データベースのトランザクションのコントロールに使うこと。その為に、主要には GPS を使って（場合によっては原子時計で）、全てのマシンの「時計」を合わせる。
グローバルな規模の分散データベースに「実時間」の時計の時間合わせを導入するというのは、データベースが単なる Cyber空間上のシステムではなく、 Cyber-Physical Systems としての性格を持つようになってきたということ
大規模分散データベースとしてのSpanner の特徴 第一に、データの複製の設定は、アプリによっ
て細かい粒度でコントロール出来る。 どのデータセンターがどのデータを持つのか データはユーザーからどのくらい離れているか（読
み込みの遅延をコントロールする） レプリカはお互いにどれくらい離れているか（書き
込みの遅延をコントロールする） どのくらいの数のレプリカが維持されているか（耐久性・可用性・読み込みのパフォーマンスをコントロールする）
データは、データセンター間のリソースの利用のバランスをとるシステムによって、動的かつ透過的にデータセンター間を移動出来る。
大規模分散データベースとしてのSpanner の特徴 第二に、 Spanner は、分散データベースで
は実装するのが難しい二つの特徴を持つ。 読み書きについての外的整合性 ある時点での、データベースをまたいだグローバ
ルに整合的な読み込み こうした特徴は、グローバルなスケールで、
たとえ実行中のトランザクションがあったとしても、整合的なバックアップ、整合的なMapReduce の実行、アトミックなスキーマの更新を、 Spanner に可能とする。
正確なコミット・タイムスタンプの利用 こうした特徴は、たとえトランザクションが
分散していたとしても、 Spanner がトランザクションにグローバルに意味のあるコミット・タイムスタンプを割り当てるという事実によって可能になった。
正確なコミット・タイムスタンプの利用 このタイムスタンプは、シリアル化された順序を反映している。それに加えて、シリアル化された順序は、外的整合性（あるいは、それと等価だが、線形化可能性）を満たしている。すなわち、あるトランザクション T1 が、別のトランザクション T2 が始まる前にコミットするなら、 T1 のコミット・タイムスタンプは、 T2 のそれよりも小さい。
Spanner は、グローバルなスケールで、こうした保証を与えた最初のシステムである。
Snapshot Isolation
Spanner の基本的な手法は、「スナップショット・アイソレーション」と言われるもの。"A Critique of ANSI SQL Isolation Levels " http://research.microsoft.com/pubs/69541/tr-95-51.pdf
Start-Timestamp Snapshot Isolation では、それぞれのトランザクションは、 Start-Timestamp と呼ばれる、トランザクションを開始した時刻のデータのスナップショット（コミットされた）からデータを読み込む。この時刻は、トランザクションの最初の読み込みの時刻の前の時刻になる。
トランザクションの Start-Timestamp以降にアクティブになった他のトランザクションによる更新は、このトランザクションからは見えない。
Read と Write
Snapshot Isolation の中のトランザクションは、その Start-Timestamp からのスナップショットのデータが維持可能である限り、読み込みがブロックされることはない。
トランザクションでの書き込み (updates, inserts, deletes) もまた、このスナップショットに反映される。もしトランザクションが、このデータに二度目のアクセス（ reads あるいは updates ）をするなら、ふたたび、読み出される。
Commit-Timestamp トランザクション T1 が、コミットの準備が
できた時、それは Commit-Timestamp を取得するのだが、それは、既に存在する Start-Timestamp あるいは Commit-Timestampより、大きな値を持つ。
トランザクションは、 T1 の実行間隔[StartTimestamp, Commit-Timestamp] 内に Commit-Timestamp を持つ他のトランザクション T2 が、 T1 が書き出したデータと同じデータを書き出していない場合に限り、コミットに成功する。
First-Commiter-Wins
そうでない場合、 T1 はアボートする。この「最初にコミットしたものが勝つ」という特徴が、更新が失われるのを防止する。
T1 がコミットされると、その Start-Timestamps が T1 の Commit-Timestampより大きい、全てのトランザクションに、その変更は見えるようになる。
BigTable のトランザクション機能の強化
Incrementally Indexing the Web with Percolator
2010 年 10 月 4 日Frank Dabek and Daniel Peng
at OSDI, 2010 https://docs.google.com/presentation/d/1gKD4FbaUIGtoimP6-ZB0iiW8V0KZt8fVET-Cfu5KiG8/present#slide=
id.i0
Google は、 2010 年に、 Caffein/Percolator と呼ばれる大きなシステム変更を行っている。この変更以降、 Google は、 Web ページのインデックス付けにMapReduce を使わなくなった。
その変化の中核は、タイムスタンプを利用した、スナップショット・アイソレーショ ンの導入による、 BigTable のトランザクション機能の強化であった。
c:data データ自身を格納 c:lock コミットされていないトランザク
ションは、 この Cell に書き込む。 PrimaryLock の場所を含んでいる。
c:write コミットされた現在のデータ。 データのタイムスタンプを格納。
c:notify ヒント : observer が走る必要がある かもしれない
c:ack O Observer “O” が走った。最後に 成功した実行のタイムスタンプを格納。
初期状態： Joe の口座には 2 ドル、 Bob の口座には、 10 ドルが、はいっている。
bal:write に、データのタイムスタンプが書き込まれることによって初めて、そのデータは外部から見えるようになる。
Bob から Joe へ、 7 ドル送金するというトランザクションを考えよう。
送金のトランザクションは、 Lockカラムに書き込むことで Bob の口座の残高をロックすることから始まる。このロックは、このトランザクションのprimary である。
このトランザクションは、また、その開始タイムスタンプ 7 にデータを書き込む。 Bob の dataカラムに 3 ドルが書き込まれる。ただし、この変化は、まだ外からは見えない。
トランザクションは、次に Joe の口座をロックして、ふたたび開始タイムスタンプ 7 に、 Joe の新しい残高 9 ドルを書き込む。
このロックは、このトランザクションの secondaryである。 primary ロック（” Bob” 行の” bal”カラム）への参照を含んでいる。クラッシュでこのロックが立ち往生して、トランザクションがロックを解消したいと思った時、このロックの解消を同期するために primary の場所が必要になる。
トランザクションは、コミットのポイントに到達する。
primary ロックを消して、それをコミットタイムスタンプと呼ばれる新しいタイムスタンプ 8 の下で、新しい書き込みレコードと置き換える。この書き込みレコードは、データが格納されているタイムスタンプへのポインターを含んでいる。
これ以降、” Bob” 行の” bal”カラムを読むものは、値 3 ドル を見ることになる。
トランザクションは、 secondary セルに書き込みデータを追加し、ロックを消去することで完了する。
これ以降、” Joe” 行の” bal”カラムを読むものは、値 9 ドル を見ることになる。
この例の場合には、ただ一つの secondary Joe があるだけである。
Web スケールの分散トランザクションの「存在証明」 Google は、この技術を「 Web スケールの分
散トランザクションの「存在証明」」と呼んでいる。
"Incrementally Indexing the Web with Percolator" https://docs.google.com/presentation/d/1gKD4FbaUIGtoimP6-ZB0iiW8V0KZt8fVET-Cfu5KiG8/present#slide=id.i0
Spanner での Paxos の利用
Spanner のもう一つの大きな特徴は、 Paxos の利用である。
Paxos
Leslie Lamport "The Part-Time Parliament" http://research.microsoft.com/en-us/um/people/lamport/pubs/lamport-paxos.pdf
"Paxos Made Simple" http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf
Spanner の階層構造Universe – Zone - Spanserver
Spanner の階層構造Universe – Zone - Spanserver ユニバースは、 Spanner のシステム全体である。 Spanner のユニバースは、一群のゾーンで組織され
ている。それぞれの Zone は、大まかにいって、 BigTable のサーバーに相当するものである。
ゾーンは、一つのゾーン・マスターと、百から数千の間のスパンサーバーを持っている。前者は、スパンサーバーにデータを割り当てる。後者は、データをクライアントにサービスする。
ユーザーのデータに割り当てられたスパンサーバーの場所を特定する為に、そのゾーンのロケーション・プロキシーが利用される。
Spanserver のソストウェア・スタック スタックの一番下では、スパンサーバーが、
100 個から 1000 個の間のタブレットと呼ばれるデータ構造のインスタンスに責任を持っている。
タブレットは、 BigTable のタブレットという抽象と同様のもので、その中では、次のようなマッピングのバッグを実装している。 (key:string, timestamp:int64) → string
Spanserver のソストウェア・スタック Bigtable とは異なって、 Spanner は、タイ
ムスタンプをデータに割り当てる。ここが、Spanner がキー・バリュー・ストアよりは、マルチ・バージョン・データベースにずっと似ている重要なポイントである。
複製をサポートする為に、それぞれのスパンサーバーは、それぞれのタブレット上に、一つの Paxos状態マシンを実装している。
レプリカ群が Paxos グループを形成 一群のレプリカが、 Paxos グループを形成
する。 Paxos状態マシンは、マッピングのバッグ
(key:string, timestamp:int64) → stringのレプリカを整合的に実装するのに利用されている。それぞれの複製のキー・バリュー・マッピングの状態は、対応するタブレットに格納される。
書き出しは、リーダーの Paxos プロトコルから開始されなければならない。読み出しのアクセスの状態は、十分更新されたどのレプリカの下にあるタブレットからでも直接に取得出来る。
Spanserver の Lock Table
リーダーである全てのレプリカのスパンサーバーは、コンカレンシーのコントロールを実装する為のロック・テーブルを実装している。
ロック・テーブル は、ツー・フェーズ・ロッキングの為の状態を含んでいる。それは、一連のキーをロック状態にマップする。
ロック・テーブルを効率的に管理する上で、長い 期間、生き続けるリーダーを持つことは、本質的に重要であることに注意。 Spannerのサーバーのリースは、 10秒と長い
Txn manager のスキップ もしトランザクションが、一つの Paxos グ
ループを含んでいるだけなら（大部分のトランザクションの場合）、それは、トランザクション・マネー ジャをバイパス出来る。というのは、ロック・テーブルと Paxos が一緒になって、トランザクションの保証を提供するからである。
Paxos Group をまたいだ調整 もしトランザクションが一つ以上の Paxos グ
ループを含んでいたら、これらのグループ・リーダーがツー・フェーズ・コミットの調整役を演ずる。
参加グループの一つが、調整役に選ばれる。そのグループの参加者のリーダーは、調整役リーダーと呼ばれ、グループのスレーブは、調整役スレーブと呼ばれる。
それぞれのトランザクション・マネージャの状態は。直下の Paxos グループに格納される。（それ故、複製される。）
大規模自律分散というアプローチ 「 Spanner は、もっとも高い抽象のレベル
では、 全世界に広がっているデータセンター内の沢山の Paxos状態マシン群をまたいで、データを分割したデータベースである。」
Spanner は、単なる「大規模分散システム」ではなく、それぞれが自律的な耐障害性を備えた「大規模自律分散システム」なのである。それによって、次のことが可能となった。
「 Spanner は、数百のデータセンターをまたいだ数百万のマシンと、数兆行のデータベースにスケールアップするように設計されている。」
Cyber-Physical Systems としてのネットワーク・システム
「ギルダーの予想」
「ネットワークがコンピュータの内部バスと同じぐらい早くなれば、マシンは、特定の目的を持ったデバイスのあつまりへとネットワーク上で分解するだろう。」
ただ、このように、ローカルとリモートの区別が、ネットワークのスピード・アップによってなくなるだろうという考え方には、強い異論がある。
ローカルとリモートを峻別する立場 今から 20 年前にこうした問題は、はっきり
と提起されていた。彼らの認識は、ネットワーク管理をしている人なら誰でも知っている、 Lease の導入として、結実する。 Jim Waldo は、“ A Note on Distributed Computing” http://www.eecs.harvard.edu/~waldo/Readings/waldo-94.pdf で、次のように述べる。
“A Note on Distributed Computing”
http://www.sunlabs.com/techrep/1994/smli_tr-94-29.pdf
ローカルなプログラミングとリモートなプログラミングを、はっきりと区別すべきだという立場
Jim Waldo et al.
ネットワーク上のシステムで相互作用するオブジェクトは、単一のアドレス空間で相互作用するオブジェクトとは、本来的に異なったやり方で取り扱われるべきであると、我々は主張している。
こうした違いが要求されるのは、ネットワーク上のシステムでは、プログラマは遅延の問題を意識せねばならず、異なったメモリーアクセスのモデルを持ち、並列性と部分的失敗(partial failure) の問題を考慮にいれなければならないからである。
我々は、ローカルとリモートのオブジェクトの違いを覆い隠そうと試みる、沢山のネットワーク・システムを見てきた。そして、これらのシステムは、頑健さと信頼性という基本的な要請を満たすことに失敗していることを示そうと思う。
こうした失敗は、過去においては、構築されたネットワーク・システムの規模の小ささで、隠蔽されていた。しかしながら、近未来に予想される、企業規模のネットワークシステムにおいては、こうした隠蔽は不可能となるであろう。
Formulated in 10 Years Ago
Network is Homegenous added by Gosling
Cyber-Physical Systems としてのクラウド・システム
クラウド技術の特徴Scalability と Availability
コモディティ化したマシンを集積するスケールアウトの手法に基づくクラウド技術は、 Scalability と Availability 両方の担保を中核と する。
そこでの技術的飛躍のポイントは、「マシンは、例外的に、あり得ない不運がかさなってクラッシュするのではなく、いつでも、例外なしに壊れるもの だ。」という認識にある。
かつて、 Google の Platforms Architect のBen Jai は、次のように語ったことがある。
「信頼性の高いハードは、ソフトウェア技術者を怠け者にする。」 「 3-year MTBF だとしても , 1000台のうち一台は、毎日だめになるという計算になる。最小の Google のアプリケーションでも、 2000台のマシンを必要とする。こうした障害を ソフトでどう対応するかデータの多重化と冗長化は、この規模ではどうしても必要となる。」
「だから、なぜ、高価な信頼性の高いハードのことで思い悩むのか ? 信頼性の高いハードは、ソフトウェア技術者を怠け者にする。障害に強いソフトウェアが、安いハードを役に立つものに変えるのだ。」
こうした認識は、ネットワークで結ばれた大規模なコンピューター・システムが、それ自身、純粋に Cyber なシステムではなく、基本的には Physical な原理に左右される Cyber-Physical Systems であることを意味している。それは当然のことだとも思う。ただ、 20 年前の Jim Waldo の警告にあるように、我々は、時に、それを忘れることがある。
Cyber-Physical Systems と量子コンピュータ
Simulating Physics with Computers
1982 年 Richard P. Feynmanhttp://www.cs.berkeley.edu/~christos/classics/Feynman.pdf
自然をシミュレートするコンピュータ コンピューターが、正確に自然と同じように振る舞う、正確なシミュレーションが存在する可能性について話そうと思う。それが証明されて、そのコンピュータのタイプが先に説明したようなものであるなら、必然的に、有限の大きさの時空の中で起きる全てのものは、有限な数の論理的な操作で正確に分析可能でなければならないことになるだろう。
量子論的システムは、古典的なコンピューターでシミュレートされるか？ 量子論的なシステムは、古典的な万能計算機
で、確率論的にシミュレートされるだろうか？ 別の言い方をすれば、コンピューターは、量子論的なシステムが行うのと、同じ確率を与えるだろうか？ コンピューターを今まで述べてきたような古典的なものだとすれば（前節で述べたような量子論的なものではないとすれば）、また法則はすべて変更されないままで、ごまかしもないとすれば、答えは明らかにノーである。
量子コンピュータ-- 万能量子シミュレーター それは、新しいタイプのコンピューター、量子コンピューター？で可能になるだろう。私が理解する限りでは、それは量子論的なシステムによって、量子コンピューターの要素によって、シミュレート出来るようになることは、いまや、明らかになった。それはチューリング・マシンではない。別のタイプのマシンである。
Quantum theory, the Church-Turing principle and the universal quantum computer
1985 年 David Deutschhttp://www.cs.berkeley.edu/~christos/classics/Deutsch_quantum_theory.pdf
Church-Turing-Deutche Thesis
Church-Turing の仮説の基礎には、暗黙の物理学的主張があることが考察される。この物理学的主張は、次のような物理学的原理として、明確に表現することが出来る。「有限な方法で実現可能な物理システムは、有限な手段によって操作される万能計算機械のモデルで完全にシミュレート可能である。」
古典物理学と万能チューリング・マシンは、前者は連続的で後者は離散的であるので、この原理には従っていない。
万能量子コンピューター チューリング・マシンのクラスの量子論的一般化である計算機械のクラスが記述され、量子論と、この「万能量子コンピューター」が、先の原理と両立可能であることが示される。
この万能量子コンピューターをまねた計算機械は、原理的には、構築可能である。そしてそれは、いかなるチューリング・マシンによっても再生不可能な、多くの目覚ましい特徴を持つであろう。
自律分散というアプローチ
現実世界の情報を全て一カ所に集約するというアプローチに対しては、「自律分散」という、別のアプローチもあり得る。
Cyber-Physical Systems と自律型のシステム 多くの電気機器は、電力さえ供給されれば、一定の役割を果たすことが出来る。
情報システムであっても、ネットワーク接続が必須ではないものがある。インターネット普及以前の「パソコン」「ワープロ」がその一例だ。
ロボットも、全てが外部からコントロールされて動作するのでは、操り人形と大差ない。ロボットで重要なのは、自律的に判断し動作する能力である。
IoT のコンセプトには、こうした自律型のシステムは含まれないが、 Cyber-Physical Systems は、これらを含んでいる。
自律分散システム 自律分散システムというのは、相対的な自律性を持つ部分システムがネットワークで結ばれて、システム全体が協調動作を行うシステムである。
情報の流れで言えば、すべての情報を一カ所にまとめるのではなく、システムの構成要素の階層的な「役割」の分担に基づいて、局所的に処理出来る情報は全て ローカルに処理する「自律性」をそれぞれの構成要素に与え、ローカルな範囲では処理が閉じない種類の情報のみを、上位階層に伝えるというモデルである。
自律性は、相対的なものである 「自律分散」の考え方は、ある種のデータの一カ所への集中を排除しない。 Amazon の倉庫ロボット kiva では、どこに何があり、どこで何をすべきかは、おそらく中央のコピュータが制御している。ただロボットの動きの多くは、ロボットが自律的に制御している。https://www.youtube.com/watch?v=lWsMdN7HMuA
データの集約・集中処理と自律分散 もっとも、検索のように、データ集約型でし
か処理出来ないものもある。ただ、この点では、 Google の Caffeine / Percolator でのBigTable のトランザクション機能の強化から、Spanner への「進化」は、興味深いものである。
「 Spanner は、もっとも高い抽象のレベルでは、 全世界に広がっているデータセンター内の沢山の Paxos状態マシン群をまたいで、データを分割したデータベースである。」
データの集約・集中処理と自律分散 こうした定式化は、データ集約型のシステム
においても、システムの拡大にともなってシステムの整合性を維持する為には、自律分散の考えに基づいたシステム設計が、重要であることを示唆している。
自律分散のモデルとそのメリット
自然界でも人間の社会でも、情報を扱う複雑なシステムの多くは、自律分散のスタイルをとっているように見える
自律分散のモデル – 生命・知能 すべての細胞には DNA のフルセットが含ま
れているのだが、細胞は、その情報の一部のみを利用して特定の機能を持つ細胞に分化する。分化した細胞は、器官を構成し、それが他の器官と協調しつつ自律的な役割を果たすことで、全体としての生命活動が維持される。
人間の脳もそうだ。脳内には無数の脳細胞があるのだが、それには特定のタイプがあり、特定の役割を担っている。それが特定のパターンで結びつくことによって、認識・感情・知覚・行動が生まれる。
自律分散のモデル – 社会的昆虫 蟻や蜂のような、社会的な昆虫の「社会」も、
自律分散のモデルと言える。 女王蜂は、働き蜂がどこにいて何をして いて
なにを見ているかを把握する必要はない。女王蜂も働き蜂も「本能」に基づいて自律的に行動する。それでも、蜂の社会システムはうまく機能している。
それは、女王蜂・働き蜂の「本能」の実体である、それぞれに埋め込まれた遺伝子情報が、そのようにプログラムされているからである。
自律分散のモデル – 人間の社会 人間の社会も、自律分散のシステムと言える。
特に、市場を通じた経済活動は、基本的には、自由意志を持つとされる個人・法人の自律的な活動に基づいている。
生産・流通・消費の過程が、経済のネットワークを構成する。
Industrie 4.0 の「水平方向の Cyber-Physical Systems 」は、自律分散型のシステムになる。
自律分散のメリット データ集約型のモデルは、まさにその点にお
いて、システムの脆弱性が生まれる可能性がある。それに対して、自律分散型のモデルは、Single Point of Failure を持たないので、より頑健なシステムを構築することが出来る。
データ集約型のモデルでは、情報の爆発的増大が起こりえる。自律分散型のシステムでは、無用な情報の爆発を防ぐことが出来る。
これから考えるべきこと
新しいネットワーク・メディアの成立 コミュニケーションと情報共有、自由時間の享受への欲求は、現代の IT 技術の普及をドライブする最大のものである。
クラウドとクラウド・デバイスを骨組みとする、新しいネットワーク・メディアは、こうした欲求にドライブされて、来る 10 年の間には、世界人口のほとんど全てを包摂するものへと発展するだろう。
同時に、新しいネットワーク・メディア上のCyber空間だけに、我々の生活や IT の可能性が閉じることは無いという展望も重要なものだ。
Cyber と Physical
情報だけの Cyber な世界に閉じること無く、また、道具や単純な機械だけの Physical な世界でもなく、 Cyber と Physical が相互作用する Cyber-Physical の世界に、 IT の世界は広がって行くだろう。
IoT / Big Data は、 Physical Cyber の情報の流れを、 Robot / 3D Printer は、 Cyber Physical な現実世界を変える働きの代表例である。
新しい経済のネットワーク Cyber-Physical Systems が新たな役割を果
たすことを期待される、もっとも広大な開拓地は、現実世界の経済が有力な候補である。製造・流通・消費の全過程を包摂する、効率的で持続可能な、新しい経済のネットワークが模索されるだろう。
とりわけ、ロボットや 3D プリンターの導入による、製造の現場と労働の変化が、新しい経済のネットワークの形成に、おおきなインパクトを与えるだろう。
集中と分散 新しいネットワーク・メディアと新しい経済
のネットワークの形成の中で、データと処理の集中は、さらに進むだろう。必ずしも、 Big Brother のようなディストピアを想像する必要は無いかもしれない。それは処理コストを低減し、利便性を高める側面を持つ。それらは、適切に管理されさえすれば、低料金の社会インフラ化して行く可能性は高い。
同時に、ハードウェアの進化と低価格化により、処理の自律分散化も、さらに進むだろう。それは、システムを全体として、頑健なものに変える。
未来展望 -- 生産の自律分散化 おそらく、 21 世紀の最大の課題は、新しい
ネットワーク・メディアと、新しい経済のネットワークのもとで、生産のスタイルを、持続可能な成長を保証し、環境にインパクトを与えない自律分散型のモデルに変革出来るのかというところにある。
明確なのは、それを推進する最も大きな力は、IT とその更なるイノベーションだということである。
マルゼミ予告 「 Cyber-Physical Systems と自律分散システム」 来月 8 月 1 日開催のマルゼミは、今回の
マルレクを受けて、 3D プリンターとロボットを取り上げます。是非、ご参加ください。
日時： ８月 1 日（金） 19:00~ 場所： 秋葉原 カスペルスキー社 会議室
登壇者：丸山不二夫 マルレクふりかえり 大迫幸一 「 3D プリンタの未来」中川友紀子 「ロボットのいる生活とIT 」
Windows Azure の Availability
Windows Azure では、 File System のレベルではなく Data Storage のレベルでReplica が導入されている。また、 Fail-over について、いくつかのシナリオが用意されているので、それを見ておこう。
MS Azure のデータノードの多重化
データの読み込みはPrimary ノードからの読み込みで完了する
データの書き出しはSecondary ノードにコピーされる。この際、多数決原理(quorum) に従う。
P
S
S
S
SWriteWrite
WriteWrite
AckAckAck
Ack
ReadValue
Write
Ack
MS Azure のデータノードの再構成
再構成のいくつかのタイプ Primary が故障する 故障した Secondary を除
く 修復した replica の追加 新しい Secondary の準備
前提 故障の検出 リーダーの選挙
P
S
S
S
S
S
これらの故障が重複して起きても安全なように設計する
B PX
こけた！
X死んだ !
経済活動と人間のコミュニケーションと情報共有の担い手としての
インターネットとデバイスの「遍在」
経済活動と人間のコミュニケーションと情報共有の担い手としての、インターネットとデバイスの「遍在」の過程は、現在も進行中である。その先頭を走っているのは、 Gang of Four達で、焦点はNext Billions のマーケットである。
Smarter Planet
Internet of Everything
Windows for the Internet of Things will be free
ビッグデータ論の特徴
ビッグデータ論とは、 Physical からCyber へ、あるいは、 Cyber から Cyberへ、情報は流れ、その情報は、最終的には一カ所へ集約され利用されるという描像に他ならない
ビッグデータ論の特徴— Physical から Cyber へ IoT では、無数のセンサーから沸き出す巨大
な情報「ビッグデータ」の処理が中心的な課題になるという議論がよくある。そうした処理が必要な場合が存在し、それが技術的にチャレンジングな課題であるのは、確かである。
ただ、物理的な世界から発した情報が、全て一カ所にまとめられ、情報として処理されるというイメージは、少し狭いとも思う。なぜなら、そこでは、 Physical から Cyber へと、情報が一方的に流れるだけだけからである。
ビッグデータ論の特徴— Physical から Cyber へ それは、世界で起きていることを、全て知りう
る「全智」の存在を考えることに似ている。ただ、世界の全てを観照的に知るだけなら、彼は、「全能」とはいえない。世界に働きかけ、世界を変えてゆく「手足」を持ってはじめて、知り得たことが役に立つ。
Physical から Cyber に情報が流れるだけでなく、 Cyber から Physical への情報の流れが、現実を変えてゆく力を持つ Cyber-Physical Systems の方が、強力なのは確かだと思う。もっとも、両方の能力を持つシステムは、人間以外には、まだ存在しないようにも見える。
ビッグデータ集約の問題 現実世界の情報を、一カ所に集約したいとい
う「ビッグデータ」論を、別の角度から考えてみよう。
機械の助けを借りれば、我々がハンドルしうる情報の総量は、確実に増加する。ただ、コストの問題を度外視したとしても、我々人間の「判断」に必要な情報の量には、自然な限界がある。
ビッグデータ集約の二つの目的 「ビッグデータ」技術というのは、一方では、検索や BI システムが典型的にそうなのだが、ビッグデータから、人間が利用可能な、スモールデータを抽出する技術である。
「ビッグデータ」技術は、他方では、金融の世界での high-frequency trading や、広告の世界での real-time bidding のように、人間の介在なしに、機械が人間に代わって「意思決定」を行う技術である。
3D プリンターとロボット — Cyber から Physical へ センサー・ネットワーク＋ビッグデータ処理
が、 Physical から Cyber へという情報の流れの代表的な例だとすると、 Cyber からPhysical の情報の流れを代表する例は、何になるのだろう？
現実を変えるという意味では、我々が用いる道具や機械は、全て、そうした役割を持つ。自動車だって、我々の物理的な位置を変えることで、現実を変える。ただ、多くの道具や機械は、人間が直接にコントロールしている。
3D プリンターとロボット — Cyber から Physical へ 人間ではなくコンピュータによって制御され
る機械が、 Cyber から Physical の情報の流れの担い手になるというのなら、すぐに思いつくのは、 3D プリンターやロボットである。
Google X : Auto Driving Car
Introduction to Embedded Systems - A Cyber-Physical Systems Approach
2011 年E. A. Lee and S. A. Seshia,
http://leeseshia.org/releases/LeeSeshia_DigitalV1_08.pdf
1 IntroductionI Modeling Dynamic Behaviors 2 Continuous Dynamics 3 Discrete Dynamics 4 Hybrid Systems 5 Composition of State Machines 6 Concurrent Models of ComputationII Design of Embedded Systems 7 Embedded Processors 8 Memory Architectures 9 Input and Output 10 Multitasking 11 Scheduling
III Analysis and Verification 12 Invariants and Temporal Logic 13 Equivalence and Refinement 14 Reachability Analysis and Model Checking 15 Quantitative AnalysisIV Appendices A Sets and Functions B Complexity and Computability
Spanner: Google’sGlobally-Distributed Database
Wilson Hsieh representing a host of authorsOSDI 2012
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/ja//archive/spanner-osdi2012.pdfhttp://research.google.com/archive/spanner.htmlVideo:https://www.usenix.org/conference/osdi12/elmo-building-globally-distributed-highly-available-database
Spanner とは何か？ Spanner は、スケーラブルで、マルチ・バージョン、グローバルに分散し、レプリカの同期を行う、 Google のデータベースである。それは、グローバルなスケールでのデータの分散と外的整合的な分散トランザクションをサポートした、初めてのシステムである。
もっとも高い抽象のレベルでは、 それは、全世界に広がっているデータセンター内の沢山の Paxos状態マシン群をまたいで、データを分割したデータベースである。
Spanner とは何か？ Spanner は、データの量やサーバーの数が変化するに応じて、マシン間でデータを再分割する。それは、マシン間で（データセンター間でさえ）、自動的にデータを移動して、負荷のバランスを取り、マシンの失敗に対応する。
Spanner は、数百のデータセンターをまたいだ数百万のマシンと、数兆行のデータベースにスケールアップするように設計されている。
Spanner と時間同期 こうした特徴は、たとえトランザクションが
分散していたとしても、 Spanner がトランザクションにグローバルに意味のあるコミット・タイムスタンプを割り当てるという事実によって可能になった。このタイムスタンプは、シリアル化された順序を反映している。それに加えて、シリアル化された順序は、外的整合性（あるいは、それと等価だが、線形化可能性）を満たしている。
Spanner と時間同期 すなわち、あるトランザクション T1 が、別
のトランザクション T2 が始まる前にコミットするなら、 T1 のコミット・タイムスタンプは、 T2 のそれよりも小さい。 Spanner は、グローバルなスケールで、こうした保証を与えた最初のシステムである。
True Time
こうした性質を可能にした重要なものは、 TrueTime API とその実装である。このAPI は、直接に、時計の不確実さを、あらわに示すものである。そして、 Spanner のタイムスタンプは、実装が提供する不確実さの範囲にディペンドしている。もし、不確実さが大きければ、 Spanner は、この不確実さを待つ為に、スピードを落とす。
この実装は、複数の現代的な時計（ GPS と原子時計）への参照を利用することで、不確実性を小さなもの（一般的には、 10ms以下）にとどめようとする。
IoP CPS初出 1999 年
Kevin Ashton2006 年NSF
構成 Internet+Things Cyber+Physical
当初のターゲット
Things の情報 Physical Systems のコントロール
現在 インターネット接続の拡大とデバイスの普及
当初の担い手 情報系（ GoF を除く） 組込・制御・ロボット系
問題意識 ナイーブな「インターネットの拡大」
物理系の特質の重視。二つの異なるモデル
ネットワークの特性
ベスト・エフォート 正確なタイミング同期・同時性の重要性
自律型システム ？ 自律型システムを含む
適用領域 Everything Social Value Chain
今後の展望 第四次産業革命
“A Note on Distributed Computing”
http://www.sunlabs.com/techrep/1994/smli_tr-94-29.pdf
ローカルなプログラミングとリモートなプログラミングを、はっきりと区別すべきだという立場
Jim Waldo et al.
ネットワーク上のシステムで相互作用するオブジェクトは、単一のアドレス空間で相互作用するオブジェクトとは、本来的に異なったやり方で取り扱われるべきであると、我々は主張している。
こうした違いが要求されるのは、ネットワーク上のシステムでは、プログラマは遅延の問題を意識せねばならず、異なったメモリーアクセスのモデルを持ち、並列性と部分的失敗(partial failure) の問題を考慮にいれなければならないからである。
我々は、ローカルとリモートのオブジェクトの違いを覆い隠そうと試みる、沢山のネットワーク・システムを見てきた。そして、これらのシステムは、頑健さと信頼性という基本的な要請を満たすことに失敗していることを示そうと思う。
こうした失敗は、過去においては、構築されたネットワーク・システムの規模の小ささで、隠蔽されていた。しかしながら、近未来に予想される、企業規模のネットワークシステムにおいては、こうした隠蔽は不可能となるであろう。
Google File System のAvailability
Google File System の Availability は、基本的には、データを蓄える役割を果たすChunk Server を多重化（通常は三重化）することによって支えられている。
Client Master
SecondaryReplica A
PrimaryReplica
SecondaryReplica B
1
23
3
3
4
5
5
6
6
7
Windows Azure の Availability
Windows Azure では、 File System のレベルではなく Data Storage のレベルでReplica が導入されている。また、 Fail-over について、いくつかのシナリオが用意されているので、それを見ておこう。
MS Azure のデータノードの多重化
データの読み込みはPrimary ノードからの読み込みで完了する
データの書き出しはSecondary ノードにコピーされる。この際、多数決原理(quorum) に従う。
P
S
S
S
SWriteWrite
WriteWrite
AckAckAck
Ack
ReadValue
Write
Ack
MS Azure のデータノードの再構成
再構成のいくつかのタイプ Primary が故障する 故障した Secondary を除
く 修復した replica の追加 新しい Secondary の準備
前提 故障の検出 リーダーの選挙
P
S
S
S
S
S
これらの故障が重複して起きても安全なように設計する
B PX
こけた！
X死んだ !
Basically Availabilityデータベースでの楽観的ロック
データベースで、二つのクライアントが、同時に競合する書き込みをしようとした場合に、どのような処理が行われるのかを見てみよう。こうした、 Optimistic Lock の手法は、現在のエンタープライズ向けのシステムでも、普通に利用されていることに注意しよう。
Client A
ClientB
5 : Ch9, Jan-1, 3
1 : Ch9, Jan-2, 21 : Ch9, Jan-2, 21 : Ch9, Jan-2, 2
Entity の取得
9 : Ch9, Jan-3, 6
Version Rating
システムの管理する version をEtag として取得する
1 : Ch9, Jan-2, 2 1 : Ch9, Jan-2, 2
Client A
ClientB
5 : Ch9, Jan-1, 3
1 : Ch9, Jan-2, 21 : Ch9, Jan-2, 21 : Ch9, Jan-2, 2
Entity をローカルに更新する
9 : Ch9, Jan-3, 6
Version Rating2: Ch9, Jan-2, 5 2: Ch9, Jan-2, 4
Client A
ClientB
5 : Ch9, Jan-1, 3
1 : Ch9, Jan-2, 21 : Ch9, Jan-2, 21 : Ch9, Jan-2, 2
データを送って Version をチェックする
9 : Ch9, Jan-3, 6
Ch9, Jan-2, 5If-Match: 1
Version Rating1: Ch9, Jan-2, 41: Ch9, Jan-2, 5
Client A
ClientB
5 : Ch9, Jan-1, 3
1 : Ch9, Jan-2, 21 : Ch9, Jan-2, 21 : Ch9, Jan-2, 2
Version が合えば、成功である
9 : Ch9, Jan-3, 6
Ch9, Jan-2, 5If-Match: 1
Version Rating1: Ch9, Jan-2, 41: Ch9, Jan-2, 5
システムは Version とデータを更新し、 Client-A を更新する。
2 : Ch9, Jan-2, 5
2: Ch9, Jan-2, 5
Client A
ClientB
5 : Ch9, Jan-1, 3
1 : Ch9, Jan-2, 21 : Ch9, Jan-2, 21 : Ch9, Jan-2, 2
Version が合わなければ、失敗である
9 : Ch9, Jan-3, 6
If-Match: 1
Version Rating1: Ch9, Jan-2, 41: Ch9, Jan-2, 5
システムは、 Precondition failed (412) を返す。
2 : Ch9, Jan-2, 5
2: Ch9, Jan-2, 5 1: Ch9, Jan-2, 4
1: Ch9, Jan-2, 4
1: Ch9, Jan-2, 4
Error: 412
Snapshot Isolation
“A Critique of ANSI SQL Isolation Levels”http://t.co/2HBae9l5gK
Start-Timestamp Snapshot Isolation では、それぞれのトランザクションは、 Start-Timestamp と呼ばれる、トランザクションを開始した時刻のデータのスナップショット（コミットされた）からデータを読み込む。この時刻は、トランザクションの最初の読み込みの時刻の前の時刻になる。
トランザクションの Start-Timestamp以降にアクティブになった他のトランザクションによる更新は、このトランザクションからは見えない。
Read と Write
Snapshot Isolation の中のトランザクションは、その Start-Timestamp からのスナップショットのデータが維持可能である限り、読み込みがブロックされることはない。
トランザクションでの書き込み (updates, inserts, deletes) もまた、このスナップショットに反映される。もしトランザクションが、このデータに二度目のアクセス（ reads あるいは updates ）をするなら、ふたたび、読み出される。
Commit-Timestamp トランザクション T1 が、コミットの準備が
できた時、それは Commit-Timestamp を取得するのだが、それは、既に存在する Start-Timestamp あるいは Commit-Timestampより、大きな値を持つ。
トランザクションは、 T1 の実行間隔[StartTimestamp, Commit-Timestamp] 内に Commit-Timestamp を持つ他のトランザクション T2 が、 T1 が書き出したデータと同じデータを書き出していない場合に限り、コミットに成功する。
First-Commiter-Wins
そうでない場合、 T1 はアボートする。この「最初にコミットしたものが勝つ」という特徴が、更新が失われるのを防止する。
T1 がコミットされると、その Start-Timestamps が T1 の Commit-Timestampより大きい、全てのトランザクションに、その変更は見えるようになる。
Formulated in 10 Years Ago
Network is Homegenous added by Gosling
複雑さを考える --- Complexity Quanta and Platform Definition
Summary of Jim Waldo‘s Keynote at the 10th Jini Community Meetinghttp://www.jini.org/files/meetings/tenth/video/Complexity_Quanta_and_Platform_Definition.movhttp://www.jini.org/files/meetings/tenth/presentations/Waldo_keynote.pdf
複雑さにおける基本的な飛躍 線形実行 (SEQ) – 人生は善良でシンプルであっ
た マルチ スレッド ･ (MT) – ツールと優秀なプログ
ラマが MT について考えることが必要 マルチ プロセス ･ (MP) – カーネルの開発者だけ
でなく誰もが利用できる。実際には、 MT の前に起きた。
マルチ・マシン (MM) 同一ネットワーク上の – マルチ・プロセスと同じではないのだが、ある人たちは、そう考えている
信頼できないマルチ・マシンたち (MMU) – 本質的には、 Web の世界である
それぞれの段階を通り抜ける際、我々は、何かを失う
マルチ・スレッドへ： 我々は、順序を失う（複数のことが同時に起こる）。これは、難しい。なぜなら、我々は、自然には、シーケンシャルに考えるから。
マルチ・プロセスへ： 単一のコンテキスト（すなわち、我々が信頼しうる共有コンテキスト）を失う。グローバルな状態が、開発のあらゆるところで利用される。（すべてをスタティックに考えよ）
それぞれの段階を通り抜ける際、我々は、何かを失う
マルチ・プロセスからマルチ・マシンへ：我々は、状態を失う。「システム」のグローバルな状態というのは、虚構である。興味深い分散システムには、整合的な状態というものは存在しない。 （ Lamport: http://research. microsoft.com/users/lamport/pubs/pubs.html ） 分散 OS のプロジェクトは、グローバルな状態を導入しようとしたが、大々的に失敗した。
信頼できないマルチ・マシンたちへ：誰を信ずることが出来るか分からない難しい状況の中で、我々は信頼を失う。
しかし、我々は何かを得てきた Seq to MT : 並列処理 MT to MP : プロセスの分離 (安全を与え
る ) MP to MM : 独立した失敗 ( 何かまずい
ことが起きても、システムの部分は生きのこる )
MM to MMU : スケール (web スケール、インターネットスケール ). 誰か他の人のリソースを利用せよ（あるいは、他の誰かが、我々のリソースを利用することを認めよ）
Transaction in BigTable
c:data データ自身を格納 c:lock コミットされていないトランザク
ションは、 この Cell に書き込む。 PrimaryLock の場所を含んでいる。
c:write コミットされた現在のデータ。 データのタイムスタンプを格納。
c:notify ヒント : observer が走る必要がある かもしれない
c:ack O Observer “O” が走った。最後に 成功した実行のタイムスタンプを格納。
初期状態： Joe の口座には 2 ドル、 Bob の口座には、 10 ドルが、はいっている。
bal:write に、データのタイムスタンプが書き込まれることによって初めて、そのデータは外部から見えるようになる。
Bob から Joe へ、 7 ドル送金するというトランザクションを考えよう。
送金のトランザクションは、 Lockカラムに書き込むことで Bob の口座の残高をロックすることから始まる。このロックは、このトランザクションのprimary である。
このトランザクションは、また、その開始タイムスタンプ 7 にデータを書き込む。 Bob の dataカラムに 3 ドルが書き込まれる。ただし、この変化は、まだ外からは見えない。
トランザクションは、次に Joe の口座をロックして、ふたたび開始タイムスタンプ 7 に、 Joe の新しい残高 9 ドルを書き込む。
このロックは、このトランザクションの secondaryである。 primary ロック（” Bob” 行の” bal”カラム）への参照を含んでいる。クラッシュでこのロックが立ち往生して、トランザクションがロックを解消したいと思った時、このロックの解消を同期するために primary の場所が必要になる。
トランザクションは、コミットのポイントに到達する。
primary ロックを消して、それをコミットタイムスタンプと呼ばれる新しいタイムスタンプ 8 の下で、新しい書き込みレコードと置き換える。この書き込みレコードは、データが格納されているタイムスタンプへのポインターを含んでいる。
これ以降、” Bob” 行の” bal”カラムを読むものは、値 3 ドル を見ることになる。
トランザクションは、 secondary セルに書き込みデータを追加し、ロックを消去することで完了する。
これ以降、” Joe” 行の” bal”カラムを読むものは、値 9 ドル を見ることになる。
この例の場合には、ただ一つの secondary Joe があるだけである。
Transaction in BigTable 詳細
1 class Transaction { 2 struct Write { Row row; Column col; string value; }; 3 vector<Write> writes_ ; 4 int start_ts_ ; 5 6 Transaction() : start_ts_(oracle.GetTimestamp()) {} 7 void Set(Write w) { writes_.push_back(w); }
クラス Transaction の働きを見てみよう。
まず、 Transaction のインスタンスの生成時に、start_ts_ には、その時点のタイムスタンプが入れられる。 ６行目。
データの読み込み： bool Get(Row row, Column c, string* value) の働き
row中の、コンカレントな write を通知するロック c:lock を、過去から start_ts_ まで、チェックする。
ペンディングされたロックがあれば、クリーンを試みて待つ。なければ、次に進む。
c:write をチェックして、過去から start_ts_までにコミットされた、書き込みをみつける。なければ、データはない。
c:write からコミットされたタイムスタンプを取得。
c:data から、コミット・タイムスタンプ時点での値を読み出す。
8 bool Get(Row row, Column c, string* value) { 9 while (true) {10 bigtable::Txn T = bigtable::StartRowTransaction(row);11 // コンカレントな write を通知するロックをチェックする12 if (T.Read(row, c+"lock", [0, start_ts_])) {13 // ペンディングされたロックがあれば、クリーンを試みて待つ14 BackoffAndMaybeCleanupLock(row, c);15 continue;16 }1718 // スタート・タイムスタンプ以下の最新の書き込みをみつける。19 latest write = T.Read(row, c+"write", [0, start ts_]);20 if (!latest write.found()) return false; // データなし21 int data_ts = latest_write.start_timestamp();22 *value = T.Read(row, c+"data", [data ts, data ts]);23 return true;24 }25 }
書き込み前処理： bool Prewrite(Write w, Write primary) の働き
Prewrite は、セル c をロックしようとする。競合があると false を返し、 Abort する。
c:write をチェックし、スタート・タイムスタンプの後にコミットされたものであれば、Abort する
c:lock をチェックし、どんなタイムスタンプでもＬｏｃｋされていれば、 Abort する。
c:data に値を書き込む。 c:lock に、スタート・タイムスタンプ
と、 primary lock の場所を書き込む。 コミットする。
26 //Prewrite は、セル c をロックしようとする。競合があると false を返す。27 bool Prewrite(Write w, Write primary) {28 Column c = w.col;29 bigtable::Txn T = bigtable::StartRowTransaction(w.row);3031 // スタート・タイムスタンプの後にコミットされたものであれば、 Abort する32 if (T.Read(w.row, c+“write”, [start ts , ∞])) return false;33 // . . . あるいは、どんなタイムスタンプでもＬｏｃｋされていれば、 Abort する34 if (T.Read(w.row, c+"lock", [0, ∞])) return false;3536 T.Write(w.row, c+"data", start ts_, w.value);37 T.Write(w.row, c+"lock", start ts_,38 {primary.row, primary.col} ); // プライマリーの場所39 return T.Commit();40 }
コミット： bool Commit() の働き writes_ベクターの先頭が primary 、それ以降を secondaries とする。
primary 、 secondaries への PreWrite が失敗すれば、コミット失敗。
コミット・タイムスタンプを取得する。 まず、 primary をコミット
c:lock のスタート・タイムスタンプ時点での値を読み込む。なければ、コミット失敗。
コミット・タイムスタンプの c:write に、 スタートタイムスタンプに書かれたデータへのポインターを書き込む。
コミット： bool Commit() の働き
コミット・タイムスタンプの c:lock を消す。 コミットする。
続いて、 secondaries をコミット。 secondaries の各Writeごとに、 コミット・タイムスタンプの c:write に、 スター
トタイムスタンプに書かれたデータへのポインターを書き込む。
コミット・タイムスタンプの c:lock を消す。 コミット成功
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;4748 int commit_ts = oracle .GetTimestamp();4950 // 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; // 動作中に abort55 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 // 第二フェーズに進む
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 }
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();}
Spanner: Google’sGlobally-Distributed Database
Wilson Hsieh representing a host of authorsOSDI 2012
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/ja//archive/spanner-osdi2012.pdfhttp://research.google.com/archive/spanner.htmlVideo:https://www.usenix.org/conference/osdi12/elmo-building-globally-distributed-highly-available-database
245
書き込みとバージョン管理 書き込みのトランザクションには、厳密な Two-Phase-
Lock を使う。 それぞれのトランザクション T には、タイムスタンプ s が割り
当てられる。 トランザクション T によって書き込まれたデータは、タイムス
タンプｓを持つ。
OSDI 2012
Time 8<8
[X]
[me]
15
[P]My friendsMy postsX’s friends
[]
[]
246
スナップショットを同期する
==外的整合性 :
コミットの順序は、グローバルな壁時計の順序を尊重する
OSDI 2012
==タイムスタンプの順序は、与えられた
グローバルな壁時計の順序を尊重する
タイムスタンプの順序 == コミットの順序
グローバルな壁時計
247
タイムスタンプとグローバル・クロック 書き込みのトランザクションについては、厳密な two-
phase locking を適用する。 ロックが保持されている間、タイムスタンプを割り当
てる。
T
Pick s = now()
Acquired locks Release locks
OSDI 2012
タイムスタンプの不変量
• タイムスタンプの順序 == コミットの順序
• タイムスタンプの順序は、グローバルな壁時計の順序を尊重する
T2
T3
T4
T1
TrueTime
“グローバルな壁時計の時間” は、ある制限の範囲だが、不確実性を持つ。
time
earliest latest
TT.now()
2*ε
250
タイムスタンプと TrueTime
T
Pick s = TT.now().latest
Acquired locks Release locks
Wait until TT.now().earliest > ss
OSDI 2012
average ε
Commit wait
average ε
コミットの Wait とレプリケーション
T
Acquired locks Release locks
Start consensus Notify slaves
Commit wait donePick s
Achieve consensus
252
Commit Wait and 2-Phase Commit
OSDI 2012
TC
Acquired locks Release locks
TP1
Acquired locks Release locks
TP2
Acquired locks Release locks
Notify participants of s
Commit wait doneCompute s for each
Start logging Done logging
Prepared
Compute overall s
Committed
Send s
253
Example
OSDI 2012
TP
Remove X from my friend list
Remove myself from X’s friend list
sC=6
sP=8
s=8 s=15
Risky post P
s=8
Time <8
[X]
[me]
15
TC T2
[P]My friendsMy postsX’s friends
8
[]
[]
254
我々がカバー出来たことは何か？
データセンター間の、ロックフリーな、 read トランザクション
外的整合性 タイムスタンプの割り当て TrueTime
時間の不確実性は、待つことでしのぐことが出来る
OSDI 2012
255
我々がカバーしなかったこと 現在の時刻を、どうよむのか。 アトミックなスキーマの変更
大部分は、ノン・ブロッキングである 未来のタイムスタンプでコミットする
過去のノン・ブロッキングな読み込み レプリカの効率的な更新
OSDI 2012
256
TrueTime Architecture
Datacenter 1 Datacenter n…Datacenter 2
GPS timemaster
GPS timemaster
GPS timemaster
Atomic-clock
timemaster
GPS timemaster
Client
OSDI 2012
GPS timemaster
Compute reference [earliest, latest] = now ± ε
257
TrueTime implementation
time
ε
0sec 30sec 60sec 90sec
+6ms
now = reference now + local-clock offsetε = reference ε + worst-case local-clock drift
referenceuncertainty
OSDI 2012
200 μs/sec
258
時計が狂うとどうなるか？
タイムスタンプの割り当てが、外的整合性を破ることになるだろう。
一年間のデータに基づけば、そういうことはありそうにない。 時計が狂うより、 CPU がおかしくなる可能性
の方が、６倍以上ありそうである。
OSDI 2012
259
将来の課題 TrueTime の改善
Lower ε < 1 ms データベースの諸特徴をきちんと構築す
る 基本的な特徴の実装を終える 多様な検索パターンを効果的にサポートする
OSDI 2012
260
結論 時計の不確実性を time API で具体化する
知らないことを知ることは、知らないことを知らないより、いいことである
不確実性を利用した、アルゴリズムを再考すること
強いセマンティックは達成可能である 大規模なスケール != 弱いセマンティックス
OSDI 2012
Spanner: Google’s Globally-Distributed Database
James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, JJ Furman, Sanjay Ghemawat et al.
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/ja//archive/spanner-osdi2012.pdf
Abstract
Abstract
Spanner は、スケーラブルで、マルチ・バージョン、グローバルに分散し、レプリカの同期を行う、 Google のデータベースである。
それは、グローバルなスケールでのデータの分散と外的整合的な分散トランザクションをサポートした、初めてのシステムである。
この論文は、 Spanner がどのような構造を持つか、その諸特徴、様々なデザインの決定の基礎にある理論的な根拠、時計の不確実性を明らかにする全く新しい time API について述べたものである。
Abstract
この API とその実装は、外的な整合性と、 Spanner の全域にわたる、過去のデータのブロックしない呼び出し、ロックのないread-only トランザクション、そしてアトミックなスキーマの変更といった強力な諸特徴をサポートする上で、 本質的に重要なものである。
Introduction
概観 Spanner は、 Google で、デザイン・構築・配備されたスケーラブルでグローバルな分散データベースである。
もっとも高い抽象のレベルでは、 それは、全世界に広がっているデータセンター内の沢山の Paxos状態マシン群をまたいで、データを分割したデータベースである。
Spanner は、数百のデータセンターをまたいだ数百万のマシンと、数兆行のデータベースにスケールアップするように設計されている。
Replica と Resharding データの複製は、グローバルな可用性と地理的な局所性の為に利用されている。クライアントは、レプリカ間で自動的にフェール・オーバーする。
Spanner は、データの量やサーバーの数が変化するに応じて、マシン間でデータを再分割する。それは、マシン間で（データセンター間でさえ）、自動的にデータを移動して、負荷のバランスを取り、マシンの失敗に対応する。
アプリケーションは、広域の自然災害に直面しても、内部で、あるいは大陸をまたいでも、データを複製することによって、高い可用性の為に、 Spanner を利用出来る。
Replica と Availability 我々のシステムの最初の利用者は、 Google の広告
システムのバックエンドを書き換えた F１であった。F1 は、アメリカ全土に広がった 5 つのレプリカを利用した。
他のアプリの大部分は、相対的には独立な事故のモードを想定してではあるが、一つの地理的な領域内で、 3 から 5 のデータセンターに、データを複製するだろう。というのは、大部分のアプリケーションは、一つか二つのデータセンターで事故が起きても、生き残ることが出来る限りは、高い可用性の上の低い遅延の方を選ぶだろう。
Spanner の主なフォーカスは、データセンターをまたいだ複製データの管理に置かれている。
Spanner と BigTable ただ、我々は、この分散システムのインフラの上に、
データベースの重要な諸特徴を、デザインし実装することにも、非常に多くの時間をかけてきた。
たとえ、多くのプロジェクトが、 BigTable を使ってハッピーだとしても、我々は、ある種のアプリに取っては、 BigTable は使うには難しくなることがあるという不満を、一貫して受け取ってきた。例えば、複雑でスキーマが変化する、あるいは、広域に複製があるにしても、強い整合性が欲しいというようなアプリだ。（同じような要求は、他の著者からもなされていた。）
Spanner と BigTable
Google の多くのアプリケーションは、相対的には貧弱な書き込み性能にもかかわらず、半リレーショナルなデータモデルと、複製の同期のサポートの故に、 Megastore を選んできた。
その結果、 Spanner は、 BigTable のようなバージョンづけられた key-value ストアから、テンポラルなマルチバージョン・データベースへと進化してきた。
Spanner のデータ形式 データは、スキーマを持つ半リレーショナル
なテーブルに格納される。データはバージョンづけられ、それぞれのバージョンは、自動的にそのコミット・タイムでタイムスタンプが与えられる。古いデータのバージョンは、設定可能なガーベージコレクション・ポリシーの元に置かれる。そうして、アプリは、古いタイムスタンプのデータを読むことが出来る。
Spanner は、一般的な目的のトランザクションをサポートし、 SQLベースの検索言語を提供する。
グローバルに分散したデータベースとしての Spanner の、興味深い特徴
第一に、データの複製の設定は、アプリによって細かい粒度でコントロール出来る。アプリは、どのデータセンターがどのデータを持つのか、データはユーザーからどのくらい離れているか（読み込みの遅延をコントロールする）、レプリカはお互いにどれくらい離れているか（書き込みの遅延をコントロールする）、そして、どのくらいの数のレプリカが維持されているか（耐久性・可用性・読み込みのパフォーマンスをコントロールする）等をコントロールする制約条件を指定出来る。
データは、また、データセンター間のリソースの利用のバランスをとるシステムによって、動的かつ透過的にデータセンター間を移動出来る。
グローバルに分散したデータベースとしての Spanner の、興味深い特徴
第二に、 Spanner は、分散データベースでは実装するのが難しい二つの特徴を持つ。 読み書きについての外的整合性 ある時点での、データベースをまたいだグローバ
ルに整合的な読み込み こうした特徴は、グローバルなスケールで、
たとえ実行中のトランザクションがあったとしても、整合的なバックアップ、整合的なMapReduce の実行、アトミックなスキーマの更新を、 Spanner に可能とする。
Timestamp こうした特徴は、たとえトランザクションが分散し
ていたとしても、 Spanner がトランザクションにグローバルに意味のあるコミット・タイムスタンプを割り当てるという事実によって可能になった。
このタイムスタンプは、シリアル化された順序を反映している。それに加えて、シリアル化された順序は、外的整合性（あるいは、それと等価だが、線形化可能性）を満たしている。すなわち、あるトランザクション T1 が、別のトランザクション T2 が始まる前にコミットするなら、 T1 のコミット・タイムスタンプは、 T2 のそれよりも小さい。
Spanner は、グローバルなスケールで、こうした保証を与えた最初のシステムである。
TrueTime API こうした性質を可能にした重要なもの
は、 TrueTime API とその実装である。 この API は、直接に、時計の不確実さを、あらわに示すものである。そして、 Spanner のタイムスタンプは、実装が提供する不確実さの範囲にディペンドしている。もし、不確実さが大きければ、 Spannerは、この不確実さを待つ為に、スピードを落とす。
この実装は、複数の現代的な時計（ GPS と原子時計）への参照を利用することで、不確実性を小さなもの（一般的には、 10ms以下）にとどめようとする。
Implementation
2.1 Spanserver Software Stack2.2 Directories and Placement2.3 Data Model
Implementation
この節では、 Spanner の構造とその実装の基礎にある理論的な根拠を述べる。
その後、複製と局所性を管理するのに利用され、データ移動の単位である、「ディレクトリー」という抽象について述べる。
最後に、我々のデータモデルと、なぜSpanner がキー・バリュー・ストアではなくリレーショナル・データベースのように見えるのか、また、アプリケーションは如何にしてデータの局所性をハンドルすることが出来るのかについて述べる。
Universe と Zone
Spanner の配備は、「ユニバース」と呼ばれる。 Spanner がデータをグローバルに管理しているとしても、ほんの少数の稼働しているユニバースがあるだけだろう。
我々は現在、テスト / プレイグラウンド・ユニバースと、開発 / 生産・ユニバースと、生産専用・ユニバースの三つを走らせている。
Spanner は、一群の「ゾーン」で組織されている。それぞれのゾーンは、大まかにいって、BigTable のサーバーに相当するものである。
Zone ゾーンは、管理上の配備の単位である。一群のゾー
ンは、また、その上にデータの複製を置くことが出来る、場所群でもある。
新しいデータセンターがサービスを開始したり、逆に、古いデータセンターがサービスを停止したりした場合、ゾーンを稼働中のシステムに追加したり取り除くことが出来る。
ゾーンは、物理的な隔離の単位でもある。データセンターには、一つかそれ以上のゾーンがあるかもしれない。例えば、異なったアプリのデータが同じデータセンター内の異なったサーバー群にまたがって分割されなければいけないような場合である。
Zonemaster と LocationProxy
図 1 は、 Spanner ユニバースのサーバーを図示したものである。
ゾーンは、一つのゾーン・マスターと、百から数千の間のスパンサーバーを持っている。前者は、スパンサーバーにデータを割り当てる。後者は、データをクライアントにサービスする。
ユーザーのデータに割り当てられたスパンサーバーの場所を特定する為に、そのゾーンのロケーション・プロキシーが利用される。
UniverseMaster とPlacementDriver ユニバース・マスターとプレスメント・ドライバーは、
現在のところ、一つしかない。 ユニバース・マスターは、第一義的には、全てのゾー
ンについてのステイタス情報が表示され、インタラクティブなデバッグの為に利用される、コンソールである。
プレスメント・ドライバーは、数分の単位のタイムスケールでの、ゾーンをまたいだデータの自動的な移動をハンドルする。プレスメント・ドライバーは、定期的にスパンサーバーと通信して、レプリカの更新条件に合致した、あるいは、負荷をバランスさせる為、移動すべきデータを見つける。
スペースの関係で、スパンサーバーについてのみ、詳しく述べることになろう。
Spanserver Software Stack
この節では、スパンサーバーの実装にフォーカスして、我々の BigTable をベースにした実装の上に、どのように、複製と分散トランザクションが、実現されたかを示す。
Spanserver Software Stack
ソストウェア・スタックは、次の図 2 に示されている。スタックの一番下では、スパンサーバーが、 100 個から 1000 個の間のタブレットと呼ばれるデータ構造のインスタンスに責任を持っている。
タブレットは、 BigTable のタブレットという抽象と同様のもので、その中では、次のようなマッピングのバッグを実装している。
(key:string, timestamp:int64) → string
Bigtable とは異なって、 Spanner は、タイムスタンプをデータに割り当てる。ここが、 Spanner がキー・バリュー・ストアよりは、マルチ・バージョン・データベースにずっと似ている重要なポイントである。
タブレットの状態は、 Bツリーに似た一群のファイルと write-ahead ログに格納されている。これらは全て Colossus と呼ばれる分散ファイルシステム（ Google File System の後継である）上にある。
複製をサポートする為に、それぞれのスパンサーバーは、それぞれのタブレット上に、一つの Paxos状態マシンを実装している。
( 初期の Spanner の具体化では、タブレットごとに複数の Paxos状態マシンをサポートしていた。それによって、もっと柔軟な複製の設定が可能となるのだが、そのデザインの複雑さの為に、我々は、それを放棄した。）
それぞれの状態マシンは、そのメタデータとログを対応するタブレットに格納する。
我々の Paxos の実装は、時間ベースのリーダーのリースで、デフォルトの長さが 10秒の、長い期間のリーダーをサポートしている。
現在の Spanner の実装では、全ての Paxosが二度ログを書き出している。一つは、タブレットのログで、もう一つは Paxos のログである。この選択は、 expendiency によるもので、最終的には修正したいと思っている。
我々の Paxos の実装は、 WAN の遅延があるにもかかわらず、 Spanner のスループットを向上させる為に、パイプライン化されている。しかし、書き込みは、 Paxos によって、順番に実行される。
Paxos
Paxos状態マシンは、マッピングのバッグのレプリカを整合的に実装するのに利用されている。それぞれの複製のキー・バリュー・マッピングの状態は、対応するタブレットに格納される。
書き出しは、リーダーの Paxos プロトコルから開始されなければならない。読み出しのアクセスの状態は、十分更新されたどのレプリカの下にあるタブレットからでも直接に取得出来る。一群のレプリカは、集って、 Paxos グループを形成する。
リーダーである全てのレプリカのスパンサーバーは、コンカレンシーのコントロールを実装する為のロック・テーブルを実装している。
ロック・テーブルは、ツー・フェーズ・ロッキングの為の状態を含んでいる。それは、一連のキーをロック状態にマップする。（ロック・テーブルを効率的に管理する上で、長い期間、生き続けるリーダーを持つことは、本質的に重要であることに注意。）
BigTable でも Spanner でも、両方とも、我々は。長いトランザクション（例えば、レポートの生成。これ数分単位の時間がかかる）の為のデザインをしてきた。こうした処理は、衝突がある場合には、楽観的コンカレンシー・コントロールでは、貧弱な性能しか出ない。
読み込みのトランザクションのような同期を必要とする操作は、ロック・テーブルからロックを取得する。その他の操作は、ロック・テーブルをバイパスする。
リーダーである全てのレプリカでは、それぞれのスパンサーバーは、分散トランザクションをサポートする為にトランザクション・マネージャーも実装している。
トランザクション・マネージャーは、参加者のリーダーを実装する為に利用される。その他のレプリカは、参加者のスレーブとなる。
もしトランザクションが、一つの Paxos グループを含んでいるだけなら（大部分のトランザクションの場合）、それは、トランザクション・マネージャをバイパス出来る。というのは、ロック・テーブルと Paxos が一緒になって、トランザクションの保証を提供するからである。
もしトランザクションが一つ以上の Paxos グループを含んでいたら、これらのグループ・リーダーがツー・フェーズ・コミットの調整役を演ずる。
参加グループの一つが、調整役に選ばれる。そのグループの参加者のリーダーは、調整役リーダーと呼ばれ、グループのスレーブは、調整役スレーブと呼ばれる。
それぞれのトランザクション・マネージャの状態は。直下の Paxos グループに格納される。（それ故、複製される。）
Directories and Placement
2.2 Directories and Placement
キー・バリュー・マッピングのバッグの上で、Spanner の実装は、「ディレクトリー」と呼ばれる「バケット化」の抽象をサポートしている。それは、共通の接頭辞を共有する連続的なキーの集まりである。（ディレクトリーという言葉の選択は、歴史的な事情によるもので、もっと良い言葉は、「バケット」だったかもしれない。）
次のセクション 2.3 で、この接頭辞の起源を説明しよう。ディレクトリーのサポートは、キーをチュイい深く選ぶことによって、データの局所性をコントロールすることを可能にする。
ディレクトリーは、データの配置の単位である。ディレクトリー内の全てのデータは、同じ複製設定を持つ。
データが Paxos グループ間を移動する時、それは図 3 が示すように、ディレクトリーからディレクトリーへと移動する。
Spanner は、ディレクトリーを、あるPaxos グループから負荷を軽減する為に移動するかもしれない。 よくアクセスされるディレクトリーを同じグループにまとめたり、アクセスする人に近いグループにディレクトリーを移動したり。
クライアントの操作が実行中でも、ディレクトリーは移動出来る。 50MB のディレクトリーは、数秒で移動出来ると考えてよい。
Paxos グループが複数のディレクトリーを含みうるという事実は、 Spanner のタブレットが BigTable のタブレットとは違っていることを意味している。 Spanner のタブレットは、単一の連続するの辞書式順序の行空間の分割ではないのである。
その代わりに、 Spanner のタブレットは、複数の行空間の分割を包み込んだコンテナーなのである。しばしば一緒にアクセスされる複数のディレクトリーを、近い場所に置くことが可能であるということで、我々は、この決定を行った。
Movedir は、 Paxos グループ間でディレクトリーを移動させるバックグラウンドのタスクである。 Movedir はまた、レプリカをPaxos グループに追加したり削除するのに利用されている。というのも、 Spanner はPaxos の設定を変えるということを、まだ、サポートしていないからだ。
Movedir は、大きなかたまりのデータ移動の際に実行される、読み出し・書き込みのブロックを避ける為に、単一のトランザクションとしては、実装されていない。
その代わりに、 movedir は、データ移動が始まったという事実を登録し、データをバックグラウンドで移動する。
名目的なデータの量以外の全てのデータを移動し終わったら、 movedir は、この名目的な量をアトミックに移動する為にトランザクションを利用し、二つの Paxos グループのメタデータを更新する。
ディレクトリーは、また、その複製の地理的なプロパティ（短く、「配置」という）が、アプリによって指定される最小の単位である。
配置指定の言語は、複製の設定を管理する責任とは分離されている。
管理者は、二つの次元をコントロールする。レプリカの数と型、そして、これらのレプリカの地理的な配置である。管理者は、これらの二つの次元で、名前でオプションのメニューを作る。（例えば、 North America, replicated 5 ways with 1 witness というような ).
アプリは、それぞれのデータベース、あるいは、個々のディレクトリーを、これらのオプションの組み合わせでタグづけて、データがいかに複製されるかをコントロールする。
例えば、あるアプリでは、エンドユーザー各人のデータを、次のように、自身のディレクトリーに格納しているかもしれない。ユーザー A のデータはヨーロッパに 3 つのレプリカを持ち、ユーザー B のデータは、北米に 5つのレプリカを持つ、ということが可能になる。
説明を分かりやすくする為に、随分、単純化したのだが、実際には、 Spanner はディレクトリーがあまりに大きくなった時には、それを複数のフラグメントに分割するだろう。
フラグメントは、異なる Paxos グループでサービスを受ける（それ故、異なるサーバーで）かもしれない。 Movedir は、実際には、グループ間でディレクトリー全体ではなく、フラグメントを移動する。
Data Model
Spanner は、次のような一群のデータの諸特徴を、アプリケーションに示す。 スキーマ化された半リレーショナルなテーブル、検索言語、一般的な目的のトランザクションである。これらの諸特徴をサポートしようという動きは、様々なファクターによってドライブされていた。
スキーマ化された半リレーショナルなテーブルと同期的な複製をサポートするニーズは、 Megastore が広く受け入れられたことでサポートされた。
Google内では、すくなくとも 300 のアプリが、 Megastore （その相対的には低いパフォーマンスにもかかわらず）を利用している。というのも、そのデータ・モデルは、管理が単純だからである。
そして、データセンターをまたぐ同期複製のサポートによって。（ BigTable は、データセンター間では、 Eventually Consistent な同期複製しかサポートしていない）
Megastore を利用したよく知られた Googleのアプリには、次のものがある。
Gmail Picasa Calendar Android Market AppEngine
Spanner で、 SQL ライクな検索言語をサポートする必要も、インタラクティブなデータ分析ツールとしての Dremel の人気をみれば、明確であった。
最後に、 BigTable では、行をまたいだトランザクションが欠けていたことも、しばしば不満の種になった。 Percolator は、部分的には、この欠点に向けて開発されたものだった。
ある人たちは、一般的なツー・フェーズ・コミットは、それがもたらすパフォーマンスの問題や可用性の問題を考えれば、サポートするのは、あまりに高いものにつくと論じてきた。
我々は、アプリケーションの開発者に、トランザクションの過剰な使用によりボトルネックが生ずるというパフォーマンスの問題を扱わせることは、いつもトランザクションを欠いたままコードを書くより、ましなことだと信じている。
Paxos 上でツー・フェーズ・コミットを走らせることは、可用性の問題を軽減する。
アプリケーションのデータ・モデルは、実装でサポートされている、ディレクトリーでバケット化されたキー・バリュー・マッピングの層の上に作られる。
アプリは、ユニバースの中に、一つ、あるいはそれ以上のデータベースを生成する。それぞれのデータベースは、無制限の数のスキーマ化されたテーブルを含むことが出来る。テーブルは、行とカラムとバージョン値を持つ、リレーショナル・データベースに見える。
ここでは、 Spanner の検索言語については深く触れない。それは、 プロトコル・バッファーの値を持つフィールドをサポートする、いくつかの拡張をほどこした SQL に見える。
Spanner のデータ・モデルは、純粋にリレーショナルなものではない。そこでは、行は名前を持たなければならない。もっと正確に言えば、全てのテーブルは、一つあるいはそれ以上の、順序づけられたプライマリー・キー・カラムのセットを持つことを要求される。
この要請は、 Spanner が依然としてキー・バリュー・ストアに見えるところである。プライマリー・キーは行に対する名前を形成し、それぞれのテーブルは、プライマリー・キー・カラムから非プライマリー・キー・カラムへのマッピングを定義する。
行は、行のキーに（たとえそれが NULL であっても）ある値が定義されている時にのみ存在する。
こうした構造を課することは、アプリケーションにキーの選択を通じてデータの局所性をコントロールさせるので、有用である。
図 4 は、ユーザーごと、アルバムごとに、写真のメタデータを格納する、 Spanner のスキーマの例である。
スキーマ言語は、 Megastore のものと似ている。それに、全ての Spanner のデータベースは、クライアントによって、一つあるいはそれ以上の、テーブルの階層によって分割されなければならないという要請を付け加えたものである。
クライアントのアプリは、データベースのこの階層を、 INTERLEAVE IN宣言によって宣言する。階層のトップのテーブルは、ディレクトリー・テーブルである。
キー K を持つディレクトリー・テーブルは、辞書式順序で K で始まる、下位のテーブルの全ての行とともに、ディレクトリーを形成する。
ON DELETE CASCADE は、このディレクトリー中のある行の削除は、関連する子供の行を全て削除することを意味している。
この図はまた、この例のデータベースのインターリーブされたレイアウトを図示している。
例えば、 Albums(2,1) は、 Albums テーブルのユーザー id 2 、アルバム id 1 の行を表している。
このディレクトリーを形成するテーブルのインターリービングは重要である。なぜなら、それは、複数のテーブル間に存在するローカルな関係を、クライアントが記述することを可能にするからである。
それは、分割された分散データベースでは、よいパフォーマンスの為に必要である。それなしでは、 Spanner は、もっとも重要なローカルな関係性を知ることが出来ない。
TrueTime
ここでは、 TrueTime API について述べ、その実装をスケッチする。詳細は、別の論文に譲る。我々の目的は、こうした APIを持つことの力を示すことである。
TrueTime
テーブル 1 は、この API のメソッドである。 TrueTime は、時間を TTinterval として、時
間の不確実性で境界付けられた、ある区間として、はっきりと表現している。（クライアントに、時間の不確実性についての考えを、まったく与えない標準的な時間のインターフェースとは、違っている）
TTinterval の端点は、 TTstamp の型を持つ。 TT.now() メソッドは、その間に TT.now() が呼び出された絶対時間を含むことが保証されている TTinterval を返す。この時刻は、 UNIX の time に似ているが、うるう秒の補正をしてある。
その瞬間の誤差の範囲を ε と定義する。それは、区間の半分の長さで、平均的な誤差の範囲は ε となる。
TT.after() と TT.before() メソッドは、 TT.now()関連の便利なラッパーである。
イベント e の絶対時間を、関数 tabs(e) で表す。より形式的に述べれば、 enow をイベントの呼び出しとしたとき、 TrueTime は、次のことを保証する。
tt = TT.now() tt.earliest ≤ tabs(enow) ≤ tt.latest
TrueTime で使われている基礎になる時間の参照は、 GPS と原子時計である。 TrueTimeは、二つの形式の時間を参照する。というのも、この二つは、失敗のモードが異なっているから。
GPS のソース参照の脆弱性は、 アンテナやレシーバの事故、ローカルな電波の干渉、正しくないうるう秒の処理やなりすまし等に関連した失敗を含んでいる。
原子時計は GPS とは関係なく、それぞれ独立に失敗することがある。あまりに長い時間の間隔は、 周波数エラーで大きくずれることがある。
TrueTime は、データセンターごとのタイム・マスター・マシンと、マシンごとのタイム・スレーブ・デーモンで実装されている。
マスターの大部分は、専用アンテナを備えたGPS受信機を持っている。これらのマスターは、アンテナ事故や電波の干渉、なりすましの危険を軽減する為に、物理的に離れて設置される。
残りのマスター（われわれは、それを「ハルマゲドン・マスター」と読んでいる）は、原子時計を装備している。
原子時計は、高価なものではない。ハルマゲドン・マスターのコストは、 GPS マスターのコストと同じオーダーである。
全てのマスターの時間参照は、定期的に、相互に比較される。それぞれのマスターはまた、参照時間と自分のローカル時計とのクロス・チェックも行う。もし、重大な相違があれば、自分をマスターから外す。
同期の間、ハルマゲドン・サーバーは、ゆっくり増えていく時間の不確実性を広告する。それは、最悪ケースの時計のずれを適用して、保守的に導きだされる。
GPS マスターは、典型的にはゼロに近いものとして、不確実性を広告する。
全てのデーモンは、一つのマスターによるエラーの脆弱性を軽減する為に、多様なマスターに投票する。あるものは、近くのデータセンターから選ばれた GPS マスターを、あるものは、遠くのデータセンターの GPS マスターを、あるものはハルマゲドン・マスターを選ぶ。
デーモンは、嘘つきを検出し排除し、ローカル・マシンの時計を、嘘つきではない時計に同期する為に、 Marzullo のアルゴリズムの変種を適用する。
壊れたローカル時計から守る為に、コンポーネントの仕様と操作環境から導かれる最悪ケースより大きな変動を繰り返すマシンは、取り除かれる。
同期の間、デーモンは、ゆっくり増えていく時間の不確実性を広告する。 ε は、最悪ケースの時計のずれを適用して、保守的に導きだされる。
ε はまた、タイム・マスターの不確実性と、タイム・マスターに対する通信遅延にディペンドする。
我々の製品版の環境では、 ε は、投票間隔では、約 1ms から 7ms の間を変動する、のこぎりの歯状の関数である。 ε は、それ故、大部分の時間 4ms である。
デーモンの投票間隔は、現在 30秒であり、現在の変異率は、毎秒あたり 200 マイクロ秒に設定されている。
のこぎり歯は、 0 から 6ms の範囲の値を持つ。残りの 1ms は、タイム・サーバーに対する通信遅延である。
事故が起きた時は、こののこぎり歯から乖離する可能性がある。例えば、タイム・マスターが一時的に使えなくなった場合は、データセンター全体で、 ε の値の増大を引き起こす。同様に、過負荷なマシンやネットワーク・リンクは、一時的で局所的な ε のスパイクを引き起こすことがある。
4 Concurrency Control
この節では、 TrueTime が、コンカレンシーのコントロールまわりの正確性という性質を、いかに保証しているのか、また、これらの性質が外的整合なトランザクション、ロックのない Read-Only トランザクション、過去のデータのブロックしない読み込みといった特徴を実装するのにどのように利用されているかを述べる。
これらの諸特徴は、例えば、全てのデータベースで、タイムスタンプ t での正当性検査の読み込みが、 t で既にコミットされている全てのトランザクションの効果を、正確に見ることを保証する。
さらに言えば、それは Paxos によって見られる書き込みを（ここで、コンテキストが明確でないが、 Paxos の書き込みという）、 Spanner のクライアントの書き込みとを区別する為にも重要である。
例えば、 TPC は、準備フェーズで Paxos の書き込みを生成するが、それは Spanner のクライアントの書き込みには、照応してはいない。
4.1 Timestamp Management
テーブル 2 は、 Spanner がサポートしている操作をまとめたものである。
Spanner の実装は、 read-write トランザクションと read-only トランザクション（スナップショット・トランザクションとよばれたもの）、スナップショット read をサポートしている。
単独の書き込みは、 read-write トランザクションとして実装されている。
スナップショットではない単独の読み出しは、read-only トランザクションとして実装されている。
双方ともに、内部的にはリトライされる。（クライアントは、自分でリトライのコードを各必要はない）
read-only transaction read-only トランザクションは、スナップショッ
ト・アイソレーションのパフォーマンスの利点をもったタイプのトランザクションである。
read-only トランザクションは、いかなる書き込みも持っていないと、あらかじめ宣言されていなければならない。それは、単純に、いかなる書き込みのない read-write トランザクションではない。
read-only トランザクションは、ロックなしで、システムが選んだタイムスタンプで実行される。だから、書き込みはブロックされない。
read-only トランザクションでの読み込みの実行は、十分にアップデートされた全てのレプリカ上で遂行される。
Snapshot read スナップショット read は、ロックなしに実
行される過去の読み出しである。 クライアントは、スナップショット read の為にタイムスタンプを指定出来る。あるいは、望むタイムスタンプの古さの上限を与えて、Spanner にタイムスタンプを選ばせることも出来る。
どちらの場合でも、スナップショット readの実行は、十分にアップデートされた全てのレプリカ上で遂行される。
read-only トランザクションでも、スナップショット read でも、双方で、いったんタイムスタンプが選ばれれば、そのタイムスタンプがガーベージ・コレクトされていない限りは、コミットは不可避である。結果として、クライアントはリトライ・ループの内部で、結果をバッファリングする必要を避けられる。
サーバーが失敗した時、クライアントは、タイムスタンプと現在の読み込み位置を繰り返し与えて、内部的に、異なるサーバーにクエリーを続ける。
4.1.1 Paxos Leader Leases
Spanner の Paxos の実装では、リーダーを長生きさせる為に（デフォルトでは、 10秒）、リースを使っている。
潜在的なリーダーは、リースの投票のリクエストを送る。定足数に達するリースの投票を受け取ると、リーダーは、リースがあることを知る。
レプリカは書き込みに成功すると暗黙にリースの投票を拡大し、リーダーは、リースの期限切れに近づくと、リースの投票の拡張をリクエストする。
リーダーのリースの期間を、それがリースの投票が定足数に達したことを見つけた時にスタートし、もはや、その定足数に達しない時（いくつかが終了したので）に終わるものと定義しよう。
Spanner は、 次のような、相互に関連のないという原則にディペンドしている。それぞれの Paxos グループにとって、それぞれの Paxosリーダーのリース期間は、他の全てのリーダーのリース期間とは、切り離されている。
Spanner の実装は、 Paxos のリーダーが、スレーブをリースの投票から解放することによって、仕事を放棄することを認めている。
相互に関係がないことを変わらないように維持する為に、 Spanner は、放棄が許可されうる場合でも制約を設けている。
smax を、リーダーが利用出来る最大のタイムスタンプとしよう。次節以降で、いつsmax が進んでいくかを記述するだろう。 任務を放棄する以前に、リーダーはTT.after(smax) が真になるまで、待たないといけない。
4.1.2 Assigning Timestamps to RW Transactions
read と write のトランザクションは、ツー・フェーズ・ロッキングを使用している。その結果、全てのロックが獲得されるなら、いかなる時間でもタイムスタンプを割り当てられうる。ただし、その前に、全てのロックが解放されてなければならない。
あるトランザクションでは、 Spanner は、Paxos が Paxos の write に割り当てたタイムスタンプ、これはトランザクションのコミットを表しているのだが、そのタイムスタンプを割り当てる。
Spanner は、次のような、単調性の原則にディペンドしている。
それぞれの Paxos グループの内部では、 Spanner は、リーダーをまたいでさえ、Paxos write に単調増加する順番にタイムスタンプを割り当てる。
一つのリーダーのレプリカは、自明なことだが、単調増加順にタイムスタンプを割り当てられる。
この原則は、リーダーをまたいで、分離性の原則を利用することで、強められる。
リーダーは、リーダーのリースの期間の範囲の中でのみ、タイムスタンプを割り当てることが出来る。
タイムスタンプ s が割り当てられた時、 s は、最大、分離性が保存されるまでしか進められない。
整合性の原則： もし、トランザクション T2 のスタートが、
トランザクション T1 のコミットよりもあとであるなら、 T2 のコミットのタイムスタンプは、 T1 のコミットのタイムスタンプより大きいものでなければならない。
トランザクション Ti のスタートとコミットのイベントを estart:i と ecommit:i としよう。そして、トランザクション Ti のコミット・タイムスタンプを s:i としよう。
この原則は、次のようになる。 tabs(ecommit:1) < tabs(estart:2)
⇒ s:1 < s:2
トランザクションを実行し、タイムスタンプを割り当てるプロトコルは、 Start とCommit wait という二つのルールに従う。それは、これらは、以下に示すように、一緒になって、この原則を保証する。
Start ルール 協調リーダーに Ti の write のコミットのリク
エストが到着するイベントを、 eserver:i としよう。
Ti write の協調リーダーは、 eserver:i 以降に計算された TT.now.latest よりも、小さくない値を、コミット・タイムスタンプ s:i を割り当てる。
ここでは参加者リーダーは、関係ないことに注意しよう。 4.2.1節で、次のルールの実装で、彼らがいかに巻き込まれるかを記述する。
Commit Wait ルール 協調リーダーは、 TT.after(s:i) が真になるま
でクライアントは Ti でコミットされたデータが見えないことを保証する。
Commit wait は、 s:i が、 Ti のコミットの絶対時間より小さいことを保証する。すなわち、s ： i < tabs(ecommit:i) である。
Commit wait の実装は、 4.2.1節で記述される。
Proof: s:1 < tabs(ecommit:1 )
(commit wait) tabs(ecommit:1 ) < tabs(estart:2 )
(assumption) tabs(estart:2 ) <= tabs(eserver:2 )
(causality) tabs(eserver:2 ) <=s2
(start) s:1 < s:2
(transitivity)
4.1.3 Serving Reads at a Timestamp
4.1.2節で記述した単調性の原則は、 Spanner が、ある read を満たすように、レプリカの状態が十分更新されているかを、正しく決定することを可能にする。
全てのレプリカは、セーフ・タイム t ：safe と呼ばれる値をチェックする。それは、レプリカが更新された最大のタイムスタンプである。
レプリカは、もし、 t <= t:safe であるタイムスタンプ t でならば、 read を満たす。
t:safe = min(tPaxos:safe, tTM:safe )
とする。ここで、それぞれの Paxos状態マシンは、セーフ・タイム tPaxos:safe を、それぞれのトランザクション・マネージャは、セーフ・タイム tTM:safe を持っているとする。
tPaxos:safe は単純である。それは、もっとも最近適用された Paxos write のタイムスタンプである。 なぜなら、タイムスタンプは単調に増加し、 write は順番に適用されるから。Paxos に関しては、 write は、 tPaxos:safe以下ではもはや起きることはない。
tTM ： safe は、もし準備された（ただしコミットされていない）トランザクション -- すなわち、 two-phase commit の二つのフェーズの途中にあるトランザクションがゼロであれば、レプリカでは ∞ である。
(参加しているスレーブでは、 tTM ： safe は、実際に、レプリカのリーダーのトランザクション・マネージャを参照している。この状態をこのスレーブは、 Paxos write で渡されたメタデータを通じて推論出来る。）
もし、このようなトランザクションが一つでもあるなら、その時、これらのトランザクションによって影響を受ける状態は、「不定」である。参加者のレプリカは、これらのトランザクションがコミットされたのかを、未だ、知らない。
4.2.1節で議論したように、コミット・プロトコルは全ての参加者が準備段階のトランザクションのタイムスタンプの下限を知っていることを保証する。
全ての参加者のリーダーは（あるグループ g にとって）、トランザクション Ti に対して、準備タイムスタンプ sPrepare:i,g を、その準備レコードに割り当てる。
協調リーダーは、トランザクションのタイムスタンプが、全ての参加グループ上で、 si >= sPrepare ： i,g であることを保証する。 それゆえ、グループ g の全てのレプリカにとって、 g で準備された全てのトランザクション Ti 上で、tTM ： safe = mini:i(sPrepare:i,g ) – 1 である。
4.1.4 Assigning Timestamps to RO Transactions
read-only トランザクションは、二つのフェーズで実行される。
まず、タイムスタンプ sread を割り当て、ついで sread でのスナップショット read として、トランザクションの read を実行する。
スナップショット read は、十分にアップデートされた、全てのレプリカで実行可能である。
トランザクションがスタートしてからの後であれば、どんな時間でも、 write について4.1.2節でおこなったのと類似の議論によって、単純な割り当て sread = TT.now().latest は、外的な整合性を保存する。
しかし、こうしたタイムスタンプは、もし、tsafe が十分に進んでいない場合、 sread でのデータの read の実行にブロックを要求することがある。（加えて、 sread の選択は分離性を保存する為に、 smax を進ませるかもしれないことに留意）
ブロックの機会を減らす為には、 Spannerは、外的整合性を保証するもっとも古いタイムスタンプを割り当てるべきである。 4.2.2節で、どのようにこうしたタイムスタンプが選ばれるかを説明する。
4.2 Details
この節では、以前には省かれた、 read-write トランザクションと read-only トランザクションの実践的な詳細について説明する。
同時に、アトミックなスキーマの変更の際に利用される特別なトランザクションについて述べる。
そして、これまで述べた基本的なスキーマの精密化について述べる。
4.2.1 Read-Write Transactions
Bigtable と同じように、トランザクションの間に起きた write は、クライアントでコミットされるまでバッファーに置かれる。その結果、トランザクション中の read は、 write トランザクションの影響を見ることが出来ない。
このデザインは、 Spanner ではうまく機能している。なぜなら、 read は、読み込まれたどんなデータでもタイムスタンプを返すのに、コミットされていない write は、まだ、タイムスタンプを持たないからである。
read-write トランザクション中の read は、デッドロックを避ける為に、 wound-wait を利用する。
クライアントは適当なグループのレプリカのリーダーに、 read を発行する。それは、 read ロックを獲得してから、もっとも最近のデータを読む。
クライアントのトランザクションがオープンな間、クライアントは、参加者のリーダーがそのトランザクションをタイムアウトしないように keepalive メッセージを送る。
クライアントが全ての read と write のバッファリングを終えたとき、 two-phase commit を始める。
クライアントは調整グループを選び、それぞれの参加者リーダーに、調整者の ID と全てのバッファーされている write とともに、コミット・メッセージを送る。
クライアントが two-phase commit を走らせることで、広域のリンクで、データを二度送ることを避ける。
調整者ではない参加者リーダーは、最初にwrite ロックを獲得する。
それから、以前のトランザクションで割り当てられたどのタイムスタンプよりも大きな値を持つ準備されたタイムスタンプを選び（単調性を保存するため）、 Paxos を通じて準備されたレコードをログに書き込む。
その時、全ての参加者は、準備したタイムスタンプを調整者に通知する。
調整者のリーダーも、最初に write ロックを獲得するが、準備のフェーズはスキップする。調整者は、全ての参加者のリーダーから聞いてから、トランザクション全体のタイムスタンプを選ぶ。
コミットのタイムスタンプ s は、全ての準備のタイムスタンプより大きいか等しい（ 4.1.3 で議論された制約を満たすため）もので、調整者がコミットメッセージを受け取った時点での TT.now().latest より大きく、かつ、リーダーが以前のトランザクションに割り当てた全てのタイムスタンプより大きい（再び、単調性を保存する為に）ものでなければならない。
調整リーダーは、 Paxos を通じてコミット・レコードをログする。（あるいは、もし、他の参加者を待っている間にタイムアウトになれば、 abort する）
どんな調整レプリカがコミット・レコードを適用することを許す以前に、調整リーダーは、 TT.after(s)まで待つ。こうして、 4.1.2 で述べた、 commit-wait ルールに従う。
調整リーダーは TT.now().latest に基づいてタイムスタンプを選ぶので、今度は、タイムスタンプが過去に属することが保証されるまで待つ。期待される待ち時間は、最小で、 2 ∗ ε である。 この待ちは、典型的には、 Paxos の通信とオーバーラップしている。
commit wait の後で、調整者は、クライアントと全ての参加リーダーに、コミットのタイムスタンプを送る。それぞれの参加者は、 Paxos を通じてトランザクションの出力をログに書き込む。全ての参加者は、同じタイムスタンプを適用し、そしてロックを解除する。
4.2.2 Read-Only Transactions
タイムスタンプを割り当てるには、 read にかかわる全ての Paxos グループの間で、交渉のフェーズが必要である。その結果、 Spanner は、全ての read-only トランザクションに対して、ある範囲の表現を要求する。それは、全てのトランザクションによって読まれるであろう、キー達を要約した表現である。 Spanner は、単独のクエリーに対して、自動的にその範囲を推論する。
もし、このスコープの値が、一つの Paxos グループによってサーブされるのなら、そのクライアントはそのグループ・リーダーに、 read-only トランザクションを発行する。（現在の Spanner の実装は、 Paxosリーダーのもとでは、 read-only トランザクションのタイムスタンプしか選べない）
そのリーダーは、 sread を割り当て、 readを実行する。一つのサイトでの read では、Spanner は、一般的には、 TT.now().latestよりはましな仕事をする。
LastTS() を、ある Paxos グループで最後にコミット write された最後のタイムスタンプとしよう。
もし、準備中のトランザクションがないのなら、割り当ては、 sread = LastTS() で、 If there are no prepared transactions, the assign- ment sread = LastTS() で、自明のことだが、外的整合性を満たす。このトランザクションは最後の書き込みの結果を見ていて、それゆえに、その後に順序付けられている。
もし、スコープの値が、複数の Paxos グループによってサーブされているなら、いくつかの選択肢がある。もっとも複雑な選択肢は、全てのグループ・リーダーと一回り LasTTS() に基づいた sread についてコミュニケーションを行うことである。
Spanner は、現在は、単純な選択を実装している。クライアントは一連の交渉を避けて、その read を sread = TT.now().latest で実行させる。 ( それは、safe time が来るまで待たないといけない）
トランザクションのすべての read は、十分にアップデートされたレプリカに送られることが出来る。
4.2.3 Schema-Change Transactions
TrueTime は、 Spanner に、アトミックなスキーマの変更のサポートを可能にする。それは通常のトランザクションでは実行が難しいだろう。なぜならば、参加者の数（データベース内のグループの数）が、数百万になりうるから。
Bigtable は、一つのデータセンター内で、アトミックなスキーマの変更をサポートしていたが、ただ、そのスキーマ変更は、全ての操作をブロックした。
Spanner のスキーマ変更トランザクションは、一般的には、通常のトランザクションのブロックしない変種である。
第一に、それは未来のタイムスタンプを、はっきりと割り当てる。それは準備フェーズで登録される。その結果、数千台のサーバーをまたいだスキーマの変更は、他の並行する活動に、最低限の障害をもたらすだけで完遂されうる。
第二に、暗黙のうちにスキーマにディペンドしている read と write は、全ての登録されている時間 t のスキーマ変更のタイムスタンプと同期する。それらは、そのタイムスタンプが、 t に先行していれば、前に進むが、もしそのタイムスタンプが t の後で、スキーマ変更のタイムスタンプの後ろだとブロックしなければならない。 TrueTime なしでは、スキーマ変更が、時間 t で起きると定義することは無意味である。
4.2.4 Refinements
先に定義された tTM ： safe は弱点を持っている。一つの安全な準備段階のトランザクションが、 t:safe を進めることを妨げる。その結果、後のタイムスタンプを持っているread は実行出来ない。たとえ、その read がそのトランザクションと競合することがなくても。
こうした偽の競合は、キー範囲から準備段階のトランザクションのタイムスタンプへの細かい精度でのマッピングで、 tTM:safe を増やしてやることで、取り除くことが出来る。
この情報は、ロック・テーブルに格納出来る。ロック・テーブルは既に、キー範囲をロック・メタデータにマップしている。 read が到着した時、キー範囲の高精度のタイムスタンプについて、それがその read と競合するかチェックするだけでいい。
先に定義した LastTS() も似たような弱点を持っている。もし、トランザクションがコミットしたばかりなら、競合しない read-only トランザクションも、そのトランザクションの後に続くように、 sread を割り当てられる。その結果、 read の実行は遅らせられることがあり得る。
この弱点は、同様に、ロック・テーブル内のキー範囲からコミット・タイムスタンプへの高い精度のマッピングで、 LastTS() を増加させてやれば手当が出来る。（我々は、まだ、この最適化を実装していない）
read-only なトランザクションが到着したら、トランザクションが競合する場合には、競合する準備段階のトランザクションがないなら（それは、高精度のタイムスタンプから決定出来る）、 LastTS() の値の最大値を取ることで、タイムスタンプを割り当てることが出来る。
先に定義した tPaxos:safe も、 Paxos writeが不在では先に進めないという点で弱点を持っている。すなわち、時間 t でのスナップショッ tread は、 その最後の write が t 以前に起きた Paxos グループでは実行されない。
Spanner は、この問題に、リーダーのリースの間隔の分離性の利点を利用することで対応する。
それぞれの Paxosリーダーは、未来の writeタイムスタンプが起きるようにしきい値を保ちながら、 tPaxos:safe を前に進める。
それは、 Paxos のシーケンス数 n から、 Paxos のシーケンス数 n + 1 で割り当てられる最小のタイムスタンプへのマッピングである、 MinNextTS(n) を維持している。
レプリカは、 n を通じて適応されたとき、 tPaxos:safe を MinNextTS(n) − 1 に進められる。
単独のリーダーは、 MinNextTS （）の約束を簡単に実行出来る。なぜなら、 MinNextTS （）で約束されたタイムスタンプは、リーダーのリースの期間の中にあるからである。分離性の原則は、リーダーをまたいで MinNextTS （）の約束を実行する。A single leader can enforce its
もし、リーダーが、リーダーのリースの終点を超えて MinNextTS （）を進めることを望むなら、まず、リースを延長しなければならない。分離性を保存する為に、 smax は常にMinNextTS （）の最大値より進んでいることに留意。
リーダーは、デフォールトでは、 8秒おきにMinNextTS （）の値を進める。こうして、準備段階のトランザクションがなくても、アイドル状態の Paxos グループの正常なスレーブは、最悪ケースでも８秒古いのよりも大きなタイムスタンプ read をサービス出来る。
リーダーは、また、スレーブからの要求に応じて、 MinNextTS （）を進めることがある。
top related