40.Google Cloud Storageの新機能 (2013/07/23)

Tweet

Ryo Yamasaki(@vierjp)です。

・Cloud Platform Blog: New in Google Cloud Storage: auto-delete, regional buckets and faster uploads
によると、Google Cloud Storageに新機能が追加されたとのことなので調べてみました。
せっかくなのでメモを公開。

◯Object Lifecycle Management

Cloud Storage上のデータを一定期間経過後に自動で削除できます。
AppEngineのDatastoreのバックアップデータなんかを一定期間経過後に自動で削除するように設定しておくと便利そう。

bucketに対してこの設定をするので、そのbucket内に配置したファイル全てにこの削除ルールが適用される。
よって、バックアップデータの保持期間のポリシー毎にbucketを分けるのが良さげ。

削除ルールには二種類のパターンがあって、
・期間を指定(日単位)
・バージョニング機能を使っている場合に保持する世代数を指定(保持しておく最新のバージョン数を指定)


・lifecycle_config.xml の記述例 (365日後に削除)

<?xml version="1.0" ?>
<LifecycleConfiguration>
    <Rule>
        <Action>
            <Delete/>
        </Action>
        <Condition>
            <Age>365</Age>
        </Condition>
    </Rule>
</LifecycleConfiguration>

・以下のコマンドでルールを適用する

gsutil lifecycle set lifecycle_config.xml gs://bucket_name

・既存のルールを取得したい場合には以下のコマンドを実行する

gsutil lifecycle get gs://bucket_name > lifecycle_config.xml

設定を無効にしたい場合には以下のような設定が空のxmlファイルを作成してそれをセットする。

<?xml version="1.0" ?>
<LifecycleConfiguration/>

◯Regional Buckets

Cloud Storageのbucketは US, EUというレベルでも指定できるが、
この機能ではさらに細かいリージョンのレベルで指定することが可能。

「bucketのリージョン」を「使用しているCompute Engineのリージョン」と同じにすれば転送速度が速くて良い、とのこと。


・ロケーションの種類
Google Cloud Platformでの「ロケーション」には、とりあえず以下の3つの概念があるようだ。

・国家・大陸 (national/continental)・・・US, EU (現状この2つ)
・リージョン ・・・ US-CENTRAL1 等
・ゾーン・・・・・・us-central1-a 等
(下に行くほど狭い概念になる)


App Engineは「国家・大陸」のレベルで指定できる。(ただしEUはプレミアプランのみ)
Cloud Storage「国家・大陸」のレベルか「リージョン」レベルを指定できる。
Compute Engineではインスタンスや永続ディスク(PD)を作成する際に「ゾーン」を指定する。
(「ゾーン」は「リージョン」の下位に紐づくので、「ゾーン」を指定すると自ずと「リージョン」も決まる)


・「Regional Buckets」の作成方法
bucket作成時に以下のように 「-l」(location)オプションでリージョンを指定する。

gsutil mb -c DRA -l US-CENTRAL1 gs://myregionalbucket

・現在Cloud Storageで指定できるリージョン
US-EAST1
US-EAST2
US-EAST3
US-CENTRAL1
US-CENTRAL2
US-WEST1

・現時点で存在するCompute Engineのリージョン
US-CENTRAL1
US-CENTRAL2
EUROPE-WEST1


当然リージョンは一致しているだろうと思ったら違った。
Cloud Storageで指定できる「US-EAST」と「US-WEST」はCompute Engineには無いし、
Compute Engineで指定できるEUROPE-WESTはCloud Storageで指定できないらしい。

ということは現時点で指定するなら「US-CENTRAL1」か「US-CENTRAL2」ということになるだろうか。


・Durable Reduced Availability (DRA) でのみ利用可能？
ブログには「Durable Reduced Availability (低可用性・低価格のストレージ) で使える」と書いてある。
Cloud Storageのドキュメントにはその点についての記述が見つからないし、
ドキュメント内のコマンドの例でもDRAのオプション(「-c DRA」)を指定していない。

しかし実際にDRAオプションを指定せずにコマンドを実行した場合、エラー(500エラー)となって失敗した。
DRAオプションを指定したら成功した。

システムエラーなので絶対これが原因とは断言しづらいけど、
やはりブログに書いてある通りDRAの場合のみ指定できるように思える。

◯gsutil - Automatic Parallel Composite Uploads

Google I/O のセッションにもあった「大きいファイルの分割Uploadするテクニック」を自動でやってくれるらしい。
大きいファイルを扱う場合に楽になりそう。


.botoファイルで以下の設定をすることが可能。

・parallel_composite_upload_threshold
閾値の指定 ここで指定した値を超えるサイズのファイルが自動で分割Uploadされる

・parallel_composite_upload_component_size
分割ファイルのサイズ

この自動分割アップロード機能を完全に無効にしたい場合には、「parallel_composite_upload_threshold」の値を「0」にする。
(自分で分割したファイルをアップロード・サーバー上で結合したい場合にこの機能が邪魔になることがあるらしい)

・分割アップロードされた一時ファイルはサーバー上で結合された後に削除される。
・結合前に転送に失敗した場合は、リジュームを活用して再度アップロードされる。
・この場合も結合まで成功したら一時ファイルは削除される。
・アップロードが正常に完了するまで一時ファイルは残る。

◯Durable Reduced Availability Storage (DRA Storage)

これは以前からある機能だけど、関連するので補足。

Durable Reduced Availability Storage は可用性が低いけど料金が安いストレージ。
・Pricing and Support - Google Cloud Storage — Google Developers

ドキュメントによれば、データのバックアップに向いているという話。
> (データのバックアップには) 高耐久性(durability)が重要ですが、最高の可用性(availability)は必須ではありません。

バックアップ時に落ちてて失敗してたら結構嫌な気もするけど、、高耐久性の方が重要そう。
「高可用性のbucket」だとしても失敗は把握できるようにしておくべきだから、
トレードオフとしてアリな気がする。


・DRAバケットの作成方法

gsutil mb -c DRA gs://<bucketname>/

・既存のバケットからデータを(事実上の)コピーするコマンド

gsutil cp -D -R gs://<standard_bucket>/* gs://<durable_reduced_availability_bucket>

現時点では「既存の標準バケット」を「DRAバケット」に変更したり、
「標準バケット」から「DRAバケット」に直接オブジェクト(ファイル)のコピーはサポートしていない。
新規にbucketを作成して、一度ダウンロードしてから再度アップロードする必要がある。

そのため「-D」で「daisy chain」オプションを指定する。
直接コピーはできないが、このコマンドを実行すると
一度ローカルのPCにデータをダウンロードして、それから新しいバケットにアップロードする形になるので
コマンド一発で「ダウンロード→アップロード」できる。

ただしこの場合に注意点が2つ。
・「ダウンロード + アップロード」をしているのでそれら両方に対して料金がかかる。
・このコマンドを実行する前にコピー先のbucketにデフォルトのACLを設定しておくべし。
　(サーバー上でのコピーではなく新規Uploadなので、コピー前のACL(アクセスコントロール)情報は失われる)

◯参考リンク

・Cloud Platform Blog: New in Google Cloud Storage: auto-delete, regional buckets and faster uploads
・Object Lifecycle Management - Google Cloud Storage — Google Developers
・Regional Buckets - Google Cloud Storage — Google Developers
・mb - Make buckets - Google Cloud Storage — Google Developers
・Durable Reduced Availability Storage - Google Cloud Storage — Google Developers



そのうちバージョニングも勉強しなきゃなぁ、と思いつつ今回はここまで。ﾉｼ



Tweet

31.Google Cloud Storageに大量データをアップロードする際のテクニック(Google I/O 2013)

Tweet

Ryo Yamasaki(@vierjp)です。

Google I/Oで聞いた「Importing Large Data Sets into Google Cloud Storage」のセッションについて、
動画を見て復習したのでメモを公開。
(動画も上記URLにあります)

◯Small to medium imports

gsutilを使った小〜中規模のアップロード方法
*「gsutil」はGoogle Cloud Storageを扱うためのCUIのツールです。

・ディレクトリ構造
[Directory]
├data
｜├data1.csv
｜├data2.csv
｜├data3.csv
｜└data4.csv
└data.csv

・カレントディレクトリのファイルをUploadする

gsutil cp data* gs://iodemo

・サブディレクトリ内のファイルも再帰的にUploadする

gsutil cp -R data* gs://iodemo

・bucket内のファイルを参照する

gsutil ls gs://iodemo

（Google Cloud Consoleからも同様に確認できます)

・ローカルからCloud StorageにUploadする

gsutil cp *.txt gs://my_bucket

・Cloud StorageからローカルにDownloadする

gsutil cp gs://my_bucket/*.txt .

・S3からローカルにDownloadする

gsutil cp s3://my_bucket/*.txt .

・S3からCloud Storageにコピー

gsutil cp s3://my_bucket/*.txt gs://my_bucket

・Cloud StorageからS3にコピー

gsutil cp gs://my_bucket/*.txt s3://my_bucket

*S3との転送にも対応しているのですね

◯マルチスレッドで高速にUploadする方法

Composite Objects and Parallel Uploads - Google Cloud Storage — Google Developers

通常CPコマンドはファイルを1つずつUploadするのでファイル数が多いと時間がかかります。
そこで「-m」オプションを指定するとマルチスレッドで複数ファイルを並列にUploadできます。
(比較的最近追加された機能なので古いgsutilでは使えません。最新版を使いましょう)

gsutil -m cp 〜〜

複数ファイルを並列に同時アップロードするので帯域とDisk I/Oをフルに使ってアップロードが可能になります。



◯Use object composition to improve throughput
サイズの大きなファイルを高速にUploadする方法

1.ファイル「big-file」を「big-file-part-*」に分割

split -n 10 big-file big-file-part-

2.マルチスレッドでUpload

gsutil -m cp big-file-part-* gs://bucket/dir/

3.ローカルの分割ファイルを削除する

rm big-file-part-*

4.Cloud Storage上で分割ファイルを結合する

gsutil compose gs://bucket/dir/big-file-part-* gs://bucket/dir/big-file

5.Cloud Storage上の分割ファイルを削除する

gsutil -m rm gs://bucket/dir/big-file-part-*

* 操作が増えるのでお金は若干余計にかかるそうです。

◯S3からCloud Storageへ、5ペタByteのデータをコピーした事例

・可能な限り速くコピーする
・Live Migration(ダウンタイム無しに)
という条件。

・AppEngineのDatastoreにオブジェクト(ファイル)のリストを持っているっぽい。
・オブジェクト名の一覧をAppEngine上で取得
・AppEngineからTaskQueueを使ってCompute Engine上に配置した「コピー処理」をキック
・Compute Engineはgsutilを使ってS3からGCSにコピー
　(ピーク時に160のCompute Engineのインスタンスが走っていた)
・顧客のシステムからVerify(hash値が一致する事を確認)
(たぶんこんな感じ？間違ってるかも)

平均で秒間10GB、最大で秒間20GBのコピーを行った。

・Object Change Notification (experimental)

Object Change Notification - Google Cloud Storage — Google Developers
bucketに対する変更の通知をWebアプリで受け取ることができる。

・JSON API  (experimental)

Getting Started - Google Cloud Storage — Google Developers

Cloud Storageに対して操作を行うJSONのAPI
JSON APIを使うと「batch request」をすることができる。
「gsutil -m」のように「呼び出し側からマルチスレッドで並行に複数のリクエストを投げる」のではなく、
「一度のリクエストで複数の命令を投げる」手法。

一気に大量のオブジェクトに対してアクセス権限を設定したり削除したりする場合等に有効。

◯Partition with Prefix

ファイル名の先頭文字列毎にUploadするテクニック。
Prefixを指定してコピーすることで簡単に同時実行する。

例えばファイル名が「0-9」で始まっているなら、以下のようにすることでさらに10分割して並列にUploadできます。

gsutil -m cp 0* gs://my_bucket
gsutil -m cp 1* gs://my_bucket
gsutil -m cp 2* gs://my_bucket
・・・
gsutil -m cp 8* gs://my_bucket
gsutil -m cp 9* gs://my_bucket

◯Copying a specific list of files from a text file or program output

テキストファイルやプログラムの出力結果で指定されたファイルをアップロードするためのテクニック

・files.txt

README.md
notes.txt
images/disk_import.jpg

catした結果をパイプで繋いでgsutilに渡す。

cat files.txt | gsutil -m cp -I gs://my_bucket

→リストに書いてあるファイルが全てコピーされる

◯run gsutil near to your source or target

ネットワーク的に速い環境からコピーするため、
ファイルのコピー元かファイルのコピー先に近いところで実行するべし、というお話。

Cloud StorageにUoloadするならCompute Engineからが速そう。
そして話は次の「Offline Disk Import」に繋がります。

◯Offline Disk Import (Limited Preview)

Offline Disk Import - Google Cloud Storage — Google Developers

Uploadしたいファイルをハードディスクに入れて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」加算されます。

◯Google Cloud Storageの最近のリリース一覧

・Versioning
・Durable Reduced Availability storage
・30% price drop
・Cloud Console
・Composite Objects
・Notifications
・JSON API
・Offline disk import



個人的には、あとはリクエスト回数に対する課金額を
「Amazon S3のリクエスト50％～60％値下げを全リージョンで開始、これまでの半額以下に」
に追従してくれれば、と思います。
2013/4/3にAmazonが半額にした結果、
これだけGoogle Cloud StorageがS3の2倍のお値段になっちゃってるんですよね(´・ω・｀)
他は概ねS3より若干安い料金体系なのですが。





Tweet

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

Tweet

こんばんは。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

こちらも併せてどうぞ！

Tweet