Google Cloud Platform Japan 公式ブログ

アジアで Google へのアクセスがより速く : FASTER - 台湾間の新海底ケーブルが開通

2016年9月14日水曜日

* この投稿は米国時間 9 月 6 日、Google の Network Resource APAC Regional Lead である Yan Tang によって投稿されたもの（投稿はこちら）の抄訳です。
最近、電子メールの送信が少し速くなったと思いませんか？お気に入りの YouTube ビデオも速くロードされるようになっていないでしょうか？また、BigQuery のクエリ結果が返されるのも普段より速くなった感じがしませんか？
もしそうなら、それは私たちがアジアで新しい高速海底ケーブルを開通させたからかもしれません。
Google など 6 社が参加する FASTER Consortium は今年 6 月、光海底ケーブルシステム FASTER の運用を開始しました。現時点で世界で最も高速なこの光ファイバケーブルは、米国と日本を結んでいます。私たちはこの超高速接続をもう少し延長しようと考えました。
そこで、この太平洋横断回線の恩恵をアジアの他地域に広げるために、私たちは日本の FASTER と台湾を結ぶケーブルに投資しました。台湾には Google にとってアジア最大のデータセンターがあり、アジア全域の数百万人のユーザーに Google のツールやサービスへの高速アクセスを提供しています。この新しいケーブルの伝送速度は最大 26 Tbps（テラビット / 秒）となっています。
26 Tbps がどれくらい速いかは、下の図をご覧ください。

台湾と日本の FASTER を結ぶ 26 Tbps の海底ケーブルは、台湾に住むすべての人が 15 秒ごとにセルフィー（自撮り画像）を日本の友人に送り続けることを可能にします。その総数は 1 日で 1,380 億枚に上ります。

すぐにはお気づきにならないかもしれませんが、この新しいケーブルは、アジア全体で Google のプロダクトやサービスの速度向上に役立つはずです。また、これによってエクスペリエンスの信頼性と一貫性も高まるでしょう。このケーブルは戦略的に、自然災害に伴うネットワーク停止を防ぐために津波の多い地域を避けて敷設されているからです。
アジアでは、世界のどの地域よりも多くの人がインターネットを日々利用しています。私たちはこのことを踏まえ、この地域に住む私たちすべてにとってインターネットが役に立つために必要なインフラストラクチャへの投資に力を入れてきました。私たちがアジアに 2 つのデータセンターを建設し、このうちシンガポールの施設を拡張したのはそのためです。
また、私たちがこうした海底ケーブルへの投資を進めているのも、それが理由です。そしてこのことは、すべての人のコンピューティング速度をもう少し向上させ、世界の人と人をもう少し近づけることにつながっているのです。
- Posted by Yan Tang, Network Resource APAC Regional Lead, Google

GCP でスケーラブルなウェブプロトタイプを構築する

2016年9月14日水曜日

* この投稿は米国時間 8 月 31 日、Google Web Engineer である Jason Mayes によって投稿されたもの（投稿はこちら）の抄訳です。
Google のウェブエンジニアとして、私は過去 5 年間、社内チームやお客様向けのスケールドシステムを開発してきました。システムの中には、ウェブのフロントやバックエンドのコンポーネントが含まれていることもよくあります。
この投稿では、Google Cloud Platform（GCP）を使って開発したカスタムメイドの機械学習システムの話をしたいと思います。このブログを読んで、自分でも何かクールなウェブアプリを構築したいと思ってもらえれば幸いです。
この話は、私がコンピュータのビジョンに関心を持ったところから始まります。私は長年、この分野に興味を持っていました。読者の皆さんの中には、望みどおりの結果を得るために最もシンプルなソリューションを探そうと努力していた私の個人的な実験に関する公開ポストを目にした方がいらっしゃるかもしれません。
私はシンプルであることが大好きなのですが、自分の手がけるプロジェクトが年を追うごとに複雑になるにつれ、特にその気持ちが大きくなりました。仲のいい友人が昔、私に「シンプルであることは複雑な芸術だ」と言ったのですが、この業界に 10 年在籍して本当にそのとおりだと感じています。

コンピュータビジョンに関する私の初期の実験において、動きを分離させようとしているところ

私のウェブエンジニア兼コンピュータサイエンティストとしての経歴は、2004 年に当時人気だった LAMP などを手がけたことから始まりました。その後 2011 年に Google に入社し、Google Cloud スタックに出会いました。つまり Google App Engine のことです。私は、スケーリングとディストリビューションを扱うシステムによって時間が大きく節約できることを知り、以来 App Engine に夢中になっています。
しかし、2011 年から時は流れ、最近私は TensorFlow を使ってウェブベースの機械学習システムを開発するプロジェクトに関わりました。ここで、私が開発に使った Google Cloud の新技術を一部紹介しましょう。

課題 : 長期間稼働しているタスクと短時間でクリティカルなタスクの両方に対し、ジョブの実行を保証するには？

TensorFlow を使って Google Compute Engine によるカスタムオブジェクトを認識しているところ

今年の初め頃、私は Google が開発したマシンインテリジェンス向けのオープンソースソフトウェアである TensorFlow の使い方を学んでいました（試す価値のあるものですよ）。
Google Compute Engine 上で TensorFlow を動かす方法がわかると、私は TensorFlow が単体ではスケールできないものであることにすぐに気づきました。負荷分散するために、いくつかのコンポーネントをそれぞれのサーバーに分割しなくてはならなかったのです。

初期デザインと課題

私のアプリケーションでディープニューラルネットワークの一部を再トレーニングするには、平均 30 分程度かかっていました。長時間かかるジョブがある可能性を考えると、ユーザーに進捗状況を知らせるために、リアルタイムのステータスアップデートを提供したいと思いました。
また、すでにトレーニングが済んだクラシファイヤーを使って画像分析をする必要もありました。これにかかる時間は、1 つのジョブにつき 100 ミリ秒以下です。こうした短時間のジョブが、30 分かかるような長時間のジョブにさえぎられるようなことがあってはなりません。
最初の実装は次のようになりました。

この段階で、次のような問題が発生しました。

Google Compute Engine サーバー上でさまざまなタイプのジョブを処理したため、非常に大きな負荷がかかってしまった。

Compute Engine のオートスケーリングプールを需要に合わせて 10 インスタンスまで作ることができたものの、時間のかかるトレーニングタスクが 10 個リクエストされると、分類やファイルのアップロードといったタスクのためのインスタンスが残らない。

プロジェクトの予算が限られていたため、一度に起動できるインスタンスは 10 個までだった。

データベースの選択肢このアプリケーションでは、さまざまな種類のワークロードをサポートする必要があったことに加え、永続的データが保管できなくてはなりませんでした。それができるデータベースは数多く、当然のことながら Google Cloud SQL もその 1 つです。ただ、この方法にはいくつか問題がありました。

時間がかかる : Cloud SQL を使うには、SQL データベースと統合できるようにすべての DB コードを自分で書き直さなくてはなりません。また、稼働するプロトタイプをできるだけ早く提供する必要がありました。

セキュリティ : Cloud SQL の統合には、Google Compute Engine のインスタンスがコアデータベースに直接アクセスする必要がありましたが、私はコアデータベースを見せたくありませんでした。

さまざまな種類のジョブ : 今は 2016 年ですから、きっとこんな問題を解決する何かがあるはずで、さまざまなジョブの種類に対応できるはずですよね？

その解決策として私は、モバイルアプリケーションやウェブアプリケーションの開発に向けた Google の Backend as a Service（BaaS）である Firebase を使うことにしました。
Firebase によって既存の API を使うことができ、（私の Node.js ベースのサーバーに最適な）JSON オブジェクトを使って永続的データを保管できるようになりました。これにより、クライアントが DB の変更をリッスンできるようになり（ジョブの進捗状況を伝えるのに最適です）、私の Cloud SQL のコアデータベースと密接に統合する必要もなくなりました。

私が利用した GCP サービス

最終的に私はサーバーを 3 つのプールに分けました。それぞれのプールは特定のタスクに対して高度に特化させており、1 つは分類用、1 つはトレーニング用、そしてもう 1 つはファイルのアップロード用としました。各タスクで利用したクラウド技術は以下のとおりです。
Firebase James Tamplin および彼のチームと話して以来、私はずっと Firebase をプロジェクトに使う機会をうかがっていました。
Firebase の主な機能の 1 つに、リアルタイムデータベースを数分で作れるというものがあります。そう、リアルタイムです。しかも、JavaScript を使うだけで、更新のすべてをリッスンできるのです。Firebase を使えば、動くチャットアプリケーションが 5 分以内に作れます。
これは、リアルタイムでジョブの進捗状況を確認するのに最適です。というのも、私はフロントエンドに問題のあるジョブへの変更をリッスンさせ、GUI をリフレッシュできるためです。
また、すべてのウェブソケットや DB fun も処理されるので、私はすごく使いやすい API を使って JSON オブジェクトを渡すだけでいいのです。Firebase はオフラインにも対応しており、オンライン状態になった時点で同期されます。
Cloud Pub/Sub 同僚の Robert Kubis と Mete Atamel が、Google のマネージドリアルタイムメッセージングサービスである Google Cloud Pub/Sub を私に紹介してくれました。
Cloud Pub/Sub は、セントラルトピックにメッセージを送ることを可能にするもので、そこから Compute Engine インスタンスがサブスクリプションを作ることもできるし、セントラルトピックに対して非同期的に緩くつながった状態でプルやプッシュすることもできます。これにより、容量に空きが出ると、すべてのジョブが最終的に稼働することが保証されます。
また、これはすべて水面下で行われるため、自分でジョブをリトライする必要もありません。時間が大幅に節約できます。

Cloud Pub/Sub のパブリッシャとなるエンドポイントの数に制限はなく、どこからでもサブスクリプションが可能

App Engine 私は App Engine でフロントエンドウェブアプリケーションをホストし、配信しました。HTML や CSS、JavaScript、テーマなどの資産はすべてここに保管されており、必要に応じて自動的にスケールされます。
さらにいい点は、App Engine がマネージドプラットフォームであることです。セキュリティ機能が搭載されているほか、App Engine の API に対して自分の好みの言語（Java、Python、PHP など）でコーディングした際に自動でスケーリングする機能も搭載されています。
API は Memcache や Cloud SQL などの高度な機能にもアクセスできるようになっており、負荷が増してもスケールする方法で頭を悩ませる必要はありません。
オートスケーリング機能の付いた Compute Engine Compute Engine は、きっとほとんどのウェブ開発者になじみのあるものでしょう。これは、自分の選択した OS をインストールできるサーバーで、そのインスタンスに対して完全にルートアクセスすることが可能です。
インスタンスは完全にカスタマイズでき（仮想 CPU の数や、RAM、ストレージの容量も設定できます）、課金は分単位のため、要求に応じてスケールアップやスケールダウンする際にさらなるコスト削減が可能です。
もちろん、ルートアクセスができるということは、これらのマシンでやりたいと思っていたことがほぼ何でもできるということなので、私も TensorFlow を稼働させる環境としてこれを選びました。
また Compute Engine は、オートスケーリングのメリットも享受できます。要求に応じて、また設定した数値に応じて、利用できる Compute Engine インスタンスの数を増やしたり減らしたりすることが可能です。私のユースケースでは、CPU の平均利用率に応じてオートスケーラはいつも 2 から 10 のインスタンスとなっていました。
Cloud Storage Google Cloud Storage は、（サイズ的にも数的にも）大量のファイルを安価に保管できるサービスです。世界中のエッジサーバーロケーションにレプリケーションされており、その場所は要求しているユーザーに近いロケーションとなっています。
私が自分の機械学習システムでクラシファイヤーをトレーニングするために使ったファイルをアップロードし、必要になるまで保管していたのもここです。
Network Load Balancer 私の JavaScript アプリケーションはウェブカメラを利用していたので、安全な HTTPS 接続にてアクセスする必要がありました。Google の Network Load Balancer は、自分で定義した異なる Compute Engine クラスタにトラフィックを送ることができるものです。
私の場合、画像分類クラスタと、新しいクラシファイヤーをトレーニングするためのクラスタがあったので、何がリクエストされたかによって、そのリクエストを適切なバックエンドに HTTPS 経由ですべて安全に送ることができました。

すべてを組み合わせた結果

これらのコンポーネントをすべて組み合わせてみると、私のシステムアーキテクチャは、だいたい次のようなものになりました。

これでちゃんと動いてはいましたが、一部無駄な部分もありました。Google Compute Engine Upload Pool のコードは、単に App Engine 上で稼働するように Java で書き直せることに気づいたのです。こうすることで直接 Cloud Storage にプッシュできるため、Compute Engine インスタンスの余分なプールが必要なくなります。やった！
また、App Engine を使うことになったため、カスタムメイドの SSL ロードバランサも必要なくなりました。App Engine 単体で新しいジョブを Pub/Sub へと簡単に内部でプッシュでき、すべてのフロントエンドのアセットをそのまま appspot.com 経由で HTTPS にて送ることができるためです。
つまり、Google の appspot.com 上でデプロイした場合、最終的なアーキテクチャは次のようになるでしょう。

アーキテクチャの複雑さが軽減されるとメンテナンスも楽になり、コスト削減にもつながります。

まとめ

Pub/Sub と Firebase を使うことで、私は 1 週間以上の開発時間を削減できたと見ています。これで私は目の前の問題にすぐに取りかかり、短時間で解決できるようになりました。さらには、プロトタイプが要求に応じてスケールしていき、予算に余裕がまったくないときでもすべてのジョブを最終的に片付けられることを保証できるようになったのです。
Google Cloud Platform サービス群の組み合わせは、ウェブ開発者が完全なエンドツーエンドシステムのプロトタイプを短時間で作るうえで素晴らしいツールキットであり、セキュリティと今後のスケーラビリティに対する支援も同時に得られるものです。ぜひ皆さんも試してみることをお勧めします。
- Posted by Jason Mayes, Google Web Engineer

GCP ウェブホスティングガイドを公開

2016年9月14日水曜日

* この投稿は米国時間 9 月 6 日、Senior Lead Technical Writer である Jim Travis によって投稿されたもの（投稿はこちら）の抄訳です。

Google Cloud Platform（GCP）では、現在ウェブサイトを運営していて、ウェブサービスのインフラをクラウドに移行することを検討しているユーザー向けに、優れた選択肢を多数提供しています。

でも、これだけ多数の製品やサービスがあると、どれが自分固有のニーズに適しているかを判断するのが難しいこともあるでしょう。そうしたユーザーがウェブホスティングの選択肢の全体像を理解することを助けるため、私たち Google は先ごろ、“Serving Websites” という新しいガイドを公開しました。

このガイドでは、対象となるユーザーがすでにサイトを運用しているか、あるいは LAMP スタックの使い方や静的ページのホスティングなど、特定のテクノロジーのセットについて理解していることを前提にしています。

そして、ユーザーが有する現在のインフラや知識を GCP のコンピューティングおよびホスティング製品に対応づける形で、より詳しいドキュメント、ソリューション、チュートリアルなどを紹介しています。

このガイドでは主に、以下の 4 つの選択肢を扱っています。

選択肢	製品	概要
静的ウェブサイト	Google Cloud Storage	Cloud storage バケットから静的ウェブページやアセットを配信します。これは GCP 上で最もシンプルな選択肢であり、余分な労力なしで自動的にスケーリングを行えます。
仮想マシン	Google Compute Engine	独自のウェブホスティングスタックのインストール、設定、管理を行います。あらゆるコンポーネントを自分でコントロールできますが、すべてを稼働させ続ける責任も自分にあります。また、ロードバランシングやスケーラビリティを提供する方法を、さまざまな選択肢から選んで決める必要もあります。
コンテナ	Google Container Engine	コンテナ技術を利用してコードの依存関係をパッケージ化し、デプロイメントを容易にします。そして、Container Engine を利用してコンテナのクラスタを管理します。
マネージドプラットフォーム	Google App Engine	コードだけに集中して App Engine にデプロイし、システムの管理は Google に任せます。使用できる言語とランタイムが決まっている standard environment と、選択肢は多いが自分で管理する必要のある flexible environment から選べます。

ガイドでは、この各選択肢について、スケーラビリティ、ロードバランシング、DevOps、ロギング、モニタリングに関する情報を提供しています。

この記事が皆さんのお役に立ち、GCP を楽しく学ぶことを後押ししてくれることを願っています。みなさんの感想をお聞かせください。そして、ぜひ無料トライアルにサインアップしてください！

- Posted by Jim Travis, Senior Lead Technical Writer

API 管理スイートの Cloud Endpoints がベータリリース

2016年9月14日水曜日

* この投稿は米国時間 9 月 1 日、Google Cloud Platform の Product Manager である Dan Ciruli によって投稿されたもの（投稿はこちら）の抄訳です。
私たち Google は先ごろ、Google Cloud Endpoints の最新機能セットとオープンソースコンポーネントをベータリリースしました。Cloud Endpoints は、Google Cloud Platform（GCP）で実行される、任意の言語で書かれた API のデプロイ、保護、モニタリング、管理を行う分散 API 管理スイートです。
また、レイテンシを低減し、カスタムドメインをサポートしてデバッグの機能を強化した Java と Python 用の Cloud Endpoints Frameworks の新バージョンもリリースしました。
私たちにとって、Google のウェブ API の規模に対応しつつ、マイクロサービスのサージも処理できるパフォーマンスを備えた API プラットフォームを構築することは、大きな課題でした。
この難題を解決するため、私たちは伝統的な API 管理機能を自分で処理するサーバーサイドプロキシを開発しました。この方法ならネットワークホップを避けられます。社内テストではレイテンシがミリ秒未満になりましたが、これは従来のスタンドアロンプロキシの数十、数百ミリ秒とは大きな違いです。
そしてこのたび、このアーキテクチャを広く皆さんに公開することになりました。Extensible Service Proxy（ESP）は、サーバーローカルアーキテクチャで実行されるように設計された NGINXf ベースのプロキシです。コンテナ化された環境あるいは単独でデプロイされるように設計され、Google Service Control との統合により、極端に低いレイテンシでのモニタリング、権限チェック、API キーチェックなど、Google が自社 API 管理で使っている多くの機能を提供します。
加えて、私たちは OpenAPI Specification のサポートも発表しました。Google は Open API Initiative（OAI）の設立時からのメンバーで、REST API の記述方法を標準化することの意味を理解しています。
Open API Specification を採用する企業は、それぞれが選んだ言語とフレームワークを使ってアプリケーションを開発しつつ、OAI のツールセットから得られるメリットを享受できます。

Google Cloud Endpoints の機能

Cloud Endpoints のベータリリースには、モバイルアプリ、ウェブアプリ、他サービスのいずれからアクセスされるかにかかわらず、独自 API の管理に必要とされる広範な機能が含まれています。
Cloud Endpoint では、利用度、エラー、消費のグラフとともに基幹 API の状態をモニタリングできます。また、API 呼び出しのログを Google Cloud Logging に、トレース情報を Google Cloud Trace に送り、Google Big Query との統合を通じて強力なアナリティクスを実現します。
さらに、組み込みの Google 認証と、Auth0、Firebase Authentication との統合を通じてエンドユーザー認証をサポートし、API キーを作成、チェックしてクライアントごとの利用を追跡します。

Cloud Endpoints は、バックエンドとして使いたい言語とフレームワークをデベロッパーが簡単に選べるように設計されています。OpenAPI Specification（以前は Swagger と呼ばれていたもの）に基づき、Google App Engine standard / flexible environment、Google Compute Engine、Google Container Engine で実行されるバックエンドをサポートします。
たとえば App Engine standard / flexible environment では、1 行の構成変更で透過的にプロキシ機能を追加することも、Kubernetes や Container Engine 上のコンテナ化バージョンのプロキシをデプロイすることも可能です。
GCP ユーザーはすでに Cloud Endpoints で開発を大幅に強化しています。Vendasta のテクニカルリーダー、Braden Bassingthwaite 氏は、「Cloud Endpoints のおかげで、私たちは今までになくスピーディかつ着実に API を構築、リリースできています。認証やパフォーマンス、状態のモニタリングを気にせずに済むようになり、優れた API を構築するために必要な時間と労力を削減できました」と述べています。

Java、Python 用の Endpoints Frameworks

上述したように、私たちは新しい API 管理機能とともに、App Engine standard environment で実行される Java、Python のための Google Cloud Endpoints API Frameworks の新バージョンも発表しました。
新バージョンのフレームワークは、レイテンシを低減し、デベロッパーエクスペリエンスを向上させ、カスタムドメインをサポートしました。また、新しい API 管理機能をオプトインできるようになっています。
Endpoints Frameworks の詳細は、Java と Python 用のドキュメントを参照してください。

ぜひお試しを！

ベータテストの最初の一部期間は Cloud Endpoints の API 管理機能が無償で提供されます。最終的な価格体系についてはベータ期間中に発表される予定です。
API は、GCP が重点を起き、力を注いできた分野です。Endpoints チームは今後、サポートするユースケースを増やし、Identity and Access Management（IAM）との統合、レートリミットとクォータ、デベロッパーポータルなどの機能を追加した新リリースを提供する予定です。どうぞご期待ください。
Cloud Endpoints の詳細はドキュメントをご覧ください。また、App Engine standard / flexible environment、Container Engine、Compute Engine のそれぞれについてクイックスタートガイドが用意されていますので、試してみてください。そして、Google Cloud Endpoints Google Group に参加し、フィードバックを送っていただければ幸いです。
- Posted by Dan Ciruli, Product Manager, Google Cloud Platform

App Engine アプリ開発をサポートする Maven / Gradle 新プラグイン

2016年9月9日金曜日

* この投稿は米国時間 8 月 29 日、Google Cloud Platform の Product Manager である Amir Rouzrokh によって投稿されたもの（投稿はこちら）の抄訳です。

Google Cloud PlatformApache MavenGradleEclipseIntelliJIntelliJ 用ネイティブプラグインstandardflexibleGoogle Cloud SDKApp Engine standard 向け Maven プラグイン既存の App Engine standard 向け Maven プラグインApp Engine Java SDK Google Cloud SDK をインストールしたら、pom.xml または build.gradle ファイルを使ってプラグインをインストールします。

pom.xml

<groupId>com.google.cloud.tools</groupId>

<artifactId>appengine-maven-plugin</artifactId>

</plugin>

</plugins>

build.gradle

buildscript {

dependencies {

classpath "com.google.cloud.tools:appengine-gradle-plugin:+" // latest version } }

apply plugin: "com.google.cloud.tools.appengine"

アプリケーションをデプロイするには次のコマンドを実行します。

$ mvn appengine:deploy

$ gradle appengineDeploy

アプリケーションをデプロイすると、その URL がシェル出力に表示されます。

両プラグインでは、別のリリースプロセスを用意したい企業ユーザー向けに、JAR や WAR などのコンパイル済みアーティファクトの場合はクラウドにデプロイせず、ターゲットディレクトリにコピーするステージングコマンドを提供しています。つまり、これらのアーティファクトを継続的インテグレーション / 継続的デリバリ（CI/CD）パイプラインに渡せるわけです（GCP 用の CI/CD 製品についてはこちらをご覧ください）。

$ mvn appengine:stage

$ gradle appengineStage

デプロイしたアプリケーションのステータスは Google Cloud Platform Console でチェックできます。Google App Engine タブで Instances をクリックすると、アプリケーションの基盤となるインフラストラクチャが表示されます。

新プラグインの詳細は、App Engine standard（Maven、Gradle）と App Engine flexible（Maven、Gradle）のドキュメントをご覧ください。サポートを希望する機能がある場合は、GitHub の Maven、Gradle プラグインページにお送りください。

GCP 上での Java プログラミングについては、Java デベロッパーポータルをご覧ください。GCP で Java プログラムを稼働させるまでに必要なすべての情報が揃っています。また、今後続々とリリースされる GCP 対応の新プラグインにもぜひご注目ください。

それでは、充実したコーディングライフを！

- Posted by Amir Rouzrokh, Product Manager, Google Cloud Platform

Google Cloud Platform Japan Blog

アジアで Google へのアクセスがより速く : FASTER - 台湾間の新海底ケーブルが開通

GCP でスケーラブルなウェブプロトタイプを構築する

GCP ウェブホスティングガイドを公開

API 管理スイートの Cloud Endpoints がベータリリース

App Engine アプリ開発をサポートする Maven / Gradle 新プラグイン

12 か月間のトライアル

Labels

Archive

Feed

Company-wide

製品・サービス

デベロッパー

Google Cloud Platform Japan Blog

アジアで Google へのアクセスがより速く : FASTER - 台湾間の新海底ケーブルが開通

GCP でスケーラブルなウェブ プロトタイプを構築する

GCP ウェブ ホスティング ガイドを公開

API 管理スイートの Cloud Endpoints がベータ リリース

App Engine アプリ開発をサポートする Maven / Gradle 新プラグイン

12 か月間のトライアル

Labels

Archive

Feed

Company-wide

製品・サービス

デベロッパー

GCP でスケーラブルなウェブプロトタイプを構築する

GCP ウェブホスティングガイドを公開

API 管理スイートの Cloud Endpoints がベータリリース