Google Compute EngineとGAE Pipeline API
Upcoming SlideShare
Loading in...5
×
 

Google Compute EngineとGAE Pipeline API

on

  • 3,182 views

 

Statistics

Views

Total Views
3,182
Views on SlideShare
3,177
Embed Views
5

Actions

Likes
3
Downloads
29
Comments
0

1 Embed 5

https://twitter.com 5

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Google Compute EngineとGAE Pipeline API Google Compute EngineとGAE Pipeline API Presentation Transcript

  • 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を通じて管理されていると、筆者は考えてい る。
  • AzureのService Model
複雑なサービスの構造をモデリングする o  高精細ビデオ会 議システムの例 n  高いパフォーマン スと信頼性が要求 される n  自動的にスケール 調整が行われる必 要がある Azureの開発段階では、こうした機能が 紹介されたことがあった。
  • AzureのService Model単純なサービスの構造をモデリングする Public Internet テンプレートは自動的に Frontend   Background     サービスモデルにマップされる Web  Role   Process  Role   Load    Balancer Fundamental  Services   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 Worker Role Role Load    Balancer Storage Service
  • 何故、今、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、GoogleCompute Engineの特徴を考えてみようと思う。o  Googleクラウドの、耐障害性・高可用性o  Googleのエンタープライズ・クラウドの取り組み o  Google Compute Engineo  Googleクラウドが提供する各種サービスo  クラウド内サービスを結合するPipe APIo  GAE + GCEのユースケース
  • Googleクラウドの、耐障害性・高可用性 クラウドを技術的に特徴づけるものは、コモディティ化 したマシンのScale-Outアーキテクチャーによる ScalabilityとそのAvailabilityである。 ただ、近年、クラウドの障害も少なくない。Googleの クラウドも例外ではない。まず、Googleクラウドの耐 障害性を高める取り組みを見ておこう。
  • 2009年7月、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. Well 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年8月1日、GFSのデザインの見直しを示唆 o  事故直後の2009年8月1日、Sean Quinlanは、ACMと のインタビューに応え、GFSのデザインの見直しを示唆。 ”GFS: Evolution on Fast-forward” 以下、その要旨。  http://queue.acm.org/detail.cfm?id=1594206o  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.htmlo  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, HighlyAvailable Storage for Interactive Services o  http://www.cidrdb.org/cidr2011/Papers/ CIDR11_Paper32.pdf
  • Megastore
  • Googleのエンタープライズ・クラウドの取り組み Google App Engine for Businessは、2010年5 月に、大々的に発表されたが、一年後の2011年5月 には、開発中止となった。
  • Google App Enginefor 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/
  • Google Compute Engineの Project Internet CLI VM Private UI VM Network API VM Code Persistent Local Cloud Disk Disk Storage
  • API Basics Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  • APIの基本はRESTJSON over HTTP o  APIが対象とする主なリソース n  プロジェクト n  インスタンス n  ネットワークとファイアウォール n  ディスクとスナップショット n  ゾーンo  アクション n  GET n  POST (create) と DELETE n  更新用に、カスタムの‘verbs’o  認証  OAuth2
  • プロジェクト Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  • プロジェクト o  プロジェクトは、全てのリソースのコンテナで、次のような 情報を含んでいる。o  チームを構成するメンバー情報o  グループのリソースの所有情報o  課金情報
  • インスタンス Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  • インスタンスは、LINUXのVMハードは、Intel Sandy Bridge o  Root権限を持つ、Ubuntu, CentOSo  いくつかのライブラリーは、プレインストールされているo  仮想CPUは、1,2,4,8個、huperthreadに一対一対応o  仮想CPUごとに、3.75GB RAMo  CPUごとに、420GB以上の一時ディスクo  新しいパフォーマンスのメトリックス  n  GCEU: Google Compute Engine Unit n  仮想CPUあたり 2.75 GCEUso  もっと小さいサイズのマシンも、準備中o  KVM Hypervisor + Linux cgroups
  • ネットワーク Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  • ネットワーク o  Private Virtual Network n  プロジェクトごとに隔離されたネットワーク n  Private IPv4 space (RFC 1918) n  Layer 3 ネットワーク n  地理的なリージョンをまたいだフラットなネットワーク n  内部的には、VM name = DNS nameo  Internet Access n  External IPs: n  1-to-1 NAT / Built in firewall system n  Outgoing SMTP blocked / UDP,TCP,ICMP のみ
  • ストレージ -- 永続ディスク Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  • ストレージ -- 永続ディスク o  高速の、整合性を保証されたパフォーマンスo  APIを通じてアクセスするo  ‘zone’に置かれるo  一つのインスタンスからはR/W可能o  複数のインスタンスからは、R/Oo  暗号化されている
  • ストレージ – 一時ディスク Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  • ストレージ – 一時ディスク o  現在は、全てのインスタンスをブートするのに利用o  インスタンスとともに、生成・消滅するo  巨大な‘拡張’デバイスo  同じ物理マシン上に置かれるo  4CPU以上では、専用ディスクが割り当てられるo  暗号化
  • ストレージ Google Cloud Storage Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  • ストレージ Google Cloud Storage o  インターネット上の、オブジェクト・ストアo  グローバル APIベースのアクセスo  データの取り出し・格納に非常に便利o  サービスのアカウントで、摩擦なしにアクセス出来る
  • LocalityManaging Location and Availability Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  • LocalityManaging Location and Availability o  Region: 地理的に離れていて、ルーティングされているo  Zone: 障害からの物理的な隔離が行われる範囲o  制限プレビュー版では、3 Zoneが提供されているが、今 後、その数を増やしていく
  • Googleクラウドが提供する各種サービス
  • 各種サービスの発表時期 p  Google Datastore 2011/05/10p  GAE4Bの断念 2011/05/12p  App Engine MapReduce 2011/05/23p  GAE Pipeline API 2011/05/28p  Google Cloud SQL 2011/10/06p  Google Cloud Storage 2011/10/11p  Google BigQuery 2012/05/01p  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 DESCo  Projections / Index-Only Queries n  SELECT A, B FROM Table
  • 制限 o  エンティティの最大サイズ 1 MBo  エンティティの全インデックスの値の最大数  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 Rare; possible to data loss. lose a small % of writes occurring near downtime (recoverable after event)
  • Free quota per app Pricing if you per day exceed your free quotaHosting Free quota per app Price per day On-demand Frontend 28 free instance $0.08 / hourInstances hours Reserved Frontend $0.05 / hourInstances High Replication 1G $0.24 / G / monthDatastore Outgoing Bandwidth 1G $0.12 / GIncoming Bandwidth 1G Free APIs Datastore API 50k free read/write/ $0.10/100k write ops small $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  複雑な仕事を、つなげて一つにまとめる新しいAPIo  Mapper + Shuffler + Reducer をつなぐ、接着剤o  MapReduceのライブラリーは、完全に、Pipelineと統合 されている。
  • MapPipeline ShufflePipeline
  • ReducePipeline CleanupPipeline
  • App Engine MapReduce 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)
  • 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  次のSQL文は、サポートされない。 n  LOAD DATA INFILE n  SELECT ... INTO OUTFILE/DUMPFILE n  INSTALL/UNINSTALL PLUGIN ... n  CREATE FUNCTION ... n  LOAD_FILE()
  • Packages Billing PlanTier RAM Included Included I/O Charge Storage per Day per DayD1 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 Per Use Billing PlanResource ChargeD1 Database Instance (0.5GB RAM) $0.10 per hourD2 Database Instance (1GB RAM) $0.19 per hourD4 Database Instance (2GB RAM) $0.38 per hourD8 Database Instance (4GB RAM) $0.77 per hour1GB Storage $0.24 per monthI/O $0.10 per Million
  • 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  バケットの名前空間は、ドメイン・スコープになっている。
  • Storage Monthly Usage Price (per GB)First 0 - 1TB $0.12Next 9TB $0.105Next 90TB $0.095Next 400TB $0.085Additional Storage Contact us Network Monthly Network Network NetworkUsage (Egress) - (Egress) - (Ingress) Americas and Asia-Pacific EMEA* (per GB) (per GB) 0 - 1TB $0.12 $0.21 Free Next 9TB $0.11 $0.18Next 90TB $0.08 $0.15Additional DataTransfer Contact us
  • Requests PUT, POST, GET GET, HEAD DELETE Requestsbucket**, GET Requests service** (per 10,000Requests requests/month) (per 1,000requests/month) $0.01 $0.01 Free
  • クラウド内サービスを結合する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 outputJobInfo 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 andExternal 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 + bclass Multiply(pipeline.Pipeline): def run(self, a, b): return a * bclass 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 objectjob = LinearFunc(6, slope=3.5, offset=7)job.start()pipeline_id = job.pipeline_id# Access outputs laterjob = 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 * kclass 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
  • 2つのデータストア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 cntFROM publicdata:samples.wikipediaWHERE LOWER(title) CONTAINS ‘speed’ AND vp_namespace = 0GROUP 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 FROMpublicdata:samples.shakespeare GROUP BYcorpus; How many works of Shakespeare are there?
  • SELECT corpus, sum(word_count) AS wordcountFROM publicdata:samples.shakespeare GROUP BYcorpus 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