Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Cloud OSの進化を考える

2.604 visualizaciones

Publicado el

クラウド研究会 10/27 丸山講演

Publicado en: Internet
  • Sé el primero en comentar

Cloud OSの進化を考える

  1. 1. クラウドOSの進化を考える 丸山不二夫 2015/10/27
  2. 2. predictable performance is difficult to achieve. In a predictable system, worst-case performance is crucial; average performance not so much. It’s with the intent of modeling a world where the Twitters, Googles, and Facebooks are no longer superpowers… just power - Aurora
  3. 3. 「ツールと優秀なプログラマーだけが、マルチ・スレッドについて考え ることができる。」 Jim Waldo 「どうして、みんな、もっと非同期のプログラム書かないんだい? イベント・ループとコールバックなら簡単だろう!」 伝 Ryan Dahl 「邪悪は、状態の中に潜む。間違い。もう一度言い直そう。邪悪は、 変更可能な状態の中に潜む。」 Akkaについて Jonas Bonér
  4. 4. 図は、ボルボックス。 数千個の体細胞からなる。 「化石の記録によると最初の多細胞生物は約10億年前に誕生した とされており、生物の誕生が35億年前であるから、多細胞化には25 億年近くを必要としたことになる。」 wikipedia 「多細胞生物」
  5. 5. クラウド研究会の再開にあたって  「クラウド」という言葉が広く知られるようになったのは、 2006年11月に開催されたWeb 2.0 Summitからだと 思う。このコンファレンスの会場で、AmazonのJeff Bezosは、EC2とS3のリリースを発表した。  丸山は、2007年2月のマルレクで、「Cloud -- Google File System とAmazon S3/EC2」というテーマで講演 をしたのを皮切りに、2008年8月から2011年9月まで、 48回クラウド研究会を主催してきた。  当時の技術的関心は、Scale out Architecture, ScalabilityとAvailability, Eventually Consistency, MapReduceの実装等を中心としたものであり、実践的に は、クラウド技術の受容がITビジネスにとって重要である ことを訴えるものだった。
  6. 6. クラウド研究会の再開にあたって  2011年当時、日本でもパブリック・クラウドの市場が立ち 上がり、クラウドの一般の企業への普及に焦点が移りつ つあった。「市場のことは、市場にまかせよ」 当初の技術 的・理論的な関心とIT業界を対象としたクラウド研究会の 活動に、区切りをつけた。  クラウドの登場から約10年が経過した。市場での激しい 競争を通じて、クラウドの受容は大きく進んだ。同時に、ク ラウドをめぐる技術的あるいはビジネス的関心も大きく変 わりつつある。あらためて、クラウドの技術的な動向と市 場の動向を考えたいと思う。  クラウド研究会の再開にあたって、丸山が注目する、現在 のクラウドの技術的な動向のオーバービューを、小論で与 えたいと思う。
  7. 7. Agenda  UNIXとの比較でクラウドOSを考える  コンテナーでのタスク管理への収斂  分散ファイル・システムの多様化  クラウド内でのイベント・ドリブン処理と 関数型言語的アプローチの浸透  クラウド・モバイル・インターフェース
  8. 8. UNIXとの比較でクラウドOSを考える 近代的なOSは、UNIXに始まると言っていい。もちろ ん、それは一つのマシン上で稼働した。 冒頭に紹介するJim Waldoの考察は、クラウド登場 以前の段階での「プラットフォームの複雑さ」について の代表的な示唆に富む考察である。
  9. 9. goo.gl/tw9F8c Summary of Jim Waldo‘s Keynote goo.gl/DBtmv5 まず、システムの複雑さについて考えてみよう
  10. 10. 複雑さにおける質的な飛躍  線形実行 (SEQ) – 人生は善良でシンプルであった  マルチ・スレッド (MT) – ツールと優秀なプログラマが MTについて考えることが必要  マルチ・プロセス (MP) – カーネルの開発者だけでな く誰もが利用できる。実際には、MTの前に起きた。  マルチ・マシン (MM) 同一ネットワーク上の – マルチ・プロセスと同じではないのだが、ある人たちは、 そう考えている  信頼できないマルチ・マシンたち(MMU) – 本質的に は、Webの世界である
  11. 11. それぞれの段階を通り抜ける際、 我々は、何かを失う  線形実行からマルチ・スレッドへ: 我々は、順序を失う(複数のことが同時に起こる)。これは、 難しい。なぜなら、我々は、自然には、シーケンシャルに 考えるから。  マルチ・スレッドからマルチ・プロセスへ: 単一のコンテキスト(すなわち、我々が信頼しうる共有コン テキスト)を失う。グローバルな状態が、開発のあらゆると ころで利用される。(すべてをスタティックに考えよ)
  12. 12. それぞれの段階を通り抜ける際、 我々は、何かを失う  マルチ・プロセスからマルチ・マシンへ: 我々は、状態を失う。「システム」のグローバルな状態とい うのは、虚構である。興味深い分散システムには、整合的 な状態というものは存在しない。 (Lamport:http://research. microsoft.com/users/lamport/pubs/pubs.html ) 分散OSのプロジェクトは、グローバルな状態を導入しよう としたが、大々的に失敗した。  信頼できないマルチ・マシンたちへ: 誰を信ずることが出来るか分からない難しい状況の中で、 我々は信頼を失う。
  13. 13. しかし、我々は何かを得てきた  Seq to MT : パラレル処理  MT to MP : プロセスの分離(安全を与える)  MP to MM : 独立した失敗 (何かまずいことが起きても、 システムの部分は生きのこる)  MM to MMU : スケール (webスケール、インターネット スケール). 誰か他の人のリソースを利用せよ(あるいは、 他の誰かが、我々のリソースを利用することを認めよ) MP->MM で発生する Partial Failureへの対応としての Leaseのアイデアは、Waldoの大きな仕事である。
  14. 14. Multi Process から Multi Machine へ Jim Waldoの区分で言うと、UNIXからクラウドOSへ の変化は、Multi Process から Multi Machine へ の変化だということになる
  15. 15. UNIXの代表的な教科書 40年前のもの。
  16. 16. このあたりが、UNIXの マイクロ・サービスかも しれない
  17. 17. UNIX Kernel File Subsystem Process Control Subsystem System Call Hardware User Program IPC Scheduler Memory Management Hardware Control Device Driver
  18. 18. UNIX Kernelの主要な構成要素  Process Control Subsystem  File Subsystem  IPC / Scheduler / Memory Management / Hardware Control  Device Driver
  19. 19. UNIXとクラウドOSとの対応  コンテナーでのタスク管理  UNIXプロセス管理  分散ファイル・システム  UNIXファイル・システム  クラウド内でのイベント・ドリブン処理  UNIX Kernel内の割り込み処理  モバイル・インターフェース  デバイス・ドライバー
  20. 20. コンテナーでのタスク管理への収斂 Containerを用いたタスク管理は、ほぼ全てのクラウ ド・プラットフォームで同時に起きつつある変化である。 それは、クラウドを背後で支えていた動的なリソース 管理の仕組みをユーザーに開放することで、クラウ ド・ベンダーの枠を超えたコンテナー・サービスの流通 を促進し、より柔軟により効率的に、新しいサービスと ビジネスを立ち上げることを可能にする。
  21. 21. UNIX Fork & Exec Unixのシステム・コールでの、fork/execを考える。 forkは、メモリー上に、親プロセスと同じ「実行環境」 を用意する。その子プロセスの「実行環境」に、exec がプログラムをロードして実行する。 http://www-h.eng.cam.ac.uk/help/tpl/unix/fork.html
  22. 22. forkとexec
  23. 23. fork 領域の確保とコピー  Unixは、単一の仮想メモリー空間で動くので、「実行環 境」を構成する「リソース」は主要にはメモリーである。  領域をmallocで確保し、その上へデータとスタックをコ ピーする。プログラム(Text)は共有される。  そのほかにプロセスのcontextの設定が必要である。
  24. 24. Container マルチ・マシンでの実行環境の準備  「マルチ・マシン」では、実行環境は、複数の物理ノードか らなるクラスター上に作られる。LXCは、ノード上にOSを Containerとしてそのまま複製する。  「実行環境」は、単なるメモリー領域+αではなく、OSを含 んだContainerから構成されることになる。また、処理の 単位は、単なるプロセスではなく、MesosのAuroraなら、 Job/Task/Process という階層を含んだものの全体とな る。
  25. 25. Container マルチ・マシンでの実行環境の準備  処理のひとかたまりに、どのような名前を使うか、その他、 いろいろ違いはあるが、AWSのContainer Manager, Mesos, Kubernete(その原型のBorgも)の行っている ことは、マルチ・マシン上での「実行環境」のallocateとプ ログラムの実行、双方の管理で、基本的には同じことであ る。クラウド上のContainerが注目される所以である。
  26. 26. Google Borg “Large-scale cluster management at Google with Borg” https://goo.gl/aN03bI
  27. 27. クラウドを支える技術  「EC2/S3のようなサービス提供ができるためには、ネット ワーク上に分散して存在している物理的なディスクや物理 的なサーバを、仮想化して論理的に管理して、稼働してい ないものはリソース・プールに登録して、変動する要求に 応じて動的にそこからリソースを取り出して仕事を割り当 てて、スケーラブルなサービス提供を保障しなければなら ない。AmazonのEC2/S3のサービス開始は、クラウドを 支えるこうした課題の重要性に、皆の眼を向けさせた。 」 「クラウドの成立過程とその技術的特徴について」 情報処理 Vol.50 No.11 Nov. 2009 https://goo.gl/SdxUjf しかし、その実装は不明なままだった
  28. 28. GFS chunkserver Linux File System GFS chunkserver Linux File System Application GFS Client GFS Architecture Chunk 2ef0 GFS Master File NameSpace /foo/bar (file name,chunk index) (chunk handle, chunk location) (chunk handle,byte range) chunk data Instruction to chunkserver Chunkserver state ・・・・・・・・ ・・・・ こういうダイアグラムは与えられたが、 こうした構成を動的に可能にするメカ ニズムは伏せられたままだった
  29. 29. ある時、ある図に見慣れないものが書かれてあった。 Workqueueって何? 多分、clusterの管理をして いるのはこれだと思ったが、どこを探しても説明はなかった
  30. 30. Google, Borgの情報公開  今年の4月、Googleは、Borgの情報を初めて公開した。 “Large-scale cluster management at Google with Borg” https://goo.gl/aN03bI  この発表に対して、Auroraのアーキテクトのコメントを含 む記事が、出ている。“Google Lifts the Veil on Borg, Revealing Apache Aurora’s Heritage”http://goo.gl/Nv8ZIQ  僕には謎だったBorgの名前の由来だが、それは、Star Trekに 登場する「宇宙種族のひとつ。蜂や蟻をモチーフにした社会的集 合意識を持っているとされ、中央制御装置としてのQueenがい る」とのこと。Facebookで友人から教えてもらった。納得。 ようやく情報が出た。10年以上、隠していたことになる。
  31. 31. Google Borg Google’s Borg system is a cluster manager that runs hundreds of thousands of jobs, from many thousands of different applications, across a number of clusters each with up to tens of thousands of machines 数十万のジョブ 数千のアプリケーション 数万のマシン
  32. 32. MesosとBorg  Mesosは、GoogleのBorgにインスパイアされて生まれ た、オープンソース・プロジェクトである。  Borgは、以前から、その存在は知られていたが、GFS, MapReduce, BigTable とは異なって、その技術的詳細 をGoogleが明かすことはなかった。Borgは、Googleの 大規模分散の中核技術であり、ある人は、それを 「Googleの秘密兵器」「Googleの急速な進化の、もっと もよく保たれた秘密」と呼んでいた。  “Return of the Borg: How Twitter Rebuilt Google‘s Secret Weapon”http://goo.gl/QyhGjx  "Twitter’s Aurora and How it Relates to Google’s Borg (Part 1)"http://goo.gl/BRhL7x 「Googleの秘密兵器」「Googleの急速な進化の、もっともよく保たれた秘密」!!
  33. 33. Mesos http://mesos.apache.org/ マルレク資料 「大規模分散システムの現在 - Twitter 」 https://goo.gl/6Ai4cm
  34. 34. Mesosとは何か? 分散システム・カーネル  Mesosは、抽象のレベルが異なるだけで、Linuxカーネ ルと同じ原理に基づいて構築されている。  Mesosのカーネルは、全てのマシン上で走り、 (例えば、 Hadoop, Spark, Kafka, Elastic Searchといった )ア プリケーションに、データセンター全体とクラウド環境をま たいで、リソース管理とスケジューリングのAPIを提供する。
  35. 35. Mesosプロジェクトの特徴  数万ノードへのスケーラビリティ  ZooKeeperを利用した、フォールト・トレラントなレプリ ケートされたマスターとスレーブ  Dockerコンテナーのサポート  Linux Containerによる、ネーティブなタスク間の分離  複数のリソース (memory, CPU, disk, ports)のスケ ジューリング  新しいパラレル・アプリケーションを開発するための Java, Python, C++ のAPI  クラスターの状態を見るためのWeb UI
  36. 36. Mesosphere データセンターOSは、 全ての主要なプラットフォームで走る
  37. 37. PaaS and Long Running Big data processing Batch scheduling Data storage Mesos で走る主要なアプリ https://goo.gl/1oDvTc
  38. 38. Mesosの主要なコンポーネント  次の図は、Mesosの主要なコンポーネントを表している。  Mesosは、それぞれのクラスター上のノードで走るスレー ブ・デーモンと、それを管理するマスター・デーモン、これ らのスレーブ上でタスクを走らせるアプリケーション(これ は、フレームワークとも呼ばれる)から構成される。
  39. 39. Framework
  40. 40. マスターとリソース・オファー  マスターは、アプリケーションがリソースのオファーを行う ことで、アプリケーション間の細かな粒度でのリソース (CPU, RAM等)の共有を可能にする。  それぞれのリソース・オファーは、それらのリストを含んで いる。マスターは、与えられた(fair sharing, strict priorityといった)組織的なポリシーに応じて、どれだけ のリソースをそれぞれのフレームワークに提供するかを決 定する。  多様なポリシーの集合をサポートするために、マスターは、 プラグインのメカニズムを通じて、容易に新しいモジュー ルを割り当てられるように、モジュラー・アーキテクチャー を用いている。
  41. 41. schedulerとexecutor  Mesosの上で走っているフレームワークは、二つのコン ポーネントからなる。一つは、フレームワークの scheduler(スケジューラー)で、マスターに提供される べきリソースを登録する。もう一つは、 executor プロセ スで、スレーブノード上で起動されてフレームワークのタス クを実行する。  マスターは、どれだけの量のリソースが、それぞれのフ レームワークに提供されるかを決定し、その一方で、フ レームワークのスケジューラーは、どの提供されたリソー スを使うかを決定する。フレームワークが、提供されたリ ソースを受け取る時には、Mesosに、実行しようと思って いるタスクの記述をMesosに渡す。その代わりに、 Mesosは、対応するスレーブ上で、タスクを起動する。
  42. 42. リソース・オファーの例 フレームワーク Mesos マスター Mesos スレーブ
  43. 43. リソース・オファーのプロセス ① Slave 1は Masterに、自分には 4 CPUあって4 GBの メモリーが空いていると報告する。報告を受けるとMaster は、Allocation Policy Moduleを呼び出す。 Allocation Moduleは、Framework 1が、利用できる リソースを求めていると伝える。 ② Masterは、Slave 1にこれだけの利用可能なリソースが あるとFramework 1にリソース提供を申し出る。 ③ Framework 1のスケジューラは、Masterに二つのタス クをSlave 1 で走らせて欲しいと応答する。一つ目のタス クは <2 CPUs, 1 GB RAM> で、二つ目のタスクは<1 CPUs, 2 GB RAM>でという情報と一緒に。
  44. 44. リソース・オファーのプロセス ④ 最後に、Master は、Slave 1 にタスクを送る。それは、 Slave1 の Framework1 の実行エンジンに適切なリ ソースを割り当てる。こうして、二つのタスクが起動される (図での、Slave 1の点線で囲まれた部分)。Slave 1の、 1 CPUと 1 GBのメモリーは、アロケートされていないの で、Framework 2のタスクに使われるかもしれない。 このリソース提供のプロセスは、タスクが終了して、新しいリ ソースがフリーになった時には、繰り返される。
  45. 45. http://aurora.apache.org/ Apache Aurora 長時間走るサービスとcronジョブのための Mesosフレームワーク
  46. 46. Apache Aurora https://github.com/apache/aurora/blob/ma ster/docs/tutorial.md マルレク資料 「大規模分散システムの現在 - Twitter 」 https://goo.gl/6Ai4cm
  47. 47. Aurora: Job  Aurora は、Mesos上でjobをスケジュールするために 利用されるMesosのフレームワークである。Mesosは、 個々のtaskを面倒見るのだが、典型的なjobは、数百に も昇るtaskのレプリカを持つ。Auroraは、Mesosの上 に、jobという抽象の層を提供する。  Auroraのjobは、taskのテンプレートと、そのtaskとほと んど等しいtaskのレプリカ(”instance id”が違うとか、マ シンごとにポート番号が違うとか。それ以外は、ほぼ同 じ。)を生成する命令からなる。  いくつのtaskがjobを構成するかは、複雑である。基本的 には、一つのjobは、一つのtaskテンプレートとそのtask とほとんど等しいtaskのレプリカ(”インスタンス”とか “shard”と呼ばれることもある)を生成する命令からなる。
  48. 48. Aurora: taskとprocess  taskは、一つのコマンドラインの命令(例えば、 my_script.py のような)に対応した、一つのprocess にすぎないこともある。ただし、taskは、その全てが一つ のsandbox上で走る沢山の別々のprocessから構成さ れることもある。例えば、logrotate, installer, master, slave というような複数のエージェントが協調して走ること がある。  こうした時、Thermosが登場する。AuroraがMesosの Task上でJobの抽象を与えるように、Thermosは、 MesosのTaskの下で、Auroraフレームワークの executorの一部としてサービスし、Processの抽象を 与える。
  49. 49. Auroraの階層  Auroraは、taskからなるjobを管理する。  Mesosは、processからなるtaskを管理する。  Thermosは、processを管理する。  全ては、 .aurora 設定ファイルで定義される。
  50. 50. Amazon EC2 Container Service https://aws.amazon.com/ecs/details/
  51. 51. AWS re:Invent 2014 Announcing Amazon EC2 Container Service https://goo.gl/Za7QqP Rabbitmqを一つContainerで走らせている aws ecs describe-task-definition ...の出力 aws ecs run-task nlp-rabbit ...
  52. 52. AWS re:Invent 2014 Announcing Amazon EC2 Container Service https://goo.gl/Za7QqP
  53. 53. AWS re:Invent 2014 Announcing Amazon EC2 Container Service https://goo.gl/Za7QqP 走るコンテナが増えて行く ... 二つのコンテナで走るサービスも
  54. 54. AWS re:Invent 2014 Announcing Amazon EC2 Container Service https://goo.gl/Za7QqPサービス本体のデプロイ
  55. 55. AWS re:Invent 2014 Announcing Amazon EC2 Container Service https://goo.gl/Za7QqP RabbitMQ Redis Node.js NGINX Audio Processor スケールさせる
  56. 56. AWS re:Invent 2014 Announcing Amazon EC2 Container Service https://goo.gl/Za7QqPスケールさせる
  57. 57. AWS re:Invent 2014 Announcing Amazon EC2 Container Service https://goo.gl/Za7QqPTerminate する
  58. 58. Amazon EC2 Container Service Features  Docker Compatibility  Managed Clusters  Task Definitions  Programmatic Control  Scheduling  Container Auto-Recovery  Container Load Balancing  Container Deployments  Local Development  Monitoring / Logging  Repository Support
  59. 59. Azure Container Service “Azure Container Service: Now and the Future” Ross Gardler 2015/09/29 https://goo.gl/A7qvTu
  60. 60. 我々が、本日、 アナウンスしたものは何か?  我々は、 Azure Resource Manager (ARM) のため の Azure Container Service Resource Provider を提供する。  このサービスの最初のプロトタイプ実装を、Azure QuickStart Templateの形で利用可能にした。
  61. 61. 我々が、本日、 アナウンスしたものは何か?  Azure Resource Managerをテコとして、 Azure Container Service は、 Docker, Apache Mesos, Marathon and Docker Swarmであらかじめ設定され たホスト達のクラスターを簡単に、生成し管理することが 可能となる。  これによって、超スケーラブルで、エンタープライズ品質の Azure クラウドと、試され済みのオープンソース技術を結 合して、コンテナー・アプリを構築する全てのチームが必 要とするであろう、コンテナーのデプロイ、オーケストレー ション、サービス管理の基礎を提供する。
  62. 62. What can you try today?
  63. 63. Azure Container Service は、 どこに向かおうとしているか?  来たるべき ARMのためのAzure Container Service Resource Providerは、 ユーザーが、 標準的なARM APIを用いてクラスターを定義・管理することを可能にする。  現在では、この設定には、数千行のコードを必要とするの だが、必要とされる技術の深い理解に注意を払う必要なく、 それが可能となる。 我々のリソース・プロバイダーは、こ の複雑さを抽象化して、数千行のコードを、デフォールト の設定では、数十行に削減するだろう。この単純化は、こ うした複雑なクラスターのデプロイと管理にあたって、設定 エラーがより少ないものになることを意味する。
  64. 64. Azure Container Service は、 どこに向かおうとしているか?  それでは、Windows Server Containersは、どうなる のであろうか? 明確にするリスクを承知で述べるなら、 我々は、 Windows Server Containers を、完全にこ のサービスと統合しようとしている。  Windows Server TP3がDocker Engineのサポートを し、8月のMesosphereとマイクロソフトが共同でApache MesosをWindows Serverにポーティングすることを発 表して以来、中心的な要素は、既に存在している。  この仕事を通じて、Windows Server Containerは、 Azure Container Serviceをサポートし、こうして、ユー ザーのニーズにもっとも適切な、どのようなオペレーショ ン・システムでも、ユーザーがコンテナーを管理できること を保証することとなった。
  65. 65. Google Container Engine “What is Google Container Engine? ” https://cloud.google.com/container- engine/docs/
  66. 66. Google Cloud Platform で Docker コンテナを実行し、Kubernetes で管理  Google Container Engine は、Docker コンテナの実 行を支える強力なクラスタ マネージャおよびオーケスト レーション システムとして機能します。ユーザーが定義す る要件(CPU やメモリなど)に基づいてコンテナをクラスタ にスケジューリングし、自動的に管理します。オープンソー スの Kubernetes システム上に構築されており、ユー ザーはオンプレミス、ハイブリッド、パブリック クラウド イ ンフラストラクチャを柔軟に利用できます。  わずか数分で仮想マシンのマネージド コンテナ クラスタ をセットアップし、デプロイの準備を整えることができます。 クラスタではロギングやコンテナのヘルス チェックといっ た機能が提供され、アプリケーションを簡単に管理できま す。 https://cloud.google.com/container-engine/
  67. 67. Google Cloud Platform で Docker コンテナを実行し、Kubernetes で管理  予約する CPU/メモリ量、レプリカの数、キープアライブ ポリシーといったコンテナの要件は、シンプルな JSON 形 式の設定ファイルで宣言します。Container Engine は 宣言に沿ってコンテナのスケジューリングを行い、要件が 満たされるようにアプリケーションを能動的に管理します。  Red Hat、Microsoft、IBM、Mirantis OpenStack、 VMware などは、自社プラットフォームへの Kubernetes の統合に取り組んでいます(こうした取り組 みを行う企業は増え続けています)。その結果として、 ワークロードの移行や複数のクラウド プロバイダーの利 用がもっと簡単になります。 https://cloud.google.com/container-engine/
  68. 68. CONTAINER ENGINE の特長  フルマネージド  プライベートな Container Registry  スケーラブル  Docker のサポート  ロギング  ハイブリッド ネットワーキング
  69. 69. Docker Swarm https://www.docker.com/docker- swarm
  70. 70. Docker Swarm  分散アプリケーションは、その本性上、同様に分散した計 算リソースを必要とする。Docker Swarmは、Docker エンジンのグループを、一つの仮想的なDockerエンジン に変える、ネーティブなクラスタリングの能力を提供する。 これらのプールされたリソースを用いて、ユーザーは、あ たかも一つの巨大なコンピュータを走らせているかのよう に、アプリケーションをスケールアウトできる。
  71. 71. http://goo.gl/FHbdF0
  72. 72. Docker Swarm  Compatible with Docker Tools: Docker Swarm は、標準のDocker APIを利用してい るので、既にDockerデーモンとコミュニケーションしてい るどのようなツールも、Swarmを透過的に複数のホスト にスケールできる。  Smart Container Scheduling ビルトインされたスケジューラーは、ノードタグやアフィニ ティー、さらには、スプレッドやビンパック等々のストラテ ジーといったフィルターを備えている。これらのフィルター は、コンテナーを配下のノードに割り当てて、パフォーマン スとリソースの利用を最大化できる。
  73. 73. Docker Swarm  Pluggable Schedulers Swarm は、ビルトインされたスケジューラーを備えてい るが、大規模な製品の配備には、簡単にMesosのバック エンドをプラグインできる。この時でも、Dockerのプラグイ ンを使い続けて、開発経験は一貫して同じままである。  Pluggable Node Discovery クラスターの中でノードを見つけるために、Docker Swarmは、何がユーザーの開発環境に最適かに応じて、 次のようなものを利用できる。ホスト上のディスカバリー・ サービス、スタティックなファイル、etcd、consul、 zookeeper。
  74. 74. 分散ファイルシステムの多様化 ファイルシステムは、データの永続性だけではなく処 理のスケールを担保するものとして、クラウド技術の 中で、もっとも活発に、かつ多様な探求が行われてい る分野である。これまでも、これからも。 それは、多数のCPU/メモリー/キャッシュ/ストレージ をまたぐ領域であり、新しいアイデアや新しいハード ウェア・デバイスが登場する可能性も高い。
  75. 75. OS とファイルシステムの結びつき  UNIXを特徴づけるのは、「プロセス」と「ファイル」という二 つの概念である。メタファーとしては、「ファイルシステム」 という「森」に、「プロセス」という「生き物」が生きていると いうもの。入力も出力もデバイスもプロセスさえも、ファイ ルと結びついている。  近代的なOSに、ファイルシステムが、その中核部分として 組み込まれる上で、UNIXは決定的な影響を与えた。ただ、 それは、OSの具体的な歴史の中では当然の流れでは あっても、論理的には必然とは言えないと思っている。  Turing Machineのテープは、ファイルに見えるかもしれ ないが、あれは、メモリーだと思ったほうがいい。ノイマン 型コンピュータの定義で、本質的に重要なのは、メモリー とCPUで、ストレージではない。
  76. 76. Turing Machine http://www.felienne.com/archives/2974
  77. 77. Von Neumann architecture https://en.wikipedia.org/wiki/Von_Neumann_architecture
  78. 78. ファイルシステムに求められるもの  ファイルシステムが担保している能力は、大雑把に言って 二つある。一つは、データの永続性の保証であり(それは、 相対的なものだ)、もう一つは、メモリーに入りきらない量 のデータの作業領域を提供することである。  前者の永続性の主要な担い手は、ファイルだけとは限ら ない。CPU/CPU Cache/Memory/Storage Cache /Storageは、永続性の時間的な階層を形成している。  後者のメモリーに入りきれない量のデータの問題は、処理 のスケールをどう担保するのかという問題と直結していて、 現代のマルチ・マシン・システムの進化の主要なドライビ ング・フォースである。データの量は、階層的にシステム の質を決める。( ”Big Data”は、のっぺらぼうだ)
  79. 79. ファイルシステム進化の新しい段階  マルチ・マシンのOSでのファイルシステムは、まず、GFS, HDFS等の「分散ファイルシステム」として始まった。  続いて、ScalabilityとEventually Consistentを特徴と する「Key/Value データストア」が登場する。もちろん、 GoogleのBigTableがトップランナーだ。BigTableによく 似たFacebookのCassandra、リング状のP2P/DHT ベースのMSのAzure Data Store、それと同じような構 造を持つAmazonのDynamo ...  重要なことは、大規模分散システムでは、この分野で、 「分散ファイルシステム」「Key/Value データストア」に続 く、「第三の波」が起きていて、活発で多様な変化が続い ていることだ。
  80. 80. 進化の方向?  残念ながら、この変化がどのような方向で収斂するのか、 あるいは、収斂するものなのかについても、僕には予想 がつかない。「この分野」と書いたが、どうも、「分散ファイ ルシステム」や「ストレージ」、「データストア」という言葉で くくるのは、気持ちが悪いところがあるのだ。多分、まだ、 適切な言葉がないのだ。  ちなみに、Crawlerが集めた膨大なWebページ情報の Index付けの主役の座を MapReduce は既に降りてい るのだが、BigTableは機能強化を繰り返して、いまも現 役のままだ。BigTableなしに、Googleのサービスを考え るのは難しい。クラウドでは、第一義的な永続性保持の 「器官」は、Key/Value データストアなのかもしれない。 (歴史的には)
  81. 81. Domain Specific な多様性  ここでは、ファイルシステムの多様な「進化」の例として、 次のものを取りあげる。  Google Spanner 分散データベースの整合性担保  Google BigQuery 木構造のハードウェア  Apache Spark FS上のデータへの関数型アプローチ  Amazon Aurora Log Structured FS  Apache Kafka FS上でのデータフロー処理  Microsoft Trinity 分散メモリー上でのグラフ処理
  82. 82. Google Spanner “Spanner: Google’s Globally-Distributed Database” http://goo.gl/ll9J1B マルレク資料 「大規模分散システムの現在 --- GFS,MapReduce, BigTableはどう進化したか」 http://bit.ly/10yW52d Spanner論文翻訳版:http://bit.ly/1pYP5S2
  83. 83. Google Spanner  Spannerは、Key/Value データストアでは未解決だった Scalabilityと整合的なTransactionの問題に折り合い をつけた。ただ、これで一件落着かというとそんなことはな い。データベース/データストアの「現実」との折り合いの つけ方は様々だからだ。現実に、Spannerを使っている のは、Googleだけだ。その技術をオープンソース化しよう というインセンティブも大きなものにはなっていない。  ただ、要素技術としての正確な時計による整合性の管理 (「相対的な」タイムスタンプあるいはバージョニングによる 整合性管理の技術は、以前からあった。Snap Isolation)は、ただちに、BigTableの機能強化にも取り 入れられているのは、注目すべきことだろう。
  84. 84. Spannerとは何か? 分散マルチバージョンデータベース 汎用のトランザクション(ACID) SQL言語のサポート スキーム化されたテーブル Semi-relationalなデータモデル 既に、製品として稼働している  Googleの広告データのストレージとして  sharded MySQL を置き換えている OSDI 2012 87
  85. 85. Spannerとは何か?  特徴: Lock-freeな、分散readトランザクション  特質: 分散トランザクションの外的整合性保証  グローバルなスケールでは、最初のシステム  実装: Concurrency controlとReplicationと2PCの統 合  正当性とパフォーマンス  可能にした技術: TrueTime  Interval-basedなグローバル時間 OSDI 2012 88
  86. 86. タイムスタンプとグローバル・クロック  書き込みのトランザクションについては、厳密なtwo- phase lockingを適用する。  ロックが保持されている間、タイムスタンプを割り当てる。 T Pick s = now() Acquired locks Release locks OSDI 2012 89
  87. 87. TrueTime Architecture Datacenter 1 Datacenter n…Datacenter 2 GPS timemaster GPS timemaster GPS timemaster Atomic- clock timemaster GPS timemaster Client OSDI 2012 90 GPS timemaster Compute reference [earliest, latest] = now ± ε
  88. 88. Google BigQuery “Dremel: Interactive Analysis of Web- Scale Datasets” http://goo.gl/yAD5dI マルレク資料 「Google Dremel」 https://goo.gl/Lpnwbf
  89. 89. Google BigQuery  プロジェクト名は、Dremel。Dremelは、分散検索エンジ ンで利用されている木構造のアーキテクチャーをしていて、 カラム単位で分割されたデータ構造を利用する。カラム型 のデータ・ストアは、リレーショナルなデータの解析には採 用されてきたが、ネストしたデータ構造へのその拡張は、 行われてこなかった。数千台のノードが、一斉に動作する。 その動作を、何年か前のマルレクで、パラパラマンガ風に 解説したことがある。https://goo.gl/L0JpAJ これは、 単なるファイルシステムの組み合わせでも、単なるデータ ベースでもない。全く新しい構成物なのだと思う。
  90. 90. Google Dremel
  91. 91. message Document { required int64 DocId; optional group Links { repeated int64 Backward; repeated int64 Forward; } repeated group Name { repeated group Language { required string Code; optional string Country; } optional string Url; }} Document DocID Links? Name* Backward* Forward* Language* Url? Code Country? サンプルのスキーマ Protocol Buffer
  92. 92. Document DocID Links? Name* Backward* Forward* Language* Url? Code Country? 10 0 0 20 0 0 http://A 0 2 http://B 1 2 NULL 1 1 http://C 0 2 20 0 2 40 1 2 60 1 2 80 0 2 NULL 0 1 10 0 2 30 1 2 en-us 0 2 en 2 2 NULL 1 1 en-gb 1 2 NULL 0 1 us 0 3 NULL 2 2 NULL 1 1 gb 1 3 NULL 0 1 サンプルの格納状態
  93. 93. MapReduceとDremel 3000 nodes, 85 billion records numRecs: table sum of int; numWords: table sum of int; emit numRecs <- 1; emit numWords <- CountWords(input.txtField); Q1: SELECT SUM(CountWords(txtField)) / COUNT(*) FROM T1
  94. 94. Apache Spark Apache Spark Lightning-fast cluster computing http://spark.apache.org/ Spark Overview http://goo.gl/wVOe7u Spark Programming Guide http://goo.gl/q4jKPe
  95. 95. Apache Spark  もちろん、MapReduceにインスパイアされているのは明 らかなのだが、OSの中核にファイルシステムがあるという のが、Unixの基本思想だとすれば、Sparkは、その思想 を受け継いでいるのかもしれない。  SparkのResilient Distributed Datasets (RDDs)は、確かに、マルチ・マシン環境での、新しい質 を備えた、Unixファイルシステムの後継者にふさわしいよ うに見える。(分散ファイルシステムは、それ自体としては、 Unixファイルシステムの量的拡大に過ぎない。)  そこでの基本操作は、read/writeではなく、 Transformation(lazy評価される)とActionである。こ れらの操作は、「関数」で定義される。
  96. 96. Apache Spark  Sparkは、関数型プログラミングのスタイルを、メモリー上 のデータ操作から、分散したファイルシステム上のデータ 操作に拡大したものと考えることができる。  「ブロードキャストされる変数」「アキュムレーター」という考 えも、少しベタだが、興味深いものだ (おそらく、こうしたア プローチは、純粋に「関数型」的ではないような気がする)。
  97. 97. Resilient Distributed Datasets (RDDs)  Spark は、resilient distributed dataset (RDD) (弾力的分散データセット)というコンセプトの周辺を回転し ている。それは、パラレルに操作されることが出来る、フォー ルト・トレラントな要素の集合である。  RDDを生成するには二つの方法がある。一つは、ドライ バー・プログラムの既存の集合をparallelizingする方法 であり、もう一つは、共有ファイルシステム、HDFS、Hbase、 あるいはHadoopにInputFormaを提供する任意のデー タ・ソースといった、外部のストレージシステムのデータセット をreferencingする方法である。
  98. 98. RDDのオペレーション  RDDは、二つのタイプの操作をサポートしている。ひとつ は transformations で、既存のデータセットから新し いデータセットを生成する。もう一つの actions は、 データセット上の計算の実行を終了してからドライバー・プ ログラムに値を返す。  例を挙げれば、 mapは transformationである。それ は、データセットの各要素を、ある関数を通じて渡して、そ の結果の新しいRDDでの表現を返す。 一方で、 reduceは actionである。 それは、RDDの全 ての要素を、ある関数を用いて集約して、最終結果をドラ イバー・プログラムに返す。
  99. 99. Local vs. cluster modes  cluster modeでは、ジョブを実行するために、Sparkは、 RDDのオペレーションをタスクに分割する。タスクのそれぞ れは、executorで操作される。実行に先立って、Sparkは、 closureを計算する。closureというのは、この計算をRDD で実行するために、executorに見えなければならない変数 とメソッドのことである。このclosureは、シリアライズ化され て、各executorに送られる。  local modeでは、一つのexecutorがあるだけである。だ から、全てが同じclosureを共有している。  しかし、他のモードではそうではない。別々のワーカー・ノー ドで走るexecutorは、それぞれ、自分のためのclosureの コピーを持っている。
  100. 100. Broadcast Variables  ブロードキャスト変数は、タスク毎に変数のコピーを送り出 すことなしに、それぞれのマシンがread-onlyの変数の キャッシュを持つことをプログラマーに可能とする。  それらは、例えば、全てのノードに効率的なやり方で大き な入力データのコピーを持たせる時に利用できる。Spark は、通信コストを削減するために、効率的なブロードキャ ストのアルゴリズムを使って、ブロードキャスト変数を分散 させようとも試みる。
  101. 101. Broadcast Variables  Sparkのactionは、分散した“shuffle”操作で分離され たステージを通じて実行される。Sparkは、それぞれのス テージ内のタスクが必要とする共通のデータを、自動的に ブロードキャストする。  こうしたやり方でブロードキャストされたデータは、シリアラ イズ化されてキャッシュされ、それぞれのタスクが走る前 に、ディシリアライズ化される。このことは、複数のステー ジをまたいだタスクが同じデータを必要とするか、あるい は、ディシリアライズ化された形式でのデータをキャッシュ することが重要な場合のみ、明示的にブロードキャスト変 数を生成することが役に立つということを意味している。
  102. 102. Accumulators  Accumulator は、関連した操作を通じて、「追加」のみを 行う変数である。それゆえ、効率的にパラレル処理でサ ポートされる。それらは、(MapReduceでの) counterや sumの実装に利用することができる。  Spark は、ネイティブには、数値型のaccumulatorをサ ポートしている。プログラマは、新しい型のサポートを追加 できる。もし、 accumulator が、名前付きで生成されれ ば、それは、SparkのUIに表示される。この機能は、ス テージの実行の進捗を理解するには役に立つ。
  103. 103. New Apache Spark Developer Training: Beyond the Basics http://goo.gl/4Segjx
  104. 104. Amazon Aurora Amazon RDS for Aurora https://aws.amazon.com/rds/aurora/ マルレク資料:「Amazonのクラウド・データベース Aurora」 http://bit.ly/1DPJ3yf
  105. 105. Amazon Aurora  大規模なシステムではないが、リレーショナル・データ ベースのストレージを、Log Structured File System で再構成しようという試み。これは面白い。RDBに関わる 様々のオペレーションが、劇的に改善される。今後のクラ ウド上のRDBの台風の目になるだろう。  ログとストレージとメモリー・キャッシュ 3者を、どう組み合 わせるかは、BigTableの心臓部であるSSTableでも、重 要だった。基本的には、同じアイデアである。  Write-Ahead-Log(WAL)のテクニックは、データベース の整合性担保のためだけではなく、いまや、大規模分散 システムのアーキテクチャーの一部になろうとしていること は興味深い(Facebookのアーキテクチャー)。
  106. 106. Amazon Aurora  データベースに適用されたサービス 指向アーキテクチャー  ログとストレージのレイヤーを、マルチ テナントで、scale outする、データ ベースに最適化されたストレージ・サー ビスに移動する  Amazon EC2, Amazon VPC, Amazon DynamoDB, Amazon SWF, Amazon Route 53 といった他のAWS のサービスと統合する  連続的なバックアップのために、Amazon S3 と統合する
  107. 107. 一個だけのデータ Foo Aは、inodeで、データFoo をポイントしている。 二個目のデータ Barを追加 A’は、新しいinodeで、 データ Bar とデータ Fooを ポイントしている。 http://bit.ly/19EWBQN LFSの基本構造 inodeとデータ A A A’
  108. 108. Fooの値を、新しいFoo’で置き換える A’’は、新しい inodeで、新しい データFoo’ と データ Bar をポイントしている。 上のデータを整理する Cleaning A’’’は、新しい inode。データ Barがコピーされ、 コピーされたBarとデータFoo’ をポイントしている。 先頭のsegmentは、現在のinodeからはポイントされない。 GC可能 http://bit.ly/19EWBQN A A’ A’’ A A’ A’’ A’’’
  109. 109. 一個だけのデータ Foo Aは、inodeで、データFoo をポイントしている。 MAは、inode Mapでinode A をポイントしている。 二個目のデータ Barを追加 A’は、新しいinodeで、データ Bar とデータ Fooをポイントしている。 MA’’は、inode Mapでinode A、A’ をポイントしている。 inode Map - inodeのindex A MA MA MA’A A’
  110. 110. A A’ A’’MA MA’ MA’’ Checkpoint region inode mapへのindex logとは、別の固定領域に置かれる Checkpoint Region Checkpoint Regionで、inode map MA’’’を選べば、Foo’と Barの値が得られるが、inode map MA’を選べば、Barとともに 古いFooの値が復元できる。
  111. 111. Roll-Forward - Crashからの回復 最終 Checkpoint 最後に書き込ま れた inode Checkpoint Region Checkpoint Region Crashからの回復は、最後に行われたCheckpointから始めて 最後に書き込まれた inodeを見つけることに帰着する。あとは、 適宜、失われたリンクを貼り直せばいい。 Scan
  112. 112. THE DESIGN AND IMPLEMENTATION OF A LOG-STRUCTURED FILE SYSTEM M. Rosenblum and J. K. Ousterhout University of California, Berkeley ACM SIGOPS Operating Systems Review 1991年 http://bit.ly/1LmyTJx
  113. 113. http://stanford.io/1aRpQA8
  114. 114. Cache, Log and File System 2006年 Google: BigTable http://bit.ly/1BgmxYs 2011年 Google: LevelDB http://bit.ly/1943U47
  115. 115. BigTableシステム構成 Bigtable セル メタデータのオペレーションを実行 ロードバランシング Bigtable Tablet Server サーバデータ フェイルオーバのハンドリング モニタリング タブレットデータの 保持 ログ メタデータ保持、 マスター選定のハンドリング Bigtable Tablet Server サーバデータ Bigtable Tablet Server サーバデータ Bigtable Master Cluster Sheduling System Google File System Chubby Lock Service Bigtable Client Bigtable Client Library Open
  116. 116. Tabletの表現 / SSTable Write Buffer in Memory Random-Access Append–Only Log on GFS SSTable on GFS SSTable on GFS SSTable on GFS mmap … Tablet
  117. 117. Write Op Read Op memtable GFS Memory SSTable files Tablet Log
  118. 118. Apache Kafka Apache Kafka: A high-throughput distributed messaging system http://kafka.apache.org/
  119. 119. Apache Kafka  Kafkaも、ログの重要性を示す一つの例かもしれない。 Pub/Sub型のメッセージング・システムは昔からあるが、 その実装に、分散ログの手法を使おうというもの。  ただ、それは実装よりの見方で、実際に果たす役割は、マ ルチ・マシンのクラスター上で、メッセージのパーシステン シーを担保し、確実なデリバリーを保証する。Unixで言え ば、パイプやリダイレクトの機能を果たす。  関数型のアプローチとは、ちょっと違うのだが、データフ ロー型のアプローチを取る時には、Kafkaは、大きな役割 を担って行くことになるだろう。
  120. 120. Log  それぞれのパーティションは、順序付けられた複製不可 の連続的に追加されたメッセージのシークエンス、すなわ ち、コミット・ログである。パーティション中のメッセージに は、offsetと呼ばれる シーケンスIDが割り当てられ、そ れはパーティション中のメッセージを一意に指定する。  ログ中のパーティションは、幾つかの目的に役立っている。 第一に、一つのサーバーにフィットするサイズを超えてロ グをスケールすることを可能にする。それぞれの個々の パーティションは、それをホストするサーバーに会っていな ければならないが、topicは多くのパーティションを持つこ とができるので、任意の大きさのデータを扱うことができる。 第二に、それは、パラレル処理の単位として機能する。
  121. 121. Microsoft Trinity “Graph query and analytics with Trinity” http://goo.gl/4TPOA7 マルレク資料「大規模グラフデータ処理」 http://bit.ly/1zK41gv
  122. 122. Microsoft Trinity  Trinityは、グラフデータ処理クラスター。大規模グラフ データ処理では、現在は、GoogleのPregelとそのオープ ンソース・クローンであるGiraphが主力である。それは、 Bulk Synchronous Parallel(BSP)と呼ばれる、ファイ ルベースのバッチ処理のモデルに基づいている。ちなみ に、MapReduceもBSPの一種である。  MS Trinity は、インメモリーkey/valueストアをベース にしている。ただし、Trinityは、「メモリー・クラウド」と呼 ぶ、「分散メモリー」のシステムを構築する。パーシステン シーという観点から見れば、「分散ファイルシステム」と「分 散メモリーシステム」は、データ保持の時間長が異なるだ けで、考え方は同じようなものである。
  123. 123. Microsoft Trinity  「知識データ」は、グラフとして表現されるので、知識処理 では、高速で大規模なグラフデータ処理が重要となる。こ の辺りが、未来のクラウド「ファイルシステム」の進化の本 丸になるのかもしれない。
  124. 124. Trinity  分散インメモリーkey/valueストア  オンライン検索処理グラフ・データベース  Facebook上で3 hopの範囲の220万のユーザー検 索を 100ms以下の時間で  entity検索等のグラフベース・サービスの基礎  オフライングラフ解析パラレル・プラットオフォーム  10億ノードのグラフ処理を60秒で  グラフ解析の基礎
  125. 125. ランダム アクセス への挑戦 単一マシンの RAM容量の 制限 高速な グラフ処理 パラレル 計算 低遅延 オンライン処理 高速 オフライン解析 Memory Cloud
  126. 126. Memory Cloudとメモリーtrunk  Memory Cloudは、2p個のメモリーtrunkから 構成される。それぞれのマシンは、複数のメモ リーtrunkをホストする。  一つのマシン上のローカル・メモリーを複数の trunkに分割するのは、次の二つの理由による。 1. trunkレベルのパラレル計算は、ロックのオー バーヘッドなしに実行出来る。 2. 一つの巨大なハッシュテーブルのパフォーマンス は、ハッシュの衝突の故に最適ではない。  それぞれのメモリーtrunkは、TFS(HDFSのよう な)にバックアップされる。
  127. 127. Key/Value ストア  Memory Cloud上に、Key/Value ストアを構築 する。  Keyは、グローバルにユニークな64bitの識別子、 Valueは、任意長のblobである。  Memory Cloudは、複数のマシン上に分散して いるので、Key/Valueペアの位置を、マシン上の 物理アドレスでは指定出来ない。  Trinityは、Key/Valueペアの位置を指定するの に、ハッシュのメカニズムを利用する
  128. 128. ハッシュ・メカニズム  まず、Key/Valueペアを格納しているマシンを特 定する。  ついで、そのマシン上の一つのメモリーtrunk上 で、Key/Valueペアの位置を見つける。
  129. 129. マシンの特定  64bitのglobal unique IDから、2pbitのハッシュ コード i を作る。  Memory Cloudは、2p個のメモリーtrunkからなる ので、これで Key/Valueペアは、Memory Cloud 中の trunk i に格納されている事が分かる。  trunk i がどのマシン上にあるかを知る為に、2p個 のスロットからなる「アドレシング・テーブル」を作成 しておく。それぞれのスロットには、マシンIDを入れ ておく。  i番目のスロットをみれば、マシンが分かる。
  130. 130. 一つのメモリーtrunk上で、 Key/Valueペアの位置を見つける。  グローバルなアドレッシングが機能する為には、 それぞれのマシンが、「アドレッシング・テーブル」 のレプリカを保持する必要がある。  それぞれのメモリーtrunkは、グローバルIDと Key/Valueペアの位置を示すoffsetと、その sizeを格納したテーブルを持っている。  このテーブルで、グローバルIDを引けば、 Key/Valueペアの位置と大きさが分かる。
  131. 131. 64bitのユニークID p-bitのハッシュコード 全てのマシンで 共有される2p個の スロットを持つ アドレッシング・ テーブル メモリー trunkごと のテーブル 二つの テーブル
  132. 132. クラウド内でのイベント・ドリブン処理と 関数型言語的アプローチの浸透 クラウドの提供するサービスを、モノリシックなものとし てではなく、いくつかのサービスの協調として提供しよ うとする流れ。共有されるプログラムのデプロイのスタ イルも、プログラミングのスタイルも変わる。こうした流 れの中で、開発言語としては、関数型言語への移行 が静かに進行している。
  133. 133. ConcurrentとParallel  日本語では、Concurrent Computingを「並行計算」、 Parallel Computingを「並列計算」と訳すのが一般的で あるようだ。ただ、「並行」と「並列」では、まぎらわしい。  昔は(といっても大昔。DijkstraやHoareといった人たち が活躍していた時代)、コンピュータ・サイエンスの初期で は、「コンカレント(並行)計算」が大事な研究領域だった。 ただ、現代では、「パラレル(並列)計算」に対する実践的 な関心が高い。  こうした関心の移行の理由は、はっきりしている。昔は、計 算というと、一つの計算機上で同一のメモリー上で行われ るのが、当たり前だったが、現代では、クラウドのように、 複数の計算機がパラレルに走って、一つの処理を行うス タイルが、広く受け入れられるようになっているからである。
  134. 134. マルチ・スレッドとマルチ・プロセス  この「同一メモリー空間か、否か」という区別は、ほぼ、現 在のマルチ・スレッドとマルチ・プロセスの違いに対応する。 だから、理論的には、マルチ・スレッドの方が先行する。多 分、実装でもそうだったと思う。プロセスとマルチ・プロセス というコンセプトが、広がるのはUnixからだと思う。  Unixでは、プログラムは全てプロセスとして走る。プロセ スのメモリー空間は論理的には完全に分離されている。 また、プロセスを生成できるのは、fork システム・コール、 ただ一つである。プロセス間の協調は、「プロセス間通信 Inter Process Communication (IPC)」のみによって 行われる。ちなみに、現代のパラレル・コンピューティング の主要な手段であるネットワーク技術は、このUnixの「プ ロセス間通信」の発展系である。
  135. 135. UNIXのコンカレント処理  それでは、Unixには、マルチ・スレッドのコンカレントなプ ログラミングは存在しないのかというと、そうではない。 Unixは、マルチ・ユーザーのタイム・シェアリングのシステ ムである。クロックから定期的に割り込みが入り、コンテキ スト・スイッチが行われる。DiskのIOも、端末からの入力 も、コンカレントな処理を要求する。  ただ、Unixは、これらの複雑なコンカレントな処理を、全て、 OSのカーネルに閉じ込めようとする。それはそれで、複 雑さの問題に対する、一つの立派な見識である。  「マルチ・スレッドのコンカレント・プログラミングは、難しく て、素人には無理です。カーネルがその部分を引き受け ますので、ユーザーは、プロセスをお使いください。」
  136. 136. プロセス生成の軽量化  これでみんなが納得して、すべて片付いたわけではない。 forkが行う、親プロセスのコピーによるプロセス空間の生 成・分離は、とても重く時間のかかる処理だ。  プロセスの生成については、必要になった時だけコピーを 行うCOW(Copy on Write)とか、コードだけでなくデータ も共有するvforkとか、プロセス空間を親のコピーによら ず、一から生成するspawnといった、いろんな方式が提 案され実装されていく。
  137. 137. ユーザーインターフェースの変化と コンカレント・プログラミング  そうしたプロセス生成の軽量化以上に重要な変化が進行 する。それは、Unixがカーネルの中に閉じ込めようとした マルチ・スレッドのコンカレントなプログラミングを、一般の ユーザーも行う必要が出てきたということである。  それは、主要には、コンピュターと我々の、ユーザーイン ターフェイスの変化がもたらしたものだ。文字列しか表示 しない端末に変わって、X-WindowsやMSのWindows が登場すると、ユーザーは、マウス等のポインティング・デ バイスからの情報を、アプリの動作にリアルタイムに反映 するプログラムを書く必要が生まれる。かつては、スタ ティックな情報を表示するだけだったWebの画面も、 Ajaxの登場によって、動的に変化するものに変わる。
  138. 138. イベント・ドリブン・プログラミング  こうして、現在では、ユーザー・プログラマーもその利用を 要求される、コンカレント・プログラミングの一群は、「イベ ント・ドリブン・プログラミング」と呼ばれている。この考え方 は、理論的には、新しいものではない。Unix/Linuxカー ネルが行っていたことの大部分は、マルチ・スレッドのイベ ント・ドリブン・プログラミングである。  一般のプログラマーが、日常的に出会うコンカレント・プロ グラミングは、マルチ・スレッドであると意識すると否とに かかわりなく、ほぼ、イベント・ドリブン・プログラミングと考 えていい。スマートフォンのプログラミングも、Ajaxや React等のWebプログラミングも、サーバー側での Node.jsも、すべて、このイベント・ドリブンのスタイルで書 かれている。
  139. 139. Reactive プログラミング  UNIXの開発者たちが、カーネルの内部に閉じ込めようと した、コンカレントで非同期のプログラミング・スタイルを、 一般のプログラマーも、日常的に利用する。このことは、コ ンカレントなプログラミングが、今日では、容易になったこ とを意味してはいない。それは、相変わらず難しく、誤りを 起こしやすいものであることに変わりはない。  こうした中で、「Reactiveプログラミング」という、関数型の プログラミング・スタイルについての関心が高まっている。 それについては、以前のマルレクでも取り上げた。
  140. 140. コンカレントの特徴づけ 「非決定論的振る舞い」  現在では、コンカレント・プログラムの定義に、「非決定論 的振る舞いをするプログラム」という定義が与えられること がある。一見わかりにくいこの定義も、いつ、どこで、どん なタイミングでイベントが発生するのか、あらかじめ予想す ることができず、かつ、イベントの発生によって異なる結果 が返ってくるという、イベント・ドリブンのスタイルを念頭に 置くとわかりやすいかもしれない。  それでは、異なる複数のマシンの協調動作を舞台とする 「パラレル・プログラミング」は、「決定論的」に振舞うので あろうか? これは、面白い問題だ。確かに、どんなに巨 大なHadoopの処理も、与えられた同一の入力セットに対 して、同一の結果が返るという意味では、「決定論」的に 振舞う。
  141. 141. クラウド内部での イベント・ドリブン・プログラミング  ただ、「コンカレント・プログラミング」との対比で、「パラレ ル・プログラミング」を、「決定論的プログラミング」と特徴 づけることが可能だとしても、そのことは、クラウドが行う 処理が、全て「決定論的」だということにはならない。  クラウドOSのアーキテクチャーというシステムの視点で考 えても、多数の入力をリアルタイムに処理するアプリケー ションというユーザーの視点で考えても、クラウドの処理を イベント・ドリブンのスタイルで記述する必要性が、高まる のは確実だと思われる。  少し飛躍するが、僕は、それは、「関数型言語」が広く受け 入れられていく変化への、一つのステップだと考えている。
  142. 142. Our new search index: Caffeine 2010年6月8日 Google Webmaster Central Blog http://googlewebmastercentral.blogs pot.jp/2010/06/our-new-search- index-caffeine.html
  143. 143. Webの進化に対応し、高まるユーザーの期待に応える為に、 私たちは、Caffeineを構築しました。この図は、古いインデキシング システムがどのように働いていたかを、Caffeineとの比較で図示 したものです。
  144. 144. 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
  145. 145. Notifications: tracking work ユーザーは、"observer" をカラムに登録する •カラム中の行に書き込みが起きると実行される •それぞれのobserverは、新しいトランザクション で走る •書き込みごとに最大で一回実行される:メッセー ジの畳み込み DocumentPr ocessor DocumentPr ocessor DocumentPr ocessor RawDocumen tLoader RawDocument Loader Document Processor Document Exporter LinkInverter アプリケーションは、一連のobserverのつながりと して構造化される
  146. 146. Notificationsの実装 Dirty column: もしobserversが走るべき行なら設定 ランダム分散スキャン •中断している仕事を見つけ、observerをスレッドプール で走らせる •スキャンは効率的である。数ビットをみるだけ No shards or work units: nothing to straggle Dirty? balance:data ... Alice Yes 5: $15 Bob No 5: $5
  147. 147. Reactive Programming マルレク資料 「Reactive プログラミング」 http://bit.ly/1kkJelH
  148. 148. Reactive Extension (Rx) by Microsoft http://msdn.microsoft.com/en- us/data/gg577609.aspx
  149. 149. 講演資料  2010年 11月 DevCamp Keynote “Rx: Curing your asynchronous programming blues” http://channel9.msdn.com/Blogs/codefest/DC2010T010 0-Keynote-Rx-curing-your-asynchronous-programming- blues  2012年 6月 TechEd Europe “Rx: Curing your asynchronous programming blues” http://channel9.msdn.com/Events/TechEd/Europe/2012/ DEV413
  150. 150. Enumerable Observable EnumarableとObservable 時間の流れ どちらもデータの集りである
  151. 151. ObservableからObserverへの通知 OnNext (42) OnNext (43) OnCompleted OnNext (“Hello”) OnError (error) OnNext* (OnError | OnCompleted)?
  152. 152. ServerサイドでのRxの利用 Netflix --- RxJava “a library for composing asynchronous and event-based programs using observable sequences for the Java VM”
  153. 153. Netflix 関連情報  Netflix API architecture http://techblog.netflix.com/search/label/api https://speakerdeck.com/benjchristensen/  Re-architecture http://techblog.netflix.com/2013/01/optimiz ing-netflix-api.html  Hystrix https://github.com/Netflix/Hystrix
  154. 154. AWS Lambda Run code without thinking about servers. Pay for only the compute time you consume. https://aws.amazon.com/lambda/
  155. 155. AWS Lambda  AWS Lambda を使用すれば、サーバーのプロビジョニ ングや管理なしでコードを実行できます。課金は実際に使 用したコンピューティング時間に対してのみ発生し、コード が実行されていないときには料金も発生しません。 Lambda を使用すれば、実質どのようなタイプのアプリ ケーションやバックエンドサービスでも管理を必要とせず に実行できます。コードさえアップロードすれば、高可用性 を実現しながらコードを実行およびスケーリングするため に必要なことは、すべて Lambda により行われます。 コードは、他の AWS サービスから自動的にトリガーする よう設定することも、ウェブやモバイルアプリケーションか ら直接呼び出すよう設定することもできます。
  156. 156. Lambdaは、どう動くのか? AWS Lambda のコードをアップ ロードする 他のAWSサービス、 HTTP endpoint、モ バイルappからのトリ ガーを設定する Lambdaは、コードが トリガーされた時だけ、 計算に必要なリソース だけを使って走る 支払いは、実際に 利用した計算時間 のみ
  157. 157. リアルタイムファイル処理  Amazon S3 を使用して AWS Lambda をトリガーし、 アップロードしたデータを直ちに処理することができます。 例えば、画像のサムネイル作成、ビデオのコード変換、 ファイルのインデックス作成、ログの処理、コンテンツの検 証、およびリアルタイムでのデータの収集とフィルタリング などに使用できます。 とった写真 写真は、S3 バケットにアッ プロードされる Lambdaが トリガーされる Lambdaは、web, mobile, tablet向けに画像リサイズの 処理をする
  158. 158. リアルタイムストリーム処理  リアルタイムのストリーミングデータを AWS Lambda と Amazon Kinesis を使用して処理することで、アプリケーショ ンのアクティビティのトラッキング、注文のトランザクション処理、 クリックストリーム分析、データクレンジング、メトリックスの生成、 ログのフィルタリング、インデックス作成、ソーシャルメディア分 析、および IoT データのテレメトリと測定などが行えます。 ソーシャル・メディアのストリ ームがリアルタイムにKinesis にロードされる Lambdaは、トレンド・データの ハッシュタグを生成するコードを 走らせ、それをDynamoDBに 格納する ソーシャル・メディア のトレンド・データを 直ちにユーザーの 検索で使えるように なる Lambdaが トリガーされる
  159. 159. 抽出、変換、ロード  AWS Lambda を使用することで、DynamoDB テーブ ル内のデータの変更すべてに対して検証、フィルタリング、 ソート、またはその他の変換を実行し、変換されたデータ を別のデータストアにロードすることができます。 オンラインから 注文が入る 注文データは、一旦 処理用のDBに置かれる Lambdaは、データ変換の コードを走らせ、結果をData Warehouseに格納 データから、分析 レポートが生成さ れる Lambdaが トリガーされる
  160. 160. IoT バックエンド  AWS Lambda と Amazon Kinesis を使用して、IoT デバイスデータのテレメトリおよび分析のためのバックエ ンドを構築できます。 トラクターのセンサー データが、Kinesisに 送られる Lambdaは、センサーデータの 傾向を感知し、異常を見つけ、 故障部品の交換を注文する Lambdaが トリガーされる
  161. 161. モバイルバックエンド API Gateway  AWS Lambda と Amazon API Gateway を使用して、 API リクエストの認証と処理のためのバックエンドを構築 できます。Lambda によって、機能が豊富でカスタマイズ されたアプリケーション体験をより簡単に作成できます。 ユーザーがステータスの 更新をポスト アプリは、エンドポイントに REST APIの呼び出しをする Lambdaが トリガーされる Lambdaは、ユーザーリストを 探して、友人に、ステータスの 更新の通知をプッシュするコー ドを走らせる
  162. 162. ウェブアプリケーション API Gateway  開発者は、AWS Lambda を他の AWS サービスと組み合わ せることで、スケールアップまたはスケールダウンを自動的に 行う強力なウェブアプリケーションを構築し、複数のデータセン ターにまたがる可用性の高い設定で実行できます。スケーラビ リティ、バックアップ、または複数データセンターによる冗長性を、 管理に労力を費やすことなく実現できます。 S3中のお天気 アプリのフロント エンドコード ユーザーが、 アプリのリンク をクリック アプリは、エンドポイ ントにREST APIの 呼び出しをする Lambdaは、地方の気象 情報を取り出し、ユーザーに 返す Lambdaが トリガーされる
  163. 163. Facebook Parse Cloud Code Parse's vision is to let developers build any mobile app without dealing with servers. https://parse.com/docs/cloudcode/guide
  164. 164. Cloud Codeのセットアップ $ parse new MyCloudCode Email: ninja@gmail.com Password: 1:MyApp Select an App: 1 $ cd MyCloudCode -config/ global.json -cloud/ main.js -public/ index.html
  165. 165. Cloud Codeのdeploy Parse.Cloud.define("hello", function( request, response ) { response.success("Hello world!"); } ); $ parse deploy curl -X POST -H "X-Parse-Application-Id: …. " -H "X-Parse-REST-API-Key: …." -H "Content-Type: application/json" -d '{}' https://api.parse.com/1/functions/hello
  166. 166. Cloud Codeの実行 run Parse.Cloud.run('hello', {}, { success: function(result) { // result is 'Hello world!' }, error: function(error) { } }); ParseCloud.callFunctionInBackground("hello", new HashMap<String, Object>(), new FunctionCallback<String>() { void done(String result, ParseException e) { if (e == null) { // result is "Hello world!” } } });
  167. 167. Cloud Code Trigger  beforeSave Triggers  afterSave Triggers  beforeDelete Triggers  afterDelete Triggers
  168. 168. beforeSave Triggers サンプル Parse.Cloud.beforeSave("Review", function(request, response) { if (request.object.get("stars") < 1) { response.error("you cannot give less than one star"); } else if (request.object.get("stars") > 5) { response.error("you cannot give more than five stars"); } else { response.success(); } }); Parse.Cloud.beforeSave(Parse.User, function(request, response) { if (!request.object.get("email")) { response.error("email is required for signup"); } else { response.success(); } }); 妥当性チェック: 星の数は、1から5まで 妥当性チェック:サインアップ には、e-mailが必要
  169. 169. クラウド・モバイル・インターフェース クラウドの最大のクライアントは、モバイルである。た だ、クラウドとモバイルの関係は、Webアプリのモデ ルのような、単純なサーバー・クライアントの関係では ない。
  170. 170. Facebook : “Parse” https://parse.com/ マルレク資料 「Facebook Parseの世界」 https://goo.gl/5pxaDb
  171. 171. Amazon : “AWS Mobile SDK” http://goo.gl/Nc5Bta
  172. 172. Microsoft : “Azure Mobile App Services” http://goo.gl/dcWlRF
  173. 173. Twitter : "Fabric" https://goo.gl/dV3Zsb
  174. 174. クラウドからのPush
  175. 175. Parse Old Web Apps Push Pull
  176. 176. https://goo.gl/4V7vRL Google GCM
  177. 177. https://goo.gl/lhJ8bl Apple APNS
  178. 178. Facebook Push Notification https://goo.gl/CuLNqf
  179. 179. API Gateway API Gatewayは、マイクロ・サービスのデザイン・パ ターンの一つ。有名な例は、Netflixのもの。 API Gatewayは、サーバーとクライアントをつなぐも のだが、現代では、それは、主要には、クラウドとモバ イルをつなぐものになる。
  180. 180. Rxの発見は、システムの Re-Atchitectureから始まった
  181. 181. ネットワーク・トラフィックは、 APIの改良で、劇的に改善した 9つあったネットワークの呼び出しは 1つになり、WANでのネットワーク 遅延は一回だけになった クライアントのロジ ックは、サーバに移 され、20以上の呼び 出しが削除された
  182. 182. モバイルバックエンド API Gateway  AWS Lambda と Amazon API Gateway を使用して、 API リクエストの認証と処理のためのバックエンドを構築 できます。Lambda によって、機能が豊富でカスタマイズ されたアプリケーション体験をより簡単に作成できます。 ユーザーがステータスの 更新をポスト アプリは、エンドポイントに REST APIの呼び出しをする Lambdaが トリガーされる Lambdaは、ユーザーリストを 探して、友人に、ステータスの 更新の通知をプッシュするコー ドを走らせる
  183. 183. ウェブアプリケーション API Gateway  開発者は、AWS Lambda を他の AWS サービスと組み合わ せることで、スケールアップまたはスケールダウンを自動的に 行う強力なウェブアプリケーションを構築し、複数のデータセン ターにまたがる可用性の高い設定で実行できます。スケーラビ リティ、バックアップ、または複数データセンターによる冗長性を、 管理に労力を費やすことなく実現できます。 S3中のお天気 アプリのフロント エンドコード ユーザーが、 アプリのリンク をクリック アプリは、エンドポイ ントにREST APIの 呼び出しをする Lambdaは、地方の気象 情報を取り出し、ユーザーに 返す Lambdaが トリガーされる
  184. 184. まとめ クラウドOS進化の方向  コンテナーでのタスク管理への収斂  分散ファイル・システムの多様化  クラウド内でのイベント・ドリブン処理と 関数型言語的アプローチの浸透  クラウド・モバイル・インターフェース

×