Google Cloud Platform Japan 公式ブログ: Google App Engine

株式会社リクルートライフスタイルの導入事例：GCP ならではのフルマネージドサービス群で膨大なデータ処理と、将来の拡張性を両立

2018年1月30日火曜日

BigQueryCloud DataflowGoogle Cloud StorageGoogle App Engine株式会社リクルートライフスタイル飲食業界に最新のデジタル経営技術を持ち込みたかった

メニューごとの注文率などの分析も BigQuery で自動集計

集客分析は Dataflow を活用しスケーラブルに実現

やりたいことと GCP が得意とすることが見事にマッチ

Airメイトシステムアーキテクチャ

こちらこちら

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

Google Cloud Platform Japan Blog

株式会社リクルートライフスタイルの導入事例：GCP ならではのフルマネージドサービス群で膨大なデータ処理と、将来の拡張性を両立

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

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

12 か月間のトライアル

Labels

Archive

Feed

Company-wide

製品・サービス

デベロッパー

Google Cloud Platform Japan Blog

株式会社リクルートライフスタイルの導入事例：GCP ならではのフルマネージドサービス群で膨大なデータ処理と、将来の拡張性を両立

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

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

12 か月間のトライアル

Labels

Archive

Feed

Company-wide

製品・サービス

デベロッパー

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

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