モバイルアプリのバックエンド サービス

ここでは、Google Cloud を使ってモバイル バックエンド サービスを構築、接続、テスト、モニタリングする方法をご紹介します。各設計パターンの説明の後には、コードサンプルとサンプルアプリのリンクを掲載しています。

ほとんどのモバイルアプリやモバイルゲームは、複数のユーザーからのデータの共有や処理、巨大なファイルの保存といったデバイスだけでは実行できない操作を行うために、バックエンド サービスを必要とします。ゲーム特有のバックエンド サービスの詳細については、クラウドゲーム インフラストラクチャの概要をご覧ください。

設計パターンの選択

モバイルアプリ用バックエンド サービスの作成手順は、ウェブベースのサービスの作成手順と同様ですが、以下を考慮する必要があります。

  • デバイスのデータ ストレージの制限
  • 複数のデバイス間のデータの同期
  • オフライン時の適切な処理
  • 通知とメッセージの送信
  • 電池の消費の最小化

以下の設計パターンは、Google Cloud を使用して上記の要件に対応するバックエンド サービスを作成するさまざまな方法を示しています。詳細については、各パターンを選択して、その説明をご覧ください。

Firebase 設計パターン App Engine 設計パターンでの Firebase App Engine フレキシブル環境設計パターンでの Firebase Endpoints 設計パターンでの App Engine スタンダード環境 Compute Engine 設計パターン

最初の 3 パターンでは、Firebase を使用します。これは、モバイルアプリと Firebase の両方が直接データを操作する、2 層アーキテクチャになっています。2 層アーキテクチャは、セキュリティ関連やデータ検証の処理に重要な違いがあります。

最後の 2 パターンに見られるような従来の 3 層モデルでは、モバイルアプリとバックエンド サービスの間に通信レイヤがあります。一般的には、このレイヤに認証およびデータ検証用のコードを記述します。

Firebase では、認証と検証を宣言型ルールとして Firebase ウェブ UI で指定します。コードを記述する必要はありません。詳細については、Firebase のドキュメントの Firebase Authentication をご覧ください。

また、これらの設計パターンには、フルマネージド プラットフォームである Firebase をベースにしたものから、完全な非マネージド プラットフォームである Compute Engine をベースにしたものまで、さまざまな段階があります。マネージド プラットフォームでは、アップグレードや自動スケーリングといったタスクは Google が行いますが、構成の自由度はいくらか制限されます。非マネージド プラットフォームでは、サーバーの構成を完全に制御できますが、管理タスクをご自分で行う必要があります。

次の表に、各設計パターンの違いを示します。

機能 Firebase Firebase と App Engine スタンダード環境 Firebase と App Engine フレキシブル環境 App Engine スタンダード環境と Cloud Endpoints Compute Engine と REST/gRPC
自動容量スケーリング ○ ○ ○ ○ オートスケーラーを構成する場合
自動リアルタイム データ同期 ○ ○ ○

自動サーバー保守 ○ ○ ○ ○

バックエンド ロジック

○ ○ ○ ○
ネイティブ バイナリの呼び出し、ファイル システムへの書き込み、その他のシステムコールの作成

○

○
データ ストレージ ○ ○ ○ 他の Google Cloud サービスを追加する場合 他の Google Cloud サービスを追加する場合
ファイル ストレージ ○
○
○
○
Cloud Storage を使用する場合
○
Cloud Storage を使用する場合
ユーザー認証の簡素化 ○ ○ ○ OAuth 2.0

モバイル バックエンド サービスの言語サポート なし App Engine ドキュメントを参照 Endpoints Frameworks ドキュメントを参照 任意
プッシュ通知などのメッセージと通知 ○
○
○
   
プラットフォーム サポート iOS、Android、ウェブ iOS、Android、ウェブ iOS、Android、ウェブ iOS、Android、ウェブ iOS、Android、ウェブ
サンドボックス内でコードを実行する必要性

なし

○

○

SSL の必要性

○

○

Firebase

Firebase は、iOS、Android、ウェブのアプリを作成するためのフルマネージド プラットフォームであり、自動データ同期、認証サービス、メッセージング、ファイル ストレージ、分析といった機能を提供します。モバイル バックエンド サービスの作成やプロトタイピングは、Firebase で始めるのが効率的です。

Firebase

推奨される用途:

  • Firebase Realtime Database に JSON データを保存し、ファイルを Firebase Storage に保存して、デバイス上のデータ ストレージの使用を限定する場合。
  • Firebase Cloud Messaging を使用して通知を送信する場合。
  • 複数のデバイス間のデータをリアルタイムで自動同期する場合。
  • オフライン時の処理を適切に行う場合。
  • 複数の ID プロバイダを利用してユーザーを認証する場合。
  • バックエンド サービスを迅速に開発する必要がある場合。

推奨されない用途:

  • バックエンド サービスを使用して同期データを変更する必要があるアプリ。

Firebase の利用の開始

Firebase の利用を開始する手順については、以下をご覧ください。

Firebase のコード例

以下は、Firebase を使用するサンプルアプリです。

Firebase と App Engine スタンダード環境

App Engine スタンダード環境は、ホスティング環境のモニタリング、更新、スケーリングを行うアプリ プラットフォームです。必要な作業は、モバイル バックエンド サービスのコードの作成のみです。

ユーザーデータの処理またはイベントのオーケストレーションがアプリ側で必要な場合は、App Engine スタンダード環境を利用して Firebase を拡張すれば、リアルタイムの自動データ同期が利用できます。

Firebase と App Engine

推奨される用途:

  • バックエンド サービスを使用して同期データを変更する必要がある Firebase アプリ。
  • Firebase データの処理や解析を定期的に実行するバックエンド サービス。

推奨されない用途:

  • ネイティブ バイナリの呼び出し、ファイル システムへの書き込み、他のシステムコールの作成を行うバックエンド サービス。
  • Firebase と永続的に接続する場合。App Engine スタンダード環境では、2 分後にソケット接続が再要求されます。

Firebase と App Engine フレキシブル環境

App Engine スタンダード環境と同様に、App Engine フレキシブル環境も、ホスティング環境のモニタリング、更新、スケーリングを行うアプリ プラットフォームです。必要な作業は、モバイル バックエンド サービスのコードの作成のみです。

スタンダード環境との違いは、フレキシブル環境では、利用者が構成できる Docker コンテナ内でバックエンド サービスが実行されることです。つまり、ネイティブ バイナリの呼び出し、ファイル システムへの書き込み、他のシステム呼び出しの作成を自分で行うことができます。

アプリ側でユーザーデータの処理やイベントのオーケストレーションを行う必要がある場合は、App Engine フレキシブル環境を利用して Firebase を拡張すれば、リアルタイムの自動データ同期が利用できます。App Engine のサンドボックス内で独自のコードを実行する必要はありません。

Firebase と App Engine フレキシブル環境

推奨される用途:

  • Firebase アプリでバックエンド サービスを使用して同期データを変更する必要があり、そのバックエンド サービスで、App Engine スタンダード環境が対応しないカスタム サーバー構成またはサードパーティ ライブラリの使用が必要な場合。
  • データ変更の通知を受信するために、バックエンド サービスが Firebase と永続的に接続する必要がある場合。フレキシブル環境では、接続を 24 時間オープンしたままにできます。

Firebase と App Engine フレキシブル環境でモバイルアプリを作成する

このチュートリアルでは、Firebase を使用して、バックエンド データ ストレージ、リアルタイム同期、ユーザー イベント ロギングの機能を備えたモバイルアプリを開発する方法を紹介します。App Engine フレキシブル環境で動作する Java サーブレットが、Firebase に保存された新しいユーザーログをリッスンして処理します。

App Engine と Endpoints

App Engine スタンダード環境用の Endpoints Frameworks は、App Engine アプリ用の API、クライアント ライブラリ、ディスカバリ ドキュメントを生成します。Endpoints を使用すると、App Engine との通信を処理するためにラッパーを作成する必要がなくなります。Endpoints によって生成されたクライアント ライブラリを使用して、モバイルアプリから直接 API 呼び出しを行えます。

App Engine で Endpoints を使用することにより、ホスティング環境のモニタリング、更新、スケーリングを行うアプリ プラットフォームを利用できます。

App Engine と Endpoints

推奨される用途:

  • バックエンド サービスを直接呼び出すためにアプリが使用するクライアント ライブラリを自動生成する場合。
  • ファイルを Cloud Storage に移動して、デバイス上の必要ストレージを削減する場合。

推奨されない用途:

  • デバイス間でリアルタイムの自動データ同期が必要なアプリ。
  • カスタム サーバーまたはサードパーティ ライブラリが必要なバックエンド サービス。
  • SSL をサポートしていないシステム(Endpoints で SSL が必要とされるため)。

Hello Endpoints

以下の入門チュートリアルでは、単純なメッセージを送信する Hello Endpoints というサンプルアプリを作成する方法を説明します。バックエンド サービスは App Engine に実装され、Endpoints でモバイルアプリに公開されます。

Tic Tac Toe

App Engine で実行されているバックエンド サービスを呼び出して単純なゲームを作成する方法を示すサンプルアプリです。Tic Tac Toe バックエンド サービスは Java で実装されます。

Compute Engine と REST または gRPC

Compute Engine を使用すると、Google インフラストラクチャ上で仮想マシンを作成して実行できます。サーバーの管理者権限を持っていれば、サーバーのすべての構成を完全に制御できます。これは、管理者が更新やメンテナンスを行う責任を負うことを意味します。

Compute Engine と REST

Compute Engine インスタンスとの接続には、主に REST と gRPC という 2 つのプロトコルが使用されます。REST のほうが広く使用されていますが、gRPC のほうが新しく、より効率的な通信が可能で、電池の消費の抑制とセキュリティ強化の面で利点があります。REST と gRPC の詳細については、カスタム バックエンド サービスへのアプリの接続をご覧ください。

推奨される用途:

  • オンプレミス サーバーまたは仮想マシンで動作する既存のバックエンド サービスを移植する場合。
  • カスタム サーバーまたはサードパーティ ライブラリが必要なバックエンド サービス。

推奨されない用途:

  • デバイス間でリアルタイムの自動データ同期が必要なアプリ。
  • 自動メンテナンス。サーバーはユーザーがメンテナンスおよび更新する必要があります。
  • 自動スケーリング。オートスケーラーはユーザーが手動で構成、管理する必要があります。

モバイルアプリでの Compute Engine と REST の使用

以下は、Compute Engine でホストされるバックエンド サービスとモバイルアプリとのエンドツーエンド接続に REST を使用するサンプルです。サンプルアプリの Stickynotes は、サービスにテキストを送信し、生成されたイメージをレスポンスとして返します。

Stickynotes のサンプルには、REST 版と gRPC 版の両方が用意されているので、2 つのプロトコルを比較できます。

モバイルアプリでの Compute Engine と gRPC の使用

以下は、Compute Engine でホストされるバックエンド サービスとモバイルアプリとのエンドツーエンド接続に gRPC とプロトコル バッファを使用するサンプルです。サンプルアプリの Stickynotes は、サービスにテキストを送信し、生成されたイメージをレスポンスとして返します。

Stickynotes のサンプルには、REST 版と gRPC 版の両方が用意されているので、2 つのプロトコルを比較できます。

モバイル バックエンド サービスの作成

Google では、Google Cloud サービスと統合されるバックエンド サービスの作成に使用できるさまざまなツールとサービスを提供しています。

Android Studio

Android Studio は、Android アプリ開発用の公式 IDE です。IntelliJ IDEA をベースにして、lint ツール、Gradle ベースのビルドシステム、コード テンプレートといった追加機能を提供します。

また、Android Studio には、Google Cloud サービスと Firebase をアプリに統合する機能が組み込まれています。詳細は、Tools for Android Studio をご覧ください。

iOS 向け Google API

Google では、CocoaPods を使用して iOS 専用の API と SDK をいくつか配布しています。CocoaPods は Swift および Objective-C Cocoa プロジェクト用のオープンソースの依存関係マネージャーで、Xcode を操作する場合に、新しい SDK をインストールまたは更新するために使用できます。

Cloud SDK

Cloud SDK には、Google Cloud でリソースを作成および管理するために使用できるツールとライブラリが含まれています。

Cloud Source Repositories

Cloud Source Repositories は、Google Cloud でホストされる多機能の Git リポジトリです。

Google Cloud Console で作成した各プロジェクトには、関連付けられた Cloud Source Repositories があります。このリポジトリは、App Engine や Compute Engine で動作するものを含め、あらゆるアプリやサービスの共同開発で使用できます。

Cloud デバッガを使用している場合、Cloud Console で Cloud Source Repositories と関連ツールを使用すれば、アプリの実行時にコードとデバッグ情報の両方を表示できます。

Cloud Debugger

Debugger を使用すると、アプリの停止や遅延を招くことなく、任意のコード位置で Java アプリの状態を調べることができます。アプリの本番環境インスタンスとステージング インスタンスの両方で Debugger を使用できます。

Debugger は次のアプリに対して使用できます。

モバイル バックエンド サービスへのアプリの接続

バックエンド サービスを作成したら、モバイルアプリのインスタンスとの通信を確立する必要があります。

Firebase へのアプリの接続

バックエンド サービスが Firebase を使用する場合は、以下の手順でモバイルアプリを Firebase に接続します。

  • Firebase アカウントを作成します。
  • Firebase からアプリの URL を取得します。
  • クライアント ライブラリをアプリにインポートします。クライアント ライブラリは iOS、Android、ウェブアプリ、REST で利用できます。
  • アプリの URL を参照して、アプリからライブラリを呼び出します。

上記の作業の詳細については、Firebase ドキュメントのスタートガイドをご覧ください。

カスタム バックエンド サービスへのアプリの接続

モバイルアプリからバックエンド サービスを呼び出す際には、複数のプロトコルが使用できます。Google Cloud で一般的に使用されるプロトコルは REST、Endpoints、gRPC です。

REST

REST はネットワーク アプリ向けのアーキテクチャであり、データの送信、読み取り、削除に HTTP リクエストを使用します。Compute Engine、App Engine スタンダード環境、App Engine フレキシブル環境のインスタンスに REST API を作成できます。アプリは REST API を呼び出して、作成したバックエンド サービスにアクセスします。

一般的に、Google Cloud では RESTful サービスの作成に次のツールを使用します。

バックエンド サービスで REST を使用する方法については、Compute Engine と REST または gRPC のコード例をご覧ください。

REST は Firebase との通信にも使用できます。詳細については、Firebase ドキュメントの Firebase Database REST API をご覧ください。

Endpoints

Endpoints は、App Engine アプリ用の API とクライアント ライブラリを生成します。Endpoints を使用すると、App Engine との通信を処理するためにラッパーを作成する必要がなくなります。Endpoints によって生成されたクライアント ライブラリを使用して、モバイルアプリから直接 API 呼び出しを行えます。

Endpoints は SSL を必要とし、App Engine で動作するアプリでのみ機能します。

バックエンド サービスで Endpoints を使用する方法を示すサンプルコードについては、App Engine と Endpoints をご覧ください。

gRPC

gRPC は、バックエンド サービスのメソッドを直接呼び出すためのフレームワークです。モバイルアプリはこれを使用して、ローカル オブジェクトと同様にメソッドを呼び出すことができます。

gRPC は、双方向ストリーミング、フロー制御、ヘッダー圧縮、単一 TCP 接続を介する複数リクエストの機能を備えた HTTP/2 標準を使用します。モバイルアプリは、gRPC の使用により通信帯域をより効率的に使用することができ、Google Cloud で動作するバックエンド サービスとアプリ間の通信で発生するレイテンシが削減できます。

gRPC のクライアントとサーバーは、gRPC がサポートする言語で作成できます。たとえば、gRPC のサーバーを Java で作成し、同時にクライアントを Go、Python、または Ruby で作成することも可能です。

バックエンド サービスで gRPC の使用法を示すサンプルコードについては、Compute Engine と REST または gRPC をご覧ください。

アプリへの通知の送信

多くのモバイルアプリで、通知は重要な機能です。通知の機能により、ユーザーがデバイスでアプリを開いていなくても、ユーザーとやり取りできます。

Firebase Cloud Messaging

Firebase Cloud Messaging(FCM)は、アプリを実行するクライアント デバイスにメッセージと通知を確実に配信するために使用できる、クロスプラットフォームのメッセージング ソリューションです。

FCM を使用すると、以下のことができます。

  • クライアント アプリにメッセージを配信する対象を、単一のデバイス、デバイス グループ、または特定トピックの配信登録をしている 3 つのデバイスのいずれかに設定できます。
  • 2 KB までの通知と 4 KB までのデータ ペイロードを配信。また、それらの両方を含むメッセージを送信。
  • 信頼性が高く電池の効率がよい FCM の接続チャネルを介して、デバイスからサーバーに確認応答、チャット、その他のメッセージを返信。

FCM を使用して通知の送信を開始するには、以下をご覧ください。

Firebase Notifications

Firebase Cloud Messaging と FCM SDK をベースに構築された Firebase Notifications では、グラフィカル コンソールを使用して、アプリを実行しているクライアント デバイスにメッセージを送信できます。

モバイル バックエンド サービスのテスト

モバイルアプリの作成時における課題の 1 つに、考えられるすべてのデバイス構成でのテストをいかに行うかということがあります。Google Cloud には、物理デバイスと仮想デバイスの両方でモバイルアプリをテストするツールが用意されています。また、バックエンド サービスのセキュリティとパフォーマンスをテストするツールもあります。

モバイルアプリをテスト用のバックエンド サービスで動作するように構成することで、本番環境を隔離し、テストで生じる副次的な影響を受けないようにすることもできます。詳細については、Firebase ドキュメントの異なる環境をサポートするをご覧ください。

Cloud Test Lab

Cloud Test Lab には、Android アプリをテストするためのクラウドベースのインフラストラクチャが用意されています。1 回のオペレーションで、さまざまなデバイスと構成でアプリをテストできます。ログ、動画、スクリーンショットを含むテスト結果を Cloud Console のプロジェクト内で確認できます。アプリのテスト用コードを記述しなくても、Cloud Test Lab が自動的にアプリを解析し、問題が発生した場所を特定します。

Cloud Test Lab では 2 種類のデバイスをサポートします。それぞれに特徴があり、使用に適した開発フェーズが異なります。さまざまなモデルが両デバイスで使用できます。

  • 仮想デバイスは、特定の Android デバイスに対する高精度の仮想シミュレーションです。これらのデバイスはスケジュール設定が非常に柔軟に行えるため、日常的に行う開発や継続的なテストに最適です。

  • 物理デバイスは Android の実デバイスであり、Google データセンターでインストールおよび実行されます。仮想デバイスでのアプリのテストでは発生しない問題を検出できる可能性があるため、物理デバイスでのテストはプレリリース版のテストに最適です。

Web Security Scanner

Web Security Scanner は、App Engine ウェブアプリに潜むセキュリティ脆弱性を特定するツールです。アプリをクロールして、開始 URL のスコープ内にあるすべてのリンクをたどり、できる限り多くのユーザー入力とイベント ハンドラの処理を試みます。

Web Security Scanner は、現時点では App Engine スタンダード環境インスタンスのみをサポートしています。App Engine フレキシブル環境、Compute Engine、その他の Google Cloud リソースではまだ有効になっていません。

Cloud Trace

Cloud Trace は、App Engine アプリからレイテンシ データを収集し、ほぼリアルタイムで Cloud Console に表示します。

Trace を使用すると、ユーザーまたは他のアプリからの受信リクエストをアプリが処理するのにかかる時間や、リクエストの処理時に実行されるオペレーション(特に RPC 呼び出し)が完了するのにかかる時間を知ることができます。

現在 Trace では、App Engine URI へのリクエストに関するエンドツーエンドのレイテンシ データと、Datastore、URL 取得、Memcache などの App Engine サービスへのラウンドトリップ RPC 呼び出しに関する追加データが収集されます。

モバイル バックエンド サービスのモニタリング

バックエンド サービスを起動したら、サービスが意図したとおりに機能することを確認するためにモニタリングを開始する必要があります。

スタンダード環境とフレキシブル環境の App Engine では、正常性モニタリングが自動的に実行され、必要に応じて新しいインスタンスが起動されます。また、Compute Engine 用に自動スケーリングを構成して、応答しないインスタンスを差し換えることもできます。

Google Cloud にも、ログを収集して分析するツールとモニタリング ダッシュボードが用意されており、指定した制限を超えてアプリが実行された場合にアラートを送信するように構成できます。

Cloud Logging

Cloud Logging は、Google Cloud 上のアプリとサービスからログを収集して保存します。Logs List にはアクセス可能なログが表示されます。ログの収集後、以下の操作が行えます。

Cloud Monitoring

Monitoring には、Google Cloud アプリ向けのダッシュボードとアラートが用意されています。

Monitoring は Cloud Console を使用して構成します。Cloud Monitoring API を使用して、モニタリング データを取得し、カスタム指標を作成できます。

Monitoring では、Google Cloud サービス、仮想マシン、一般的なオープンソース サーバー(MongoDB、Apache、Nginx、Elasticsearch など)のパフォーマンス指標を確認できます。

次のステップ