Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
Google App Engine における非同期処理の効率的な使い方
2015年10月20日火曜日
* この投稿は、米国時間 10 月 15 日、RealMassive の CTO で博士号を持つ Jason Vertrees と、Principal Software Engineer の David Lippa によって投稿されたもの（
投稿はこちら
）の抄訳です。
今回のゲスト投稿は、RealMassive の CTO で博士号を持つ Jason Vertrees 氏と、Principal Software Engineer の David Lippa 氏です。RealMassive は、Google App Engine を使ってリアルタイムで不動産情報を有料配信しています。
マルチプロセスとマルチスレッドは現代のアプリケーションの主流です。Google App Engine は、並列処理の主要な方法として
tasklet
と
deferred task
を提供しています。ここでは、この 2 つのテクノロジーを深く掘り下げ、非同期処理のために tasklet を使うべきケースは何で、deferred task を使うべきケースは何なのかを考えてみます。
tasklet は、アプリケーションのイベント ループにおいて、yield 文に達するまで非同期に実行される関数です。yield 文はスケジューラに対して次の呼び出しに移るよう指示します。一般的なユースケースは、ほかの仕事をしながらデータ ストアからエンティティを非同期にフェッチするというものです。
この場合、ブロックするのはエンティティが必要になったときだけです。
tasklet は、トランザクションのコンテキストで標準的に使うこともでき、非トランザクション実行、既存トランザクションの継続、新トランザクションの開始の 3 通りにデコレートできます。tasklet は、tasklet を起動した HTTP リクエストの処理中に実行されるので、要求の 60 秒のデッドラインを超過させることがあります。
また、伝統的な ThreadPool のコンテキストで実行される Thread によく似ており、同じように管理する必要があります。
deferred task は“ファイア・アンド・フォーゲット”です。長時間実行され、戻り値が無視される冪等な処理であり、deferred task を起動した HTTP リクエストよりもずっと後に実行することができます。RealMassive では、バッチへの分割が必要なダイジェスト メールの送出に deferred task をよく使っています。このような意味では、deferred task は Thread というよりも MapReduce の Mapper や Reducer に近い存在です。
タスクはプッシュまたはプルの“タスクキュー”に追加され、キュー * のルールに基づいて実行されます。deferred task は長時間実行できるので（10 分以上になることがよくあります）、トランザクション処理のデコレートを行ったときに動作が非常に大きく変わります。1 つのトランザクションの中に追加できる
トランザクション タスクは 5 つだけ
で、それらはトランザクション終了前に実行され、必ずしもただちに実行されるとは限りません。
時間がかかる処理をトランザクション実行しなければならないとき、デベロッパーがすべきことは何でしょうか。本物のデータ モデルを単純化、正規化したものを使って、RealMassive が実際に直面した例について見てみます。このデータ モデルは過度に単純化したものではありませんが、わかりやすいものです。
まず、いくつか注意すべきポイントを挙げておきます。
すべてのエンティティは、そのエンティティに対して処理を行った User の NDB キーでタギングされています。
Space は Building 内のスイートを表現します。Space は Building のフロアにあり、平方フィート単位のサイズを持ちます。イメージやビデオなどの添付物を持つこともあります。
Building は物理的なビルを表現します。それぞれの属性（床面積の合計やオーナーなど）、住所を持ちます。
Spaces と Buildings は互いに相互参照を持ちます。
from google.appengine.ext import ndb, deferred
class User(ndb.Model):
username = ndb.StringProperty()
email = ndb.StringProperty()
class BaseModel(ndb.Model):
created_by = ndb.KeyProperty(User)
edited_by = ndb.KeyProperty(User, repeated=True)
class Media(BaseModel):
url = ndb.StringProperty()
edited_by = ndb.KeyProperty(User, repeated=True)
class Address(ndb.StructuredProperty):
street = ndb.StringProperty()
city = ndb.StringProperty()
state = ndb.StringProperty()
zipcode = ndb.StringProperty()
class Building(BaseModel):
address = ndb.StructuredProperty(Address)
size = ndb.IntegerProperty()
# prevent cyclical dependencies
space_keys = ndb.KeyProperty(kind=’Space’, repeated=True)
owner = ndb.KeyProperty(User)
def remove(self):
for s in space_keys:
s.get().remove()
self.key.delete()
class Space(BaseModel):
building = ndb.KeyProperty(Building)
sf_available = ndb.IntegerProperty()
floor_number = ndb.IntegerProperty()
suite_number = ndb.IntegerProperty()
attachments = ndb.KeyProperty(Media, repeated=True)
def remove(self):
for a in attachments:
a.delete()
ここで最初の問に戻りましょう。たとえば、このデータ モデルの下で NDB から Building を削除するタスクのように、トランザクション実行しなければならない時間のかかるタスクをどのように処理すればよいのでしょうか。
NoSQL の場合と同じように、カスケードする削除はトランザクション内でプログラムによって実行しなければなりません。依存関係の木構造を適宜下のレベルまで下りていくのです。
現状では、私たちの実装にはいくつか欠陥があります。
削除処理は、HTTP リクエストを実行しているのと同じスレッドで実行されるので、多くの Space を持つ Building では、削除処理によって DeadlineExceededError が起きる可能性があります。
削除処理がトランザクション実行されていないため、1 つの Space の処理が失敗すると、迷子の Space が生じる可能性があります。
Media には寿命を管理する参照カウントがないため、やはり迷子になる可能性があります。
これらの欠陥から考えると、正解は deterred task の中で削除を実行し、remove() 呼び出しを
ndb.transactional
でデコレートすることかもしれません。そうすると、どうなるかを見てみましょう。
class Building(BaseModel):
address = ndb.StructuredProperty(Address)
size = ndb.IntegerProperty()
# prevent cyclical dependencies
space_keys = ndb.KeyProperty(kind=’Space’, repeated=True)
owner = ndb.KeyProperty(User)
@ndb.transactional(xg=True)
def remove(self):
for s in space_keys:
deferred.defer(s.get().remove)
self.key.delete()
class Space(BaseModel):
building = ndb.KeyProperty(Building)
sf_available = ndb.IntegerProperty()
floor_number = ndb.IntegerProperty()
suite_number = ndb.IntegerProperty()
attachments = ndb.KeyProperty(Media, repeated=True)
@ndb.transactional(xg=True)
def remove(self):
for a in attachments:
deferred.defer(a.delete)
しかし、このアプローチにもいくつか問題があります。
キューが同時処理をサポートする場合、キューのペースを 1/ 秒に設定しない限り、削除の順序を保証することはできません。
Building.remove()
は、
Space.remove()
に処理を委ねる前に
get()
を呼び出しているので、デッドラインを超える可能性があります。
すべてが同じトランザクション内で実行されるように見えるため、このコードのセマンティクスは非常にわかりにくくなっています。
スケーラビリティがありません。Building が 5 つ以上の Space を持つ場合、トランザクション内の deferred task の数の上限を超える可能性があります。また、グループをまたがるトランザクションは
クロックタイムで 30 秒に制限されています
。
本当の正解は、ほとんどの処理で tasklet を使い、処理を先延ばしするかどうかを呼び出し元に決めさせることです。
class Building(BaseModel):
address = ndb.StructuredProperty(Address)
size = ndb.IntegerProperty()
# prevent cyclical dependencies
space_keys = ndb.KeyProperty(kind=’Space’, repeated=True)
owner = ndb.KeyProperty(User)
@ndb.transactional(xg=True)
@ndb.tasklet
def remove(self):
futures = []
for s in space_keys:
sp = yield s.get_async()
futures.extend(sp.remove_async())
ndb.wait_all(futures)
self.key.delete()
class Space(BaseModel):
building = ndb.KeyProperty(Building)
sf_available = ndb.IntegerProperty()
floor_number = ndb.IntegerProperty()
suite_number = ndb.IntegerProperty()
attachments = ndb.KeyProperty(Media, repeated=True)
@ndb.transactional(xg=True)
def remove_async(self):
return ndb.delete_multi_async(self.attachments)
def remove(self):
ndb.Future.wait_all(self.remove_async())
tasklet と deferred task は、どちらも App Engine の並列処理を単純化する抽象を提供します。トランザクション内で処理を行っている場合や、HTTP リクエストの寿命が尽きた後も処理を行う場合には、非同期処理に見合った適切なテクノロジーを選ぶことが大切です。
* タスクキューの違いや細部には深入りしません。詳しくは引用先を参照してください。
新設の us-east1 リージョンで App Engine と Cloud Datastore が利用可能に
2015年10月19日月曜日
* この投稿は、米国時間 10 月 15 日、Product Manager である Lorne Kligerman によって投稿されたもの（
投稿はこちら
）の抄訳です。
Google は先ごろ、
米国サウスカロライナでの us-east1 リージョンの新設
に伴い、Google Cloud Platform が多くの人々や企業にとってさらに身近なものになると発表しました。
そしてベータ段階にあるこの新リージョンでの
Google App Engine
と
Google Cloud Datastore
の提供を開始しました。
us-east1 では、App Engine や Cloud Datastore などの Cloud Platform サービスがホストされるので、サービス間で高速な通信が可能なうえ、マルチゾーンでの App Engine と Cloud Datastore の高可用性を実現できます。
App Engine を Compute Engine や Cloud Storage と組み合わせたソリューションを構築したい人や、すべてのレプリカを相互に非常に近接させて Cloud Datastore の書き込みレイテンシを低く抑えたい人にとっては、これはビッグ ニュースです。
us-east1 の利用を開始するには、
Developers Console
を開いて新しいプロジェクトの作成を選択し、App Engine の場所として us-east1 を指定します。いったんプロジェクトを作成するとリージョンは変更できないので、注意してください。
世界各地の Google データセンターで提供されるサービスや、アプリケーションのデプロイにおけるベスト プラクティス、さまざまなリージョンやゾーンへのデータ保存について詳しく知りたい方は、Google の
Cloud Datacenter Locations
ページや
Geography and Regions
ページをチェックしてください。
- Posted by Lorne Kligerman, Product Manager
映画『ザ・ウォーク』の裏側をご紹介
2015年10月16日金曜日
* この投稿は、米国時間 10 月 12 日、Atomic Fiction の共同創設者で、Visual Effects Supervisor の Kevin Baillie によって投稿されたもの（
投稿はこちら
）の抄訳です。
今日のゲスト投稿は、ビジュアル エフェクト会社の
Atomic Fiction
（カリフォルニア州オークランド）の共同創設者で、Visual Effects Supervisor の Kevin Baillie 氏です。
映画やテレビのために「想像しうるかぎりの最も真に迫った虚構を作り出すこと」を目標として、私たちは 5 年前にビジュアル エフェクト会社の
Atomic Fiction
を設立しました。
当時、エフェクト業界は暗黒時代に突入しており、経営破綻や廃業が相次いでいましたが、私たちには希望の光が見えていたのです。映像には未だかつてないほど多くの視覚効果が使われていましたし、エンターテインメント業界で古くから伝えられてきた技術モデルは明らかに移り変わろうとしていました。
映画には写真レベルのリアルなイメージが使われますが、私たちはその作成に必要なデータ処理のために、巨大な“レンダー ファーム”を構築するのではなく、ビジネス モデルの中心にクラウドを据えることにしました。しかし、この業界で長く経験を積んでいる人々の多くは、口々にこう言いました。「そりゃうまくいかないよ、止めた方がいい」
それでも、ちょっとした工夫と向こう見ずの馬力で、私たちのチームはハードルを 1 つずつクリアしていきました。私たちは、クラウドのツールを全面的に使用して、『トランスフォーマー』や『フライト』、『スタートレック』、『コスモス』、『ゲーム・オブ・スローンズ』といった A 級作品のデータ処理を手がけた、最初にして唯一のビジュアル エフェクト会社に成長しましたが、私たちにとって最大のチャレンジはその後にやってきました。
『バック・トゥ・ザ・フューチャー』や『ロジャー・ラビット』、『フォレスト・ガンプ』の監督である Robert Zemeckis 氏は、私たちが取り組んでいたクラウド ベースのワークフローのメリットに魅力を感じて、Denzel Washington 主演の『フライト』に出てくる
象徴的な飛行機のクラッシュ シーン
を Atomic Fiction に任せてくれました。その『フライト』が成功を収めた直後の 2013 年、彼が私たちに声をかけてきたのです。
「『ザ・ウォーク』の仕事をやってもらえないか。予算はとんでもなく少ないんだけど、ツインタワーを再現してもらわなければならないし、それはこれ以上ないくらいにリアルでなくては困る。それから、1974 年のニューヨークを一から作ってもらわないといけないんだ。映画にして 30 分くらいの分量がある」
これを聞いた私たちは心躍りました。クラウドの未来を信じてよかったと思いながら私たちは答えました。「もちろんやります」
『ザ・ウォーク』の仕事の技術的な要求がいかに厳しいものかを理解していただくためには、レンダリング処理について説明すべきでしょう。シーンを作り始めた時点では、アーティストはシーンを表す“ワイヤーフレーム”を相手にします。ワイヤーフレームは軽いもので、こんな感じです。
このように割と簡単なものなので、シーンはすぐに操作できます。ですから、アーティストのチームは、Maya や Katana といったプログラムを使ってカメラをどのように動かすか、サーフェスにどのようなテクスチャを入れるか、光をどのように当てるかといったことに関する“レシピ”を作ることができます。レシピを作ったら、実際にそのとおりにしてみなければなりません。光を当てたときに数百万のサーフェスがそれをどのように受け止め、反射するかを計算するプロセスがレンダリングです。最終的なシーンは、次のようになります。
1 つのフレームを作る 1 つのイテレーションは『ザ・ウォーク』の 1/24 秒分ですが、入力が 83GB あり、レンダリングには 16 コアのインスタンスで 7 時間かかります。まったく同時に映画の中の同じように込み入った他の部分を 1,000 のインスタンスでレンダリングするところを想像してみてください。映画の 1 秒分を作るためには 5,000 プロセッサ時間が必要です。デッドラインのことを考えると、オンデマンドで 15,000 コアまで使えるようにする必要がありました。そうでないと間に合わないのです。また、プロジェクトが終わるまで利益がどうなるかはわからなかったので、会社を存続させるためにコストもできる限り下げておく必要がありました。
必要とされる規模と経済性を両立させるためには、クラウドをフルに活用しなければならないことはわかっていました。しかし、既存のクラウド レンダリング ソリューションの中で私たちが必要とする規模に対応できるものは存在しなかったので、独自のソフトウェアを Google Cloud Platform の上で開発することにしました。効率が良く、リソースの可用性が高く、課金が分ごとという Google Cloud Platform が、私たちが Conductor と呼ぶソフトウェアのバックエンドになりました。弊社のアーティストたちは、 Conductor を使用してクラウド レンダリングのワークフローを最初から最後まで管理しました。
Atomic Fiction は無事に『ザ・ウォーク』の仕事を終わらせました。Deadline Hollywood が「今年見た中で一番」と評価し、USA Today が「見事」と称賛するエフェクト シーケンスを作り上げることに成功したのです。
『ザ・ウォーク』の製作に関する統計上の数字は、これまでの映画製作の中でもクラウド コンピューティングを最大限活用したことを表しています。Conductor の最終的なスコア カードをご覧ください。
『ザ・ウォーク』のレンダリングには合計で 910 万コア時間が使われています。
映画製作は極端な追い込み型の作業であり、『ザ・ウォーク』も例外ではありません。最後の月だけでレンダリングに 200 万コア時間を使っています。
同時に 15,000 コア以上という規模のピークは、大量の I/O を伴うレンダリングを行っているときに記録されています。
平均でアーティストの生産性は 20% 向上しました。
従来のインフラストラクチャと比較して、50% を超えるコスト削減に成功しています。
Atomic Fiction は Conductor を自由に使えたため、Zemeckis 監督はクライマックス シーンを 4 分長くすることができました。
『ザ・ウォーク』のために使った Conductor の月別プロセッサ時間のグラフを見ると、プロジェクト全体の中でプロセッサのニーズがいかに大きく変動したかがわかります。
Robert Zemeckis 監督は、映画の最後のカットを完成させてから、私たちに電話で、「今までに作った中で最も見事なエフェクトを使った映画になったと思う。他の方法で映画を作ることなど考えられない」と言ってくれました。他のどんな監督よりもビジュアル エフェクトのアートを発展させてきた人物の言葉を聞いて、私たちはとても栄誉なことだと思いました。
次の動画で私たちの仕事の一部を見てください。これを実現するために Google Cloud Platform が力を発揮したのです。
ぜひ
www.atomicfiction.com
にアクセスして、私たちの仕事をご覧ください。また、
www.renderconductor.com
では、『ザ・ウォーク』のように Conductor を使ってレンダリングする方法を知ることができます。さらに、
Google の Media Solutions サイト
でも、他の企業が自身のメディア ワークフローのために Google Cloud Platform をいかに活用しているかが紹介されています。
-Posted by Kevin Baillie, co-founder and visual effects supervisor,
Atomic Fiction
CoreOS、VMware、Google の担当幹部が語るコンテナの現状
2015年10月15日木曜日
* この投稿は、米国時間 10 月 9 日、Global Lead, Product Marketing の Cornelius Willis によって投稿されたもの（
投稿はこちら
）の抄訳です。
Google のエンジニアが
cgroups
（コンテナを実現する Linux カーネルの機能）に取り組み始めて以来、Google はコンテナ技術のイノベーションをリードしてきました。
オープンソースのコンテナ オーケストレーション エンジンである Kubernetes の開発を主導してきただけでなく、Gmail から Maps、YouTube まで Google のすべてのサービスがコンテナで動作しています。
Google は毎週 20 億以上のコンテナを起動して動的かつ柔軟にサービスを提供しており、そうすることでインフラストラクチャのリソースの使用率と効率性を高めています。コンテナは、ウェブスケールのサービスを提供する企業で以前から実運用されていましたが、広く注目され、すべての開発者にとって使いやすくなってきたのはごく最近です。
こうしてコンテナの導入が広まりつつある中、次のような質問をよく耳にします。「コンテナはなぜ重要なのか」「どのくらい安全なのか」「どのように使えばよいのか」
私は、今年 10 月の Google Cloud Platform Newsletter のために、これらのテーマについてコンテナ ソフトウェア業界の幹部と議論を交わしました。その顔ぶれは、CoreOS の CEO である
Alex Polvi
氏、VMware でクラウド ネイティブ アプリケーション担当 VP 兼 CTO を務める
Kit Colbert
氏、Google の Google Cloud Platform 担当 Product Manager である
Craig McLuckie
氏です。以下の動画に議論の模様が収録されています。
Google Cloud Platform Newsletter を次回からメールで受け取りたい方は、
ここ
から申し込んでください。
私たちの議論の要点をいくつか以下に紹介します。
なぜ誰もがコンテナ技術に関心を持っているのでしょうか？
Craig McLuckie
氏 : アプリケーションの分離とデプロイに関する非常に困難な問題をコンテナ技術が解決したからです。今後を展望すると、どのような企業でも、以前は巨大インターネット企業の専売特許だった技術を使いこなせることが必要になります。
コンテナに関して私たちが払拭しなければならない俗説は何ですか？
Alex Polvi
氏 : 「コンテナは本質的に安全性が低い」という俗説です。コンテナを使用する前は、人々は単に 1 台のマシンでさまざまなアプリケーションを動かしていただけです。それらのうちのいずれかが攻撃者に何らかの方法で侵害されたら、サーバー上の残りの部分全体も被害に遭うおそれがあります。少なくとも、コンテナを使用すれば、各アプリケーション同士の境界に壁を作ることになります。
コンテナを定着させるためには、業界ではどのようなことが必要になりますか？
Kit Colbert
氏 : 現在、私たちが接しているお客様のほとんどは先進的な企業です。今後は、敷居の低い手軽なソリューションを増やしていくべきでしょう。IT 部門にとっては、きちんと機能するものが購入してすぐに使えるようになるわけです。
議論で取り上げられたトピック：
Open Container Initiative（OCI）
Cloud Native Computing Foundation（CNCF）
App Container（appc）
の仕様
コンテナ ランタイム :
docker
、
rkt
Kubernetes
: Google が立ち上げたプロジェクトで開発されているオープンソースのコンテナ クラスタ オーケストレーション エンジン
-Posted by Cornelius Willis, Global Lead, Product Marketing
Vitess と Kubernetes でクラウド ネイティブな MySQL シャーディング
2015年10月13日火曜日
* この投稿は、米国時間 10 月 6 日、YouTube の Software Engineer である Anthony Yeh によって投稿されたもの（
投稿はこちら
）の抄訳です。
Kubernetes
などの
クラウド ネイティブ
なテクノロジーは、小さな論理ユニットの山からスケーラブルなサービスを組み立てるのに役立ちます。
前回の投稿
では、MySQL をスケーラブルな Kubernetes アプリケーションに変身させる手段として
Vitess
（YouTube のメイン データベースを動かすオープンソース プロジェクト）を紹介しました。
私たちの目標は、ステートレス アプリケーション サーバーのスケーリングと同じくらい簡単に、Kubernetes 管理下の永続データストアをスケーリングすることでした。
ポッド
を追加で起動するためにコマンドを 1 つ実行するだけです。その後、私たちは大きく前進し（2,500 回以上新しいコミットをプッシュしています）、新しいクラウド ネイティブな Vitess の安定バージョンにあと少しでたどり着くところまで来ています。
Vitess 2.0
私たちは安定リリースに向けた準備の一環として、
Vitess v2.0.0
のアルファ ビルドを公開しています。以下は、前回の投稿以降の新機能の一部です。
Kubernetes 1.0 API 最終版を使用
Java、Python、PHP、Go による正式な
Vitess クライアント ライブラリ
Java と Go のクライアントは HTTP/2 ベースの新
gRPC
フレームワークを使用
MariaDB 10.0 に加え、MySQL 5.6 の上でも動作
AngularJS で作られた新しい管理ダッシュボード
Google Cloud Storage
などのブロッブ ストアに接続するために設計された組み込みの backup/restore
可逆的で定形的なフェイルオーバーのための GTID ベースの
リペアレンティング
従来よりも単純な
スキーマ変更
また、
ドキュメント
の整備にも力を注ぎました。特に、本稿では新しいウォークスルーの 1 つを掘り下げていこうと思っています。それは、ライブ データベースの透過的な
リシャーディング
です。つまり、コードを変更せず、アプリケーションに影響を及ぼすほどのダウンタイムを起こさずにシャードの数を変更することです。
Vitess シャーディング
S. Alex Smith 氏が書いているように、
シャーディングはより良い薬
です。確かに、アプリケーションのロジックはややこしくなり、データベース管理のワークロードは数倍になります。しかし、クラウド環境で MySQL を実行するときには、1 つのノードだけではあまり大きくできないので、シャーディングは特に重要です。シャードのルーティングは Vitess が面倒を見てくれるため、アプリケーションのデータ アクセス レイヤをシンプルな状態に保つことができます。また、Vitess がシャードごとの管理作業を自動化してくれるので、小さなチームで大艦隊を管理できます。
Vitess に合ったシャーディング戦略は、私たちが
レンジ ベース シャード
と呼んでいるものです。シャードは、ハッシュ テーブルのバケットのようなものと考えることができます。レコードをどのバケットに入れるかは、キーだけで決まります。ですから、個々のキーがどのバケットに入っているかを管理する表を別途作る必要はありません。
バケット数を変えやすくするため、私たちは
コンシステント ハッシュ
を使っています。つまり、各キーをバケット番号にマッピングするハッシュ関数ではなく、各キーを非常に大きな集合（たとえば、すべての 8 バイト シーケンスの集合）のランダムに分散した（しかし一様な）値にマッピングする関数を使うのです。そして、これらの値の範囲（私たちが
キースペース ID
と呼んでいるもの）に対して 1 つずつバケットを割り当てます。
透過的なリシャーディング
新しい
リシャーディングの試運転
を実行するためには、
シャーディングなしのガイド
の説明に従って、まずクラスタを立ち上げる必要があります。両ガイドは同じ
サンプル アプリケーション
を使っています。それは、複数の番号付きページをサポートするゲストブックです。
サンプル アプリケーションのコード
には、与えられた数字をすべての 8 バイト シーケンスの集合に変換し、コンシステント ハッシュで必要なマッピングを実現する get_keyspace_id() 関数が含まれています。シャーディングされていない場合、これらの値は格納されますが使われません。シャーディングを導入すると、ページ番号は作成したすべてのシャードに均一（平均で）に分散され、ページ数に合わせてスケーリングできるようになります。
リシャーディングを行う前は、Vitess ダッシュボードには “0” という名前の
カスタム シャード
だけが表示されます。シャーディングされていない
キースペース
は以下のような表示になります。
リシャーディングの試運転
を始めると、同じキースペースに 2 つの新しいシャードが追加されます。リシャーディング中、新しいシャードは元のシャードと並んで実行されますが、マイグレートの準備が整うまでアイドル状態のままになります（Vitess は新しいシャードにトラフィックをルーティングしません）。ダッシュボードには 3 つのシャードが表示されますが、アクティブなのはシャード “0” だけです。
次に、元のシャードから
スキーマとデータをコピーする
ために、いくつかの Vitess コマンドを実行します。ライブ マイグレーションの眼目は、最初のスナップショット コピーが終わると、Vitess が自動的に新しいアップデートを元のシャードから新しいシャードにレプリケートし始めるところにあります。私たちはこれをフ
ィルタード レプリケーション
と呼んでいますが、それは DML が適用されるシャードだけに送っているからです。Vitess には、
データの完全性を確かめる
ためにオリジナルとコピーの両データ セットを行ごとに比較するツールもあります。
コピーの確認が終わり、フィルタード レプリケーションがリアルタイム アップデートに追いついたら、アプリケーションのトラフィックを元のシャードから新しいシャードにアトミックにシフトするよう Vitess に指示する
マイグレート コマンド
を実行できます。切り替えは、元のマスターに対する書き込みを止め、新マスターがフィルタード レプリケーションの最後のイベントを受け取るのを待ち、新マスターに対する書き込みを有効にするという手順で行われます。このプロセスは自動化されているので、一般に書き込み不能な時間は約 1 秒程度に収まります。
これで、
古いシャードを解体できます
。ダッシュボードには新しいシャードだけが表示されるはずです。
アプリケーションにシャード数の切り替えを知らせていないことに注意してください。Vitess がマイグレーションの進行と共に自動的にその場でクエリをリルートしているので、リシャーディング プロセスはアプリケーションからは完全に透過的になっています。
YouTube では、Vitess を使って昨年だけでほぼすべての MySQL データベースをリシャーディング（
水平にも垂直にも
）しており、サイトの拡大と共にもっと多くのリシャーディングが見込まれます。なお、
試運転で使われている命令
はフルに試せるようになっています。
スケーリング ベンチマーク
シャーディングは、シャードの追加によって書き込みスループットを線形にスケーリングするというものです。これは、個々のシャードが実際には別々のデータベースだから実現できることです。アプリケーションに対しては単純で統一的な視界を提供しながら、この分離を実現するうえで難しいのは、ボトルネックを作らないことです。クラウドでのスケーリングのデモに向けて、私たちは Vitess クライアントと
Yahoo! Cloud Serving Benchmark
（YCSB）用ドライバを統合しました。
下に示すグラフは暫定的なものですが、
Google Container Engine
上で実行されている Vitess にシャードを追加したときの書き込みスループットのスケーリングを示しています。このベンチマークでは、YCSB に Vitess クラスタの
ロード バランサ
を与え、クラスタに大量の INSERT 文を送るように指示しています。さまざまなシャードに対する文のルーティングは Vitess が行っています。
与えられた数のシャードの最大スループット（QPS）は、書き込みのラウンドトリップ レイテンシが下がり始める点で計測したもので、私たちはしきい値を平均で 15m 秒以上、クエリ全体の最悪の 1%（99 パーセンタイル）で 50m 秒以上としています。
レプリカの追加によって Vitess の読み出しトラフィックのスケーリングがどうなるかを示すために、“ほとんどが読み出し”（95% が読み出しで 5% が書き込み）というワークロードでも YCSB を実行しています。この場合、最大スループットは読み出しのラウンドトリップ レイテンシが下がり始める点で計測したもので、私たちはしきい値を平均で 5m 秒以上、クエリ全体の最悪の 1% で 20m 秒以上としています。
ベンチマークの数値を上げるためにできることは、まだたくさんあります（たとえば MySQL 自体のパフォーマンスのチューニングなど）。しかし、規模が拡大してもパフォーマンスが落ちないことは、この暫定的な結果からも明らかでしょう。そして、水平にスケーリングしているので、1 台のマシンの大きさからは制限を受けません。
まとめ
クラウド ネイティブ バージョンの Vitess は安定リリースに向けて着実に進んでいます。実際に
試していただき
、最終リリースに組み込んでほしい機能をぜひお知らせください。
ディスカッション フォーラム
に投稿するか、
GitHub
でイシューを立てていただければ私たちに届きます。Vitess のアップデートについて通知を希望される場合は、頻度の低い方の
アナウンス リスト
に登録してください。
- Posted By Anthony Yeh, Software Engineer, YouTube
Google Cloud Security Scanner の一般提供を開始
2015年10月9日金曜日
* この投稿は、米国時間 10 月 7 日、 Product Manager の Matthew O’Connor によって投稿されたもの（
投稿はこちら
）の抄訳です。
Google は Cloud Security Scanner の一般提供を開始します。
どんなに慎重な開発者でも絶対にミスを犯さないとは限りません。セキュリティに関係するミスは悲惨な事態を招くこともあります。
Google の目標の 1 つは、これまでよりも簡単にセキュアなウェブ アプリケーションを開発し、開発ライフサイクルの早い段階で問題を解決できるようにすることです。
先日発表された Cloud Security Scanner を活用することで、App Engine の開発者はウェブ アプリケーションの数ある一般的なセキュリティ上の弱点について、アプリケーションをプロアクティブにテストできるようになります。
たとえば、Cross-Site Scripting（XSS）、Mixed Content、Flash インジェクションなどの問題を検出できるほか、安全でない Javascript ライブラリを使用する際はアラートで通知することが可能です。
セットアップが簡単で使いやすい Cloud Security Scanner は、App Engine で構築、提供される最新かつ複雑な Javascript 中心のアプリケーションに適しています。
Cloud Security Scanner はGoogle Cloud Platform のお客様に無料で提供されます。
こちら
からぜひ利用を開始してください。
数か月にわたる β 版のテストでは、製品チームに素晴らしいフィードバックをお寄せいただきありがとうございました。皆様のサポートに心から感謝いたします。
- Posted by: Matthew O’Connor, Product Manager
Cloud Spin プロジェクト ： 第 3 部 - Google Cloud Platform を利用した動画処理
2015年10月9日金曜日
* この投稿は、米国時間 10 月 2 日、Google Cloud Platform の Francesc Campoy Flores によって投稿されたもの（
投稿はこちら
）の抄訳です。
本シリーズの
第 1 部
と
第 2 部
では、
Google Cloud Platform のグローバル イベント Next
のために制作されたインタラクティブ デモ “Cloud Spin” について紹介しました。そしてこのデモのために、Android スマートフォン 19 台による動画の同時撮影をオーケストレートするモバイル アプリケーションをどのように構築したかを説明しました。
第 1 部 - Google Cloud Platform で作る 180 度回転アニメーション
第 2 部 - 動画撮影をオーケストレートするモバイル アプリを構築
本シリーズの最終回となる第 3 部では、各スマートフォンから動画を取り込んで、その動画からオーディオ キューに対応するフレームを特定し、それらをまとめて 180 度回転アニメーション GIF を作成するまでのステップを取り上げます。
こうした Cloud Spin のバックエンド処理のために、設計上どのような決定を行ったか、バックエンド処理をどのように実現したかを説明します。
下図はバックエンド設計の概要を示しています。
各スマートフォンで動作するモバイル アプリが、撮影した動画を
Google Cloud Storage
のバケットにアップロードします。
Google Compute Engine
インスタンスで動作する抽出プロセスが、オーディオ キューに対応する単一フレームを特定し、抽出します。
App Engine の Managed VM
で動作する合成プロセスが個々のフレームをつなぎ合わせ、被写体のポーズの周辺をカメラが半円状に高速移動して撮影したような動画を作成し、対応するアニメーション GIF を生成します。
Cloud Spin のバックエンド サービスをどのように構築したか
バックエンド サービスが行う処理を設計した後、それらのサービスを構築する過程でいくつかの課題を解決しなければなりませんでした。以下を行う方法を見つける必要があったのです。
大量の動画、フレーム、GIF データを保存する
各動画からオーディオ キューに対応するフレームを抽出する
これらのフレームを合成してアニメーション GIF を作成する
動画処理を高速化する
動画、フレーム、GIF データを保存
取り込まれた素材動画、抽出されたフレーム、最終的に作成されたアニメーション GIF の保存に最適な場所は
Google Cloud Storage
だと判断しました。使いやすく、モバイル デバイスと緊密に統合されており、強い一貫性を提供するのに加え、デモが人気を集めたら大量のトラフィックを処理できるように自動的にスケールするからです。
また、私たちは Cloud Storage のバケットを
Object Change Notifications
で構成し、Recording（動画撮影）アプリによってスマートフォンから新しい動画がアップロードされるとバックエンド動画処理が開始されるようにしました。
オーディオ キューに対応するフレームを抽出
オーディオ キュー（ビープ音）に対応するフレームを特定するのは厄介です。音声と動画は異なる品質、異なるサンプリング レートで記録されるので、両者を対応づけるには工夫が必要です。Cloud Spin プロジェクトでは、音声セクションのノイズが最大のフレームを特定する必要がありました。そのため、音声フレームをフレーム インターバル単位でグループ化し、各グループ（複数のフレーム インターバルから成る）が 1 つの動画フレームにほぼ対応するようにしました。
さらに、各グループに含まれる音声サンプルの振幅の 2 乗の平均値を計算することで、各グループの平均ノイズを算出しました。こうして平均ノイズが最大のグループを特定し、対応する動画フレームを PNG ファイルとして抽出しました。
抽出プロセスは Python で作成し、
MoviePy
（
FFmpeg
フレームワークを使用する動画編集モジュール）を利用して、動画のエンコードとデコードを処理しました。
フレームを合成してアニメーション GIF を作成
一連の動画フレームからアニメーション GIF を生成するプロセスは、4 つの FFmpeg コマンドだけで実行できます。これらのコマンドは Bash スクリプトで実行します。まず、すべてのフレームを順番につなぎ合わせて動画を生成し、カラー パレットを抽出して、Twitter にアップロードできる低解像度の GIF を生成します。
動画処理を高速化
動画を 1 台のマシンで 1 つずつ処理すると、私たちが目指していたよりも長い時間がかかってしまい、Next のデモ参加者に自分のアニメーション GIF の出来上がりを待たせてしまうことになります。
Cloud Spin では 1 回のデモにつき 19 本の動画を撮影します。半円状に配置された 19 台のスマートフォンがそれぞれ撮影する仕組みです。各動画から同期されたフレームを抽出するのに 5 秒、フレームを合成するのに 10 秒かかるとすると、順次処理を行う場合、動画を撮影してからアニメーション GIF が生成されるまでに 2 分近くもかかることになります（19 × 5 秒 ＋ 10 秒 ＝ 105 秒）。
このプロセスは、フレーム抽出を並列化することで高速化できます。19 台の仮想マシンでそれぞれ各動画を処理すれば、動画撮影からアニメーション GIF 生成までの時間は 15 秒で済みます。これを実現するためには、設計を変更して複数マシンの同期を取らなければなりませんでした。
ワークロードを並列化
フレームの抽出および合成プロセスは、独立したアプリケーションとして開発しました。そうすることで、フレーム抽出が並列化しやすくなりました。
Google Compute Engine
上で抽出アプリケーションを 19 個の
Docker
コンテナで、合成アプリケーションを 1 個の Docker コンテナで実行できるようになっています。
とはいえ、各動画が 1 つの抽出アプリケーションだけで処理されるようにするには、どうすればよいでしょうか。この問題を効率の良いスケーラブルな方法で解決してくれるメッセージングシステムが
Google Cloud Pub/Sub
です。
Cloud Pub/Sub では、サブスクライバとの疎結合を実現する通信チャンネルを作成できます。これは、抽出アプリケーションと合成アプリケーションが Cloud Pub/Sub を介して、双方の基盤実装についての前提なしでやり取りすることを意味します。これによって、将来のインフラの進化が実装しやすくなります。
上図は、抽出および合成アプリケーションの処理キューとして機能する 2 つの Cloud Pub/Sub トピックを示しています。各モバイル アプリが新しい動画をアップロードすると、Cloud Pub/Sub は、videos（動画）というトピックに関するメッセージをパブリッシュします。抽出アプリケーションは videos トピックをサブスクライブしています。
新しいメッセージがパブリッシュされると、それを最初に取得した抽出アプリケーションがそのメッセージをリースし、動画からオーディオ キューに対応するフレームを抽出する処理を行います。処理が成功すると、抽出アプリケーションは videos メッセージの受信を Cloud Pub/Sub に知らせます。
これを受けて Cloud Pub/Sub は、frames（フレーム）というトピックに関する新しいメッセージをパブリッシュします。フレームの抽出処理が失敗した場合は、videos メッセージのリースが期限切れになり、Cloud Pub/Sub はそのメッセージを再びパブリッシュします。ほかの抽出アプリケーションがこのメッセージをリースし、動画処理を行います。
frames トピックに関するメッセージがパブリッシュされると、合成アプリケーションがそれを取得し、1 回のセッションで抽出されるフレームがすべてそろい、つなぎ合わせてアニメーション GIF を作成できる状態になるのを待ちます。すべてのフレームがそろったことを合成アプリケーションで検知するには、セッション内のオーディオ キューに対応するすべてのフレームのリアルタイム ステータスをチェックする方法が必要です。
Firebase でフレームのステータスを管理
本シリーズの第 2 部では、リアルタイム同期機能を提供する
Firebase
データベースを使用して、スマートフォンによる同時動画撮影のオーケストレーションをどのように管理したかを解説しました。
Firebase
は、各スマートフォンで撮影した動画からオーディオ キューに対応するフレームを抽出するプロセスを追跡する目的でも使用しました。次のスクリーンショットに示すように、セッションで抽出された各フレームにはステータス フィールドを追加しました。
Android スマートフォンで動画が撮影されると、
Firebase
はこのステータスを RECORDING に設定し、動画が Cloud Storage にアップロードされると、ステータスを UPLOADING に設定します。オーディオ キューに対応するフレームが抽出されると、ステータスは READY となります。
セッションでオーディオ キューに対応するすべてのフレームが抽出され、そのステータスが READY に設定されると、合成プロセスがそれらのフレームをつなぎ合わせてアニメーション GIF を作成し、GIF を Cloud Storage に、そのパスを Firebase に保存します。
ステータスを Firebase に保存することで、Android スマートフォンで撮影された動画の処理における各ステップと、アニメーション GIF の完成をリアルタイムに示すダッシュボードを作成することができました。
Cloud Spin のバックエンド サービスは、Google Cloud Platform のグローバル イベント Next までに開発が完了しました。開発したサービスは、動画撮影を行うモバイル アプリと共に本番でスムーズに稼働し、私たちはデモを盛況のうちに成功させることができました。
Cloud Spin アニメーションは、Twitter フィード:
@googlecloudspin
でたくさん見ることができます。Cloud Spin の完全なソース コードも公開される予定です。
GitHub の Cloudspin
リポジトリをチェックしてください。
Cloud Spin を取り上げた本シリーズは今回の第 3 部で終了です。私たちは、このデモをとても楽しんで制作しました。皆さんにとっても、楽しい発見がたくさんあったことを願っています。
私たちがこのデモで目指したのは、Google Cloud Platform の可能性を面白い形で紹介すること、そして皆さんが何か素晴らしいものをビルドするヒントになることです。
- Posted by Francesc Campoy Flores, Google Cloud Platform
12 か月間のトライアル
300 ドル相当が無料になるトライアルで、あらゆる GCP プロダクトをお試しいただけます。
Labels
.NET
.NET Core
.NET Core ランタイム
.NET Foundation
#gc_inside
#gc-inside
#GoogleCloudSummit
#GoogleNext18
#GoogleNext19
#inevitableja
Access Management
Access Transparency
Advanced Solutions Lab
AI
AI Hub
AlphaGo
Ansible
Anthos
Anvato
Apache Beam
Apache Maven
Apache Spark
API
Apigee
APIs Explore
App Engine
App Engine Flex
App Engine flexible
AppArmor
AppEngine
AppScale
AprilFool
AR
Artifactory
ASL
ASP.NET
ASP.NET Core
Attunity
AutoML Vision
AWS
Big Data
Big Data NoSQL
BigQuery
BigQuery Data Transfer Service
BigQuery GIS
Billing Alerts
Bime by Zendesk
Bitbucket
Borg
BOSH Google CPI
Bower
bq_sushi
BreezoMeter
BYOSL
Capacitor
Chromium OS
Client Libraries
Cloud API
Cloud Armor
Cloud Audit Logging
Cloud AutoML
Cloud Bigtable
Cloud Billing Catalog API
Cloud Billing reports
Cloud CDN
Cloud Client Libraries
Cloud Console
Cloud Consoleアプリ
Cloud Container Builder
Cloud Dataflow
Cloud Dataflow SDK
Cloud Datalab
Cloud Dataprep
Cloud Dataproc
Cloud Datastore
Cloud Debugger
Cloud Deployment Manager
Cloud Endpoints
Cloud Firestore
Cloud Foundry
Cloud Foundry Foundation
Cloud Functions
Cloud Healthcare API
Cloud HSM
Cloud IAM
Cloud IAP
Cloud Identity
Cloud IoT Core
Cloud Jobs API
Cloud KMS
Cloud Launcher
Cloud Load Balancing
Cloud Machine Learning
Cloud Memorystore
Cloud Memorystore for Redis
Cloud monitoring
Cloud NAT
Cloud Natural Language API
Cloud Networking
Cloud OnAir
Cloud OnBoard
cloud Pub/Sub
Cloud Resource Manager
Cloud Resource Manager API
Cloud SCC
Cloud SDK
Cloud SDK for Windows
Cloud Security Command Center
Cloud Services Platform
Cloud Source Repositories
Cloud Spanner
Cloud Speech API
Cloud Speech-to-Text
Cloud SQL
Cloud Storage
Cloud Storage FUSE
Cloud Tools for PowerShell
Cloud Tools PowerShell
Cloud TPU
Cloud Translation
Cloud Translation API
Cloud Virtual Network
Cloud Vision
Cloud VPC
CloudBerry Backup
CloudBerry Lab
CloudConnect
CloudEndure
Cloudflare
Cloudian
CloudML
Cluster Federation
Codefresh
Codelabs
Cohesity
Coldline
Colossus
Compute Engine
Compute user Accounts
Container Engine
Container Registry
Container-Optimized OS
Container-VM Image
Couchbase
Coursera
CRE
CSEK
Customer Reliability Engineering
Data Studio
Databases
Dbvisit
DDoS
Debugger
Dedicated Interconnect
deep learning
Deployment Manager
Developer Console
Developers
DevOps
Dialogflow
Disney
DLP API
Docker
Dockerfile
Drain
Dreamel
Eclipse
Eclipse Orion
Education Grants
Elasticsearch
Elastifile
Energy Sciences Network
Error Reporting
ESNet
Evernote
FASTER
Fastly
Firebase
Firebase Analytics
Firebase Authentication
Flexible Environment
Forseti Security
G Suite
Gartner
gcloud
GCP
GCP Census
GCP 移行ガイド
GCP 認定資格チャレンジ
GCPUG
GCP導入事例
gcsfuse
GEO
GitHub
GitLab
GKE
Go
Go 言語
Google App Engine
Google Apps
Google Certified Professional - Data Engineer
Google Cloud
Google Cloud Certification Program
Google Cloud Client Libraries
Google Cloud Console
Google Cloud Dataflow
Google Cloud Datalab
Google Cloud Datastore
Google Cloud Endpoints
Google Cloud Explorer
Google Cloud Identity and Access Management
Google Cloud INSIDE
Google Cloud INSIDE Digital
Google Cloud INSIDE FinTech
Google Cloud Interconnect
Google Cloud Launcher
Google Cloud Logging
Google Cloud Next '18 in Tokyo
Google Cloud Next '19 in Tokyo
Google Cloud Platform
Google Cloud Resource Manager
Google Cloud Security Scanner
Google Cloud Shell
Google Cloud SQL
Google Cloud Storage
Google Cloud Storage Nearline
Google Cloud Summit '18
Google Cloud Summit ’18
Google Cloud Tools for IntelliJ
Google Code
Google Compute Engine
Google Container Engine
Google Data Analytics
Google Data Studio
Google Date Studio
Google Deployment Manager
Google Drive
Google Earth Engine
Google Genomics
Google Kubernetes Engine
Google maps
google maps api
Google Maps APIs
Google Maps Platform
Google SafeSearch
Google Service Control
Google Sheets
Google Slides
Google Translate
Google Trust Services
Google VPC
Google マップ
Google 公認プロフェッショナル
GoogleNext18
GPU
Gradle
Grafeas
GroupBy
gRPC
HA / DR
Haskell
HEPCloud
HIPAA
Horizon
HTCondor
IaaS
IAM
IBM
IBM POWER9
icon
IERS
Improbable
INEVITABLE ja night
inevitableja
InShorts
Intel
IntelliJ
Internal Load Balancing
Internet2
IoT
Issue Tracker
Java
Jenkins
JFrog
JFrog Artifactory SaaS
Jupiter
Jupyter
Kaggle
Kayenta
Khan Academy
Knative
Komprise
kubefed
Kubeflow Pipelines
Kubernetes
KVM
Landsat
load shedding
Local SSD
Logging
Looker
Machine Learning
Magenta
Managed Instance Group
Managed Instance Group Updater
Maps API
Maps-sensei
Mapsコーナー
Maven
Maxon Cinema 4D
MightyTV
Mission Control
MongoDB
MQTT
Multiplay
MySQL
Nearline
Network Time Protocol
Networking
neural networks
Next
Node
NoSQL
NTP
NuGet パッケージ
OCP
OLDISM
Open Compute Project
OpenCAPI
OpenCAPI Consortium
OpenShift Dedicated
Orbitera
Organization
Orion
Osaka
Paas
Panda
Particle
Partner Interconnect
Percona
Pete's Dragon
Pivotal
Pivotal Cloud Foundry
PLCN
Podcast
Pokemon GO
Pokémon GO
Poseidon
Postgre
PowerPoint
PowerShell
Professional Cloud Network Engineer
Protocol Buffers
Puppet
Pythian
Python
Qwiklabs
Rails
Raspberry Pi
Red Hat
Redis
Regional Managed Instance Groups
Ruby
Rust
SAP
SAP Cloud Platform
SC16
ScaleArc
Secure LDAP
Security & Identity
Sentinel-2
Service Broker
Serving Websites
Shared VPC
SideFX Houdini
SIGOPS Hall of Fame Award
Sinatra
Site Reliability Engineering
Skaffold
SLA
Slack
SLI
SLO
Slurm
Snap
Spaceknow
SpatialOS
Spinnaker
Spring
SQL Server
SRE
SSL policies
Stack Overflow
Stackdriver
Stackdriver Agent
Stackdriver APM
Stackdriver Debugger
Stackdriver Diagnostics
Stackdriver Error Reporting
Stackdriver Logging
Stackdriver Monitoring
Stackdriver Trace
Stanford
Startups
StatefulSets
Storage & Databases
StorReduce
Streak
Sureline
Sysbench
Tableau
Talend
Tensor Flow
Tensor Processing Unit
TensorFlow
Terraform
The Carousel
TPU
Trace
Transfer Appliance
Transfer Service
Translate API
Uber
Velostrata
Veritas
Video Intelligence API
Vision API
Visual Studio
Visualization
Vitess
VM
VM Image
VPC Flow Logs
VR
VSS
Waze
Weave Cloud
Web Risk AP
Webyog
Wide and Deep
Windows Server
Windows ワークロード
Wix
Worlds Adrift
Xplenty
Yellowfin
YouTube
Zaius
Zaius P9 Server
Zipkin
ZYNC Render
アーキテクチャ図
イベント
エラーバジェット
エンティティ
オンライン教育
クラウド アーキテクト
クラウド移行
グローバル ネットワーク
ゲーム
コードラボ
コミュニティ
コンテスト
コンピューティング
サーバーレス
サービス アカウント
サポート
ジッター
ショート動画シリーズ
スタートガイド
ストレージ
セキュリティ
セミナー
ソリューション ガイド
ソリューション: メディア
データ エンジニア
データセンター
デベロッパー
パートナーシップ
ビッグデータ
ファジング
プリエンプティブル GPU
プリエンプティブル VM
フルマネージド
ヘルスケア
ホワイトペーパー
マイクロサービス
まっぷす先生
マルチクラウド
リージョン
ロード シェディング
運用管理
可用性
海底ケーブル
機械学習
金融
継続的デリバリ
月刊ニュース
資格、認定
新機能、アップデート
深層学習
深層強化学習
人気記事ランキング
内部負荷分散
認定試験
認定資格
料金
Archive
2019
8月
7月
6月
5月
4月
3月
2月
1月
2018
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2017
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2016
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2015
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2014
12月
11月
10月
9月
8月
6月
5月
4月
3月
2月
Feed
月刊ニュースレターに
登録
新着ポストをメールで受け取る
Follow @GoogleCloud_jp
