Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
More from maruyama097
More from maruyama097 (20)
Cloud OSの進化を考える
- 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. 「ツールと優秀なプログラマーだけが、マルチ・スレッドについて考え ることができる。」 Jim Waldo 「どうして、みんな、もっと非同期のプログラム書かないんだい？ イベント・ループとコールバックなら簡単だろう！」 伝 Ryan Dahl 「邪悪は、状態の中に潜む。間違い。もう一度言い直そう。邪悪は、 変更可能な状態の中に潜む。」 Akkaについて Jonas Bonér
- 5. クラウド研究会の再開にあたって 「クラウド」という言葉が広く知られるようになったのは、 2006年11月に開催されたWeb 2.0 Summitからだと 思う。このコンファレンスの会場で、AmazonのJeff Bezosは、EC2とS３のリリースを発表した。 丸山は、2007年2月のマルレクで、「Cloud -- Google File System とAmazon S3/EC2」というテーマで講演 をしたのを皮切りに、2008年8月から2011年9月まで、 48回クラウド研究会を主催してきた。 当時の技術的関心は、Scale out Architecture, ScalabilityとAvailability, Eventually Consistency, MapReduceの実装等を中心としたものであり、実践的に は、クラウド技術の受容がITビジネスにとって重要である ことを訴えるものだった。
- 6. クラウド研究会の再開にあたって 2011年当時、日本でもパブリック・クラウドの市場が立ち 上がり、クラウドの一般の企業への普及に焦点が移りつ つあった。「市場のことは、市場にまかせよ」 当初の技術 的・理論的な関心とIT業界を対象としたクラウド研究会の 活動に、区切りをつけた。 クラウドの登場から約10年が経過した。市場での激しい 競争を通じて、クラウドの受容は大きく進んだ。同時に、ク ラウドをめぐる技術的あるいはビジネス的関心も大きく変 わりつつある。あらためて、クラウドの技術的な動向と市 場の動向を考えたいと思う。 クラウド研究会の再開にあたって、丸山が注目する、現在 のクラウドの技術的な動向のオーバービューを、小論で与 えたいと思う。
- 7. Agenda UNIXとの比較でクラウドOSを考える コンテナーでのタスク管理への収斂 分散ファイル・システムの多様化 クラウド内でのイベント・ドリブン処理と 関数型言語的アプローチの浸透 クラウド・モバイル・インターフェース
- 9. goo.gl/tw9F8c Summary of Jim Waldo‘s Keynote goo.gl/DBtmv5 まず、システムの複雑さについて考えてみよう
- 10. 複雑さにおける質的な飛躍 線形実行 (SEQ) – 人生は善良でシンプルであった マルチ･スレッド (MT) – ツールと優秀なプログラマが MTについて考えることが必要 マルチ･プロセス (MP) – カーネルの開発者だけでな く誰もが利用できる。実際には、MTの前に起きた。 マルチ・マシン (MM) 同一ネットワーク上の – マルチ・プロセスと同じではないのだが、ある人たちは、 そう考えている 信頼できないマルチ・マシンたち(MMU) – 本質的に は、Webの世界である
- 12. それぞれの段階を通り抜ける際、 我々は、何かを失う マルチ・プロセスからマルチ・マシンへ： 我々は、状態を失う。「システム」のグローバルな状態とい うのは、虚構である。興味深い分散システムには、整合的 な状態というものは存在しない。 （Lamport:http://research. microsoft.com/users/lamport/pubs/pubs.html ） 分散OSのプロジェクトは、グローバルな状態を導入しよう としたが、大々的に失敗した。 信頼できないマルチ・マシンたちへ： 誰を信ずることが出来るか分からない難しい状況の中で、 我々は信頼を失う。
- 13. しかし、我々は何かを得てきた Seq to MT : パラレル処理 MT to MP : プロセスの分離(安全を与える) MP to MM : 独立した失敗 (何かまずいことが起きても、 システムの部分は生きのこる) MM to MMU : スケール (webスケール、インターネット スケール). 誰か他の人のリソースを利用せよ（あるいは、 他の誰かが、我々のリソースを利用することを認めよ） MP->MM で発生する Partial Failureへの対応としての Leaseのアイデアは、Waldoの大きな仕事である。
- 14. Multi Process から Multi Machine へ Jim Waldoの区分で言うと、UNIXからクラウドOSへ の変化は、Multi Process から Multi Machine へ の変化だということになる
- 17. UNIX Kernel File Subsystem Process Control Subsystem System Call Hardware User Program IPC Scheduler Memory Management Hardware Control Device Driver
- 18. UNIX Kernelの主要な構成要素 Process Control Subsystem File Subsystem IPC / Scheduler / Memory Management / Hardware Control Device Driver
- 19. UNIXとクラウドOSとの対応 コンテナーでのタスク管理 UNIXプロセス管理 分散ファイル・システム UNIXファイル・システム クラウド内でのイベント・ドリブン処理 UNIX Kernel内の割り込み処理 モバイル・インターフェース デバイス・ドライバー
- 22. forkとexec
- 23. fork 領域の確保とコピー Unixは、単一の仮想メモリー空間で動くので、「実行環 境」を構成する「リソース」は主要にはメモリーである。 領域をmallocで確保し、その上へデータとスタックをコ ピーする。プログラム（Text）は共有される。 そのほかにプロセスのcontextの設定が必要である。
- 27. Container マルチ・マシンでの実行環境の準備 処理のひとかたまりに、どのような名前を使うか、その他、 いろいろ違いはあるが、AWSのContainer Manager, Mesos, Kubernete（その原型のBorgも）の行っている ことは、マルチ・マシン上での「実行環境」のallocateとプ ログラムの実行、双方の管理で、基本的には同じことであ る。クラウド上のContainerが注目される所以である。
- 28. Google Borg “Large-scale cluster management at Google with Borg” https://goo.gl/aN03bI
- 29. クラウドを支える技術 「EC2/S3のようなサービス提供ができるためには、ネット ワーク上に分散して存在している物理的なディスクや物理 的なサーバを、仮想化して論理的に管理して、稼働してい ないものはリソース・プールに登録して、変動する要求に 応じて動的にそこからリソースを取り出して仕事を割り当 てて、スケーラブルなサービス提供を保障しなければなら ない。AmazonのEC2/S3のサービス開始は、クラウドを 支えるこうした課題の重要性に、皆の眼を向けさせた。 」 「クラウドの成立過程とその技術的特徴について」 情報処理 Vol.50 No.11 Nov. 2009 https://goo.gl/SdxUjf しかし、その実装は不明なままだった
- 30. 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 ・・・・・・・・ ・・・・ こういうダイアグラムは与えられたが、 こうした構成を動的に可能にするメカ ニズムは伏せられたままだった
- 32. 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年以上、隠していたことになる。
- 33. 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 数十万のジョブ 数千のアプリケーション 数万のマシン
- 34. 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の急速な進化の、もっともよく保たれた秘密」！！
- 35. Mesos http://mesos.apache.org/ マルレク資料 「大規模分散システムの現在 - Twitter 」 https://goo.gl/6Ai4cm
- 36. Mesosとは何か？ 分散システム・カーネル Mesosは、抽象のレベルが異なるだけで、Linuxカーネ ルと同じ原理に基づいて構築されている。 Mesosのカーネルは、全てのマシン上で走り、 （例えば、 Hadoop, Spark, Kafka, Elastic Searchといった ）ア プリケーションに、データセンター全体とクラウド環境をま たいで、リソース管理とスケジューリングのAPIを提供する。
- 37. Mesosプロジェクトの特徴 数万ノードへのスケーラビリティ ZooKeeperを利用した、フォールト・トレラントなレプリ ケートされたマスターとスレーブ Dockerコンテナーのサポート Linux Containerによる、ネーティブなタスク間の分離 複数のリソース (memory, CPU, disk, ports)のスケ ジューリング 新しいパラレル・アプリケーションを開発するための Java, Python, C++ のAPI クラスターの状態を見るためのWeb UI
- 39. PaaS and Long Running Big data processing Batch scheduling Data storage Mesos で走る主要なアプリ https://goo.gl/1oDvTc
- 41. Framework
- 42. マスターとリソース・オファー マスターは、アプリケーションがリソースのオファーを行う ことで、アプリケーション間の細かな粒度でのリソース （CPU, RAM等）の共有を可能にする。 それぞれのリソース・オファーは、それらのリストを含んで いる。マスターは、与えられた（fair sharing, strict priorityといった）組織的なポリシーに応じて、どれだけ のリソースをそれぞれのフレームワークに提供するかを決 定する。 多様なポリシーの集合をサポートするために、マスターは、 プラグインのメカニズムを通じて、容易に新しいモジュー ルを割り当てられるように、モジュラー・アーキテクチャー を用いている。
- 43. schedulerとexecutor Mesosの上で走っているフレームワークは、二つのコン ポーネントからなる。一つは、フレームワークの scheduler（スケジューラー）で、マスターに提供される べきリソースを登録する。もう一つは、 executor プロセ スで、スレーブノード上で起動されてフレームワークのタス クを実行する。 マスターは、どれだけの量のリソースが、それぞれのフ レームワークに提供されるかを決定し、その一方で、フ レームワークのスケジューラーは、どの提供されたリソー スを使うかを決定する。フレームワークが、提供されたリ ソースを受け取る時には、Mesosに、実行しようと思って いるタスクの記述をMesosに渡す。その代わりに、 Mesosは、対応するスレーブ上で、タスクを起動する。
- 45. リソース・オファーのプロセス ① 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>でという情報と一緒に。
- 46. リソース・オファーのプロセス ④ 最後に、Master は、Slave 1 にタスクを送る。それは、 Slave1 の Framework1 の実行エンジンに適切なリ ソースを割り当てる。こうして、二つのタスクが起動される （図での、Slave 1の点線で囲まれた部分）。Slave 1の、 1 CPUと 1 GBのメモリーは、アロケートされていないの で、Framework 2のタスクに使われるかもしれない。 このリソース提供のプロセスは、タスクが終了して、新しいリ ソースがフリーになった時には、繰り返される。
- 48. Apache Aurora https://github.com/apache/aurora/blob/ma ster/docs/tutorial.md マルレク資料 「大規模分散システムの現在 - Twitter 」 https://goo.gl/6Ai4cm
- 49. 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”と呼ばれることもある）を生成する命令からなる。
- 50. 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の抽象を 与える。
- 52. Auroraの階層 Auroraは、taskからなるjobを管理する。 Mesosは、processからなるtaskを管理する。 Thermosは、processを管理する。 全ては、 .aurora 設定ファイルで定義される。
- 54. 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 ...
- 55. AWS re:Invent 2014 Announcing Amazon EC2 Container Service https://goo.gl/Za7QqP
- 56. AWS re:Invent 2014 Announcing Amazon EC2 Container Service https://goo.gl/Za7QqP 走るコンテナが増えて行く ... 二つのコンテナで走るサービスも
- 57. AWS re:Invent 2014 Announcing Amazon EC2 Container Service https://goo.gl/Za7QqPサービス本体のデプロイ
- 58. AWS re:Invent 2014 Announcing Amazon EC2 Container Service https://goo.gl/Za7QqP RabbitMQ Redis Node.js NGINX Audio Processor スケールさせる
- 59. AWS re:Invent 2014 Announcing Amazon EC2 Container Service https://goo.gl/Za7QqPスケールさせる
- 60. AWS re:Invent 2014 Announcing Amazon EC2 Container Service https://goo.gl/Za7QqPTerminate する
- 61. 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
- 62. Azure Container Service “Azure Container Service: Now and the Future” Ross Gardler 2015/09/29 https://goo.gl/A7qvTu
- 63. 我々が、本日、 アナウンスしたものは何か？ 我々は、 Azure Resource Manager (ARM) のため の Azure Container Service Resource Provider を提供する。 このサービスの最初のプロトタイプ実装を、Azure QuickStart Templateの形で利用可能にした。
- 64. 我々が、本日、 アナウンスしたものは何か？ Azure Resource Managerをテコとして、 Azure Container Service は、 Docker, Apache Mesos, Marathon and Docker Swarmであらかじめ設定され たホスト達のクラスターを簡単に、生成し管理することが 可能となる。 これによって、超スケーラブルで、エンタープライズ品質の Azure クラウドと、試され済みのオープンソース技術を結 合して、コンテナー・アプリを構築する全てのチームが必 要とするであろう、コンテナーのデプロイ、オーケストレー ション、サービス管理の基礎を提供する。
- 65. What can you try today?
- 66. Azure Container Service は、 どこに向かおうとしているか？ 来たるべき ARMのためのAzure Container Service Resource Providerは、 ユーザーが、 標準的なARM APIを用いてクラスターを定義・管理することを可能にする。 現在では、この設定には、数千行のコードを必要とするの だが、必要とされる技術の深い理解に注意を払う必要なく、 それが可能となる。 我々のリソース・プロバイダーは、こ の複雑さを抽象化して、数千行のコードを、デフォールト の設定では、数十行に削減するだろう。この単純化は、こ うした複雑なクラスターのデプロイと管理にあたって、設定 エラーがより少ないものになることを意味する。
- 67. 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をサポートし、こうして、ユー ザーのニーズにもっとも適切な、どのようなオペレーショ ン・システムでも、ユーザーがコンテナーを管理できること を保証することとなった。
- 68. Google Container Engine “What is Google Container Engine? ” https://cloud.google.com/container- engine/docs/
- 69. Google Cloud Platform で Docker コンテナを実行し、Kubernetes で管理 Google Container Engine は、Docker コンテナの実 行を支える強力なクラスタ マネージャおよびオーケスト レーション システムとして機能します。ユーザーが定義す る要件（CPU やメモリなど）に基づいてコンテナをクラスタ にスケジューリングし、自動的に管理します。オープンソー スの Kubernetes システム上に構築されており、ユー ザーはオンプレミス、ハイブリッド、パブリック クラウド イ ンフラストラクチャを柔軟に利用できます。 わずか数分で仮想マシンのマネージド コンテナ クラスタ をセットアップし、デプロイの準備を整えることができます。 クラスタではロギングやコンテナのヘルス チェックといっ た機能が提供され、アプリケーションを簡単に管理できま す。 https://cloud.google.com/container-engine/
- 70. Google Cloud Platform で Docker コンテナを実行し、Kubernetes で管理 予約する CPU/メモリ量、レプリカの数、キープアライブ ポリシーといったコンテナの要件は、シンプルな JSON 形 式の設定ファイルで宣言します。Container Engine は 宣言に沿ってコンテナのスケジューリングを行い、要件が 満たされるようにアプリケーションを能動的に管理します。 Red Hat、Microsoft、IBM、Mirantis OpenStack、 VMware などは、自社プラットフォームへの Kubernetes の統合に取り組んでいます（こうした取り組 みを行う企業は増え続けています）。その結果として、 ワークロードの移行や複数のクラウド プロバイダーの利 用がもっと簡単になります。 https://cloud.google.com/container-engine/
- 71. CONTAINER ENGINE の特長 フルマネージド プライベートな Container Registry スケーラブル Docker のサポート ロギング ハイブリッド ネットワーキング
- 73. Docker Swarm 分散アプリケーションは、その本性上、同様に分散した計 算リソースを必要とする。Docker Swarmは、Docker エンジンのグループを、一つの仮想的なDockerエンジン に変える、ネーティブなクラスタリングの能力を提供する。 これらのプールされたリソースを用いて、ユーザーは、あ たかも一つの巨大なコンピュータを走らせているかのよう に、アプリケーションをスケールアウトできる。
- 75. Docker Swarm Compatible with Docker Tools： Docker Swarm は、標準のDocker APIを利用してい るので、既にDockerデーモンとコミュニケーションしてい るどのようなツールも、Swarmを透過的に複数のホスト にスケールできる。 Smart Container Scheduling ビルトインされたスケジューラーは、ノードタグやアフィニ ティー、さらには、スプレッドやビンパック等々のストラテ ジーといったフィルターを備えている。これらのフィルター は、コンテナーを配下のノードに割り当てて、パフォーマン スとリソースの利用を最大化できる。
- 76. Docker Swarm Pluggable Schedulers Swarm は、ビルトインされたスケジューラーを備えてい るが、大規模な製品の配備には、簡単にMesosのバック エンドをプラグインできる。この時でも、Dockerのプラグイ ンを使い続けて、開発経験は一貫して同じままである。 Pluggable Node Discovery クラスターの中でノードを見つけるために、Docker Swarmは、何がユーザーの開発環境に最適かに応じて、 次のようなものを利用できる。ホスト上のディスカバリー・ サービス、スタティックなファイル、etcd、consul、 zookeeper。
- 78. OS とファイルシステムの結びつき UNIXを特徴づけるのは、「プロセス」と「ファイル」という二 つの概念である。メタファーとしては、「ファイルシステム」 という「森」に、「プロセス」という「生き物」が生きていると いうもの。入力も出力もデバイスもプロセスさえも、ファイ ルと結びついている。 近代的なOSに、ファイルシステムが、その中核部分として 組み込まれる上で、UNIXは決定的な影響を与えた。ただ、 それは、OSの具体的な歴史の中では当然の流れでは あっても、論理的には必然とは言えないと思っている。 Turing Machineのテープは、ファイルに見えるかもしれ ないが、あれは、メモリーだと思ったほうがいい。ノイマン 型コンピュータの定義で、本質的に重要なのは、メモリー とCPUで、ストレージではない。
- 81. ファイルシステムに求められるもの ファイルシステムが担保している能力は、大雑把に言って 二つある。一つは、データの永続性の保証であり（それは、 相対的なものだ）、もう一つは、メモリーに入りきらない量 のデータの作業領域を提供することである。 前者の永続性の主要な担い手は、ファイルだけとは限ら ない。CPU/CPU Cache/Memory/Storage Cache /Storageは、永続性の時間的な階層を形成している。 後者のメモリーに入りきれない量のデータの問題は、処理 のスケールをどう担保するのかという問題と直結していて、 現代のマルチ・マシン・システムの進化の主要なドライビ ング・フォースである。データの量は、階層的にシステム の質を決める。（ ”Big Data”は、のっぺらぼうだ）
- 82. ファイルシステム進化の新しい段階 マルチ・マシンのOSでのファイルシステムは、まず、GFS, HDFS等の「分散ファイルシステム」として始まった。 続いて、ScalabilityとEventually Consistentを特徴と する「Key/Value データストア」が登場する。もちろん、 GoogleのBigTableがトップランナーだ。BigTableによく 似たFacebookのCassandra、リング状のP2P/DHT ベースのMSのAzure Data Store、それと同じような構 造を持つAmazonのDynamo ... 重要なことは、大規模分散システムでは、この分野で、 「分散ファイルシステム」「Key/Value データストア」に続 く、「第三の波」が起きていて、活発で多様な変化が続い ていることだ。
- 83. 進化の方向？ 残念ながら、この変化がどのような方向で収斂するのか、 あるいは、収斂するものなのかについても、僕には予想 がつかない。「この分野」と書いたが、どうも、「分散ファイ ルシステム」や「ストレージ」、「データストア」という言葉で くくるのは、気持ちが悪いところがあるのだ。多分、まだ、 適切な言葉がないのだ。 ちなみに、Crawlerが集めた膨大なWebページ情報の Index付けの主役の座を MapReduce は既に降りてい るのだが、BigTableは機能強化を繰り返して、いまも現 役のままだ。BigTableなしに、Googleのサービスを考え るのは難しい。クラウドでは、第一義的な永続性保持の 「器官」は、Key/Value データストアなのかもしれない。 （歴史的には）
- 84. Domain Specific な多様性 ここでは、ファイルシステムの多様な「進化」の例として、 次のものを取りあげる。 Google Spanner 分散データベースの整合性担保 Google BigQuery 木構造のハードウェア Apache Spark FS上のデータへの関数型アプローチ Amazon Aurora Log Structured FS Apache Kafka FS上でのデータフロー処理 Microsoft Trinity 分散メモリー上でのグラフ処理
- 85. Google Spanner “Spanner: Google’s Globally-Distributed Database” http://goo.gl/ll9J1B マルレク資料 「大規模分散システムの現在 --- GFS,MapReduce, BigTableはどう進化したか」 http://bit.ly/10yW52d Spanner論文翻訳版：http://bit.ly/1pYP5S2
- 86. Google Spanner Spannerは、Key/Value データストアでは未解決だった Scalabilityと整合的なTransactionの問題に折り合い をつけた。ただ、これで一件落着かというとそんなことはな い。データベース／データストアの「現実」との折り合いの つけ方は様々だからだ。現実に、Spannerを使っている のは、Googleだけだ。その技術をオープンソース化しよう というインセンティブも大きなものにはなっていない。 ただ、要素技術としての正確な時計による整合性の管理 （「相対的な」タイムスタンプあるいはバージョニングによる 整合性管理の技術は、以前からあった。Snap Isolation）は、ただちに、BigTableの機能強化にも取り 入れられているのは、注目すべきことだろう。
- 87. Spannerとは何か？ 分散マルチバージョンデータベース 汎用のトランザクション(ACID) SQL言語のサポート スキーム化されたテーブル Semi-relationalなデータモデル 既に、製品として稼働している Googleの広告データのストレージとして sharded MySQL を置き換えている OSDI 2012 87
- 88. Spannerとは何か？ 特徴: Lock-freeな、分散readトランザクション 特質: 分散トランザクションの外的整合性保証 グローバルなスケールでは、最初のシステム 実装: Concurrency controlとReplicationと2PCの統 合 正当性とパフォーマンス 可能にした技術: TrueTime Interval-basedなグローバル時間 OSDI 2012 88
- 89. タイムスタンプとグローバル・クロック 書き込みのトランザクションについては、厳密なtwo- phase lockingを適用する。 ロックが保持されている間、タイムスタンプを割り当てる。 T Pick s = now() Acquired locks Release locks OSDI 2012 89
- 90. 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 ± ε
- 91. Google BigQuery “Dremel: Interactive Analysis of Web- Scale Datasets” http://goo.gl/yAD5dI マルレク資料 「Google Dremel」 https://goo.gl/Lpnwbf
- 92. Google BigQuery プロジェクト名は、Dremel。Dremelは、分散検索エンジ ンで利用されている木構造のアーキテクチャーをしていて、 カラム単位で分割されたデータ構造を利用する。カラム型 のデータ・ストアは、リレーショナルなデータの解析には採 用されてきたが、ネストしたデータ構造へのその拡張は、 行われてこなかった。数千台のノードが、一斉に動作する。 その動作を、何年か前のマルレクで、パラパラマンガ風に 解説したことがある。https://goo.gl/L0JpAJ これは、 単なるファイルシステムの組み合わせでも、単なるデータ ベースでもない。全く新しい構成物なのだと思う。
- 93. Google Dremel
- 94. 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
- 95. 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 サンプルの格納状態
- 97. 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
- 98. 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
- 99. Apache Spark もちろん、MapReduceにインスパイアされているのは明 らかなのだが、OSの中核にファイルシステムがあるという のが、Unixの基本思想だとすれば、Sparkは、その思想 を受け継いでいるのかもしれない。 SparkのResilient Distributed Datasets (RDDs)は、確かに、マルチ・マシン環境での、新しい質 を備えた、Unixファイルシステムの後継者にふさわしいよ うに見える。（分散ファイルシステムは、それ自体としては、 Unixファイルシステムの量的拡大に過ぎない。） そこでの基本操作は、read/writeではなく、 Transformation（lazy評価される）とActionである。こ れらの操作は、「関数」で定義される。
- 100. Apache Spark Sparkは、関数型プログラミングのスタイルを、メモリー上 のデータ操作から、分散したファイルシステム上のデータ 操作に拡大したものと考えることができる。 「ブロードキャストされる変数」「アキュムレーター」という考 えも、少しベタだが、興味深いものだ （おそらく、こうしたア プローチは、純粋に「関数型」的ではないような気がする）。
- 101. Resilient Distributed Datasets (RDDs) Spark は、resilient distributed dataset (RDD) （弾力的分散データセット）というコンセプトの周辺を回転し ている。それは、パラレルに操作されることが出来る、フォー ルト・トレラントな要素の集合である。 RDDを生成するには二つの方法がある。一つは、ドライ バー・プログラムの既存の集合をparallelizingする方法 であり、もう一つは、共有ファイルシステム、HDFS、Hbase、 あるいはHadoopにInputFormaを提供する任意のデー タ・ソースといった、外部のストレージシステムのデータセット をreferencingする方法である。
- 102. RDDのオペレーション RDDは、二つのタイプの操作をサポートしている。ひとつ は transformations で、既存のデータセットから新し いデータセットを生成する。もう一つの actions は、 データセット上の計算の実行を終了してからドライバー・プ ログラムに値を返す。 例を挙げれば、 mapは transformationである。それ は、データセットの各要素を、ある関数を通じて渡して、そ の結果の新しいRDDでの表現を返す。 一方で、 reduceは actionである。 それは、RDDの全 ての要素を、ある関数を用いて集約して、最終結果をドラ イバー・プログラムに返す。
- 103. Local vs. cluster modes cluster modeでは、ジョブを実行するために、Sparkは、 RDDのオペレーションをタスクに分割する。タスクのそれぞ れは、executorで操作される。実行に先立って、Sparkは、 closureを計算する。closureというのは、この計算をRDD で実行するために、executorに見えなければならない変数 とメソッドのことである。このclosureは、シリアライズ化され て、各executorに送られる。 local modeでは、一つのexecutorがあるだけである。だ から、全てが同じclosureを共有している。 しかし、他のモードではそうではない。別々のワーカー・ノー ドで走るexecutorは、それぞれ、自分のためのclosureの コピーを持っている。
- 104. Broadcast Variables ブロードキャスト変数は、タスク毎に変数のコピーを送り出 すことなしに、それぞれのマシンがread-onlyの変数の キャッシュを持つことをプログラマーに可能とする。 それらは、例えば、全てのノードに効率的なやり方で大き な入力データのコピーを持たせる時に利用できる。Spark は、通信コストを削減するために、効率的なブロードキャ ストのアルゴリズムを使って、ブロードキャスト変数を分散 させようとも試みる。
- 105. Broadcast Variables Sparkのactionは、分散した“shuffle”操作で分離され たステージを通じて実行される。Sparkは、それぞれのス テージ内のタスクが必要とする共通のデータを、自動的に ブロードキャストする。 こうしたやり方でブロードキャストされたデータは、シリアラ イズ化されてキャッシュされ、それぞれのタスクが走る前 に、ディシリアライズ化される。このことは、複数のステー ジをまたいだタスクが同じデータを必要とするか、あるい は、ディシリアライズ化された形式でのデータをキャッシュ することが重要な場合のみ、明示的にブロードキャスト変 数を生成することが役に立つということを意味している。
- 106. Accumulators Accumulator は、関連した操作を通じて、「追加」のみを 行う変数である。それゆえ、効率的にパラレル処理でサ ポートされる。それらは、（MapReduceでの） counterや sumの実装に利用することができる。 Spark は、ネイティブには、数値型のaccumulatorをサ ポートしている。プログラマは、新しい型のサポートを追加 できる。もし、 accumulator が、名前付きで生成されれ ば、それは、SparkのUIに表示される。この機能は、ス テージの実行の進捗を理解するには役に立つ。
- 108. New Apache Spark Developer Training: Beyond the Basics http://goo.gl/4Segjx
- 109. Amazon Aurora Amazon RDS for Aurora https://aws.amazon.com/rds/aurora/ マルレク資料：「Amazonのクラウド・データベース Aurora」 http://bit.ly/1DPJ3yf
- 110. Amazon Aurora 大規模なシステムではないが、リレーショナル・データ ベースのストレージを、Log Structured File System で再構成しようという試み。これは面白い。RDBに関わる 様々のオペレーションが、劇的に改善される。今後のクラ ウド上のRDBの台風の目になるだろう。 ログとストレージとメモリー・キャッシュ 3者を、どう組み合 わせるかは、BigTableの心臓部であるSSTableでも、重 要だった。基本的には、同じアイデアである。 Write-Ahead-Log(WAL)のテクニックは、データベース の整合性担保のためだけではなく、いまや、大規模分散 システムのアーキテクチャーの一部になろうとしていること は興味深い（Facebookのアーキテクチャー）。
- 111. Amazon Aurora データベースに適用されたサービス 指向アーキテクチャー ログとストレージのレイヤーを、マルチ テナントで、scale outする、データ ベースに最適化されたストレージ・サー ビスに移動する Amazon EC2, Amazon VPC, Amazon DynamoDB, Amazon SWF, Amazon Route 53 といった他のAWS のサービスと統合する 連続的なバックアップのために、Amazon S3 と統合する
- 113. 一個だけのデータ Foo Aは、inodeで、データFoo をポイントしている。 二個目のデータ Barを追加 A’は、新しいinodeで、 データ Bar とデータ Fooを ポイントしている。 http://bit.ly/19EWBQN LFSの基本構造 inodeとデータ A A A’
- 114. 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’’’
- 115. 一個だけのデータ 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’
- 116. 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の値が復元できる。
- 117. Roll-Forward - Crashからの回復 最終 Checkpoint 最後に書き込ま れた inode Checkpoint Region Checkpoint Region Crashからの回復は、最後に行われたCheckpointから始めて 最後に書き込まれた inodeを見つけることに帰着する。あとは、 適宜、失われたリンクを貼り直せばいい。 Scan
- 118. 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
- 120. Cache, Log and File System 2006年 Google: BigTable http://bit.ly/1BgmxYs 2011年 Google: LevelDB http://bit.ly/1943U47
- 121. 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
- 122. Tabletの表現 / SSTable Write Buffer in Memory Random-Access Append–Only Log on GFS SSTable on GFS SSTable on GFS SSTable on GFS mmap … Tablet
- 123. Write Op Read Op memtable GFS Memory SSTable files Tablet Log
- 124. Apache Kafka Apache Kafka: A high-throughput distributed messaging system http://kafka.apache.org/
- 125. Apache Kafka Kafkaも、ログの重要性を示す一つの例かもしれない。 Pub/Sub型のメッセージング・システムは昔からあるが、 その実装に、分散ログの手法を使おうというもの。 ただ、それは実装よりの見方で、実際に果たす役割は、マ ルチ・マシンのクラスター上で、メッセージのパーシステン シーを担保し、確実なデリバリーを保証する。Unixで言え ば、パイプやリダイレクトの機能を果たす。 関数型のアプローチとは、ちょっと違うのだが、データフ ロー型のアプローチを取る時には、Kafkaは、大きな役割 を担って行くことになるだろう。
- 127. Log それぞれのパーティションは、順序付けられた複製不可 の連続的に追加されたメッセージのシークエンス、すなわ ち、コミット・ログである。パーティション中のメッセージに は、offsetと呼ばれる シーケンスIDが割り当てられ、そ れはパーティション中のメッセージを一意に指定する。 ログ中のパーティションは、幾つかの目的に役立っている。 第一に、一つのサーバーにフィットするサイズを超えてロ グをスケールすることを可能にする。それぞれの個々の パーティションは、それをホストするサーバーに会っていな ければならないが、topicは多くのパーティションを持つこ とができるので、任意の大きさのデータを扱うことができる。 第二に、それは、パラレル処理の単位として機能する。
- 129. Microsoft Trinity “Graph query and analytics with Trinity” http://goo.gl/4TPOA7 マルレク資料「大規模グラフデータ処理」 http://bit.ly/1zK41gv
- 130. Microsoft Trinity Trinityは、グラフデータ処理クラスター。大規模グラフ データ処理では、現在は、GoogleのPregelとそのオープ ンソース・クローンであるGiraphが主力である。それは、 Bulk Synchronous Parallel（BSP）と呼ばれる、ファイ ルベースのバッチ処理のモデルに基づいている。ちなみ に、MapReduceもBSPの一種である。 MS Trinity は、インメモリーkey/valueストアをベース にしている。ただし、Trinityは、「メモリー・クラウド」と呼 ぶ、「分散メモリー」のシステムを構築する。パーシステン シーという観点から見れば、「分散ファイルシステム」と「分 散メモリーシステム」は、データ保持の時間長が異なるだ けで、考え方は同じようなものである。
- 132. Trinity 分散インメモリーkey/valueストア オンライン検索処理グラフ・データベース Facebook上で3 hopの範囲の220万のユーザー検 索を 100ms以下の時間で entity検索等のグラフベース・サービスの基礎 オフライングラフ解析パラレル・プラットオフォーム 10億ノードのグラフ処理を60秒で グラフ解析の基礎
- 134. Memory Cloudとメモリーtrunk Memory Cloudは、2p個のメモリーtrunkから 構成される。それぞれのマシンは、複数のメモ リーtrunkをホストする。 一つのマシン上のローカル・メモリーを複数の trunkに分割するのは、次の二つの理由による。 1. trunkレベルのパラレル計算は、ロックのオー バーヘッドなしに実行出来る。 2. 一つの巨大なハッシュテーブルのパフォーマンス は、ハッシュの衝突の故に最適ではない。 それぞれのメモリーtrunkは、TFS（HDFSのよう な）にバックアップされる。
- 135. Key/Value ストア Memory Cloud上に、Key/Value ストアを構築 する。 Keyは、グローバルにユニークな64bitの識別子、 Valueは、任意長のblobである。 Memory Cloudは、複数のマシン上に分散して いるので、Key/Valueペアの位置を、マシン上の 物理アドレスでは指定出来ない。 Trinityは、Key/Valueペアの位置を指定するの に、ハッシュのメカニズムを利用する
- 137. マシンの特定 64bitのglobal unique IDから、2pbitのハッシュ コード i を作る。 Memory Cloudは、2p個のメモリーtrunkからなる ので、これで Key/Valueペアは、Memory Cloud 中の trunk i に格納されている事が分かる。 trunk i がどのマシン上にあるかを知る為に、2p個 のスロットからなる「アドレシング・テーブル」を作成 しておく。それぞれのスロットには、マシンIDを入れ ておく。 i番目のスロットをみれば、マシンが分かる。
- 138. 一つのメモリーtrunk上で、 Key/Valueペアの位置を見つける。 グローバルなアドレッシングが機能する為には、 それぞれのマシンが、「アドレッシング・テーブル」 のレプリカを保持する必要がある。 それぞれのメモリーtrunkは、グローバルIDと Key/Valueペアの位置を示すoffsetと、その sizeを格納したテーブルを持っている。 このテーブルで、グローバルIDを引けば、 Key/Valueペアの位置と大きさが分かる。
- 141. ConcurrentとParallel 日本語では、Concurrent Computingを「並行計算」、 Parallel Computingを「並列計算」と訳すのが一般的で あるようだ。ただ、「並行」と「並列」では、まぎらわしい。 昔は（といっても大昔。DijkstraやHoareといった人たち が活躍していた時代）、コンピュータ・サイエンスの初期で は、「コンカレント（並行）計算」が大事な研究領域だった。 ただ、現代では、「パラレル（並列）計算」に対する実践的 な関心が高い。 こうした関心の移行の理由は、はっきりしている。昔は、計 算というと、一つの計算機上で同一のメモリー上で行われ るのが、当たり前だったが、現代では、クラウドのように、 複数の計算機がパラレルに走って、一つの処理を行うス タイルが、広く受け入れられるようになっているからである。
- 142. マルチ・スレッドとマルチ・プロセス この「同一メモリー空間か、否か」という区別は、ほぼ、現 在のマルチ・スレッドとマルチ・プロセスの違いに対応する。 だから、理論的には、マルチ・スレッドの方が先行する。多 分、実装でもそうだったと思う。プロセスとマルチ・プロセス というコンセプトが、広がるのはUnixからだと思う。 Unixでは、プログラムは全てプロセスとして走る。プロセ スのメモリー空間は論理的には完全に分離されている。 また、プロセスを生成できるのは、fork システム・コール、 ただ一つである。プロセス間の協調は、「プロセス間通信 Inter Process Communication (IPC)」のみによって 行われる。ちなみに、現代のパラレル・コンピューティング の主要な手段であるネットワーク技術は、このUnixの「プ ロセス間通信」の発展系である。
- 143. UNIXのコンカレント処理 それでは、Unixには、マルチ・スレッドのコンカレントなプ ログラミングは存在しないのかというと、そうではない。 Unixは、マルチ・ユーザーのタイム・シェアリングのシステ ムである。クロックから定期的に割り込みが入り、コンテキ スト・スイッチが行われる。DiskのIOも、端末からの入力 も、コンカレントな処理を要求する。 ただ、Unixは、これらの複雑なコンカレントな処理を、全て、 OSのカーネルに閉じ込めようとする。それはそれで、複 雑さの問題に対する、一つの立派な見識である。 「マルチ・スレッドのコンカレント・プログラミングは、難しく て、素人には無理です。カーネルがその部分を引き受け ますので、ユーザーは、プロセスをお使いください。」
- 144. プロセス生成の軽量化 これでみんなが納得して、すべて片付いたわけではない。 forkが行う、親プロセスのコピーによるプロセス空間の生 成・分離は、とても重く時間のかかる処理だ。 プロセスの生成については、必要になった時だけコピーを 行うCOW(Copy on Write)とか、コードだけでなくデータ も共有するvforkとか、プロセス空間を親のコピーによら ず、一から生成するspawnといった、いろんな方式が提 案され実装されていく。
- 147. Reactive プログラミング UNIXの開発者たちが、カーネルの内部に閉じ込めようと した、コンカレントで非同期のプログラミング・スタイルを、 一般のプログラマーも、日常的に利用する。このことは、コ ンカレントなプログラミングが、今日では、容易になったこ とを意味してはいない。それは、相変わらず難しく、誤りを 起こしやすいものであることに変わりはない。 こうした中で、「Reactiveプログラミング」という、関数型の プログラミング・スタイルについての関心が高まっている。 それについては、以前のマルレクでも取り上げた。
- 148. コンカレントの特徴づけ 「非決定論的振る舞い」 現在では、コンカレント・プログラムの定義に、「非決定論 的振る舞いをするプログラム」という定義が与えられること がある。一見わかりにくいこの定義も、いつ、どこで、どん なタイミングでイベントが発生するのか、あらかじめ予想す ることができず、かつ、イベントの発生によって異なる結果 が返ってくるという、イベント・ドリブンのスタイルを念頭に 置くとわかりやすいかもしれない。 それでは、異なる複数のマシンの協調動作を舞台とする 「パラレル・プログラミング」は、「決定論的」に振舞うので あろうか？ これは、面白い問題だ。確かに、どんなに巨 大なHadoopの処理も、与えられた同一の入力セットに対 して、同一の結果が返るという意味では、「決定論」的に 振舞う。
- 149. クラウド内部での イベント・ドリブン・プログラミング ただ、「コンカレント・プログラミング」との対比で、「パラレ ル・プログラミング」を、「決定論的プログラミング」と特徴 づけることが可能だとしても、そのことは、クラウドが行う 処理が、全て「決定論的」だということにはならない。 クラウドOSのアーキテクチャーというシステムの視点で考 えても、多数の入力をリアルタイムに処理するアプリケー ションというユーザーの視点で考えても、クラウドの処理を イベント・ドリブンのスタイルで記述する必要性が、高まる のは確実だと思われる。 少し飛躍するが、僕は、それは、「関数型言語」が広く受け 入れられていく変化への、一つのステップだと考えている。
- 150. 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
- 152. 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
- 153. Notifications: tracking work ユーザーは、"observer" をカラムに登録する •カラム中の行に書き込みが起きると実行される •それぞれのobserverは、新しいトランザクション で走る •書き込みごとに最大で一回実行される：メッセー ジの畳み込み DocumentPr ocessor DocumentPr ocessor DocumentPr ocessor RawDocumen tLoader RawDocument Loader Document Processor Document Exporter LinkInverter アプリケーションは、一連のobserverのつながりと して構造化される
- 154. Notificationsの実装 Dirty column: もしobserversが走るべき行なら設定 ランダム分散スキャン •中断している仕事を見つけ、observerをスレッドプール で走らせる •スキャンは効率的である。数ビットをみるだけ No shards or work units: nothing to straggle Dirty? balance:data ... Alice Yes 5: $15 Bob No 5: $5
- 155. Reactive Programming マルレク資料 「Reactive プログラミング」 http://bit.ly/1kkJelH
- 156. Reactive Extension (Rx) by Microsoft http://msdn.microsoft.com/en- us/data/gg577609.aspx
- 157. 講演資料 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
- 159. ObservableからObserverへの通知 OnNext (42) OnNext (43) OnCompleted OnNext (“Hello”) OnError (error) OnNext* (OnError | OnCompleted)?
- 160. ServerサイドでのRxの利用 Netflix --- RxJava “a library for composing asynchronous and event-based programs using observable sequences for the Java VM”
- 161. 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
- 162. AWS Lambda Run code without thinking about servers. Pay for only the compute time you consume. https://aws.amazon.com/lambda/
- 163. AWS Lambda AWS Lambda を使用すれば、サーバーのプロビジョニ ングや管理なしでコードを実行できます。課金は実際に使 用したコンピューティング時間に対してのみ発生し、コード が実行されていないときには料金も発生しません。 Lambda を使用すれば、実質どのようなタイプのアプリ ケーションやバックエンドサービスでも管理を必要とせず に実行できます。コードさえアップロードすれば、高可用性 を実現しながらコードを実行およびスケーリングするため に必要なことは、すべて Lambda により行われます。 コードは、他の AWS サービスから自動的にトリガーする よう設定することも、ウェブやモバイルアプリケーションか ら直接呼び出すよう設定することもできます。
- 165. リアルタイムファイル処理 Amazon S3 を使用して AWS Lambda をトリガーし、 アップロードしたデータを直ちに処理することができます。 例えば、画像のサムネイル作成、ビデオのコード変換、 ファイルのインデックス作成、ログの処理、コンテンツの検 証、およびリアルタイムでのデータの収集とフィルタリング などに使用できます。 とった写真 写真は、S3 バケットにアッ プロードされる Lambdaが トリガーされる Lambdaは、web, mobile, tablet向けに画像リサイズの 処理をする
- 166. リアルタイムストリーム処理 リアルタイムのストリーミングデータを AWS Lambda と Amazon Kinesis を使用して処理することで、アプリケーショ ンのアクティビティのトラッキング、注文のトランザクション処理、 クリックストリーム分析、データクレンジング、メトリックスの生成、 ログのフィルタリング、インデックス作成、ソーシャルメディア分 析、および IoT データのテレメトリと測定などが行えます。 ソーシャル・メディアのストリ ームがリアルタイムにKinesis にロードされる Lambdaは、トレンド・データの ハッシュタグを生成するコードを 走らせ、それをDynamoDBに 格納する ソーシャル・メディア のトレンド・データを 直ちにユーザーの 検索で使えるように なる Lambdaが トリガーされる
- 167. 抽出、変換、ロード AWS Lambda を使用することで、DynamoDB テーブ ル内のデータの変更すべてに対して検証、フィルタリング、 ソート、またはその他の変換を実行し、変換されたデータ を別のデータストアにロードすることができます。 オンラインから 注文が入る 注文データは、一旦 処理用のDBに置かれる Lambdaは、データ変換の コードを走らせ、結果をData Warehouseに格納 データから、分析 レポートが生成さ れる Lambdaが トリガーされる
- 168. IoT バックエンド AWS Lambda と Amazon Kinesis を使用して、IoT デバイスデータのテレメトリおよび分析のためのバックエ ンドを構築できます。 トラクターのセンサー データが、Kinesisに 送られる Lambdaは、センサーデータの 傾向を感知し、異常を見つけ、 故障部品の交換を注文する Lambdaが トリガーされる
- 169. モバイルバックエンド API Gateway AWS Lambda と Amazon API Gateway を使用して、 API リクエストの認証と処理のためのバックエンドを構築 できます。Lambda によって、機能が豊富でカスタマイズ されたアプリケーション体験をより簡単に作成できます。 ユーザーがステータスの 更新をポスト アプリは、エンドポイントに REST APIの呼び出しをする Lambdaが トリガーされる Lambdaは、ユーザーリストを 探して、友人に、ステータスの 更新の通知をプッシュするコー ドを走らせる
- 170. ウェブアプリケーション API Gateway 開発者は、AWS Lambda を他の AWS サービスと組み合わ せることで、スケールアップまたはスケールダウンを自動的に 行う強力なウェブアプリケーションを構築し、複数のデータセン ターにまたがる可用性の高い設定で実行できます。スケーラビ リティ、バックアップ、または複数データセンターによる冗長性を、 管理に労力を費やすことなく実現できます。 S3中のお天気 アプリのフロント エンドコード ユーザーが、 アプリのリンク をクリック アプリは、エンドポイ ントにREST APIの 呼び出しをする Lambdaは、地方の気象 情報を取り出し、ユーザーに 返す Lambdaが トリガーされる
- 171. 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
- 172. 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
- 173. 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
- 174. 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!” } } });
- 175. Cloud Code Trigger beforeSave Triggers afterSave Triggers beforeDelete Triggers afterDelete Triggers
- 176. 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が必要
- 177. クラウド・モバイル・インターフェース クラウドの最大のクライアントは、モバイルである。た だ、クラウドとモバイルの関係は、Webアプリのモデ ルのような、単純なサーバー・クライアントの関係では ない。
- 178. Facebook : “Parse” https://parse.com/ マルレク資料 「Facebook Parseの世界」 https://goo.gl/5pxaDb
- 179. Amazon : “AWS Mobile SDK” http://goo.gl/Nc5Bta
- 180. Microsoft : “Azure Mobile App Services” http://goo.gl/dcWlRF
- 182. クラウドからのPush
- 183. Parse Old Web Apps Push Pull
- 187. API Gateway API Gatewayは、マイクロ・サービスのデザイン・パ ターンの一つ。有名な例は、Netflixのもの。 API Gatewayは、サーバーとクライアントをつなぐも のだが、現代では、それは、主要には、クラウドとモバ イルをつなぐものになる。
- 191. モバイルバックエンド API Gateway AWS Lambda と Amazon API Gateway を使用して、 API リクエストの認証と処理のためのバックエンドを構築 できます。Lambda によって、機能が豊富でカスタマイズ されたアプリケーション体験をより簡単に作成できます。 ユーザーがステータスの 更新をポスト アプリは、エンドポイントに REST APIの呼び出しをする Lambdaが トリガーされる Lambdaは、ユーザーリストを 探して、友人に、ステータスの 更新の通知をプッシュするコー ドを走らせる
- 192. ウェブアプリケーション API Gateway 開発者は、AWS Lambda を他の AWS サービスと組み合わ せることで、スケールアップまたはスケールダウンを自動的に 行う強力なウェブアプリケーションを構築し、複数のデータセン ターにまたがる可用性の高い設定で実行できます。スケーラビ リティ、バックアップ、または複数データセンターによる冗長性を、 管理に労力を費やすことなく実現できます。 S3中のお天気 アプリのフロント エンドコード ユーザーが、 アプリのリンク をクリック アプリは、エンドポイ ントにREST APIの 呼び出しをする Lambdaは、地方の気象 情報を取り出し、ユーザーに 返す Lambdaが トリガーされる
- 193. まとめ クラウドOS進化の方向 コンテナーでのタスク管理への収斂 分散ファイル・システムの多様化 クラウド内でのイベント・ドリブン処理と 関数型言語的アプローチの浸透 クラウド・モバイル・インターフェース