Google Compute Engineと GAE Pipe API

@maruyama097 丸山不二夫

はじめに

クラウド・サービス提供者とIaaS

o  クラウド・サービスの提供者は、クラウドの管理・制御システムそのものの機能として、プロセッサー資源・ストレージ資源・ネットワーク資源等のリソースを、利用者のニーズに応じて動的に再配分し、特定のユーザー・ドメインをきってサービスを提供するFabricを構成する能力を、基本的には備えている。

o  IaaSは、クラウド・サービスの提供者にとっては、自らの能力のこうした部分を、クラウド・サービスの利用者に、一部解放することと等しい。その意味では、ASP起源のSaaSのサービス提供者の一部を除いて、クラウド・サービスの提供者は、IaaSを提供する能力を、もともと持っていたと考えることが出来る。Azureにしても、Google Compute Engineにしても。

クラウドのFabricを構成する能力

o  IaaSにしても、そのクラウドのFabricを構成する能力が、そのまま、利用者に提供される訳ではない。

o  ただ、クラウドのFabricを構成する能力自身が、進化していく。その細部を我々が知ることは少ないのだが。

o  そして、その一部は、我々も利用可能になる。GoogleのIaaSを主題とする小論で、Pipeline APIを取り上げたのは、それがクラウド内でFabricを構成する能力と密接に関係していると、筆者が考えているからである。

o  かつては、GoogleのMapReduceは、今とは違うフレームで管理されていたと思う。ただ、今では、それはPipeline APIを通じて管理されていると、筆者は考えている。

o 高精細ビデオ会議システムの例 n  高いパフォーマン

スと信頼性が要求される

n  自動的にスケール調整が行われる必要がある

AzureのService Model複雑なサービスの構造をモデリングする

Azureの開発段階では、こうした機能が 紹介されたことがあった。

AzureのService Model 単純なサービスの構造をモデリングする

Public Internet

Fundamental  Services  

Load    Balancer

Frontend  Web  Role  

Background    Process  Role  

テンプレートは自動的に サービスモデルにマップされる

Load Balancer Channel

Endpoint

Interface

Directory Resource

PaaSとIaaS

o  PaaSも、もちろん、IaaS同様、クラウド・サービス提供者の自在にサービスを提供するFabricを構成出来る能力の基盤の上にたっている。

o  IaaSの場合には、クラウド・サービス利用者に、Fabric構成の広い自由度が認められるのに対して、PaaSの場合には、テンプレートとして与えられた固定的なFabric （必要なScalabiliyは認められるのだが）の上で、主要にアプリケーションを開発・デプロイする。

o  PaaSでは、IaaSでは必要な、システム構成・管理の手間を省き、アプリケーション開発に集中して、すぐにサービスを展開出来るというメリットがあると考えることが出来る。

PaaSとしてのAzure が想定している 基本的なサービス・モデル

Public Internet

Web Role

Storage Service

Worker Role

Load    Balancer

何故、今、IaaSなのか？

o  こうしたPaaSのメリットは、ある場合には、弱点にもなる。現実のエンタープライズのシステムでは、サービスの特質や、ある場合には、歴史的な経緯から、PaaSのシステムが想定している単純なFabricより、複雑なシステム構成を取っているところが少なくない。

o  エンタープライズ・システムのクラウド移行にとって、課題の一つは、それまでのソフトウェア資産の継承である。それは多くの場合、システム自体の継承と結びついている。On Premiseへの志向の強さは、そこに起因する。

o  その意味では、IaaSへの注目は、クラウドのエンタープライズへの受容が進む中で、クラウド・サービス提供者側が、よりきめ細かく、エンタープライズ側のニーズに応えようという動きと考えることが出来る。

クラウド内サービスとIaaS

o  IaaSの柔軟性も、ある場合には、弱点になる。クラウド上にスクラッチからシステムを構築し、それを管理し続けるのは、PaaSと比べるとコストがかかる。

o  だから、IaaSの提供者は、裸のIaaSシステムを提供しているだけでは、十分な競争力を持つことは出来ない。IaaSの利用者にとって、彼らのサービス構築に役立つ、様々なクラウド内のサービスを提供することによって、IaaS間の競争で優位に立とうとする。

o  IaaSの提供者の、クラウド内サービスのメニューは多様である。IaaSの利用者が、システムを選択するにあたって、それは少なくない意味を持っている。

Agenda

小論では、次のような角度から、GoogleのIaaS、Google Compute Engineの特徴を考えてみようと思う。

o  Googleクラウドの、耐障害性・高可用性 o  Googleのエンタープライズ・クラウドの取り組み

o  Google Compute Engine o  Googleクラウドが提供する各種サービス o  クラウド内サービスを結合するPipe API o  GAE + GCEのユースケース

Googleクラウドの、 耐障害性・高可用性

クラウドを技術的に特徴づけるものは、コモディティ化したマシンのScale-OutアーキテクチャーによるScalabilityとそのAvailabilityである。 ただ、近年、クラウドの障害も少なくない。Googleのクラウドも例外ではない。まず、Googleクラウドの耐障害性を高める取り組みを見ておこう。

2009年７月、Google大規模障害

o  2009年7月2日, 6:45 AM から12:35 PM まで、Google App Engineに大規模な障害発生。

o  この障害の根本的な原因は、データセンタ内のノードが、

サーバー側できちんとしたチェックを行わずに、不適切に構成されたFileHandleを送りつけたことに起因するGFS Master serverのバグであった。これを処理しようとして、Masterは、スタック・オーバーフローを起こした。

o  障害報告　https://groups.google.com/forum/?fromgroups#!msg/google-appengine/6SN_x7CqffU/ecHIgNnelboJ

Transactions Across Datacenters （Weekend Project）

o  この障害事故の少し前、2009年5月27日　Google IO で、Ryan Barrettは、自らのWeekend Projectとして、データセンターをまたいだシステムを提案していた。

o  http://www.google.com/intl/ja/events/io/2009/sessions/TransactionsAcrossDatacenters.html

n  what if your entire datacenter falls off the face of the earth? This talk will examine how current large scale storage systems handle fault tolerance and consistency, with a particular focus on the App Engine datastore. We'll cover techniques such as replication, sharding, two phase commit, and consensus protocols (e.g. Paxos), then explore how they can be applied across datacenters.

Google、2009年８月1日、 GFSのデザインの見直しを示唆

o  事故直後の2009年８月1日、Sean Quinlanは、ACMとのインタビューに応え、GFSのデザインの見直しを示唆。 ”GFS: Evolution on Fast-forward” 以下、その要旨。　http://queue.acm.org/detail.cfm?id=1594206

o  GFSの単一マスターで行くという決定は、実際には、設計の非常に早い段階でなされたものだ。主要には、デザインをシンプルなものにするというのが、その理由だ。

o  ただ、問題は、すぐに起きていた。ストレージの容量が、数百テラからペタバイトに、さらには数十ペタに増大するにつれて、マスターが維持しなければならないメタデータの割合は、増えていった。

GFS: Evolution on Fast-forward

o  同様に、データのボリュームとともに、リカバリーのデータを探す為にメタデータをスキャンするというような操作がリニアなスケールで増えていく。こうして、マスターに要求される仕事の量は、本質的に増大する。

o  GFSが、いまや、多くの挑戦にさらされているのは、疑問の余地はない。一例を挙げれば、不断に増大するユーザーの大群と直面していて遅延が大きな問題となるアプリケーションを、本来は、バッチ・システムの効率を上げる為にデザインされたシステムの上でサポートしていることの、不格好さは、誰の目にも明らかである。

GFS: Evolution on Fast-forward

o  BigTableの登場は、この点では、いくらかの助けにはなった。ただ、明らかになったのは、BigTable は、実際には、GFSとは、最良の組み合わせではなかったということだ。事実、この組み合わせは、GFSシステムの単一マスターのデザインのボトルネックとしての限界を、他の場合よりも、はるかに明らかなものとしただけだった。

o  これした理由から、Googleの技術者達は、過去2年間というもの、BigTableの利点を最大限生かしながら、現GFSに取っては特に困難であると証明されているいくつかの問題を攻略する、新しい分散マスターシステムのデザインに取り組んできた。

HDFSのAvatar Node

o  ちなみに、Facebookが、HDFSのMaster Nodeの二重化、いわゆ、Avatar Nodeの実装の次の論文を発表したのは、2011年のSIGMODでのことであった。

o  “Apache Hadoop goes Realtime at Facebook” http://dl.acm.org/citation.cfm?id=1989438&bnc=1

2009年9月、Bigtableの見直し

o  2009年9月14日、Ryan Barrettは、“Migration to a Better Datastore”を発表http://googleappengine.blogspot.jp/2009/09/migration-to-better-datastore.html

o  Megastore replication saves the day! Megastore is an internal library on top of Bigtable that supports declarative schemas, multi-row transactions, secondary indices, and recently, consistent replication across datacenters.

2011年1月 Megastore: Providing Scalable, Highly Available Storage for Interactive Services

o  http://www.cidrdb.org/cidr2011/Papers/CIDR11_Paper32.pdf

Megastore

Googleのエンタープライズ・クラウドの取り組み

Google App Engine for Businessは、2010年５月に、大々的に発表されたが、一年後の2011年５月には、開発中止となった。

Google App Engine for Business

o  2010年5月19日　Google I/Oで、企業が直面している問題を解決するために、新しいバージョンのGAE4Bをスクラッチから開発すると発表。

o  GoogleとVMwareとの協業。Google I/Oでの、VMware CEO Paul Maritzの発言 http://www.youtube.com/GoogleDevelopers#p/c/02292AD8CFFE1349/7/KzTgzKkBtqE

VMware CEO　Paul Maritz

当時の問題意識：　App Engineの エンタープライズ利用での問題

o  なぜ、GAE4Bを開発したのか？　当時のGoogleの問題意識を振り返ることは、意味がある。App Engineは、エンタープライズ・システムとしては、次のような問題があったとされていた。

o  On Premise側では再利用できない、GAE独自のプログラミング・モデル。

o  SQLデータベースの未サポート。 o  機能上の制限（30秒ルール等）。

どのようなシステムを構想していたか

o  新しいApp Engine for Businessは、次のような特徴を備えているとされていた。

o  Spring Frameworkの採用により、PublicとOn Premiseのシステムとの間での連続的な移行可能性とHybrid Systemの構築の容易さを獲得。

o  Java/Spring開発者の従来のスキルを、クラウド・プログラミングに活用ができる。

o  大規模なBigTableに加えて、標準的なSQLデータベースのアクセスが出来る。

o  SLA/サポートの保障。

Google App Engine for Business 開発中止 2011年5月12日

o  GAE4B が予定していた機能の殆どは App Engine に組み込まれ、お支払い頂いているお客様であればそれらの機能が使用できます。

o  SLA、独自ドメインでの SSL、サポート、新しいビジネスに適した利用規約、オフラインでの支払いなどがこれにあたります。Domain Console は現在 Trusted Tester を実施しており、しばらくはそのままの状態が続きます。

o  今後も GAE4B は単独のサービスとして提供されることはありません。

http://googledevjp.blogspot.jp/2011/05/google-app-engine-preview.html

GAE1.5の発表　2011年5月10日

o  Backends: developer-controlled, long-running, addressable sets of instances

o  Pull Queues:you can write a Backend to do some background processing and pull 1, 10, or 100s of tasks off the Pull Queue

o  High Replication Datastore as default: setting HRD as the default for all new apps created, lowering the price of HRD storage from $0.45 down to $0.24, and encouraging everybody to begin plans to migrate.

http://googleappengine.blogspot.jp/2011/05/app-engine-150-release.html

Google Compute Engine

2012年6月28日 http://cloud.google.com/products/compute-engine.html https://developers.google.com/events/io/sessions/gooio2012/313/ https://developers.google.com/events/io/sessions/gooio2012/302/

CLI

API

Persistent Disk

VM

Internet

UI

Code

Private Network

Local Disk

Cloud Storage

Project

VM VM

Google Compute Engineの

CLI

API

Persistent Disk

VM

Internet

UI

Code

Private Network

Local Disk

Cloud Storage

Project

VM VM

API Basics

APIの基本はREST JSON over HTTP

o  APIが対象とする主なリソース n  プロジェクト n  インスタンス n  ネットワークとファイアウォール n  ディスクとスナップショット n  ゾーン

o  アクション n  GET n  POST (create) と DELETE n  更新用に、カスタムの‘verbs’

o  認証　 OAuth2

CLI

API

Persistent Disk

VM

Internet

UI

Code

Private Network

Local Disk

Cloud Storage

Project

VM VM

プロジェクト

プロジェクト

o  プロジェクトは、全てのリソースのコンテナで、次のような情報を含んでいる。

o  チームを構成するメンバー情報 o  グループのリソースの所有情報 o  課金情報

CLI

API

Persistent Disk

VM

Internet

UI

Code

Private Network

Local Disk

Cloud Storage

Project

VM VM

インスタンス

インスタンスは、LINUXのVM ハードは、Intel Sandy Bridge

o  Root権限を持つ、Ubuntu, CentOS o  いくつかのライブラリーは、プレインストールされている o  仮想CPUは、1,2,4,8個、huperthreadに一対一対応 o  仮想CPUごとに、3.75GB RAM o  CPUごとに、420GB以上の一時ディスク o  新しいパフォーマンスのメトリックス　

n  GCEU: Google Compute Engine Unit n  仮想CPUあたり 2.75 GCEUs

o  もっと小さいサイズのマシンも、準備中 o  KVM Hypervisor + Linux cgroups

CLI

API

Persistent Disk

VM

Internet

UI

Code

Private Network

Local Disk

Cloud Storage

Project

VM VM

ネットワーク

ネットワーク

o  Private Virtual Network n  プロジェクトごとに隔離されたネットワーク n  Private IPv4 space (RFC 1918) n  Layer 3 ネットワーク n  地理的なリージョンをまたいだフラットなネットワーク n  内部的には、VM name = DNS name

o  Internet Access n  External IPs: n  1-to-1 NAT / Built in firewall system n  Outgoing SMTP blocked / UDP,TCP,ICMP

のみ

CLI

API

Persistent Disk

VM

Internet

UI

Code

Private Network

Local Disk

Cloud Storage

Project

VM VM

ストレージ -- 永続ディスク

ストレージ -- 永続ディスク

o  高速の、整合性を保証されたパフォーマンス o  APIを通じてアクセスする o  ‘zone’に置かれる o  一つのインスタンスからはR/W可能 o  複数のインスタンスからは、R/O o  暗号化されている

CLI

API

Persistent Disk

VM

Internet

UI

Code

Private Network

Local Disk

Cloud Storage

Project

VM VM

ストレージ – 一時ディスク

ストレージ – 一時ディスク

o  現在は、全てのインスタンスをブートするのに利用 o  インスタンスとともに、生成・消滅する o  巨大な‘拡張’デバイス o  同じ物理マシン上に置かれる o  4CPU以上では、専用ディスクが割り当てられる o  暗号化

CLI

API

Persistent Disk

VM

Internet

UI

Code

Private Network

Local Disk

Cloud Storage

Project

VM VM

ストレージ Google Cloud Storage

ストレージ Google Cloud Storage

o  インターネット上の、オブジェクト・ストア o  グローバル APIベースのアクセス o  データの取り出し・格納に非常に便利 o  サービスのアカウントで、摩擦なしにアクセス出来る

CLI

API

Persistent Disk

VM

Internet

UI

Code

Private Network

Local Disk

Cloud Storage

Project

VM VM

Locality Managing Location and Availability

Locality Managing Location and Availability

o  Region: 地理的に離れていて、ルーティングされている o  Zone: 障害からの物理的な隔離が行われる範囲 o  制限プレビュー版では、3 Zoneが提供されているが、今

後、その数を増やしていく

Googleクラウドが提供する 各種サービス

各種サービスの発表時期

p  Google Datastore 2011/05/10 p  GAE4Bの断念 2011/05/12 p  App Engine MapReduce 2011/05/23 p  GAE Pipeline　API 2011/05/28

p  Google Cloud SQL 2011/10/06 p  Google Cloud Storage 2011/10/11

p  Google BigQuery 2012/05/01 p  Google Compute Engine 2012/06/28

Google DataStore

Google DataStoreは、Google Bigtableの機能拡張版である。 2011年5月10日 発表 https://developers.google.com/appengine/docs/python/datastore/overview

Google DataStore

o  マスター/スレーブ データストア n  マスター/スレーブ レプリケーション システムを使用し、

データが書き込まれるとデータは非同期に複製される。 n  読み取りとクエリに対して強い整合性 n  データ センターにトラブルや計画的ダウンタイムが発

生すると、一時的に利用できなくなる。 o  高レプリケーション データストア（デフォールト）

n  データを、Paxos アルゴリズムに基づいて、複数（3っつのZone）のデータ センターに複製。

n  非常に高い可用性を実現（書き込みの遅延は高い）。 n  結果整合性を保証。 n  マスター/スレーブ方式の約3倍のリソース消費。

Datastore/Megastore/Bigtable

http://www.slideshare.net/ikailan/introducing-the-app-engine-datastore

エンティティとプロパティ

o  データストアのデータ オブジェクトは「エンティティ」と呼ばれ、1 つ以上の「プロパティ」を持つ。

o  各エンティティはそれぞれを一意に識別する「キー」を持つ。最も単純なキーは、「種類（kind）」とデータストアによって付与される「エンティティ ID」である。

o  プロパティは、整数、浮動小数点値、文字列、日付、バイナリ データなどのいずれかのデータ型の名前付きの値。

o  データストア エンティティはスキーマレス。同じ種類の 2 つのエンティティのプロパティが同じである必要はなく、同じプロパティに対して同じ値の型を使用する必要もない。

クエリとインデックス トランザクションとエンティティ グループ

o  データストアのクエリではインデックスを使用する。インデックスとは、クエリ結果が希望する順序で含まれる表である。App Engine アプリケーションでは、設定ファイルでインデックスを定義する。

o  アプリケーションでデータストアのエンティティに変更を加えると、データストアは正しい結果でインデックスを更新する。アプリケーションでクエリを実行すると、データストアは対応するインデックスから結果を直接フェッチする。

o  Transaction API を使用すると、1 つのトランザクション内で 1 つのエンティティに対して複数の処理を実行できる。

o  エンティティ グループは、エンティティ間の関係の階層構造で定義される。

Datastoreでは、 SQLのサブセットが使える

o  Filters n  SELECT * FROM Table WHERE A=1 AND

(B=2 OR C=3) o Sorting

n  SELECT * FROM Table ORDER BY A, B DESC

o  Projections / Index-Only Queries n  SELECT A, B FROM Table

制限

o  エンティティの最大サイズ 1 MB o  エンティティの全インデックスの値の最大数 　5,000 個

n  エンティティは、インデックスで、そのエンティティを参照する行と列の各組み合わせに対して 1 つの値を使用する。インデックスに登録されたプロパティが複数の値を持つ場合、値が繰り返されて表に複数の行が必要になるので、エンティティのインデックス値の数が増える可能性がある。

High Replication Master/Slave Performance

Put/delete latency 1/2x–1x 1x

Get latency 1x 1x

Query latency 1x 1x

Consistency

Put/get/delete Strong Strong

Most queries Eventual Strong

Ancestor queries Strong Strong

Occasional planned read-only period No Yes

Unplanned downtime Extremely rare; no data loss.

Rare; possible to lose a small % of writes occurring near downtime (recoverable after event)

Free quota per app per day

Pricing if you exceed your free quota

Hosting Free quota per app per day

Price

On-demand Frontend Instances

28 free instance hours

$0.08 / hour

Reserved Frontend Instances

$0.05 / hour

High Replication Datastore

1G $0.24 / G / month

Outgoing Bandwidth 1G $0.12 / G Incoming Bandwidth 1G Free

APIs

Datastore API 50k free read/write/small

$0.10/100k write ops $0.07/100k read ops $0.01/100k small ops

Blobstore API 5G $0.13 / G / month

App Engine MapReduce

A model to do efficient distributed computing over large data sets. 2011年5月11日発表 http://code.google.com/p/appengine-mapreduce/ http://www.youtube.com/watch?v=EIxelKcyCC0

App EngineからMapReduceを 利用可能にする際、考えたこと

o  スケールの次元の追加 n  非常に沢山のアプリが走っている n  それらのアプリが同時にMapReduceを走らせる

o  隔離：そうしたアプリが、他のアプリのパフォーマンスに影響を与えるべきではない。

o  リミットの評価：一日分のリソースを、15分間で使い切り、オンライン・トラフィックも殺してしまうことを誰も望まない

o  非常に遅い実行：無料のアプリは、リソースのリミット以下にとどまりながら、とても遅く実行されることを望む。

o  保護：悪意のあるApp Engineの利用者から、システムを守る。

Pipeline API o  複雑な仕事を、つなげて一つにまとめる新しいAPI o  Mapper + Shuffler + Reducer をつなぐ、接着剤 o  MapReduceのライブラリーは、完全に、Ｐｉｐｅｌｉｎｅと統合

されている。

MapPipeline

ShufflePipeline

ReducePipeline

CleanupPipeline

class MyPipeline(base_handler.PipelineBase): def run(self, parameter): output = yield mapreduce_pipeline.MapreducePipeline( “name_of_pipeline_step”, “main.map_function”, “main.reduce_function”, “mapreduce.input_readers.DatastoreInputReader”, “mapreduce.output_writers.FileOutputWriter”, mapper_params=() reducer_params=(), shards=16) yield AnotherPiprline(output)

App Engine MapReduce

Google Cloud SQL

Google Cloud SQL は、Googleクラウド内のMySQLデータベースである。2011年10月6日、発表。 https://developers.google.com/cloud-sql/

Google Cloud SQLの特徴

o  MySQLデータベースを、クラウド上で動かす。 o  地理的にはなれたデータセンター間で、データベースの複

製を同期することが出来る。 o  mysqldumpを利用して、データベースのimport,

exportが出来る。 o  Java, PythonからのAPIが使える。 o  コマンドライン・ツールがある。 o  Google API Consoleで、SQLが使える。

制限

o  一つのインスタンスのサイズは、10GBまで。 o  ユーザー定義関数は、サポートされていない。 o  MySQLのレプリカはサポートされない。 o  次のＳＱＬ文は、サポートされない。

n  LOAD DATA INFILE n  SELECT ... INTO OUTFILE/DUMPFILE n  INSTALL/UNINSTALL PLUGIN ... n  CREATE FUNCTION ... n  LOAD_FILE()

Packages Billing Plan Tier RAM Included

Storage Included I/O per Day

Charge per Day

D1 0.5GB 1GB 850K $1.46

D2 1GB 2GB 1.7M $2.93

D4 2GB 5GB 4M $5.86

D8 4GB 10GB 8M $11.71

Resource Charge D1 Database Instance (0.5GB RAM) $0.10 per hour D2 Database Instance (1GB RAM) $0.19 per hour D4 Database Instance (2GB RAM) $0.38 per hour D8 Database Instance (4GB RAM) $0.77 per hour 1GB Storage $0.24 per month I/O $0.10 per Million

Per Use Billing Plan

Google Cloud Storage

Fast, scalable, highly available object store　　2011年10月11日発表。 https://developers.google.com/appengine/docs/python/googlestorage/

Google Cloud Storageとは？

o  Google Cloud Storageは、Googleのクラウド・インフラの上に、データを格納し、それにアクセスする、 RESTful サービス。このサービスは、Googleクラウドのパフォーマンスとスケーラビリティを、先進的なセキュリティ技術と共有の能力とに結びつける。

o  全てのデータは、複数のデータセンタに複製される。 o  書き込みと、読み出しのデータの整合性は保たれる。 o  オブジェクトのサイズは、数テラバイトまで可能。アップ

ロード、ダウンロードでレジュームが可能。range-GETをサポートしている。

o  バケットの名前空間は、ドメイン・スコープになっている。

Monthly Usage Price (per GB) First 0 - 1TB $0.12 Next 9TB $0.105 Next 90TB $0.095 Next 400TB $0.085 Additional Storage Contact us

Monthly Usage

Network (Egress) - Americas and EMEA* (per GB)

Network (Egress) - Asia-Pacific (per GB)

Network (Ingress)

0 - 1TB $0.12 $0.21 Free

Next 9TB $0.11 $0.18 Next 90TB $0.08 $0.15 Additional Data Transfer

Contact us

Storage

Network

PUT, POST, GET bucket**, GET service** Requests (per 1,000 requests/month)

GET, HEAD Requests (per 10,000 requests/month)

DELETE Requests

$0.01 $0.01 Free

Requests

クラウド内サービスを結合する Pipeline API

The Google App Engine Pipeline API connects together complex, time-consuming workflows. 2011年5月28日　発表 http://code.google.com/p/appengine-pipeline/ https://developers.google.com/events/io/sessions/gooio2012/307/

Overview

o  Google App Engine Pipeline API は、複雑で時間を消費するワークフロー（人間の仕事も含む）を、一つに結合する。

o  Pipeline APIの目標は、柔軟さ、ワークフローの再利用、そして、テスト可能性である。

o  このAPIの第一のユースケースは、App Engineの様々のMapReduceを、計算パイプラインに結合することである。

Job Graphs

[ (x - y) * (x - z) ] - 2

http://code.google.com/p/appengine-pipeline/wiki/GettingStartedJava

immediate jobs

class DiffJob extends Job2<Integer, Integer, Integer> { @Override public Value<Integer> run(Integer a, Integer b) { return immediate(a - b); } } class MultJob extends Job2<Integer, Integer, Integer> { @Override public Value<Integer> run(Integer a, Integer b) { return immediate(a*b); } }

Generator Jobs

class ComplexJob extends Job3<Integer, Integer, Integer, Integer> { @Override public Value<Integer> run(Integer x, Integer y, Integer z) { DiffJob diffJob = new DiffJob(); MultJob multJob = new MultJob(); FutureValue<Integer> r = futureCall(diffJob, immediate(x), immediate(y)); FutureValue<Integer> s = futureCall(diffJob, immediate(x), immediate(z)); FutureValue<Integer> t = futureCall(multJob, r, s); FutureValue<Integer> u = futureCall(diffJob, t, immediate(2)); return u; } }

FutureValue<Integer> r = 　　　　futureCall(diffJob, immediate(x), immediate(y));

ComplexJob and the child graph

Running Pipelines

PipelineService service = 　 PipelineServiceFactory. newPipelineService(); String pipelineId = 　 service. startNewPipeline( new ComplexJob(), 11, 5, 7); // Later, check on the status and get the final output JobInfo jobInfo = service. getJobInfo(pipelineId); JobInfo.State state = jobInfo. getJobState(); if (JobInfo.State.COMPLETED_SUCCESSFULLY 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　== state){ System.out.println("The output is " + 　　　　　　　　　 jobInfo. getOutput()); }

PipelineService

<T1,T2,T3> java.lang.String startNewPipeline( Job3<?,T1,T2,T3> jobInstance, T1 arg1, T2 arg2, T3 arg3, JobSetting... settings) void stopPipeline(String pipelineHandle); void deletePipelineRecords(String pipelineHandle); void submitPromisedValue(String promiseHandle, Object value);

Promised Values and External Agents

o  PromisedValueは、ある非同期の外部のエージェントが値を提供するとき、埋められるであろう、値のスロットを表現している。このメカニズムは、このフレームワークが、MapReduceのような他のフレームワークに呼び出しを行って、同時に、パイプライン中に、人間からの入力を待つことを可能にする。

o  次のパイプラインは、人間から三つの整数を受け取り、それをComplexJobに入力として渡し、その答えを人間に返し、さらにもう一つ整数を要求し、追加の整数を、ComplexJobの結果と掛けている。

class ExternalAgentJob extends Job1<Integer, String> { @Override public Value<Integer> run(String userEmail) { // Invoke ComplexJob on three promised values PromisedValue<Integer> x = newPromise(Integer.class); PromisedValue<Integer> y = newPromise(Integer.class); PromisedValue<Integer> z = newPromise(Integer.class); FutureValue<Integer> intermediate = futureCall(new ComplexJob(), x, y, z); // Kick off the process of retrieving the data from the external agent getIntFromUser("Please give 1st int", userEmail, x.getHandle()); getIntFromUser("Please give 2nd int", userEmail, y.getHandle()); getIntFromUser("Please give 3rd int", userEmail, z.getHandle()); // Send the user the intermediate result and ask for one more integer FutureValue<Integer> oneMoreInt = futureCall(new PromptJob(), intermediate, immediate(userEmail)); // Invoke MultJob on intermediate and oneMoreInt return futureCall(new MultJob(), intermediate, oneMoreInt); }

public static void getIntFromUser(String prompt, String userEmail, String promiseHandle) { // 1. Send the user an e-mail containing the prompt. // 2. Ask user to submit one more integer on some web page. // 3. promiseHandle is a query string argument // 4. Handler for submit invokes submitPromisedValue(promiseHandle, value) } } class PromptJob extends Job2<Integer, Integer, String> { @Override public Value<Integer> run(Integer intermediate, String userEmail) { String prompt = "The intermediate result is " + intermediate + "." + " Please give one more int"; PromisedValue<Integer> oneMoreInt = newPromise(Integer.class); ExternalAgentJob.getIntFromUser(prompt, userEmail, oneMoreInt.getHandle()); return oneMoreInt; } }

Pythonでの定義

class Add(pipeline.Pipeline): def run(self, a, b): return a + b class Multiply(pipeline.Pipeline): def run(self, a, b): return a * b class LinearFunc(pipeline.Pipeline): def run(self, x, slope=1, offset=0): # y = m*x + b mx = yield Multiply(x, slope) yield Add(mx, offset)

http://code.google.com/p/appengine-pipeline/wiki/GettingStarted

Pythonでの呼び出し

# Create it like an object job = LinearFunc(6, slope=3.5, offset=7) job.start() pipeline_id = job.pipeline_id # Access outputs later job = LinearFunc.from_id(pipeline_id) if job.has_finalized: 　　job.outputs.default.value == 28 # True

Pipelineは、どのように動くのか？

http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/en//events/io/2011/static/presofiles/google_io_2011_pipeline_api.pdf

Pipelineは、どのように動くのか？ 次のサンプルで見てみよう

class Add(pipeline.Pipeline): def run(self, *values): return sum(values)

class Multiply(pipeline.Pipeline): def run(self, i=1, j=1, k=1): return i * j * k

class Polynomial(pipeline.Pipeline): def run(self, x, A, B, C): # y = A*x^2 + B*x + C Ax_2 = yield Multiply(A, x, x) Bx = yield Multiply(B, x) yield Add(Ax_2, Bx, C)

先のコードでは、変数 A,B,C,X と関数Multiply, Addの定義、中間結果の変数 Ax_2,Bx が与えられている

yieldが生み出す結果を入れる スロットと、全てのスロットが満た された時にのみ、制御を次に進 めるBarrierが、用意される。

AX_2,BXの計算を始める。 それぞれは、独立した処理で 構わない。

計算結果を、それぞれの スロットに格納する。

スロットが満たされると、それを Barrierに通知する。

Barrierは、全てのスロットが 埋まった時、次のステップを 実行する。

準備ができている値を使って 次の計算が行われる。

結果は、用意されたスロットに 格納される。

DatastoreのJoinに MapReduce/Pipelineを利用する

http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/en//events/io/2011/static/presofiles/google_io_2011_pipeline_api.pdf

２つのデータストアPRODUCTとSALESの エンティティを、キー SKU でジョインするのに、 MapReduceを使うサンプル

class JoinOnSKU(base_handler.PipelineBase): def run(self): product_data = yield DatastrorageMapperPipeline( mapper_spec = ‘main.Datastore_map’ , entity_kind_spec = ‘main.ProductDescription’ , shards = 16 ) sales_data = yield DatastoreMapperPipeline( mapper_spec = ‘main.Datastore_map’ , entity_kind_spec = ‘main.ProductSales’ , shards = 16 ) all_data = yield pipeline_common.Extend(product_data, sales_data) shuffled_data = yield mapreduce_pipeline.ShufflePipeline( ‘Shuffle by Product ID’ , all_data, shards = 16)

join_by_user_id = yield mapreduce_pipeline.ReducePipeline( ‘Join by SKU ID’ , ‘main storage_reduce’ , output_writer_spec = ‘mapreduce.output_writers.FileOutputWriter’ , params = { ‘output_writer’ : { ‘filesystem’: ‘gs’ . ‘gs_bucket_name’: ‘datastore_export’ , ‘output_sharding’: ‘none’ } }, filenames = shuffled_data) def storage_reduce(key, value) : # Do something with the resulting values # A’JOIN , a count, etc. etc. yield (‘%s¥n’ % result )

product_data = yield DatastrorageMapperPipeline( mapper_spec = ‘main.Datastore_map’ , entity_kind_spec = ‘main.ProductDescription’ , shards = 16 )

sales_data = yield DatastoreMapperPipeline( mapper_spec = ‘main.Datastore_map’ , entity_kind_spec = ‘main.ProductSales’ , shards = 16 )

shuffled_data = yield mapreduce_pipeline.ShufflePipeline( ‘Shuffle by Product ID’ , all_data, shards = 16)

join_by_user_id = yield mapreduce_pipeline.ReducePipeline( ‘Join by SKU ID’ , ‘main storage_reduce’ , output_writer_spec = ‘mapreduce.output_writers.FileOutputWriter’ , params = { ... } filenames = shuffled_data)

Google BigQuery

テラバイトのデータを、ボタン一つのクリックで分析する。　2012年5月1日　発表 https://developers.google.com/bigquery/ https://developers.google.com/events/io/sessions/gooio2012/312/

Google BigQuery

o  Google BigQuery サービスは、非常に大きなデータセット、可能的には数百万行のデータに対して、SQL-likeな検索を行うことを可能とする。そのデータは、自分のものであってもいいし、誰かが共有してくれたものでもいい。

o  BigQueryは、非常に巨大な、追加しか認められないような少数のテーブルからなるデータのインタラクティブな解析に最適である。

o  もっと、伝統的なリレーショナル・データベースに対しては、BigQueryの代わりに、Google Cloud SQL を使った方がいいかもしれない。

SELECT timestamp, title, COUNT(*) as cnt FROM publicdata:samples.wikipedia WHERE LOWER(title) CONTAINS ‘speed’ AND vp_namespace = 0 GROUP BY title, timestamp ORDER BY cnt DESC LIMIT 20;

Wikipediaの中から、’speed’という ことばを含むタイトルを持つ論文を 探し出す。

BigQueryの特徴

o  スピード – 数百万行を数秒で解析する o  スケール – テラバイトのデータ、数兆のレコード o  単純さ – Googleのインフラの上で動く、SQL-likeな検

索言語 o  共有 – Googleアカウントを利用した、グループ・ベース、

個人ベースの強力なパーミッション機能。 o  セキュリティ – セキュアなSSLアクセス o  複数のアクセス方法

n  BigQueryブラウザ n  bq コマンドライン・ツール n  REST API n  Google Apps Script

SELECT corpus FROM publicdata:samples.shakespeare GROUP BY corpus;

How many works of Shakespeare are there?

SELECT corpus, sum(word_count) AS wordcount FROM publicdata:samples.shakespeare GROUP BY corpus ORDER BY wordcount DESC; Which are the longest works?

https://developers.google.com/events/io/sessions/gooio2012/307/

class IteratorPipeline(base_handler.PipelineBase): def run(self, entity_type): output = yield mapreduce_pipeline.MapperPipeline( “Datastore_Iterator_” + entity_type, “main.datastore_map”, “mapreduce.input_readers.DatastoreInputReader”, output_writer_spec = “mapreduce.output_writers.FileOutputWriter”, params = { “input_reader”: { “entity_kind”: entity_type, }, “output_writer”: { “filesystem”: “gs”, “gs_bucket_name”: GS_BUCKET, “output_sharding”: “none”, } }, shards=SHARDS) yield CloudStorageToBigQuery(output) class CloudStorageToBigQuery(base_handler.PipelineBase): def run(self, files): table.name = ‘gplus_data_%s’ % datatime.utconv().strftime(...) jobs = bigquery.service.jobs() result = jobs.insert(projectId=Project_ID, body=build_job.data(table_name,files)).execute()

GAE + GCEのユースケース

Orchestrating Google Compute Engine through Google App Engine https://developers.google.com/events/io/sessions/gooio2012/308/

Google App Engine + Google Compute Engine

Video Sharing System

Uploading Files

Create task queue entry

Task queue consumer

Workload

Shoe result

Scaling