More Related Content 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
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ビジネスにとって重要である
ことを訴えるものだった。
10. 複雑さにおける質的な飛躍
線形実行 (SEQ) – 人生は善良でシンプルであった
マルチ・スレッド (MT) – ツールと優秀なプログラマが
MTについて考えることが必要
マルチ・プロセス (MP) – カーネルの開発者だけでな
く誰もが利用できる。実際には、MTの前に起きた。
マルチ・マシン (MM) 同一ネットワーク上の –
マルチ・プロセスと同じではないのだが、ある人たちは、
そう考えている
信頼できないマルチ・マシンたち(MMU) – 本質的に
は、Webの世界である
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 へ
の変化だということになる
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
数十万のジョブ
数千のアプリケーション
数万のマシン
39. PaaS and
Long Running Big data processing Batch scheduling Data storage
Mesos で走る主要なアプリ https://goo.gl/1oDvTc
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のタスクに使われるかもしれない。
このリソース提供のプロセスは、タスクが終了して、新しいリ
ソースがフリーになった時には、繰り返される。
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の抽象を
与える。
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 ...
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
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 クラウドと、試され済みのオープンソース技術を結
合して、コンテナー・アプリを構築する全てのチームが必
要とするであろう、コンテナーのデプロイ、オーケストレー
ション、サービス管理の基礎を提供する。
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をサポートし、こうして、ユー
ザーのニーズにもっとも適切な、どのようなオペレーショ
ン・システムでも、ユーザーがコンテナーを管理できること
を保証することとなった。
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 のサポート
ロギング
ハイブリッド ネットワーキング
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。
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の機能強化にも取り
入れられているのは、注目すべきことだろう。
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 ± ε
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
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の
コピーを持っている。
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 と統合する
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の値が復元できる。
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
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
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番目のスロットをみれば、マシンが分かる。
141. ConcurrentとParallel
日本語では、Concurrent Computingを「並行計算」、
Parallel Computingを「並列計算」と訳すのが一般的で
あるようだ。ただ、「並行」と「並列」では、まぎらわしい。
昔は(といっても大昔。DijkstraやHoareといった人たち
が活躍していた時代)、コンピュータ・サイエンスの初期で
は、「コンカレント(並行)計算」が大事な研究領域だった。
ただ、現代では、「パラレル(並列)計算」に対する実践的
な関心が高い。
こうした関心の移行の理由は、はっきりしている。昔は、計
算というと、一つの計算機上で同一のメモリー上で行われ
るのが、当たり前だったが、現代では、クラウドのように、
複数の計算機がパラレルに走って、一つの処理を行うス
タイルが、広く受け入れられるようになっているからである。
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のつながりと
して構造化される
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
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
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が必要
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が
トリガーされる