O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Google Compute EngineとGAE Pipeline API

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio

Confira estes a seguir

1 de 144 Anúncio

Google Compute EngineとGAE Pipeline API

Baixar para ler offline

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Anúncio

Semelhante a Google Compute EngineとGAE Pipeline API (20)

Mais de maruyama097 (20)

Anúncio

Mais recentes (20)

Google Compute EngineとGAE Pipeline API

  1. 1. Google Compute Engineと GAE Pipe API @maruyama097 丸山不二夫
  2. 2. はじめに
  3. 3. クラウド・サービス提供者とIaaS o  クラウド・サービスの提供者は、クラウドの管理・制御シス テムそのものの機能として、プロセッサー資源・ストレージ 資源・ネットワーク資源等のリソースを、利用者のニーズ に応じて動的に再配分し、特定のユーザー・ドメインをきっ てサービスを提供するFabricを構成する能力を、基本的 には備えている。 o  IaaSは、クラウド・サービスの提供者にとっては、自らの 能力のこうした部分を、クラウド・サービスの利用者に、一 部解放することと等しい。その意味では、ASP起源の SaaSのサービス提供者の一部を除いて、クラウド・サー ビスの提供者は、IaaSを提供する能力を、もともと持って いたと考えることが出来る。Azureにしても、Google Compute Engineにしても。
  4. 4. クラウドのFabricを構成する能力 o  IaaSにしても、そのクラウドのFabricを構成する能力が、 そのまま、利用者に提供される訳ではない。 o  ただ、クラウドのFabricを構成する能力自身が、進化して いく。その細部を我々が知ることは少ないのだが。 o  そして、その一部は、我々も利用可能になる。Googleの IaaSを主題とする小論で、Pipeline APIを取り上げたの は、それがクラウド内でFabricを構成する能力と密接に 関係していると、筆者が考えているからである。 o  かつては、GoogleのMapReduceは、今とは違うフレー ムで管理されていたと思う。ただ、今では、それは Pipeline APIを通じて管理されていると、筆者は考えてい る。
  5. 5. AzureのService Model
 複雑なサービスの構造をモデリングする o  高精細ビデオ会 議システムの例 n  高いパフォーマン スと信頼性が要求 される n  自動的にスケール 調整が行われる必 要がある Azureの開発段階では、こうした機能が 紹介されたことがあった。
  6. 6. AzureのService Model 単純なサービスの構造をモデリングする Public Internet テンプレートは自動的に Frontend   Background     サービスモデルにマップされる Web  Role   Process  Role   Load    Balancer Fundamental  Services   Load Balancer Channel Endpoint Interface Directory Resource
  7. 7. PaaSとIaaS o  PaaSも、もちろん、IaaS同様、クラウド・サービス提供者 の自在にサービスを提供するFabricを構成出来る能力の 基盤の上にたっている。 o  IaaSの場合には、クラウド・サービス利用者に、Fabric構 成の広い自由度が認められるのに対して、PaaSの場合 には、テンプレートとして与えられた固定的なFabric (必 要なScalabiliyは認められるのだが)の上で、主要にアプ リケーションを開発・デプロイする。 o  PaaSでは、IaaSでは必要な、システム構成・管理の手間 を省き、アプリケーション開発に集中して、すぐにサービス を展開出来るというメリットがあると考えることが出来る。
  8. 8. PaaSとしてのAzure が想定している 基本的なサービス・モデル Public Internet Web Worker Role Role Load    Balancer Storage Service
  9. 9. 何故、今、IaaSなのか? o  こうしたPaaSのメリットは、ある場合には、弱点にもなる。 現実のエンタープライズのシステムでは、サービスの特質 や、ある場合には、歴史的な経緯から、PaaSのシステム が想定している単純なFabricより、複雑なシステム構成を 取っているところが少なくない。 o  エンタープライズ・システムのクラウド移行にとって、課題 の一つは、それまでのソフトウェア資産の継承である。そ れは多くの場合、システム自体の継承と結びついている。 On Premiseへの志向の強さは、そこに起因する。 o  その意味では、IaaSへの注目は、クラウドのエンタープラ イズへの受容が進む中で、クラウド・サービス提供者側が、 よりきめ細かく、エンタープライズ側のニーズに応えようと いう動きと考えることが出来る。
  10. 10. クラウド内サービスとIaaS o  IaaSの柔軟性も、ある場合には、弱点になる。クラウド上 にスクラッチからシステムを構築し、それを管理し続ける のは、PaaSと比べるとコストがかかる。 o  だから、IaaSの提供者は、裸のIaaSシステムを提供して いるだけでは、十分な競争力を持つことは出来ない。 IaaSの利用者にとって、彼らのサービス構築に役立つ、 様々なクラウド内のサービスを提供することによって、 IaaS間の競争で優位に立とうとする。 o  IaaSの提供者の、クラウド内サービスのメニューは多様 である。IaaSの利用者が、システムを選択するにあたっ て、それは少なくない意味を持っている。
  11. 11. Agenda 小論では、次のような角度から、GoogleのIaaS、Google Compute Engineの特徴を考えてみようと思う。 o  Googleクラウドの、耐障害性・高可用性 o  Googleのエンタープライズ・クラウドの取り組み o  Google Compute Engine o  Googleクラウドが提供する各種サービス o  クラウド内サービスを結合するPipe API o  GAE + GCEのユースケース
  12. 12. Googleクラウドの、 耐障害性・高可用性 クラウドを技術的に特徴づけるものは、コモディティ化 したマシンのScale-Outアーキテクチャーによる ScalabilityとそのAvailabilityである。 ただ、近年、クラウドの障害も少なくない。Googleの クラウドも例外ではない。まず、Googleクラウドの耐 障害性を高める取り組みを見ておこう。
  13. 13. 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
  14. 14. 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.
  15. 15. 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=1594206 o  GFSの単一マスターで行くという決定は、実際には、設計 の非常に早い段階でなされたものだ。主要には、デザイン をシンプルなものにするというのが、その理由だ。 o  ただ、問題は、すぐに起きていた。ストレージの容量が、数 百テラからペタバイトに、さらには数十ペタに増大するに つれて、マスターが維持しなければならないメタデータの 割合は、増えていった。
  16. 16. GFS: Evolution on Fast-forward o  同様に、データのボリュームとともに、リカバリーのデータ を探す為にメタデータをスキャンするというような操作がリ ニアなスケールで増えていく。こうして、マスターに要求さ れる仕事の量は、本質的に増大する。 o  GFSが、いまや、多くの挑戦にさらされているのは、疑問 の余地はない。一例を挙げれば、不断に増大するユー ザーの大群と直面していて遅延が大きな問題となるアプリ ケーションを、本来は、バッチ・システムの効率を上げる為 にデザインされたシステムの上でサポートしていることの、 不格好さは、誰の目にも明らかである。
  17. 17. GFS: Evolution on Fast-forward o  BigTableの登場は、この点では、いくらかの助けには なった。ただ、明らかになったのは、BigTable は、実際に は、GFSとは、最良の組み合わせではなかったということ だ。事実、この組み合わせは、GFSシステムの単一マス ターのデザインのボトルネックとしての限界を、他の場合 よりも、はるかに明らかなものとしただけだった。 o  これした理由から、Googleの技術者達は、過去2年間と いうもの、BigTableの利点を最大限生かしながら、現 GFSに取っては特に困難であると証明されているいくつか の問題を攻略する、新しい分散マスターシステムのデザイ ンに取り組んできた。
  18. 18. 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
  19. 19. 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.
  20. 20. 2011年1月 Megastore: Providing Scalable, Highly Available Storage for Interactive Services o  http://www.cidrdb.org/cidr2011/Papers/ CIDR11_Paper32.pdf
  21. 21. Megastore
  22. 22. Googleのエンタープライズ・クラウ ドの取り組み Google App Engine for Businessは、2010年5 月に、大々的に発表されたが、一年後の2011年5月 には、開発中止となった。
  23. 23. 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
  24. 24. VMware CEO Paul Maritz
  25. 25. 当時の問題意識: App Engineの エンタープライズ利用での問題 o  なぜ、GAE4Bを開発したのか? 当時のGoogleの問題 意識を振り返ることは、意味がある。App Engineは、エ ンタープライズ・システムとしては、次のような問題があっ たとされていた。 o  On Premise側では再利用できない、GAE独自のプログ ラミング・モデル。 o  SQLデータベースの未サポート。 o  機能上の制限(30秒ルール等)。
  26. 26. どのようなシステムを構想していたか o  新しいApp Engine for Businessは、次のような特徴を 備えているとされていた。 o  Spring Frameworkの採用により、PublicとOn Premiseのシステムとの間での連続的な移行可能性と Hybrid Systemの構築の容易さを獲得。 o  Java/Spring開発者の従来のスキルを、クラウド・プログ ラミングに活用ができる。 o  大規模なBigTableに加えて、標準的なSQLデータベース のアクセスが出来る。 o  SLA/サポートの保障。
  27. 27. 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
  28. 28. 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
  29. 29. 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/
  30. 30. Google Compute Engineの Project Internet CLI VM Private UI VM Network API VM Code Persistent Local Cloud Disk Disk Storage
  31. 31. API Basics Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  32. 32. APIの基本はREST JSON over HTTP o  APIが対象とする主なリソース n  プロジェクト n  インスタンス n  ネットワークとファイアウォール n  ディスクとスナップショット n  ゾーン o  アクション n  GET n  POST (create) と DELETE n  更新用に、カスタムの‘verbs’ o  認証  OAuth2
  33. 33. プロジェクト Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  34. 34. プロジェクト o  プロジェクトは、全てのリソースのコンテナで、次のような 情報を含んでいる。 o  チームを構成するメンバー情報 o  グループのリソースの所有情報 o  課金情報
  35. 35. インスタンス Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  36. 36. インスタンスは、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
  37. 37. ネットワーク Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  38. 38. ネットワーク 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 のみ
  39. 39. ストレージ -- 永続ディスク Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  40. 40. ストレージ -- 永続ディスク o  高速の、整合性を保証されたパフォーマンス o  APIを通じてアクセスする o  ‘zone’に置かれる o  一つのインスタンスからはR/W可能 o  複数のインスタンスからは、R/O o  暗号化されている
  41. 41. ストレージ – 一時ディスク Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  42. 42. ストレージ – 一時ディスク o  現在は、全てのインスタンスをブートするのに利用 o  インスタンスとともに、生成・消滅する o  巨大な‘拡張’デバイス o  同じ物理マシン上に置かれる o  4CPU以上では、専用ディスクが割り当てられる o  暗号化
  43. 43. ストレージ Google Cloud Storage Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  44. 44. ストレージ Google Cloud Storage o  インターネット上の、オブジェクト・ストア o  グローバル APIベースのアクセス o  データの取り出し・格納に非常に便利 o  サービスのアカウントで、摩擦なしにアクセス出来る
  45. 45. Locality Managing Location and Availability Project Internet CLI VM Private UI API VM Network VM Code Persistent Local Cloud Disk Disk Storage
  46. 46. Locality Managing Location and Availability o  Region: 地理的に離れていて、ルーティングされている o  Zone: 障害からの物理的な隔離が行われる範囲 o  制限プレビュー版では、3 Zoneが提供されているが、今 後、その数を増やしていく
  47. 47. Googleクラウドが提供する 各種サービス
  48. 48. 各種サービスの発表時期 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
  49. 49. Google DataStore Google DataStoreは、Google Bigtableの機能 拡張版である。 2011年5月10日 発表 https://developers.google.com/appengine/ docs/python/datastore/overview
  50. 50. Google DataStore o  マスター/スレーブ データストア n  マスター/スレーブ レプリケーション システムを使用し、 データが書き込まれるとデータは非同期に複製される。 n  読み取りとクエリに対して強い整合性 n  データ センターにトラブルや計画的ダウンタイムが発 生すると、一時的に利用できなくなる。 o  高レプリケーション データストア(デフォールト) n  データを、Paxos アルゴリズムに基づいて、複数(3っ つのZone)のデータ センターに複製。 n  非常に高い可用性を実現(書き込みの遅延は高い)。 n  結果整合性を保証。 n  マスター/スレーブ方式の約3倍のリソース消費。
  51. 51. Datastore/Megastore/Bigtable http://www.slideshare.net/ikailan/introducing-the-app-engine-datastore
  52. 52. エンティティとプロパティ o  データストアのデータ オブジェクトは「エンティティ」と呼ば れ、1 つ以上の「プロパティ」を持つ。 o  各エンティティはそれぞれを一意に識別する「キー」を持つ。 最も単純なキーは、「種類(kind)」とデータストアによって 付与される「エンティティ ID」である。 o  プロパティは、整数、浮動小数点値、文字列、日付、バイ ナリ データなどのいずれかのデータ型の名前付きの値。 o  データストア エンティティはスキーマレス。同じ種類の 2 つのエンティティのプロパティが同じである必要はなく、同 じプロパティに対して同じ値の型を使用する必要もない。
  53. 53. クエリとインデックス トランザクションとエンティティ グループ o  データストアのクエリではインデックスを使用する。イン デックスとは、クエリ結果が希望する順序で含まれる表で ある。App Engine アプリケーションでは、設定ファイル でインデックスを定義する。 o  アプリケーションでデータストアのエンティティに変更を加 えると、データストアは正しい結果でインデックスを更新す る。アプリケーションでクエリを実行すると、データストアは 対応するインデックスから結果を直接フェッチする。 o  Transaction API を使用すると、1 つのトランザクション 内で 1 つのエンティティに対して複数の処理を実行できる。 o  エンティティ グループは、エンティティ間の関係の階層構 造で定義される。
  54. 54. 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
  55. 55. 制限 o  エンティティの最大サイズ 1 MB o  エンティティの全インデックスの値の最大数  5,000 個 n  エンティティは、インデックスで、そのエンティティを参照する行と 列の各組み合わせに対して 1 つの値を使用する。インデックス に登録されたプロパティが複数の値を持つ場合、値が繰り返され て表に複数の行が必要になるので、エンティティのインデックス値 の数が増える可能性がある。
  56. 56. 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)
  57. 57. Free quota per app Pricing if you per day exceed your free quota Hosting Free quota per app Price per day On-demand Frontend 28 free instance $0.08 / hour Instances hours Reserved Frontend $0.05 / hour Instances High Replication 1G $0.24 / G / month Datastore Outgoing Bandwidth 1G $0.12 / G Incoming 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
  58. 58. 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
  59. 59. App EngineからMapReduceを 利用可能にする際、考えたこと o  スケールの次元の追加 n  非常に沢山のアプリが走っている n  それらのアプリが同時にMapReduceを走らせる o  隔離:そうしたアプリが、他のアプリのパフォーマンスに影 響を与えるべきではない。 o  リミットの評価:一日分のリソースを、15分間で使い切り、 オンライン・トラフィックも殺してしまうことを誰も望まない o  非常に遅い実行:無料のアプリは、リソースのリミット以下 にとどまりながら、とても遅く実行されることを望む。 o  保護:悪意のあるApp Engineの利用者から、システムを 守る。
  60. 60. Pipeline API o  複雑な仕事を、つなげて一つにまとめる新しいAPI o  Mapper + Shuffler + Reducer をつなぐ、接着剤 o  MapReduceのライブラリーは、完全に、Pipelineと統合 されている。
  61. 61. MapPipeline ShufflePipeline
  62. 62. ReducePipeline CleanupPipeline
  63. 63. 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)
  64. 64. Google Cloud SQL Google Cloud SQL は、Googleクラウド内の MySQLデータベースである。2011年10月6日、発表。 https://developers.google.com/cloud-sql/
  65. 65. Google Cloud SQLの特徴 o  MySQLデータベースを、クラウド上で動かす。 o  地理的にはなれたデータセンター間で、データベースの複 製を同期することが出来る。 o  mysqldumpを利用して、データベースのimport, exportが出来る。 o  Java, PythonからのAPIが使える。 o  コマンドライン・ツールがある。 o  Google API Consoleで、SQLが使える。
  66. 66. 制限 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()
  67. 67. Packages Billing Plan Tier RAM Included Included I/O Charge Storage per Day 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 Per Use Billing Plan 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
  68. 68. Google Cloud Storage Fast, scalable, highly available object store   2011年10月11日発表。 https://developers.google.com/appengine/ docs/python/googlestorage/
  69. 69. Google Cloud Storageとは? o  Google Cloud Storageは、Googleのクラウド・インフ ラの上に、データを格納し、それにアクセスする、 RESTful サービス。このサービスは、Googleクラウドの パフォーマンスとスケーラビリティを、先進的なセキュリ ティ技術と共有の能力とに結びつける。 o  全てのデータは、複数のデータセンタに複製される。 o  書き込みと、読み出しのデータの整合性は保たれる。 o  オブジェクトのサイズは、数テラバイトまで可能。アップ ロード、ダウンロードでレジュームが可能。range-GETを サポートしている。 o  バケットの名前空間は、ドメイン・スコープになっている。
  70. 70. Storage 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 Network Monthly Network Network Network Usage (Egress) - (Egress) - (Ingress) Americas and Asia-Pacific EMEA* (per GB) (per GB) 0 - 1TB $0.12 $0.21 Free Next 9TB $0.11 $0.18 Next 90TB $0.08 $0.15 Additional Data Transfer Contact us
  71. 71. Requests PUT, POST, GET GET, HEAD DELETE Requests bucket**, GET Requests service** (per 10,000 Requests requests/month) (per 1,000 requests/month) $0.01 $0.01 Free
  72. 72. クラウド内サービスを結合する 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/
  73. 73. Overview o  Google App Engine Pipeline API は、複雑で時間を 消費するワークフロー(人間の仕事も含む)を、一つに結 合する。 o  Pipeline APIの目標は、柔軟さ、ワークフローの再利用、 そして、テスト可能性である。 o  このAPIの第一のユースケースは、App Engineの様々 のMapReduceを、計算パイプラインに結合することであ る。
  74. 74. Job Graphs [ (x - y) * (x - z) ] - 2 http://code.google.com/p/appengine-pipeline/wiki/GettingStartedJava
  75. 75. 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); } }
  76. 76. 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));
  77. 77. ComplexJob and the child graph
  78. 78. 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()); }
  79. 79. 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);
  80. 80. Promised Values and External Agents o  PromisedValueは、ある非同期の外部のエージェントが 値を提供するとき、埋められるであろう、値のスロットを表 現している。このメカニズムは、このフレームワークが、 MapReduceのような他のフレームワークに呼び出しを 行って、同時に、パイプライン中に、人間からの入力を待 つことを可能にする。 o  次のパイプラインは、人間から三つの整数を受け取り、そ れをComplexJobに入力として渡し、その答えを人間に 返し、さらにもう一つ整数を要求し、追加の整数を、 ComplexJobの結果と掛けている。
  81. 81. 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); }
  82. 82. 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; } }
  83. 83. 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
  84. 84. 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
  85. 85. Pipelineは、どのように動くのか? http://static.googleusercontent.com/ external_content/untrusted_dlcp/ www.google.com/en//events/io/2011/ static/presofiles/ google_io_2011_pipeline_api.pdf
  86. 86. 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)
  87. 87. 先のコードでは、変数 A,B,C,X と関数 Multiply, Addの定義、中間結果の変 数 Ax_2,Bx が与えられている
  88. 88. yieldが生み出す結果を入れる スロットと、全てのスロットが満た された時にのみ、制御を次に進 めるBarrierが、用意される。
  89. 89. AX_2,BXの計算を始める。 それぞれは、独立した処理で 構わない。
  90. 90. 計算結果を、それぞれの スロットに格納する。
  91. 91. スロットが満たされると、それを Barrierに通知する。
  92. 92. Barrierは、全てのスロットが 埋まった時、次のステップを 実行する。
  93. 93. 準備ができている値を使って 次の計算が行われる。
  94. 94. 結果は、用意されたスロットに 格納される。
  95. 95. 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
  96. 96. 2つのデータストアPRODUCTとSALESの エンティティを、キー SKU でジョインするのに、 MapReduceを使うサンプル
  97. 97. 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)
  98. 98. 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 )
  99. 99. product_data = yield DatastrorageMapperPipeline( mapper_spec = ‘main.Datastore_map’ , entity_kind_spec = ‘main.ProductDescription’ , shards = 16 )
  100. 100. sales_data = yield DatastoreMapperPipeline( mapper_spec = ‘main.Datastore_map’ , entity_kind_spec = ‘main.ProductSales’ , shards = 16 )
  101. 101. shuffled_data = yield mapreduce_pipeline.ShufflePipeline( ‘Shuffle by Product ID’ , all_data, shards = 16)
  102. 102. 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)
  103. 103. Google BigQuery テラバイトのデータを、ボタン一つのクリックで分析す る。 2012年5月1日 発表 https://developers.google.com/bigquery/ https://developers.google.com/events/io/ sessions/gooio2012/312/
  104. 104. Google BigQuery o  Google BigQuery サービスは、非常に大きなデータ セット、可能的には数百万行のデータに対して、SQL-like な検索を行うことを可能とする。そのデータは、自分のも のであってもいいし、誰かが共有してくれたものでもいい。 o  BigQueryは、非常に巨大な、追加しか認められないよう な少数のテーブルからなるデータのインタラクティブな解 析に最適である。 o  もっと、伝統的なリレーショナル・データベースに対しては、 BigQueryの代わりに、Google Cloud SQL を使った方 がいいかもしれない。
  105. 105. 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’という ことばを含むタイトルを持つ論文を 探し出す。
  106. 106. BigQueryの特徴 o  スピード – 数百万行を数秒で解析する o  スケール – テラバイトのデータ、数兆のレコード o  単純さ – Googleのインフラの上で動く、SQL-likeな検 索言語 o  共有 – Googleアカウントを利用した、グループ・ベース、 個人ベースの強力なパーミッション機能。 o  セキュリティ – セキュアなSSLアクセス o  複数のアクセス方法 n  BigQueryブラウザ n  bq コマンドライン・ツール n  REST API n  Google Apps Script
  107. 107. SELECT corpus FROM publicdata:samples.shakespeare GROUP BY corpus; How many works of Shakespeare are there?
  108. 108. SELECT corpus, sum(word_count) AS wordcount FROM publicdata:samples.shakespeare GROUP BY corpus ORDER BY wordcount DESC; Which are the longest works?
  109. 109. https://developers.google.com/events/io/sessions/gooio2012/307/
  110. 110. 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()
  111. 111. GAE + GCEのユースケース Orchestrating Google Compute Engine through Google App Engine https://developers.google.com/events/io/ sessions/gooio2012/308/
  112. 112. Google App Engine + Google Compute Engine
  113. 113. Video Sharing System
  114. 114. Uploading Files
  115. 115. Create task queue entry
  116. 116. Task queue consumer
  117. 117. Workload
  118. 118. Shoe result
  119. 119. Scaling

×