Google Cloud Platform Japan 公式ブログ: Firebase

ゲスト投稿 : Smash.gg が Firebase と GCP に移行した理由

2017年10月10日火曜日

編集部注 : Smash.gg は世界中のプレーヤーや組織に利用されている e スポーツプラットフォームです。毎月 2,000 件ほど開催され、合計で 6 万人以上が参加するオンラインイベントをサポートしています。最近では、世界最大規模の格闘ゲーム大会 “EVO 2017” をホストしました。この投稿は Google Cloud Platform（GCP）に移行した企業をシリーズでお伝えするもので、今回が第 1 回目です。GCP に関心を持った経緯、移行の理由、移行によって得られたメリットなどを Smash.gg の共同創設者に語っていただきました。今後は、特定サービスの移行に関する技術の詳細についてもお伝えしていきます。お楽しみに。PubNubFirebase

Firebase Realtime Database を使用したオンライン対戦の様子。2 人のプレーヤーがリアルタイムでゲームにチェックインし、セットアップし、レポートまで行っている。

Firebase Realtime DatabaseReactFluxFirebase Cloud MessagingGoogle Cloud Functionsモデレーターのリクエストを管理者に知らせるGoogle Cloud Pub/SubGoogle BigQueryGCP への移行Google Cloud Next '17Stackdriver TraceStackdriver LoggingGoogle Cloud DatastoreGoogle Container EngineGoogle App EngineGoogle Cloud SQLlog-based metricsエクスポート機能

トレースを JSON の形でログ出力するようにトレースレポータを作成

その後、Stackdriver のログエクスポート機能を用いて、トレースを Pub/Sub トピックに送信

最後に、Cloud Functions の Pub/Sub サブスクライバが REST API を利用してトレースをレポート

移行の結果確約利用割引Spark CapitalAccelHorizons Ventures投資募集中* この投稿は米国時間 9 月 8 日、Smash.gg の Engineering Director/Co-founder である Nathan Welch によって投稿されたもの（投稿はこちら）の抄訳です。- By Nathan Welch, Engineering Director/Co-founder, Smash.gg

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

Firebase と App Engine によるモバイルバックエンドサービスの構築

2016年7月12日火曜日

* この投稿は米国時間 6 月 30 日、Google Cloud Platform の Solutions Architect である Teppei Yagihashi によって投稿されたもの（投稿はこちら）の抄訳です。
私たちは Google I/O 2016 において、Google のいくつかのモバイル製品を 1 つに統合するという、Firebase に関する重要なリリースを発表しました。
新しい Firebase は、モバイルクライアントとバックエンドサービスを構築する際の複雑さを緩和します。また、ユーザーベースの拡大やアプリからの収益向上、アプリのイベントデータの収集と分析に役立つツールを提供します。
Firebase を使えば、スケーラブルで疎結合なシステムを容易に構築できます。たとえば、既存の Android クライアントに一切影響を及ぼすことなく、iOS もしくはウェブのクライアントを追加することが可能です。バックエンドサービスが必要な場合は、App Engine Flexible Environment が新しいバックエンドの能力を自動的に追加してくれます。
私たちは先ごろ、ステップバイステップガイドとサンプルコード（Android アプリ、App Engine ベースのバックエンドサービス）によるネイティブチャットアプリケーションの作り方を具体的に説明した新しいソリューションドキュメントを公開しました。
このソリューションドキュメント “Build a mobile app using Firebase and App Engine Flexible Environment”（Firebase と App Engine Flexible Environment を使ったモバイルアプリ構築）では、Android アプリと App Engine Flexible Environment で実行されるサーブレットとの間のやり取りの方法が示されています。

Android クライアントアプリは、Firebase Realtime Database にデータを格納することで、他のユーザーとチャットメッセージを交換します。また、サインインおよびサインアウトイベントやチャネル変更イベントなどのユーザーアクティビティログをリアルタイムで Java サーブレットにプッシュします。
前述のサンプルコードでは、サーブレットインスタンスはアクティビティログを単純にメモリにキャッシュしていますが、これは Firebase と App Engine Flexible Environment の組み合わせで可能になることの一例に過ぎません。サーブレットインスタンスは、たとえば次のような用途に使用できます。

非同期の重いバックエンド処理 : リソースを大量に消費し、クライアントデバイスではとても実行できないようなタスクは、バックエンドサービスによって非同期に処理できます。

リアルタイムな不正利用の検出 : サーブレットは短時間で複数のデバイスのユーザーイベントを検出できます。

ETL 処理 : バックエンドサービスは、高度な分析のために、ユーザーイベントログを Google BigQuery など他のデータストアに送ることができます。

詳細は、Firebase のドキュメントや、Google Cloud Platform の各種サービスを使ったモバイルソリューションの構築方法を参照してください。Firebase と App Engine に興味がある方は、無料トライアルにサインアップすることをお勧めします。
- Posted by Teppei Yagihashi, Solutions Architect, Google Cloud Platform

GCP との統合が進む Firebase

2016年6月2日木曜日

* この投稿は米国時間 5 月 18 日、Firebase Product Leads である James Tamplin と Francis Ma によって投稿されたもの（投稿はこちら）の抄訳です。Google に買収Google Cloud Platform（GCP）Google I/O 2016Google Cloud StorageGoogle BigQueryこちらの新しいサイトFirebase のブログ機能に関する要望

Firebase と Google App Engine でリアルタイムデータにバックエンドロジックを追加

2015年11月4日水曜日

* この投稿は、米国時間 10 月 27 日、 Firebase の Benjamin Wulfe によって投稿されたもの（投稿はこちら）の抄訳です。App Engine

Use Firebase and Google App Engine in an Android App（Androidアプリで Firebase と Google App Engine を利用）

Firebase：モバイルアプリ構築用プラットフォームで、リアルタイムのデータストレージ＆同期、ユーザー認証などを提供。

Android Studio：IntelliJ IDEAベースのAndroid開発環境

Cloud Tools for Android Studio：Android Studioに含まれるツール一式。Google Cloud Platformサービスとの統合が可能。

Google App Engine：クラウドでアプリケーションコードを実行するための環境、Platform as a service (PaaS)

- Posted by Benjamin Wulfe, Firebase

8月19日(水) ハンズオンセミナー: Google Cloud Workshop: はじめてみよう Firebase

2015年8月17日月曜日

Google Cloud PlatformFirebasehttp://eventdots.jp/event/567833

クラウドにおけるモバイルファースト開発

2015年6月4日木曜日

* この投稿は、米国時間 5 月 29 日、Product Marketing Manager の Andy Tzou によって投稿されたものの抄訳です。ユーザーがモバイルファースト、そしてモバイルオンリーへと移っていくようになり、Google では、モバイル特有の課題に対するソリューションを用意することを目指してきました。例えば、デベロッパーがアプリのフロントエンドユーザーエクスペリエンスに専念できるフルマネージドサービスや、デベロッパーがプロジェクトに必要なだけ管理できるプラットフォームと IaaS (infrastructure-as-a-service) などです。

モバイルの世界 Firebase は、モバイルの世界において、これまでのプログラミングモデルの限界への画期的な一歩です。RESTful なモデルは、特にウェブにおいては大きな役割を果たしてきましたが、モバイルにおいてはどうでしょう。例えば、地下鉄へ入る時、飛行機モードにする時、接続エリアが制限された場所では、ネットワークの接続が断続的になったり、ネット環境自体が存在しないことさえあります。こんな環境でシームレスなサービスを作ることは難しいのに、ユーザーはオフラインでも動くアプリを求めるようになっています。 シームレスなオフライン機能 先日の Google I/O で Firebase は、iOS と Android でのオフラインをネイティブサポートすると公表しました。Firebaseは、デベロッパーに代わってデータを維持し、ネットワークが利用できない場合には自動的にデータをデバイスにローカル保存します。接続が回復すると、自動的にアプリケーションデータをクラウドに同期します。RESTful なモデルでは、デベロッパー自身がシームレスなオフライン環境を作ろうと努めなければならず、さらには、モバイル、デスクトップ、Android、iOS と、多種多様なクライアントにアプリケーションデータを常に同期させることを期待され、デベロッパーにとって複雑さは勢いを増すばかりです。Firebase は、接続状態に関係なく、デベロッパーに代わって、デバイス全体にわたるデータ同期を管理します。 リアルタイム オフラインに加え、ユーザーはアプリには素早く、迅速な応答を期待します。自分が乗る予定の車が徐々に近づいていることを地図上で確認したり、SNS への投稿が瞬時に表示されたり、Google ドキュメントでリアルタイムに共同編集したりです。リアルタイムであることは、ユーザーエクスペリエンスにおいて重要になってきました。 Screen Shot 2015-05-12 at 7.56.08 PM.png

Screen Shot 2015-05-12 at 7.56.08 PM.png

Firebase は、モバイルアプリケーションに対するリアルタイム同期アプローチの先駆けです。アプリケーションデータは、デベロッパーの労力を必要とせずに、クラウドおよびクライアントデバイス全体とリアルタイムで同期されます。 インフラストラクチャとコンピューティング さらに、Google Cloud Platform では、既存のバックエンドの管理または移行を検討するモバイルデベロッパーのために、Google App Engine や Managed VM、Google Compute Engine といったモバイルアプリ構築のためのさまざまなオプションを提供しています。長期的なジョブのホスト、分析の実行、またはカスタムビジネスロジックの記述のために最適です。
RovioFeedlyCitrix Firebase や Google Cloud Platform を使って、次世代の素晴らしいモバイルエクスペリエンス構築を! -Posted by Andy Tzou, Product Marketing Manager, Google Cloud Platform

Google Cloud Platform Live：Container Engine、Cloud Networking、その他の発表について

2014年11月5日水曜日

livestream シンプルで柔軟なコンピュート環境の選択肢Google Container EngineKubernetes と Google Compute Engine による Docker コンテナ運用サービスGoogle Container EngineApp Engine における Managed VMPaaSの進化Managed VM Google Cloud Interconnect：グローバルなアーキテクチャをサポートするより良いネットワーク接続

Direct Peeering　-　33 カ国 70 箇所以上の POP (Point of Presence) に高速な回線を直接接続することができます。

Carrier Interconnect　-　Equinix, IX Reach, Level 3, TATA Communications, Telx, Verizon, Zayo など、Google のキャリアパートナーを経由して Google に接続することができます。

来月、VPN を利用した接続方式を提供する予定です。

ネットワーク Google Firebase：リアルタイムのモバイル／Web アプリケーション開発を簡単に Google Cloud Debugger Google Compute Engine Autoscaler Cloud Platform のフリートライアルについてこちらフリートライアルこちら成長するパートナー・エコシステムTableauRed HatDataStaxMongoDBSaltStackFastlyBitnamiLaunchpadCloud Accelerator 急速に増加する顧客企業数Atomic Fiction 新たな価格削減Google Compute engine 価格 10％削減

Google Cloud Platform Japan Blog

ゲスト投稿 : Smash.gg が Firebase と GCP に移行した理由

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

Firebase と App Engine によるモバイルバックエンドサービスの構築

GCP との統合が進む Firebase

Firebase と Google App Engine でリアルタイムデータにバックエンドロジックを追加

8月19日(水) ハンズオンセミナー: Google Cloud Workshop: はじめてみよう Firebase

クラウドにおけるモバイルファースト開発

Google Cloud Platform Live：Container Engine、Cloud Networking、その他の発表について

12 か月間のトライアル

Labels

Archive

Feed

Company-wide

製品・サービス

デベロッパー