2013年5月17日金曜日

27.Google I/Oで発表されたGoogle Cloud Platformの新機能





こんばんは。Ryo Yamasaki(@vierjp)です。

現在Google I/Oに参加するためサンフランシスコに来ています。
今は2日目の夜ですが、
Google Cloud Platformの変更点についてセッションを聞いて理解した限りで書こうと思います。
まだ検証もドキュメントの確認もちゃんとできていないので間違っている点もあるかもしれませんが予めご了承ください。
3日目のセッションを聞いた後や実際に検証した上で間違いに気がついたら訂正なり追加の記事なり書くと思います。

間違いに気がついた方はツッコミやご指摘いただけたら幸いです。


◯Google App Engine


◯PHP対応


https://developers.google.com/appengine/docs/php/

・概要
AppEngine上で使えるプログラミング言語として、
Python、Java、Goに続く第四の言語としてPHPが追加されました。
言語に関する要望の中では昔からPHPが一番多かったそうで、今回ついに対応となりました。


ドキュメント内ではデータアクセスとして書かれているのが
「Cloud SQL」と「Cloud Storage」のみで「Datastore」についての言及がありませんが、
セッション中のサンプルコードにはDatastoreへのアクセスっぽいコードが存在していました。
* 2013/5/23追記 セッションの動画を見直したら「Cloud Data Store」(後述)と言っていました。



* 2013/5/24追記 早速Limited Previewをもらえたので試してみました。以下の記事も参考にどうぞ。
28.Google App Engine for PHP (GAE/PHP) を早速試してみた
29.Google App Engine for PHPでWordPressを動かしてみた
30.Google App Engine for PHPにおけるポータビリティを考える
36.Google App Engine for PHPでWordPressを運用するためのプラグインが登場
39.Google App Engine for PHPでCakePHPを動かしてみた


◯Modulalized Applications (Servers?)



スライドによって名称が「Modulalized Applications」だったり「Servers」だったりしましたが、同じ物を指していると思います。

おそらくTrusted Tester中に「Servers」と呼ばれていた機能で、
一つの「アプリ」の中に複数の「コンポーネント」を定義できるものではないかと。
これは現在の「アプリケーション」と「バージョン」の概念の間に存在するような仕組み。
たぶんこんな感じ?(想像図です)

概念は既存の「backends」の位置づけに似ていますが、
・スケーリング
・デプロイ
・バージョニング
・パフォーマンス設定
を「コンポーネント」毎にできるようになります。
例えば、
インスタンスクラス(F1等)やインスタンス数等の設定は「コンポーネント」毎に設定できます。
と言っても既存のBackendsでも上記については一応できていたので、
もう少し細かく設定できたり制限がなくなるといった要素もあるのかもしれません。
セッションでは「3つのコンポーネントに分けているアプリ」の例もありましたが、
「Frontendとbackends」という既存の分け方を、より柔軟にするような趣旨かと思います。

これが正式リリースされた際に既存の「Frontend」「Backend」がどうなるかは少し気になります。
(既存のアプリのために何らかの形で残りそうには思いますが)

以下についてはアプリ毎に存在し、各コンポーネントから共有する形になります。
・Datastore
・Memcache
・TaskQueue

この機能について、あるセッションでは「Launched Today」と書いてあったり、
また別のセッションでは「Limited Preview」と書いてあったりで、
リリース時期がいまいち不明です。

ただ、これがリリースされたらさすがに管理画面の構成が変わるはずですが、
現状変わっていないのでおそらくまだ「Limited Preview」なのでしょう。


◯Mobile Backend Starter




「サーバーサイドのコードを一切書かずにサーバーと連携するAndroidアプリを作る」ためのAppEngineアプリ。
「Mobile Backend Starter」は「Platformの拡張」ではなく、「AppEngineのアプリケーション」として提供されます。

以前からこのブログで扱っている「Google Cloud Endpoints」も近い要素がありますが、これは本当にサーバーの知識が不要です。

・サーバー側アプリをデプロイをするための環境を構築する必要が無い
→eclipseをダウンロードして、アプリのソースコードを取得してデプロイする・・・という作業が必要ありません。
Webの画面上から「Mobile Backend Starter」のアプリを直接デプロイすることができます。

・OAuth2の認証をサポート
 (内部的にはCloud Endpointsを使用しています)

・サーバー側のコードを書く必要が無い
→DAOをAPIとして公開するような作りになっていて、クライアント側からクエリの内容を指定してクエリを実行します。
 (詳しく見ていないけどアクセスコントロールの仕組みはちゃんとあるらしい)

・ContinuousQuery
 ・サーバー側でクエリの結果に影響するデータが登録されると自動でクライアント側の画面に反映される
  ・クライアント側からクエリを実行した際にProspective Searchに端末IDとクエリの内容を登録する
  ・データの更新時にProspectiveSearchが呼び出される(登録内容にマッチする更新が行われたか、が確認される)
  ・ProspectiveSearchに登録した条件にマッチした場合、GCMを使ってクライアント側に通知する
  ・クライアント側はGCMのMessageを受け取ると、API経由でクエリを再実行して「最新のクエリ結果」を取得して描画する

・クライアント側を楽に実装するための仕組みも用意されているらしい。

大々的に好評されていませんでしたが実は4/20ぐらいにはリリースされていて、少しソースを読んでいました。
Mobile Solutions - Google Cloud Platform — Cloud Platform」で
「Try it now」ボタンを押して利用を開始する事ができます。

ソースコードも公開されているので、
ProspectiveSearchとGCMの利用方法のサンプルアプリとして見ても面白いと思います。



◯Cloud Datastore


https://developers.google.com/datastore/

Blog @vierjp : 33.Google Cloud Datastoreを試してみた 概要編 (1/3)」に詳細をまとめ直しています。

◯概要
位置づけとしてはAppEngineのDatastoreを単独のサービスとして切り出したもの。
現在「Preview Release」という扱い。
概要レベルでは機能も同じとのこと。
ただしプログラムからの呼び出し方は大きく異なる模様。

これまでDatastoreはAppEngineの各アプリと1:1で完全に紐付いていて、
そのアプリ以外からアクセスすることができなかったが、
Cloud Datastoreとして単独のサービスになった事で、
異なるAppEngineアプリや環境から呼び出すことができるようになった。

複数のAppEngineのアプリから同一のDatastoreにアクセスしたり、
逆に一つのAppEngineのアプリから複数のDatastoreにアクセスしたり、
Compute Engineからアクセスしたりもできる。
さらには別のクラウドやオンプレミスのサーバーからもアクセスできる。


◯Cloud DatastoreのAPI
基本的に既存のDatastoreと機能は同じだそうですが、
ドキュメントを見る限りアクセス方法は異なります。
Protocol Buffer形式でリクエストを投げる「Protocol Buffers API」か、
JSON形式でリクエストを投げる「JSON API」を使用します。
Protocol Buffers APIは現状JavaとPythonから利用できます。
(現時点でGO用・PHP用は用意されていません)

注意が必要なのは既存のDatastoreアクセスに使っている「Low Level API」とは異なるという事。
そのため現在利用している「Low Levle APIベースのフレームワーク」は
「Cloud Datastore」に対してそのままでは使えないのでしょう。
(API Proxyレベルで処理を差し替えて対応できたりしないだろうか)
* 2013/06/11 追記 AppEngine上のアプリからはこれまで通りに使えます。
詳しくは「Blog @vierjp : 33.Google Cloud Datastoreを試してみた 概要編 (1/3)」を参照。

JSON API経由なら言語を問わず利用する事ができるので、
node.jsのサーバーから利用する」ような事もできます。

JSON APIは既にAPIs Explorerに表示されています。
Discovery APIベースなので、多くの言語に対応するClient Libraryが公開されることでしょう。


◯ユースケース
- ケース1 AppEngineアプリのバックエンドとしてCompute Engineを使う場合

AppEngineのアプリが保存する大量データの処理にCompute Engineを使う。
データの保存領域に「Cloud Datastore」を使うことで、
時間のかかる大量データの処理をCompute Engine上のバッチから行う事ができる。
(Cloud DatastoreならAppEngineのアプリとCompute Engineの両方からアクセスできるので)

ComputeEngineを使っていわゆる「夜間バッチ」的な一括処理に使ったり、
DatastoreのデータをBigQueryに転送する前に加工したり、
という用途が思いつきます。

これまではAppEngineアプリの持つ大量データの処理は
「Shutdown対応」をした上でbackendsを使ったり、細かいたくさんのTaskに分散させて処理する等、
実装段階で手間をかけていましたが、それが軽減されるでしょう。


- ケース2 Compute Engine上にWebアプリを配置する場合
AppEngineを使わない場合でも、
例えばCompute Engine上にnode.jsのサーバーを立てて、
そのデータ保存領域としてCloud Datastoreを使うということもできます。

実際にI/O 3日目の「Code Labs」でこの説明が行われるようです。
「Getting Start」では「node.jsからGoogle Cloud Datastoreを使う方法」について書かれています。
Overview - Google Cloud Datastore — Google Developers


- ケース3
 AppEngine・ComputeEngine以外のクラウド環境からデータを操作する
 JSON APIがあるので基本的にどこからでも操作できるはずです。
 自社にあるオンプレミスのサーバーからアクセスすることもできますし、
 アプリのアップグレードに伴うデータの一括更新処理をローカル環境から実行するようなこともできるでしょう。
 (この場合ComputeEngineから動かすのと比べて速度が遅そうですが)


◯Preview期間中の制限
Preview期間中は、課金を有効にしている場合にも、
Read、Write、Small Operationそれぞれに対して
「10 million per day, no more than 500 per second」のlimitが設定されています。
(連絡すれば増やしてもらえるそうです)



◯Google Compute Engine



現地時間で15日についにGoogle Compute Engineが一般公開されたそうです。
以前と比べて変更されたのは以下のとおりです。

- Sub-hour Billing
 課金の時間単位が変わったそうです。
 最低課金額は10分単位だが、その後は一分単位で課金される、とのこと。

- Shared Core Instance
 →f1-micro,g1-smallの追加
  さらに安いインスタンスが追加されました。
  これまでの一番安いインスタンスが「n1-standard-1」の「$0.115/h」ですが、
  「f1-micro」は「$0.019/h」で格段にお安くなっています。
  実際にどのくらいのパフォーマンスがあるのかわかりませんが、
  メモリをそれほど必要としない長時間の処理に良いのでしょう。

- Advanced Routing
3日目のセッションで話されるそうですが未確認です。
* 2013/5/25追記 オンプレミス環境や他のクラウドとセキュアに繋ぐためのVPN的なもの・・・らしいです。

- Persistent Diskのサイズが最大10TBになった。
これまでの最大サイズ「1TB」から10倍の「10TB」になります。

参考:
Google Compute Engine Pricing (料金体系)



◯Google Cloud Storage (2013/5/23追記)

すっかり忘れてましたがセッション動画見直していたら新機能があったので追記。

◯Offline Disk Import (Limited Preview) 
https://developers.google.com/storage/docs/early-access?hl=ja

アップロードしたいファイルをハードディスクに入れてGoogleに送ると、
Google内のネットワークからUploadしてくれる
という究極手段。
(最初ネタかと思ったのは内緒^-^;)

Google/IO 初日の5/15にサービス開始。

・手順
1.Offline Disk ImportのInterest Formから申し込み
2.SATAのハードディスクをencfs(暗号化ファイルシステム)でフォーマットする
3.データをハードディスクにコピーする
4.Googleに郵送する
5.Googleが顧客が所有する新しいbucketにimportする(Googleの高速なネットワークを使って)
6.GoogleがHDDを郵送で返す

* 現時点ではアメリカ国内の顧客限定です
ただし、間違いなく今後数ヶ月の間に国際的に利用できるように拡大するし、
優先順位が上がるかもしれないので海外の顧客も「Interest Form」から連絡してください、とのこと。

料金は通常のGoogle Cloud Storageの料金がリクエスト回数, 帯域使用料,ストレージ使用料」に加えて
HDD一つ毎に「$80」加算されます。

* 2013/5/24追記 Google Cloud Storeのセッションに関して別途詳細記事を書きました。
31.Google Cloud Storageに大量データをアップロードする際のテクニック(Google I/O 2013)



◯Google BigQuery (2013/5/28追記)

IO報告会(#Devfest)で知ったので追記。

◯Google Analytics and AdSense Data Analysis in BigQuery
AdSense BigQuery Integration Guide - AdSense — Google Developers

・BigQueryでGoogle AdSenseのデータを分析可能になりました
・Google Analyticsのデータは2013年9月の公開を目指しているそうです

AdsenseにしてもAnalyticsにしても、
BigQueryを使ってこれらと自社で持っている別の情報とをJoinして分析できる事が魅力です。

Google BigQueryのセッションに関して別途詳細記事を書きました。
32.Google BigQueryでAnalyticsとAdSenseのデータを分析する(Google I/O 2013)


概要レベルですが、今日はここまでとしてまた近日中に続報を書こうと思います。

以上、 San Franciscoからでした!



◯TopGate社 Google I/O フィードバックセミナー (2013/6/11追記)

2013/5/31に行われた「TopGate社 Google I/O フィードバックセミナー」で
私がGoogle Cloud Platform担当として発表したスライドです。
Report of Google I/O 2013 Google Cloud Platform

こちらも併せてどうぞ!


0 件のコメント:

コメントを投稿