Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cyber-Physical Systems とは何か?

4,725 views

Published on

マルレク2014-2015 7月

Published in: Technology
  • Be the first to comment

Cyber-Physical Systems とは何か?

  1. 1. Cyber-Physical Systems と 自律分散システム @maruyama097 丸山不二夫
  2. 2. Agenda  Cyber-Physical Systemとは、何か?  Cyber-Physical Systemsの歴史での重要な 出来事  Cyber-Physical Systemsが挑戦している課題  Cyber-Physical Systemsとして情報システム を捉え直す  自律分散というアプローチ  これから考えるべきこと
  3. 3. Cyber-Physical System とは、何か? ここでは、Cyber-Physical Systemsの簡 単な定義を与えて、共通部分の多いIoTや ビッグデータ論との比較を行う
  4. 4. “Internet of Things” 最初の意味 “Internet of Things” という言葉はKevin Ashton によって、1999年に提案された
  5. 5. “That ‘Internet of Things’ Thing” by Kevin Ashton 初出  “Internet of Things” というフレーズは、私が 1999年にProcter & Gamble (P&G) 社で 行ったプレゼンのタイトルとして、初めて世に出た。 P&G社のサプライチェインの新しいアイデアとし てのRFIDを、当時、最もホットなトピックであった インターネットに結びつけたことは、経営幹部の 強い注意を引きつけるに十分だった。 すべてのモノにIDを持たせるというアイデア “That 'Internet of Things' Thing” by Kevin Ashton http://bit.ly/1bt4GBP
  6. 6.  今日の情報技術は、人間によって生み出される 情報にあまりに依存していて、我々のコンピュー タは、モノについてより、人間の考えについての 方をよく知っている。  もし、我々の助けなしに自分で集めたデータを 使って、モノについて知りうる全てのことを知って いるコンピュータがあったとすれば、我々は、すべ てのモノを追跡しその数を数えることが出来、無 駄や損失やコストを多いに削減することが出来る だろう。 人が生み出す情報ではなく、モノについての情報 “That 'Internet of Things' Thing” by Kevin Ashton http://bit.ly/1bt4GBP
  7. 7. 日本への影響「ユビキタス」 情報通信白書特集テーマの変遷  2004年「世界に拡がるユビキタスネットワーク社 会の構築」  2005年「u-Japanの胎動」  2006年「ユビキタスエコノミー」  2007年「ユビキタスエコノミーの進展とグローバ ル展開」  2008年「活力あるユビキタスネット社会の実現」  2009「日本復活になぜ情報通信が必要なのか」 http://bit.ly/1n66E07
  8. 8. 日本への影響「ユビキタス」 ITの世界で何が起きていたか?  2004年「世界に拡がるユビキタスネットワーク社 会の構築」Google上場  2005年「u-Japanの胎動」CPS  2006年「ユビキタスエコノミー」Amazon EC2/S3  2007年「ユビキタスエコノミーの進展とグローバ ル展開」iPhone  2008年「活力あるユビキタスネット社会の実現」 Microsoft Azure Android  2009「日本復活になぜ情報通信が必要なのか」 http://bit.ly/1n66E07
  9. 9. 丸山の「ユビキタス論」へのコメント 2010年4月マルレク「日本のクラウド」  それは、平面上にアモルファスに広がる構造を欠 いたネットワーク。そして、それは、ネットワークや デバイスやチップの遍在でしかない。  クラウドとモバイルデバイスは、ネットワークに、 ネットワークの背骨ともいうべき、明確な垂直構造 をもたらす。そうした視点を欠く。  我々にとって重要なのはネットワーク自身の遍在 ではなく経済活動と人間のコミュニケーションと情 報共有の担い手としてのネットワークの遍在であ る。Human Centric Sensor Network http://bit.ly/1n66E07
  10. 10. SNS・クラウドの基本構造:情報の涌 き出し口としての個人(+マシン) Server Centric P2P
  11. 11. Cyber-Physical Systemsとは何か
  12. 12. Cyber-Physical Systemsとは何か?  Cyber-Physical Systems(CPS)とは、コン ピュータの計算能力と物理的なシステムの能力 が結びつけられて両者がしっかりと協調するシス テムである。  組込み系を中心としたリアルタイムの処理技術と、 機械の制御を中心とするディジタル・アナログの ハイブリッド技術の二つが合流して生まれた。  2006年にアメリカのNSFが大学や研究機関に Cyber-Physical Systems研究に大規模な資 金提供を始めて、全世界にこのコンセプトは広 まった。
  13. 13. CyberとPhysicalの違い  Cyber-Physical Systemsのコンセプトで重要 なことは、コンピュータやネットワークのプログラ ムを中心とするCyberな世界と、現実の機械を中 心とするPhysicalな世界が、まったく異なる原理 でドライブされているという認識である。  Cyberの世界は、論理的・数学的な「正しさ」が基 本原理。その意味では、その原理は抽象的なも の。一方、Physicalな世界を動かしているのは、 最終的には、物理法則。それは、具体的で現実 的なもの。Cyber-Physical Systemsは、この 異なる二つの世界が結びついたシステム。
  14. 14. 単純なCyber-Physical Systemの図式 Physical system Cyber Physical CSPは、Physical  Cyber とCyber  Physical の二つのパスを持つことに留意しよう。
  15. 15. 抽象化した Cyber-Physical Systemsの図式 数学的原理Cyber World Physical World 物理法則
  16. 16. CPSとIoP  CSPとIoTのコンセプトは、共通部分を持つ。ただ、 この二つのコンセプトには、違いも存在する。  IoTは、今日では、「多数のデバイスやセンサー が、(インター)ネットにつながること」と理解される ことが多く、また、そこから発生するビッグデータ の処理にも関心が向けられる。  CSPでは、関心は、コンピュータによる物理系の リアルタイムの制御にも置かれる。インターネット 接続を必ずしも前提としない自律型のロボットや、 3Dプリンターは、CPSの一つの例。
  17. 17. ビッグデータ論の特徴 — PhysicalからCyberへ  IoTでは、無数のセンサーから沸き出す巨大な情 報「ビッグデータ」の処理が中心的な課題になると いう議論がよくある。そうした処理が必要な場合 が存在し、それが技術的にチャレンジングな課題 であるのは、確かである。  ただ、物理的な世界から発した情報が、全て一カ 所にまとめられ、情報として処理されるというイ メージは、少し狭いとも思う。なぜなら、そこでは、 PhysicalからCyberへと、情報が一方的に流れ るだけだけからである。
  18. 18. 単純化した IoTとビッグデータの図式 Cyber World Big Data Physical World
  19. 19. 3Dプリンターとロボット — CyberからPhysicalへ  CyberからPhysicalの情報の流れを代表する例 は、何になるのだろう?  現実を変えるという意味では、我々が用いる道具 や機械は、全て、そうした役割を持つ。ただ、多く の道具や機械は、人間が直接にコントロールして いる。  人間ではなくコンピュータによって制御される機械 が、CyberからPhysicalの情報の流れの担い手 になるというのなら、すぐに思いつくのは、3Dプリ ンターやロボットである。
  20. 20. 単純化した ロボットや3Dプリンターの図式 Cyber World Control Physical World
  21. 21. PhysicalとCyberの相互作用の 発展段階を考える  IoTの最初期には、Thingsは単なるモノ(に付け られたRFIDタグ)だったので、CPの作用は望 むべきも無かった。ThingsがSensorsになって も、こうした事情はさして変わらない。  このレベルでは、センサー・レベルのIoTと3Dプリ ンター/ロボットは、情報の流れに関して言えば、 「相補的」な関係にある。  Things(こうした言い方が妥当なものか議論の余 地がある)が、センサーを備えたアクティブ・デバ イスになったとき、Cyber-Physical Systemsの 重要性が、もっと明らかになる。
  22. 22. Cyber-Physical Systemsの歴史 での、重要な出来事 ここでは、Cyber-Physical Systemsの歴 史をふりかえって、いくつかの重要な出来事を ピックアップしてみよう
  23. 23. Cyber-Physical Systemsの コンセプトの始まり Cyber-Physical Systemsのコンセプトを始 めて打ち出したのは、アメリカのNSFである。 2006年のことである。
  24. 24. NSF Workshop On Cyber- Physical Systems 2006/10/16-17 「Cyber-physical systemsは、インターネッ トが、我々人間が互いに関係しあうスタイルを 変化させたのと、丁度同じように、我々と物理 的世界との関係を変化させて行くだろう。」 http://varma.ece.cmu.edu/CPS/
  25. 25. http://varma.ece.cmu.edu/CPS/Presentations/Zhao.pdf
  26. 26. アメリカの国益にかなう 基礎研究にフォーカスする 境界横断的 なんでもが、CPSなのではない!
  27. 27. 2006年のWorkShopAcademics Panel Sessionの冒頭で Janosが、プレゼンをしている http://varma.ece.cmu.edu/CPS/Presentations/Panel-1/Janos-Sztipanovits.pdf
  28. 28. コンピュータ・システムと 物理的なシステムが 交わる領域 数学的領域 物理法則
  29. 29. Cyber-Physical Systems (CPS) 2009/02/27 PROGRAM SOLICITATION NSF 08-611 http://www.nsf.gov/pubs/2008/nsf08 611/nsf08611.htm
  30. 30. Synopsis of Program:  Cyber-Physical Systemsという術語は、コン ピュータ上のリソースと物理的なリソースの間の 強い結合と協調をさしている。  我々は、未来のCyber-Physical Systemsは、 今日、我々が、適合性、自律性、効率性、機能性、 信頼性、安全性、可用性といった言葉で表すもの を、はるかに超えて進むだろうと展望している。
  31. 31. Cyber-Physical Systemsでの研究の前進は、我々の 世界を次のようなシステムを持つものに変えることを約束 している。  より高速に反応するシステム(自律的な衝突回避シス テム等)  より精密な動作を行うシステム(ロボットによる外科手 術、ナノ・スケールの工作機械等)  危険で近づけない環境での作業システム(捜索と救出、 消火作業と探索)  大規模で分散したものの協調を行うシステム(交通制 御の自動化等)、高度に効率的で(正味のエネルギー を消費しないビル等)  人間の能力を増大し社会福祉を拡大するシステム(介 護支援技術、いつでもどこでも、健康状態のモニタリン グと医療サービスの提供を可能とするシステム)
  32. 32. NFSのCyber-Physical Systemsの 取り組みに対するドイツの批判的評価 「アメリカでは既に2006年から、NSFが、 Cyber-Physical Systemを、最重要な研究 分野として位置づけていた。 しかしながら、CPSを、特に製造業の分野で 利用するという点に関しては、実際には、ほと んど何もなされなかった。」 “Indusrie 4.0” 文書より
  33. 33. Advanced Manufacturing Partnership 設立の呼びかけをするオバマ大統領 2011年6月
  34. 34. 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
  35. 35. オバマ演説 「アメリカで発明しアメリカで製造する」  “本日、私は、我々の全て-- 私的企業・大学・政 府機関-– に、アメリカ製造業のルネッサンスを スパークさせ、我が国の製造業が世界のいかな る国とも競争するために必要な最先端のツール を開発するのを助ける為に、一緒になるよう呼び かける。... これらの重要な投資によって、我々は、合衆国が 「ここで発明し、ここで製造する」国にとどまり、ア メリカの労働者に、高品質・高賃金の仕事を作り 出すことを保証する事が出来る” http://www.whitehouse.gov/the-press-office/2011/06/24/ president-obama-launches-advanced-manufacturing-partnership
  36. 36. 2012年NNMIIの設立  2012年7月、AMPは16の勧告をレポートする。 その中には、”National Network of Manufacturing Innovation Institutes (NNMII)” の設立が含まれていた。  NNMIIは、官民連携組織で、アメリカの企業の国 際的競争力を高め、アメリカの製造施設への投 資を増加させる為に、「優れた製造技術の地域の ハブ」になる事が期待された。
  37. 37. オバマ演説 “Made in America”  “我々は、地域を助ける為に、その地域を、世界 の先端技術の仕事のセンターに変える事を助け る為に、進んで一緒にパートナーを組もうとする 企業と大学を求めている。 というのも、我々は、製造業の次の革命が、 「Made in America」になる事を望んでいるから だ。" -- President Obama, May 9, 2013 http://manufacturing.gov/nnmi_overview.html
  38. 38.  2013年度予算では、advanced manufacturingに対する研究開発予算は、 19%増えて22億ドル(2,200億円)に。  この予算で、National Institute of Standards and Technology (NIST)は、 国内の製造業に研究施設とノウハウを提供する 施策に1億ドル(100億円)を支出。  NISTは、またAdvanced Manufacturing Portal を運営している。これは、AMIの勧告に 基づいたもの。
  39. 39. “Recommendations for implementing the strategic initiative INDUSTRIE 4.0” 2013年4月 http://www.plattform-i40. de/sites/default/files/Report_Industrie%2 04.0_engl_1.pdf
  40. 40. ”INDUSTRIE 4.0” のビジョン Cyber-Physicalへ  第一次産業革命: 機械  18世紀末の蒸気機関の導入  第二次産業革命: 電気  20世紀に始まる電気を動力とする大規模工場生産  第三次産業革命: IT  1970年代に始まり今日まで続いている、電子技術・ ITを利用した生産の自動化  第四次産業革命: Cyber-Physical  ネットワークのサイバー空間と物理的な生産の世界が 結びつく
  41. 41. Cyber-Physicalシステム:製造環境と Internet of Things and Services  ThingsとServicesのインターネットの製造環境 への導入が、第四次産業革命への道を開く。  将来、ビジネスは、Cyber-Physicalシステムの 形で、機械と倉庫と製造機能を一つに合体させる グローバルなネットワークを確立するだろう。  Cyber-Physicalシステムは、スマートマシンとス トレージと、自律的に情報を交換しそれぞれが独 立に動作を起動しコントロールする能力を持った 生産施設から構成される。
  42. 42. Cyber-Physical System (CPS)  このCyber-Physicalシステムは、製造工程、生 産工学、物質資源の利用、サプライ・チェイン、そ して、ライフサイクルの管理に含まれている産業 の全過程に対して、根本的な改良を容易にする。
  43. 43. Smart Factory : CPSの中核 スマート自動車スマート流通 Smart Factory スマートグリッドスマートビルディング スマートプロダクト CPS
  44. 44. Cyber-Physical Systemと 二重のネットワーク・システム  Cyber-Physicalシステムに組み込まれた製造 システムは、工場と企業のビジネス・プロセスに 垂直方向にネットワークで接続され、水平方向に は、注文がなされた時からロジスティックに送り出 されるまさにその時まで、リアルタイムに管理可 能な多様なバリュー・ネットワークに接続される。  それに加えて、水平・垂直双方のネットワークは、 ともに、バリュー・チェイン全体を横断した、end-to- end のエンジニアリングを可能にし、また、そ れを要求する。
  45. 45. 垂直方向のネットワーク: 工場内の統合されたネットワーク化された 製造システム
  46. 46. 水平方向のネットワーク: 多数の企業を結んだバリュー・ネットワーク
  47. 47. 水平方向のネットワーク: 多数の企業を結んだバリュー・ネットワーク それはグローバルなものかもしれない
  48. 48. end-to-end: 製品の開発・設計 から、消費者個人 へのサービスの 提供まで 生産 サービス 生産エンジニアリング 生産計画 製品のデザインと開発
  49. 49. Project Ara -- CPS開発ツールの無償提供 2014/04/15-16 Project Araは、自己をCyber-Physical System(CPS) と規定している。重要な事 は、Project Araの中心的な柱として、CPS 開発の為のツール群Metamorphosysが オープンソースの形で無償提供されている事 である。 http://www.projectara.com/
  50. 50. Project Ara Conference 2014/04/15-16 Day 2 “Metamorphosys design tools ” http://www.projectara.com/ara-developers-conference/
  51. 51. Project Ara Conference 2014/04/15-16 Day 2 “Metamorphosys design tools ”
  52. 52. 自分のモデルと その結果をどの ように組織する か? 回路をどう設計するか? Araのモジュールに収まる? 「関心の分離」は、必ずしもうまく機能しない 電波の干渉は起きないか? ソフトはうまく動くか? 動作のスピードは? 発熱しないか? Ara: Cyber-Physical システム デザインの挑戦
  53. 53. Tool Chain Metamorphosys を構成する三つのプラトフォーム  モデル統合プラットフォーム  ツール統合プラットフォーム  実行統合プラットフォーム
  54. 54. Project Araのエコシステムの基礎 モジュール開発ツールの共有  誰もが「ものづくり」のツールを持つことが出来る: オープンソースでの無償提供。  誰もが容易に使える:これらのツールは、ハード ウェア設計の専門家でなくても、Araのモジュール をデザインする事を助ける事が出来る。  誰もが簡単にデータを交換・共有出来る:グロー バルでオープンな「ものづくり」コミュニティとデー タのネットワーク・マーケットの拡大。  誰もが簡単に「ものづくり」出来る:データを3Dプ リンターにいれれば、その場で、ものが出来る。 部品の輸送コストは大幅に削減出来る。
  55. 55. 3Dプリンターによるモジュールの製造 Googleは、3Dプリ ンターの最大手3D Systemsと共同で、 2015年までに、次の ようなAraモジュール を製造する3Dプリン ターを作ろうとしてい る。
  56. 56. モジュール開発ツール、3Dプリンターを使った開発サイクル 再利用可能なAraコンポーネントをデザイン ・アプリとドライバーの開発 ・ハードウェア・モジュールの開発 Araシステムの設定と統合 ・個人向けの設定 ・変更可能 ユーザーの期待に応えながら、 安全性と操作性の基準を保証 する Araプラットフォームで定義された デザインの制約を満たしながら、 デザインツールMetamorphosys が提供するデザイン手法を利用
  57. 57. Cyber-Physical Systemsが 挑戦している課題 ここでは、Edward Leeのプレゼンに基づい て、Cyber-Physical Systemsが、どのよう な課題に挑戦しようとしているかを見てみよう。 CyberとPhysicalの統合では、「時間」の問 題が、重要な問題であることが分かる。
  58. 58. http://wwwdi.supelec.fr/fb/SeminaireLee2013
  59. 59. 地図をドリルしても 石油は出ない。
  60. 60. 我々は、モデルについては、決定論的な言明を行う ことが出来る。それから、実現されたシステムの、いく つかの特徴を推論出来る。 この推論の妥当性は、モデルの忠実さに依存する。 そして、その忠実さというのは、常に近似でしかないのだ。
  61. 61. 決定論的なモデル 同期的なディジタル論理回路
  62. 62. 決定論的なモデル 単一スレッドの命令的なプログラム
  63. 63. 決定論的なモデル 微分方程式
  64. 64. ただし、決定論的なものの組み合わせは、 非決定論的なものになる
  65. 65. 単純なCyber-Physical Systemsの図式 インターネットのプロトコルは、そのままでは、Best Effort のプロトコルであることを忘れずに。(丸山注)
  66. 66. 計算は、無時間的な命令言語で 行われる。 物理的なプラントは、常微分方程式 で、モデルが与えられる。
  67. 67. このコードは、 タイミングをコント ロールしようとしている。 しかし、本当にそうなっ ているか?
  68. 68. タイミングの振る舞いは、そのプロ グラムとハードウェア・プラットフォー ムの組み合わせで生まれてくる
  69. 69. タイミングがシステムの振る舞いに影響を与える時には、設計はもろい ものになる。ハードウェア、ソフトウェア、あるいは、環境の小さな変化が 大きな、予期しない、タイミングの変化を引き起こす。テストを、やりなおさ なければならない。
  70. 70. 重要な挑戦 タイミングは、ソフトウェアのセマンティックスの一部ではない C, C#, Java, Haskel, OCaml 等でのプログラムの正しい 実行は、何を計算するにしても、それがどれくらい時間がかか るかということとは、何の関係も無い。ほとんど全ての計算と ネットワークの抽象は、この前提の上に立っている。 プログラマーは、タイミングの振る舞いを 特定する為には、プログラミングの抽象の 外に踏み出さなければならない。 プログラマーは、依拠すべき 地図を持っていない!
  71. 71. コンピュータ・サイエンスが、タイミングを 無視してきた訳ではないが... 今日では、コンピュータにとっては、 タイミングは、単なる、パフォーマンスの 尺度にすぎない。 タイミングは、正確性の規範である必要 がある。
  72. 72. 正確性の規範 我々は、ソフトウェアに絶対的な信頼を 持つことが出来る。そこでは、ハードウェア のエラーだけが唯一の問題となる。 しかし、タイミングに関しては、そうでは ないのだ。
  73. 73. 我々が、それからコンピュータを組み立てているハード ウェアには、「正確」な計算とタイミングを提供する能力 を持っている。 同期的なディジタル論理回路図 という抽象は、トランジスターの 細かな動作を考える必要を無くす。 ... しかし、その上のソフトウェア の抽象は、タイミングの正確さを 無視している。
  74. 74. CPSの挑戦その1 我々は、プログラムの正確な実行が、サブシステム のIOで、常に、同じ(ある正確さの範囲で)時間的な 振る舞いをするように、プログラミング・モデルを変更 出来るか? 我々は、決定論的なCPSモデルを必要としている
  75. 75. CPSの挑戦その2 いかにしたら、我々は、既存の言語・ツール・方法論に よって生み出される強力な惰性を克服して、本質的な 抽象を変更するかもしれないイノベーションを可能に 出来るか? 我々は、オープン・マインドである必要がある
  76. 76. CPSにとって、まさに「時間」の概念は、微妙である 理想化された ニュートン力学 の時間概念
  77. 77. コンピュータのプラットフォームでは、t にアクセスしない。 代わりに、ローカルな時間の測定が利用される。
  78. 78. いろいろ、微妙な問題がある。時間同期? その正確性は? その表現形式は? Superdense Time? Hyperdense Time? 多形式時間? 同時性の意味論? 理想化された ニュートン力学 の時間概念
  79. 79. 重要な技術が、まさに、登場しつつある 時計同期の技術である 時計同期は、世界を変え ようとしている グレゴリー暦グリニッジ標準時IEEE 1588 1500年代 日単位 1800年代 秒単位 2000年代 ナノセカンド単位
  80. 80. GPSは、100ns単位の 正確な時間を、戸外の アクセスで、デバイスに 与えることが出来る
  81. 81. 時計同期は、次のことを可能にする  エネルギーの効率化  通信なしでさえも、協調動作が可能に  セキュリティー  リソース管理  決定論的振る舞い
  82. 82. CPSの挑戦その3 我々は、いかにしたら、現実界のリアルな時間の測定 や時間同期、また、物理的なシステムで利用されてい る工学的モデルと整合的な、時間のモデルを開発出来 るか? 我々は、時間の意味論を必要としている
  83. 83. 工学的抽象と 工学的方法論 こうしたシステムの構成要素は、異なる専門領域の専門家の もとで、多様な工学的原理に基づいて、複数のべンダーから 提供されている。、
  84. 84. 航空機用の「電力供給 システム」を考えてみよう 物理的には、  発電機  大容量リレー  配電系統  負荷機器  ...
  85. 85. 小さなサブシステムでも、実際は、巨象である
  86. 86. CPSの挑戦その4 我々は、いかにしたら、工学的原理と橋渡しをしつつ、 要求や期待を明確にする、システムの構成要素間の インターフェースを定義出来るか? 我々は、「モデル工学」の原理を必要としている
  87. 87. 四つの大きな挑戦 1. 決定論的なCPSモデル 2. 言語とツールについてオープンマインドであること 3. 時間の意味論 4. 「モデル工学」の原理
  88. 88. Cyber-Physical Systemsとして 情報システムを捉え直す 最初に見たCPSシステムの図式では、Cyber システムを、情報の世界にのみ閉じるシステ ムとして特徴付けてきた。 ただ、こうした描像も一面的なものである。 ここでは、Cyber-Physical Systemsとして、 あらためて、情報システムを捉え直してみよう
  89. 89. Cyber-Physical Systemsとして の大規模分散データベース
  90. 90. 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-globally-distributed- highly-available-database
  91. 91. Spannerでの正確な「時計」の利用  Spannerのアプローチのポイントは、「正確なタ イムスタンプ」をグローバルな規模に広がった分 散データベースのトランザクションのコントロール に使うこと。その為に、主要にはGPSを使って(場 合によっては原子時計で)、全てのマシンの「時 計」を合わせる。  グローバルな規模の分散データベースに「実時 間」の時計の時間合わせを導入するというのは、 データベースが単なるCyber空間上のシステム ではなく、Cyber-Physical Systemsとしての性 格を持つようになってきたということ
  92. 92. 大規模分散データベースとしての Spannerの特徴  第一に、データの複製の設定は、アプリによって細 かい粒度でコントロール出来る。  どのデータセンターがどのデータを持つのか  データはユーザーからどのくらい離れているか(読み込み の遅延をコントロールする)  レプリカはお互いにどれくらい離れているか(書き込みの 遅延をコントロールする)  どのくらいの数のレプリカが維持されているか(耐久性・ 可用性・読み込みのパフォーマンスをコントロールする)  データは、データセンター間のリソースの利用のバランス をとるシステムによって、動的かつ透過的にデータセン ター間を移動出来る。
  93. 93. 大規模分散データベースとしての Spannerの特徴  第二に、Spannerは、分散データベースでは実 装するのが難しい二つの特徴を持つ。  読み書きについての外的整合性  ある時点での、データベースをまたいだグローバルに 整合的な読み込み  こうした特徴は、グローバルなスケールで、たとえ 実行中のトランザクションがあったとしても、整合 的なバックアップ、整合的なMapReduceの実行、 アトミックなスキーマの更新を、Spannerに可能 とする。
  94. 94. 正確なコミット・タイムスタンプの利用  こうした特徴は、たとえトランザクションが分散して いたとしても、Spannerがトランザクションにグ ローバルに意味のあるコミット・タイムスタンプを 割り当てるという事実によって可能になった。
  95. 95. 正確なコミット・タイムスタンプの利用  このタイムスタンプは、シリアル化された順序を反 映している。それに加えて、シリアル化された順 序は、外的整合性(あるいは、それと等価だが、 線形化可能性)を満たしている。すなわち、あるト ランザクションT1が、別のトランザクションT2が始 まる前にコミットするなら、T1のコミット・タイムスタ ンプは、T2のそれよりも小さい。  Spannerは、グローバルなスケールで、こうした 保証を与えた最初のシステムである。
  96. 96. Snapshot Isolation Spannerの基本的な手法は、「スナップショット・ア イソレーション」と言われるもの。 "A Critique of ANSI SQL Isolation Levels " http://research.microsoft.com/pubs/6954 1/tr-95-51.pdf
  97. 97. Start-Timestamp  Snapshot Isolationでは、それぞれのトランザ クションは、Start-Timestampと呼ばれる、トラ ンザクションを開始した時刻のデータのスナップ ショット(コミットされた)からデータを読み込む。こ の時刻は、トランザクションの最初の読み込みの 時刻の前の時刻になる。  トランザクションのStart-Timestamp以降にア クティブになった他のトランザクションによる更新 は、このトランザクションからは見えない。
  98. 98. ReadとWrite  Snapshot Isolationの中のトランザクションは、 そのStart-Timestampからのスナップショットの データが維持可能である限り、読み込みがブロッ クされることはない。  トランザクションでの書き込み(updates, inserts, deletes)もまた、このスナップショットに 反映される。もしトランザクションが、このデータに 二度目のアクセス(reads あるいはupdates)を するなら、ふたたび、読み出される。
  99. 99. Commit-Timestamp  トランザクションT1が、コミットの準備ができた時、 それはCommit-Timestampを取得するのだが、 それは、既に存在するStart-Timestampあるい はCommit-Timestampより、大きな値を持つ。  トランザクションは、T1の実行間隔 [StartTimestamp, Commit-Timestamp] 内にCommit-Timestampを持つ他のトランザ クションT2が、T1が書き出したデータと同じデー タを書き出していない場合に限り、コミットに成功 する。
  100. 100. First-Commiter-Wins  そうでない場合、T1はアボートする。この「最初に コミットしたものが勝つ」という特徴が、更新が失 われるのを防止する。  T1がコミットされると、そのStart-Timestamps がT1のCommit-Timestampより大きい、全て のトランザクションに、その変更は見えるようにな る。
  101. 101. BigTableの トランザクション機能の強化
  102. 102. 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
  103. 103.  Googleは、2010年に、Caffein/Percolatorと 呼ばれる大きなシステム変更を行っている。この 変更以降、Googleは、Web ページのインデッ クス付けにMapReduceを使わなくなった。  その変化の中核は、タイムスタンプを利用した、 スナップショット・アイソレーションの導入による、 BigTableのトランザクション機能の強化であった。
  104. 104.  c:data データ自身を格納  c:lock コミットされていないトランザクションは、 このCellに書き込む。PrimaryLock の場所を含んでいる。  c:write コミットされた現在のデータ。 データのタイムスタンプを格納。  c:notify ヒント: observerが走る必要がある かもしれない  c:ack O Observer “O”が走った。最後に 成功した実行のタイムスタンプを格納。
  105. 105.  初期状態: Joeの口座には2ドル、Bobの口座には、10 ドルが、はいっている。  bal:writeに、データのタイムスタンプが書き込まれること によって初めて、そのデータは外部から見えるようになる。  BobからJoeへ、7ドル送金するというトランザクションを考 えよう。
  106. 106.  送金のトランザクションは、Lockカラムに書き込むことで Bobの口座の残高をロックすることから始まる。このロック は、このトランザクションのprimaryである。  このトランザクションは、また、その開始タイムスタンプ7 にデータを書き込む。Bobのdataカラムに3ドルが書き込 まれる。ただし、この変化は、まだ外からは見えない。
  107. 107.  トランザクションは、次にJoeの口座をロックして、ふたた び開始タイムスタンプ7に、Joeの新しい残高9ドルを書き 込む。  このロックは、このトランザクションのsecondaryである。 primaryロック(”Bob”行の”bal”カラム)への参照を含ん でいる。クラッシュでこのロックが立ち往生して、トランザク ションがロックを解消したいと思った時、このロックの解消 を同期するためにprimaryの場所が必要になる。
  108. 108.  トランザクションは、コミットのポイントに到達する。  primaryロックを消して、それをコミットタイムスタンプと呼 ばれる新しいタイムスタンプ8の下で、新しい書き込みレ コードと置き換える。この書き込みレコードは、データが格 納されているタイムスタンプへのポインターを含んでいる。  これ以降、”Bob”行の”bal”カラムを読むものは、値3ド ルを見ることになる。
  109. 109.  トランザクションは、secondary セルに書き込みデータを 追加し、ロックを消去することで完了する。  これ以降、”Joe”行の”bal”カラムを読むものは、値9ドル を見ることになる。  この例の場合には、ただ一つのsecondary Joeがあるだ けである。
  110. 110. Webスケールの分散トランザクション の「存在証明」  Googleは、この技術を「Webスケールの分散ト ランザクションの「存在証明」」と呼んでいる。  "Incrementally Indexing the Web with Percolator" https://docs.google.com/presentation/d/ 1gKD4FbaUIGtoimP6- ZB0iiW8V0KZt8fVET-Cfu5KiG8/ present#slide=id.i0
  111. 111. SpannerでのPaxosの利用 Spannerのもう一つの大きな特徴は、Paxos の利用である。
  112. 112. 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
  113. 113. Spannerの階層構造 Universe – Zone - Spanserver
  114. 114. Spannerの階層構造 Universe – Zone - Spanserver  ユニバースは、Spannerのシステム全体である。  Spannerのユニバースは、一群のゾーンで組織されてい る。それぞれのZoneは、大まかにいって、BigTableの サーバーに相当するものである。  ゾーンは、一つのゾーン・マスターと、百から数千の間の スパンサーバーを持っている。前者は、スパンサーバーに データを割り当てる。後者は、データをクライアントにサー ビスする。  ユーザーのデータに割り当てられたスパンサーバーの場 所を特定する為に、そのゾーンのロケーション・プロキ シーが利用される。
  115. 115. Spanserverのソストウェア・スタック  スタックの一番下では、スパンサーバーが、100 個から1000個の間のタブレットと呼ばれるデータ 構造のインスタンスに責任を持っている。  タブレットは、BigTableのタブレットという抽象と 同様のもので、その中では、次のようなマッピング のバッグを実装している。 (key:string, timestamp:int64) → string
  116. 116. Spanserverのソストウェア・スタック  Bigtableとは異なって、Spannerは、タイムスタ ンプをデータに割り当てる。ここが、Spannerが キー・バリュー・ストアよりは、マルチ・バージョン・ データベースにずっと似ている重要なポイントで ある。  複製をサポートする為に、それぞれのスパンサー バーは、それぞれのタブレット上に、一つの Paxos状態マシンを実装している。
  117. 117. レプリカ群がPaxosグループを形成  一群のレプリカが、Paxos グループを形成する。  Paxos状態マシンは、マッピングのバッグ (key:string, timestamp:int64) → string のレプリカを整合的に実装するのに利用されてい る。それぞれの複製のキー・バリュー・マッピング の状態は、対応するタブレットに格納される。  書き出しは、リーダーのPaxosプロトコルから開 始されなければならない。読み出しのアクセスの 状態は、十分更新されたどのレプリカの下にある タブレットからでも直接に取得出来る。
  118. 118. SpanserverのLock Table  リーダーである全てのレプリカのスパンサーバー は、コンカレンシーのコントロールを実装する為の ロック・テーブルを実装している。  ロック・テーブルは、ツー・フェーズ・ロッキングの 為の状態を含んでいる。それは、一連のキーを ロック状態にマップする。  ロック・テーブルを効率的に管理する上で、長い 期間、生き続けるリーダーを持つことは、本質的 に重要であることに注意。Spannerのサーバー のリースは、10秒と長い
  119. 119. Txn managerのスキップ  もしトランザクションが、一つのPaxosグループを 含んでいるだけなら(大部分のトランザクションの 場合)、それは、トランザクション・マネージャをバ イパス出来る。というのは、ロック・テーブルと Paxosが一緒になって、トランザクションの保証を 提供するからである。
  120. 120. Paxos Groupをまたいだ調整  もしトランザクションが一つ以上のPaxosグルー プを含んでいたら、これらのグループ・リーダーが ツー・フェーズ・コミットの調整役を演ずる。  参加グループの一つが、調整役に選ばれる。そ のグループの参加者のリーダーは、調整役リー ダーと呼ばれ、グループのスレーブは、調整役ス レーブと呼ばれる。  それぞれのトランザクション・マネージャの状態は。 直下のPaxosグループに格納される。(それ故、 複製される。)
  121. 121. 大規模自律分散というアプローチ  「Spannerは、もっとも高い抽象のレベルでは、 全世界に広がっているデータセンター内の沢山の Paxos状態マシン群をまたいで、データを分割し たデータベースである。」  Spannerは、単なる「大規模分散システム」では なく、それぞれが自律的な耐障害性を備えた「大 規模自律分散システム」なのである。それによっ て、次のことが可能となった。  「Spannerは、数百のデータセンターをまたいだ 数百万のマシンと、数兆行のデータベースにス ケールアップするように設計されている。」
  122. 122. Cyber-Physical Systemsとして のネットワーク・システム
  123. 123. 「ギルダーの予想」  「ネットワークがコンピュータの内部バスと 同じぐらい早くなれば、マシンは、特定の目 的を持ったデバイスのあつまりへとネット ワーク上で分解するだろう。」  ただ、このように、ローカルとリモートの区別が、 ネットワークのスピード・アップによってなくなるだ ろうという考え方には、強い異論がある。
  124. 124. ローカルとリモートを峻別する立場  今から20年前にこうした問題は、はっきりと提起 されていた。彼らの認識は、ネットワーク管理をし ている人なら誰でも知っている、Leaseの導入と して、結実する。Jim Waldoは、“A Note on Distributed Computing” http://www.eecs.harvard.edu/~waldo/R eadings/waldo-94.pdf で、次のように述べる。
  125. 125. “A Note on Distributed Computing” Jim Waldo et al. http://www.sunlabs.com/techrep/1994/sml i_tr-94-29.pdf ローカルなプログラミングとリモートなプログラ ミングを、はっきりと区別すべきだという立場
  126. 126. ネットワーク上のシステムで相互作用するオブジェ クトは、単一のアドレス空間で相互作用するオブ ジェクトとは、本来的に異なったやり方で取り扱わ れるべきであると、我々は主張している。 こうした違いが要求されるのは、ネットワーク上の システムでは、プログラマは遅延の問題を意識せ ねばならず、異なったメモリーアクセスのモデルを 持ち、並列性と部分的失敗(partial failure)の問題 を考慮にいれなければならないからである。
  127. 127. 我々は、ローカルとリモートのオブジェクトの違いを 覆い隠そうと試みる、沢山のネットワーク・システム を見てきた。そして、これらのシステムは、頑健さと 信頼性という基本的な要請を満たすことに失敗し ていることを示そうと思う。 こうした失敗は、過去においては、構築されたネッ トワーク・システムの規模の小ささで、隠蔽されて いた。しかしながら、近未来に予想される、企業規 模のネットワークシステムにおいては、こうした隠 蔽は不可能となるであろう。
  128. 128. Formulated in 10 Years Ago Network is Homegenous added by Gosling
  129. 129. Cyber-Physical Systemsとして のクラウド・システム
  130. 130. クラウド技術の特徴 ScalabilityとAvailability  コモディティ化したマシンを集積するスケールアウ トの手法に基づくクラウド技術は、Scalabilityと Availability両方の担保を中核とする。  そこでの技術的飛躍のポイントは、「マシンは、例 外的に、あり得ない不運がかさなってクラッシュす るのではなく、いつでも、例外なしに壊れるもの だ。」という認識にある。  かつて、GoogleのPlatforms ArchitectのBen Jaiは、次のように語ったことがある。
  131. 131. 「信頼性の高いハードは、ソフトウェア 技術者を怠け者にする。」  「3-year MTBFだとしても, 1000台のうち一台 は、毎日だめになるという計算になる。最小の Googleのアプリケーションでも、2000台のマシ ンを必要とする。こうした障害をソフトでどう対応 するかデータの多重化と冗長化は、この規模では どうしても必要となる。」  「だから、なぜ、高価な信頼性の高いハードのこと で思い悩むのか? 信頼性の高いハードは、ソフト ウェア技術者を怠け者にする。障害に強いソフト ウェアが、安いハードを役に立つものに変えるの だ。」
  132. 132.  こうした認識は、ネットワークで結ばれた大規模な コンピューター・システムが、それ自身、純粋に Cyberなシステムではなく、基本的には Physicalな原理に左右されるCyber-Physical Systemsであることを意味している。それは当然 のことだとも思う。ただ、20年前のJim Waldoの 警告にあるように、我々は、時に、それを忘れるこ とがある。
  133. 133. Cyber-Physical Systemsと 量子コンピュータ
  134. 134. Simulating Physics with Computers 1982年Richard P. Feynman http://www.cs.berkeley.edu/~christo s/classics/Feynman.pdf
  135. 135. 自然をシミュレートするコンピュータ  コンピューターが、正確に自然と同じように振る舞 う、正確なシミュレーションが存在する可能性につ いて話そうと思う。それが証明されて、そのコン ピュータのタイプが先に説明したようなものである なら、必然的に、有限の大きさの時空の中で起き る全てのものは、有限な数の論理的な操作で正 確に分析可能でなければならないことになるだろ う。
  136. 136. 量子論的システムは、古典的なコン ピューターでシミュレートされるか?  量子論的なシステムは、古典的な万能計算機で、 確率論的にシミュレートされるだろうか? 別の言 い方をすれば、コンピューターは、量子論的なシ ステムが行うのと、同じ確率を与えるだろうか? コンピューターを今まで述べてきたような古典的 なものだとすれば(前節で述べたような量子論的 なものではないとすれば)、また法則はすべて変 更されないままで、ごまかしもないとすれば、答え は明らかにノーである。
  137. 137. 量子コンピュータ -- 万能量子シミュレーター  それは、新しいタイプのコンピューター、量子コン ピューター?で可能になるだろう。 私が理解する限りでは、それは量子論的なシステ ムによって、量子コンピューターの要素によって、 シミュレート出来るようになることは、いまや、明ら かになった。それはチューリング・マシンではない。 別のタイプのマシンである。
  138. 138. Quantum theory, the Church- Turing principle and the universal quantum computer 1985年David Deutsch http://www.cs.berkeley.edu/~christo s/classics/Deutsch_quantum_theory. pdf
  139. 139. Church-Turing-Deutche Thesis  Church-Turingの仮説の基礎には、暗黙の物 理学的主張があることが考察される。 この物理学的主張は、次のような物理学的原理 として、明確に表現することが出来る。 「有限な方法で実現可能な物理システムは、有限 な手段によって操作される万能計算機械のモデ ルで完全にシミュレート可能である。」  古典物理学と万能チューリング・マシンは、前者 は連続的で後者は離散的であるので、この原理 には従っていない。
  140. 140. 万能量子コンピューター  チューリング・マシンのクラスの量子論的一般化 である計算機械のクラスが記述され、量子論と、 この「万能量子コンピューター」が、先の原理と両 立可能であることが示される。  この万能量子コンピューターをまねた計算機械は、 原理的には、構築可能である。そしてそれは、い かなるチューリング・マシンによっても再生不可能 な、多くの目覚ましい特徴を持つであろう。
  141. 141. 自律分散というアプローチ 現実世界の情報を全て一カ所に集約するとい うアプローチに対しては、「自律分散」という、 別のアプローチもあり得る。
  142. 142. Cyber-Physical Systemsと 自律型のシステム  多くの電気機器は、電力さえ供給されれば、一定 の役割を果たすことが出来る。  情報システムであっても、ネットワーク接続が必 須ではないものがある。インターネット普及以前 の「パソコン」「ワープロ」がその一例だ。  ロボットも、全てが外部からコントロールされて動 作するのでは、操り人形と大差ない。ロボットで重 要なのは、自律的に判断し動作する能力である。  IoTのコンセプトには、こうした自律型のシステム は含まれないが、Cyber-Physical Systemsは、 これらを含んでいる。
  143. 143. 自律分散システム  自律分散システムというのは、相対的な自律性を 持つ部分システムがネットワークで結ばれて、シ ステム全体が協調動作を行うシステムである。  情報の流れで言えば、すべての情報を一カ所に まとめるのではなく、システムの構成要素の階層 的な「役割」の分担に基づいて、局所的に処理出 来る情報は全てローカルに処理する「自律性」を それぞれの構成要素に与え、ローカルな範囲で は処理が閉じない種類の情報のみを、上位階層 に伝えるというモデルである。
  144. 144. 自律性は、相対的なものである  「自律分散」の考え方は、ある種のデータの一カ 所への集中を排除しない。Amazonの倉庫ロ ボットkivaでは、どこに何があり、どこで何をすべ きかは、おそらく中央のコピュータが制御している。 ただロボットの動きの多くは、ロボットが自律的に 制御している。 https://www.youtube.com/watch?v=lWs MdN7HMuA
  145. 145. データの集約・集中処理と 自律分散  もっとも、検索のように、データ集約型でしか処理 出来ないものもある。ただ、この点では、Google のCaffeine / Percolator でのBigTableのトラ ンザクション機能の強化から、Spannerへの「進 化」は、興味深いものである。  「Spannerは、もっとも高い抽象のレベルでは、 全世界に広がっているデータセンター内の沢山の Paxos状態マシン群をまたいで、データを分割し たデータベースである。」
  146. 146. データの集約・集中処理と 自律分散  こうした定式化は、データ集約型のシステムにお いても、システムの拡大にともなってシステムの 整合性を維持する為には、自律分散の考えに基 づいたシステム設計が、重要であることを示唆し ている。
  147. 147. 自律分散のモデルとそのメリット 自然界でも人間の社会でも、情報を扱う複雑 なシステムの多くは、自律分散のスタイルを とっているように見える
  148. 148. 自律分散のモデル– 生命・知能  すべての細胞にはDNAのフルセットが含まれて いるのだが、細胞は、その情報の一部のみを利 用して特定の機能を持つ細胞に分化する。分化 した細胞は、器官を構成し、それが他の器官と協 調しつつ自律的な役割を果たすことで、全体とし ての生命活動が維持される。  人間の脳もそうだ。脳内には無数の脳細胞があ るのだが、それには特定のタイプがあり、特定の 役割を担っている。それが特定のパターンで結び つくことによって、認識・感情・知覚・行動が生ま れる。
  149. 149. 自律分散のモデル– 社会的昆虫  蟻や蜂のような、社会的な昆虫の「社会」も、自律 分散のモデルと言える。  女王蜂は、働き蜂がどこにいて何をしていてなに を見ているかを把握する必要はない。女王蜂も働 き蜂も「本能」に基づいて自律的に行動する。そ れでも、蜂の社会システムはうまく機能している。  それは、女王蜂・働き蜂の「本能」の実体である、 それぞれに埋め込まれた遺伝子情報が、そのよ うにプログラムされているからである。
  150. 150. 自律分散のモデル– 人間の社会  人間の社会も、自律分散のシステムと言える。特 に、市場を通じた経済活動は、基本的には、自由 意志を持つとされる個人・法人の自律的な活動に 基づいている。  生産・流通・消費の過程が、経済のネットワークを 構成する。  Industrie 4.0の「水平方向のCyber-Physical Systems」は、自律分散型のシステムになる。
  151. 151. 自律分散のメリット  データ集約型のモデルは、まさにその点において、 システムの脆弱性が生まれる可能性がある。そ れに対して、自律分散型のモデルは、Single Point of Failure を持たないので、より頑健なシ ステムを構築することが出来る。  データ集約型のモデルでは、情報の爆発的増大 が起こりえる。自律分散型のシステムでは、無用 な情報の爆発を防ぐことが出来る。
  152. 152. これから考えるべきこと
  153. 153. 新しいネットワーク・メディアの成立  コミュニケーションと情報共有、自由時間の享受 への欲求は、現代のIT技術の普及をドライブする 最大のものである。  クラウドとクラウド・デバイスを骨組みとする、新し いネットワーク・メディアは、こうした欲求にドライ ブされて、来る10年の間には、世界人口のほと んど全てを包摂するものへと発展するだろう。  同時に、新しいネットワーク・メディア上のCyber 空間だけに、我々の生活やITの可能性が閉じる ことは無いという展望も重要なものだ。
  154. 154. CyberとPhysical  情報だけのCyberな世界に閉じること無く、また、 道具や単純な機械だけのPhysicalな世界でもな く、CyberとPhysicalが相互作用するCyber- Physical の世界に、ITの世界は広がって行くだ ろう。  IoT / Big Data は、Physical  Cyber の情 報の流れを、Robot / 3D Printerは、Cyber  Physical な現実世界を変える働きの代表例であ る。
  155. 155. 新しい経済のネットワーク  Cyber-Physical Systemsが新たな役割を果た すことを期待される、もっとも広大な開拓地は、現 実世界の経済が有力な候補である。製造・流通・ 消費の全過程を包摂する、効率的で持続可能な、 新しい経済のネットワークが模索されるだろう。  とりわけ、ロボットや3Dプリンターの導入による、 製造の現場と労働の変化が、新しい経済のネット ワークの形成に、おおきなインパクトを与えるだろ う。
  156. 156. 集中と分散  新しいネットワーク・メディアと新しい経済のネット ワークの形成の中で、データと処理の集中は、さ らに進むだろう。必ずしも、Big Brotherのような ディストピアを想像する必要は無いかもしれない。 それは処理コストを低減し、利便性を高める側面 を持つ。それらは、適切に管理されさえすれば、 低料金の社会インフラ化して行く可能性は高い。  同時に、ハードウェアの進化と低価格化により、 処理の自律分散化も、さらに進むだろう。それは、 システムを全体として、頑健なものに変える。
  157. 157. 未来展望-- 生産の自律分散化  おそらく、21世紀の最大の課題は、新しいネット ワーク・メディアと、新しい経済のネットワークのも とで、生産のスタイルを、持続可能な成長を保証 し、環境にインパクトを与えない自律分散型のモ デルに変革出来るのかというところにある。  明確なのは、それを推進する最も大きな力は、IT とその更なるイノベーションだということである。
  158. 158. マルゼミ予告「Cyber-Physical Systemsと自律分散システム」  来月8月1日開催のマルゼミは、今回のマルレ クを受けて、3Dプリンターとロボットを取り上 げます。是非、ご参加ください。  日時: 8月1日(金) 19:00~  場所: 秋葉原カスペルスキー社会議室  登壇者: 丸山不二夫マルレクふりかえり 大迫幸一「3Dプリンタの未来」 中川友紀子「ロボットのいる生活とIT」
  159. 159. Windows AzureのAvailability Windows Azureでは、File Systemのレベル ではなくData StorageのレベルでReplicaが 導入されている。また、Fail-overについて、いく つかのシナリオが用意されているので、それを 見ておこう。
  160. 160. MS Azureのデータノードの多重化  データの読み込みは Primaryノードからの 読み込みで完了する  データの書き出しは Secondaryノードにコ ピーされる。この際、多 数決原理(quorum)に 従う。 P Ack Ack S S S S Write Write Write Write Ack Ack Read Value Write Ack
  161. 161. MS Azureのデータノードの再構成  再構成のいくつかのタイプ  Primary が故障する  故障したSecondaryを除く  修復したreplicaの追加  新しいSecondaryの準備  前提  故障の検出  リーダーの選挙 こけた! X P B S P S S XS 死んだ! これらの故障が重複して起き ても安全なように設計する
  162. 162. 経済活動と人間のコミュニケーションと情報共有の 担い手としての インターネットとデバイスの「遍在」 経済活動と人間のコミュニケーションと情報共 有の担い手としての、インターネットとデバイ スの「遍在」の過程は、現在も進行中である。 その先頭を走っているのは、Gang of Four 達で、焦点はNext Billionsのマーケットであ る。
  163. 163. Smarter Planet
  164. 164. Internet of Everything
  165. 165. Windows for the Internet of Things will be free
  166. 166. ビッグデータ論の特徴 ビッグデータ論とは、PhysicalからCyberへ、 あるいは、CyberからCyberへ、情報は流れ、 その情報は、最終的には一カ所へ集約され利 用されるという描像に他ならない
  167. 167. ビッグデータ論の特徴 — PhysicalからCyberへ  IoTでは、無数のセンサーから沸き出す巨大な情 報「ビッグデータ」の処理が中心的な課題になると いう議論がよくある。そうした処理が必要な場合 が存在し、それが技術的にチャレンジングな課題 であるのは、確かである。  ただ、物理的な世界から発した情報が、全て一カ 所にまとめられ、情報として処理されるというイ メージは、少し狭いとも思う。なぜなら、そこでは、 PhysicalからCyberへと、情報が一方的に流れ るだけだけからである。
  168. 168. ビッグデータ論の特徴 — PhysicalからCyberへ  それは、世界で起きていることを、全て知りうる「全 智」の存在を考えることに似ている。ただ、世界の 全てを観照的に知るだけなら、彼は、「全能」とはい えない。世界に働きかけ、世界を変えてゆく「手足」 を持ってはじめて、知り得たことが役に立つ。  Physical からCyberに情報が流れるだけでなく、 CyberからPhysicalへの情報の流れが、現実を変 えてゆく力を持つCyber-Physical Systemsの方 が、強力なのは確かだと思う。もっとも、両方の能力 を持つシステムは、人間以外には、まだ存在しない ようにも見える。
  169. 169. ビッグデータ集約の問題  現実世界の情報を、一カ所に集約したいという 「ビッグデータ」論を、別の角度から考えてみよう。  機械の助けを借りれば、我々がハンドルしうる情 報の総量は、確実に増加する。ただ、コストの問 題を度外視したとしても、我々人間の「判断」に必 要な情報の量には、自然な限界がある。
  170. 170. ビッグデータ集約の二つの目的  「ビッグデータ」技術というのは、一方では、検索 やBIシステムが典型的にそうなのだが、ビッグ データから、人間が利用可能な、スモールデータ を抽出する技術である。  「ビッグデータ」技術は、他方では、金融の世界で のhigh-frequency tradingや、広告の世界で のreal-time biddingのように、人間の介在なし に、機械が人間に代わって「意思決定」を行う技 術である。
  171. 171. 3Dプリンターとロボット — CyberからPhysicalへ  センサー・ネットワーク+ビッグデータ処理が、 PhysicalからCyberへという情報の流れの代表 的な例だとすると、CyberからPhysicalの情報の 流れを代表する例は、何になるのだろう?  現実を変えるという意味では、我々が用いる道具 や機械は、全て、そうした役割を持つ。自動車 だって、我々の物理的な位置を変えることで、現 実を変える。ただ、多くの道具や機械は、人間が 直接にコントロールしている。
  172. 172. 3Dプリンターとロボット — CyberからPhysicalへ  人間ではなくコンピュータによって制御される機械 が、CyberからPhysicalの情報の流れの担い手 になるというのなら、すぐに思いつくのは、3Dプリ ンターやロボットである。
  173. 173. Google X : Auto Driving Car
  174. 174. 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
  175. 175. 1 Introduction I Modeling Dynamic Behaviors 2 Continuous Dynamics 3 Discrete Dynamics 4 Hybrid Systems 5 Composition of State Machines 6 Concurrent Models of Computation II Design of Embedded Systems 7 Embedded Processors 8 Memory Architectures 9 Input and Output 10 Multitasking 11 Scheduling
  176. 176. III Analysis and Verification 12 Invariants and Temporal Logic 13 Equivalence and Refinement 14 Reachability Analysis and Model Checking 15 Quantitative Analysis IV Appendices A Sets and Functions B Complexity and Computability
  177. 177. 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-globally-distributed- highly-available-database
  178. 178. Spannerとは何か?  Spannerは、スケーラブルで、マルチ・バージョン、 グローバルに分散し、レプリカの同期を行う、 Googleのデータベースである。それは、グロー バルなスケールでのデータの分散と外的整合的 な分散トランザクションをサポートした、初めての システムである。  もっとも高い抽象のレベルでは、それは、全世界 に広がっているデータセンター内の沢山のPaxos 状態マシン群をまたいで、データを分割したデー タベースである。
  179. 179. Spannerとは何か?  Spannerは、データの量やサーバーの数が変化 するに応じて、マシン間でデータを再分割する。そ れは、マシン間で(データセンター間でさえ)、自動 的にデータを移動して、負荷のバランスを取り、マ シンの失敗に対応する。  Spannerは、数百のデータセンターをまたいだ数 百万のマシンと、数兆行のデータベースにスケー ルアップするように設計されている。
  180. 180. Spannerと時間同期  こうした特徴は、たとえトランザクションが分散して いたとしても、Spannerがトランザクションにグ ローバルに意味のあるコミット・タイムスタンプを 割り当てるという事実によって可能になった。この タイムスタンプは、シリアル化された順序を反映し ている。それに加えて、シリアル化された順序は、 外的整合性(あるいは、それと等価だが、線形化 可能性)を満たしている。
  181. 181. Spannerと時間同期  すなわち、あるトランザクションT1が、別のトラン ザクションT2が始まる前にコミットするなら、T1の コミット・タイムスタンプは、T2のそれよりも小さい。 Spannerは、グローバルなスケールで、こうした 保証を与えた最初のシステムである。
  182. 182. True Time  こうした性質を可能にした重要なものは、 TrueTime API とその実装である。このAPIは、 直接に、時計の不確実さを、あらわに示すもので ある。そして、Spannerのタイムスタンプは、実装 が提供する不確実さの範囲にディペンドしている。 もし、不確実さが大きければ、Spannerは、この 不確実さを待つ為に、スピードを落とす。  この実装は、複数の現代的な時計(GPSと原子 時計)への参照を利用することで、不確実性を小 さなもの(一般的には、10ms以下)にとどめよう とする。
  183. 183. IoP CPS 初出1999年 Kevin Ashton 2006年 NSF 構成Internet+Things Cyber+Physical 当初のターゲットThingsの情報Physical Systemsのコント ロール 現在インターネット接続の拡大と デバイスの普及 当初の担い手情報系(GoFを除く) 組込・制御・ロボット系 問題意識ナイーブな「インターネットの 拡大」 物理系の特質の重視。 二つの異なるモデル ネットワークの特性ベスト・エフォート正確なタイミング 同期・同時性の重要性 自律型システム? 自律型システムを含む 適用領域Everything Social Value Chain 今後の展望第四次産業革命
  184. 184. “A Note on Distributed Computing” Jim Waldo et al. http://www.sunlabs.com/techrep/1994/sml i_tr-94-29.pdf ローカルなプログラミングとリモートなプログラ ミングを、はっきりと区別すべきだという立場
  185. 185. ネットワーク上のシステムで相互作用するオブジェ クトは、単一のアドレス空間で相互作用するオブ ジェクトとは、本来的に異なったやり方で取り扱わ れるべきであると、我々は主張している。 こうした違いが要求されるのは、ネットワーク上の システムでは、プログラマは遅延の問題を意識せ ねばならず、異なったメモリーアクセスのモデルを 持ち、並列性と部分的失敗(partial failure)の問題 を考慮にいれなければならないからである。
  186. 186. 我々は、ローカルとリモートのオブジェクトの違いを 覆い隠そうと試みる、沢山のネットワーク・システム を見てきた。そして、これらのシステムは、頑健さと 信頼性という基本的な要請を満たすことに失敗し ていることを示そうと思う。 こうした失敗は、過去においては、構築されたネッ トワーク・システムの規模の小ささで、隠蔽されて いた。しかしながら、近未来に予想される、企業規 模のネットワークシステムにおいては、こうした隠 蔽は不可能となるであろう。
  187. 187. Google File Systemの Availability Google File SystemのAvailabilityは、基本 的には、データを蓄える役割を果たすChunk Serverを多重化(通常は三重化)することによっ て支えられている。
  188. 188. Client Master Secondary Replica A Primary Replica Secondary Replica B 1 2 3 3 3 4 5 5 6 6 7
  189. 189. Windows AzureのAvailability Windows Azureでは、File Systemのレベル ではなくData StorageのレベルでReplicaが 導入されている。また、Fail-overについて、いく つかのシナリオが用意されているので、それを 見ておこう。
  190. 190. MS Azureのデータノードの多重化  データの読み込みは Primaryノードからの 読み込みで完了する  データの書き出しは Secondaryノードにコ ピーされる。この際、多 数決原理(quorum)に 従う。 P Ack Ack S S S S Write Write Write Write Ack Ack Read Value Write Ack
  191. 191. MS Azureのデータノードの再構成  再構成のいくつかのタイプ  Primary が故障する  故障したSecondaryを除く  修復したreplicaの追加  新しいSecondaryの準備  前提  故障の検出  リーダーの選挙 こけた! X P B S P S S XS 死んだ! これらの故障が重複して起き ても安全なように設計する
  192. 192. Basically Availability データベースでの楽観的ロック データベースで、二つのクライアントが、同時に 競合する書き込みをしようとした場合に、どの ような処理が行われるのかを見てみよう。 こうした、Optimistic Lockの手法は、現在の エンタープライズ向けのシステムでも、普通に 利用されていることに注意しよう。
  193. 193. Client A Client B Version Rating 5 : Ch9, Jan-1, 3 1 : Ch9, Jan-2, 2 Entityの取得 9 : Ch9, Jan-3, 6 システムの管理するversionを Etagとして取得する
  194. 194. Entityをローカルに更新する Client A Client B Version Rating 2: Ch9, Jan-2, 5 2: Ch9, Jan-2, 4 1 : Ch9, Jan-2, 2 1 : Ch9, Jan-2, 2 5 : Ch9, Jan-1, 3 1 : Ch9, Jan-2, 2 9 : Ch9, Jan-3, 6
  195. 195. データを送ってVersionをチェックする Client A Client B 5 : Ch9, Jan-1, 3 1 : Ch9, Jan-2, 2 9 : Ch9, Jan-3, 6 If-Match: Ch9, Jan-2, 5 1 Version Rating 1: Ch9, Jan-2, 5 1: Ch9, Jan-2, 4
  196. 196. Versionが合えば、成功である Client A Client B 5 : Ch9, Jan-1, 3 2 : Ch9, Jan-2, 5 1 2 9 : Ch9, Jan-3, 6 2: Ch9, Jan-2, 5 If-Match: Ch9, Jan-2, 5 1 Version Rating 1: Ch9, Jan-2, 5 1: Ch9, Jan-2, 4 システムはVersionとデータを更新し、 Client-Aを更新する。
  197. 197. Versionが合わなければ、失敗である Client A Client B Error: 412 2: Ch9, Jan-2, 5 1: Ch9, Jan-2, 4 5 : Ch9, Jan-1, 3 2 : Ch9, Jan-2, 5 1 2 9 : Ch9, Jan-3, 6 If-Match: 1 Version Rating 1: Ch9, Jan-2, 5 1: Ch9, Jan-2, 4 1: Ch9, Jan-2, 4 1: Ch9, Jan-2, 4 システムは、Precondition failed (412) を返す。
  198. 198. Snapshot Isolation “A Critique of ANSI SQL Isolation Levels” http://t.co/2HBae9l5gK
  199. 199. Start-Timestamp  Snapshot Isolationでは、それぞれのトランザ クションは、Start-Timestampと呼ばれる、トラ ンザクションを開始した時刻のデータのスナップ ショット(コミットされた)からデータを読み込む。こ の時刻は、トランザクションの最初の読み込みの 時刻の前の時刻になる。  トランザクションのStart-Timestamp以降にア クティブになった他のトランザクションによる更新 は、このトランザクションからは見えない。
  200. 200. ReadとWrite  Snapshot Isolationの中のトランザクションは、 そのStart-Timestampからのスナップショットの データが維持可能である限り、読み込みがブロッ クされることはない。  トランザクションでの書き込み(updates, inserts, deletes)もまた、このスナップショットに 反映される。もしトランザクションが、このデータに 二度目のアクセス(reads あるいはupdates)を するなら、ふたたび、読み出される。
  201. 201. Commit-Timestamp  トランザクションT1が、コミットの準備ができた時、 それはCommit-Timestampを取得するのだが、 それは、既に存在するStart-Timestampあるい はCommit-Timestampより、大きな値を持つ。  トランザクションは、T1の実行間隔 [StartTimestamp, Commit-Timestamp] 内にCommit-Timestampを持つ他のトランザ クションT2が、T1が書き出したデータと同じデー タを書き出していない場合に限り、コミットに成功 する。
  202. 202. First-Commiter-Wins  そうでない場合、T1はアボートする。この「最初に コミットしたものが勝つ」という特徴が、更新が失 われるのを防止する。  T1がコミットされると、そのStart-Timestamps がT1のCommit-Timestampより大きい、全て のトランザクションに、その変更は見えるようにな る。
  203. 203. Formulated in 10 Years Ago Network is Homegenous added by Gosling
  204. 204. 複雑さを考える--- Complexity Quanta and Platform Definition Summary of Jim Waldo‘s Keynote at the 10th Jini Community Meeting http://www.jini.org/files/meetings/tenth/vid eo/Complexity_Quanta_and_Platform_Defin ition.mov http://www.jini.org/files/meetings/tenth/pr esentations/Waldo_keynote.pdf
  205. 205. 複雑さにおける基本的な飛躍  線形実行(SEQ) – 人生は善良でシンプルであった  マルチ・スレッド(MT) – ツールと優秀なプログラマが MTについて考えることが必要  マルチ・プロセス(MP) – カーネルの開発者だけでな く誰もが利用できる。実際には、MTの前に起きた。  マルチ・マシン(MM) 同一ネットワーク上の– マルチ・プロセスと同じではないのだが、ある人たちは、 そう考えている  信頼できないマルチ・マシンたち(MMU) – 本質的に は、Webの世界である
  206. 206. それぞれの段階を通り抜ける際、 我々は、何かを失う  マルチ・スレッドへ: 我々は、順序を失う(複数のことが同時に起こ る)。これは、難しい。なぜなら、我々は、自然 には、シーケンシャルに考えるから。  マルチ・プロセスへ: 単一のコンテキスト(すなわち、我々が信頼し うる共有コンテキスト)を失う。グローバルな状 態が、開発のあらゆるところで利用される。 (すべてをスタティックに考えよ)
  207. 207. それぞれの段階を通り抜ける際、 我々は、何かを失う  マルチ・プロセスからマルチ・マシンへ: 我々は、状態を失う。「システム」のグローバ ルな状態というのは、虚構である。興味深い 分散システムには、整合的な状態というもの は存在しない。(Lamport: http://research. microsoft.com/users/lamport/pubs/pubs.html ) 分散OSのプロジェクトは、グローバルな状態 を導入しようとしたが、大々的に失敗した。  信頼できないマルチ・マシンたちへ: 誰を信ずることが出来るか分からない難しい 状況の中で、我々は信頼を失う。
  208. 208. しかし、我々は何かを得てきた  Seq to MT : 並列処理  MT to MP : プロセスの分離(安全を与える)  MP to MM : 独立した失敗(何かまずいこと が起きても、システムの部分は生きのこる)  MM to MMU : スケール(webスケール、イ ンターネットスケール). 誰か他の人のリソース を利用せよ(あるいは、他の誰かが、我々のリ ソースを利用することを認めよ)
  209. 209. Transaction in BigTable
  210. 210.  c:data データ自身を格納  c:lock コミットされていないトランザクションは、 このCellに書き込む。PrimaryLock の場所を含んでいる。  c:write コミットされた現在のデータ。 データのタイムスタンプを格納。  c:notify ヒント: observerが走る必要がある かもしれない  c:ack O Observer “O”が走った。最後に 成功した実行のタイムスタンプを格納。
  211. 211.  初期状態: Joeの口座には2ドル、Bobの口座には、10 ドルが、はいっている。  bal:writeに、データのタイムスタンプが書き込まれること によって初めて、そのデータは外部から見えるようになる。  BobからJoeへ、7ドル送金するというトランザクションを考 えよう。
  212. 212.  送金のトランザクションは、Lockカラムに書き込むことで Bobの口座の残高をロックすることから始まる。このロック は、このトランザクションのprimaryである。  このトランザクションは、また、その開始タイムスタンプ7 にデータを書き込む。Bobのdataカラムに3ドルが書き込 まれる。ただし、この変化は、まだ外からは見えない。
  213. 213.  トランザクションは、次にJoeの口座をロックして、ふたた び開始タイムスタンプ7に、Joeの新しい残高9ドルを書き 込む。  このロックは、このトランザクションのsecondaryである。 primaryロック(”Bob”行の”bal”カラム)への参照を含ん でいる。クラッシュでこのロックが立ち往生して、トランザク ションがロックを解消したいと思った時、このロックの解消 を同期するためにprimaryの場所が必要になる。
  214. 214.  トランザクションは、コミットのポイントに到達する。  primaryロックを消して、それをコミットタイムスタンプと呼 ばれる新しいタイムスタンプ8の下で、新しい書き込みレ コードと置き換える。この書き込みレコードは、データが格 納されているタイムスタンプへのポインターを含んでいる。  これ以降、”Bob”行の”bal”カラムを読むものは、値3ド ルを見ることになる。
  215. 215.  トランザクションは、secondary セルに書き込みデータを 追加し、ロックを消去することで完了する。  これ以降、”Joe”行の”bal”カラムを読むものは、値9ドル を見ることになる。  この例の場合には、ただ一つのsecondary Joeがあるだ けである。
  216. 216. Transaction in BigTable 詳細
  217. 217. 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_には、その時点のタイムスタンプが 入れられる。6行目。
  218. 218. データの読み込み:bool Get(Row row, Column c, string* value) の働き  row中の、コンカレントなwriteを通知するロック c:lockを、過去からstart_ts_まで、チェックする。  ペンディングされたロックがあれば、クリーンを試 みて待つ。なければ、次に進む。  c:writeをチェックして、過去からstart_ts_まで にコミットされた、書き込みをみつける。なければ、 データはない。  c:writeからコミットされたタイムスタンプを取得。  c:dataから、コミット・タイムスタンプ時点での値 を読み出す。
  219. 219. 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 } 17 18 // スタート・タイムスタンプ以下の最新の書き込みをみつける。 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 }
  220. 220. 書き込み前処理:bool Prewrite(Write w, Write primary) の働き  Prewriteは、セルcをロックしようとする。競合が あるとfalseを返し、Abortする。  c:writeをチェックし、スタート・タイムスタンプの 後にコミットされたものであれば、Abortする  c:lockをチェックし、どんなタイムスタンプでもLo ckされていれば、Abortする。  c:dataに値を書き込む。  c:lockに、スタート・タイムスタンプと、primary lockの場所を書き込む。  コミットする。
  221. 221. 26 //Prewriteは、セルcをロックしようとする。競合があるとfalseを返す。 27 bool Prewrite(Write w, Write primary) { 28 Column c = w.col; 29 bigtable::Txn T = bigtable::StartRowTransaction(w.row); 30 31 // スタート・タイムスタンプの後にコミットされたものであれば、Abortする 32 if (T.Read(w.row, c+“write”, [start ts , ∞])) return false; 33 // . . . あるいは、どんなタイムスタンプでもLockされていれば、Abortする 34 if (T.Read(w.row, c+"lock", [0, ∞])) return false; 35 36 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 }
  222. 222. コミット:bool Commit() の働き  writes_ベクターの先頭がprimary、それ以降を secondariesとする。  primary、secondariesへのPreWriteが失敗 すれば、コミット失敗。  コミット・タイムスタンプを取得する。  まず、primaryをコミット  c:lockのスタート・タイムスタンプ時点での値を読み込 む。なければ、コミット失敗。  コミット・タイムスタンプのc:writeに、スタートタイムス タンプに書かれたデータへのポインターを書き込む。
  223. 223. コミット:bool Commit() の働き  コミット・タイムスタンプのc:lockを消す。  コミットする。  続いて、secondariesをコミット。secondaries の各Writeごとに、  コミット・タイムスタンプのc:writeに、スタートタイムス タンプに書かれたデータへのポインターを書き込む。  コミット・タイムスタンプのc:lockを消す。  コミット成功
  224. 224. 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 // 第二フェーズに進む
  225. 225. 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 }
  226. 226. 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(); }
  227. 227. 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-globally-distributed- highly-available-database
  228. 228. 書き込みとバージョン管理  書き込みのトランザクションには、厳密なTwo-Phase- Lockを使う。  それぞれのトランザクションTには、タイムスタンプsが割り当 てられる。  トランザクションTによって書き込まれたデータは、タイムスタ ンプsを持つ。 Time <8 8 [X] [me] 15 [P] My friends My posts X’s friends [] [] OSDI 2012 245
  229. 229. スナップショットを同期する グローバルな壁時計 == 外的整合性: コミットの順序は、グローバルな壁時計の 順序を尊重する == タイムスタンプの順序は、与えられた グローバルな壁時計の 順序を尊重する タイムスタンプの順序== コミットの順序 OSDI 2012 246
  230. 230. タイムスタンプとグローバル・クロック  書き込みのトランザクションについては、厳密な two-phase lockingを適用する。  ロックが保持されている間、タイムスタンプを割り当 てる。 Acquired locks Release locks T Pick s = now() OSDI 2012 247
  231. 231. タイムスタンプの不変量 • タイムスタンプの順序== コミットの順序 T 2 • タイムスタンプの順序は、グローバルな壁時計 の順序を尊重する T 3 T 4 T 1
  232. 232. TrueTime  “グローバルな壁時計の時間” は、ある制限の 範囲だが、不確実性を持つ。 time TT.now() earliest latest 2*ε
  233. 233. タイムスタンプとTrueTime Acquired locks Release locks T Pick s = TT.now().latest s Wait until TT.now().earliest > s OSDI 2012 Commit wait average ε average ε 250
  234. 234. コミットのWaitとレプリケーション Achieve consensus Acquired locks Release locks T Start consensus Notify slaves Pick s Commit wait done
  235. 235. Commit Wait and 2-Phase Commit TC OSDI 2012 Acquired locks Release locks TP1 Notify participants of s Acquired locks Release locks TP2 Acquired locks Release locks Compute s for each Commit wait done 252 Start logging Done logging Prepared Compute overall s Committed Send s
  236. 236. Example TC T2 TP Remove X from my friend list Risky post P s=8 s=15 Remove myself from X’s friend list sC=6 sP=8 s=8 Time <8 [X] [me] 15 [P] My friends My posts X’s friends 8 [] [] OSDI 2012 253
  237. 237. 我々がカバー出来たことは何か?  データセンター間の、ロックフリーな、read トラ ンザクション  外的整合性  タイムスタンプの割り当て  TrueTime  時間の不確実性は、待つことでしのぐことが出来る OSDI 2012 254
  238. 238. 我々がカバーしなかったこと  現在の時刻を、どうよむのか。  アトミックなスキーマの変更  大部分は、ノン・ブロッキングである  未来のタイムスタンプでコミットする  過去のノン・ブロッキングな読み込み  レプリカの効率的な更新 OSDI 2012 255
  239. 239. TrueTime Architecture GPS timemaster GPS timemaster GPS timemaster Atomic-clock timemaster GPS timemaster GPS timemaster Client Datacenter 1 Datacenter 2 … Datacenter n Compute reference [earliest, latest] = now ± ε OSDI 2012 256
  240. 240. TrueTime implementation now = reference now + local-clock offset ε = reference ε + worst-case local-clock drift 200 μs/sec time ε +6ms reference uncertainty 0sec 30sec 60sec 90sec OSDI 2012 257
  241. 241. 時計が狂うとどうなるか?  タイムスタンプの割り当てが、外的整合性を破 ることになるだろう。  一年間のデータに基づけば、そういうことはあ りそうにない。  時計が狂うより、CPUがおかしくなる可能性の方 が、6倍以上ありそうである。 OSDI 2012 258
  242. 242. 将来の課題  TrueTimeの改善  Lower ε < 1 ms  データベースの諸特徴をきちんと構築する  基本的な特徴の実装を終える  多様な検索パターンを効果的にサポートする OSDI 2012 259
  243. 243. 結論  時計の不確実性をtime APIで具体化する  知らないことを知ることは、知らないことを知らない より、いいことである  不確実性を利用した、アルゴリズムを再考すること  強いセマンティックは達成可能である  大規模なスケール!= 弱いセマンティックス OSDI 2012 260
  244. 244. 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_conten t/untrusted_dlcp/research.google.com/ja//archive/sp anner-osdi2012.pdf
  245. 245. Abstract
  246. 246. Abstract  Spannerは、スケーラブルで、マルチ・バージョン、 グローバルに分散し、レプリカの同期を行う、 Googleのデータベースである。  それは、グローバルなスケールでのデータの分散 と外的整合的な分散トランザクションをサポートし た、初めてのシステムである。  この論文は、Spannerがどのような構造を持つ か、その諸特徴、様々なデザインの決定の基礎 にある理論的な根拠、時計の不確実性を明らか にする全く新しいtime APIについて述べたもの である。
  247. 247. Abstract  このAPIとその実装は、外的な整合性と、 Spannerの全域にわたる、過去のデータのブ ロックしない呼び出し、ロックのないread-onlyト ランザクション、そしてアトミックなスキーマの変更 といった強力な諸特徴をサポートする上で、本質 的に重要なものである。
  248. 248. Introduction

×