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

この記事は、Google Cloud Platform(GCP)を使用してモバイル バックエンド サービスを構築、接続、テスト、モニタリングするためのガイダンスです。各設計パターンの説明の後には、コードサンプルとサンプルアプリのリンクを掲載しています。

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

設計パターンの選択

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

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

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

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

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

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

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

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

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

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

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

バックエンド ロジック

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

○

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

モバイル バックエンド サービスの言語サポート なし App Engine ドキュメントを参照 Endpoints Frameworks ドキュメントを参照 すべて
プッシュ通知などのメッセージと通知 ○
○
○
○
Cloud Messaging を使用
○
Cloud Messaging を使用
プラットフォーム サポート 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 に移動して、デバイス上の必要ストレージを削減する場合。
  • Cloud Messaging を呼び出して通知を送信する場合。

推奨されない用途:

  • デバイス間でリアルタイムの自動データ同期が必要なアプリ。
  • カスタム サーバーまたはサードパーティ ライブラリが必要なバックエンド サービス。
  • 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 では、GCP サービスと統合されるバックエンド サービスの作成に使用できるさまざまなツールとサービスを提供しています。

Android Studio

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

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

iOS 向け Google API

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

Cloud SDK

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

Cloud Source Repositories

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

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

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

Stackdriver Debugger

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

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

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

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

Firebase へのアプリの接続

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

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

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

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

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

REST

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

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

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

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

エンドポイント

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

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

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

gRPC

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

gRPC は、双方向ストリーミング、フロー制御、ヘッダー圧縮、単一 TCP 接続を介する複数リクエストの機能を備えた HTTP/2 標準を使用します。gRPC を使用すると、モバイルアプリの帯域幅効率を高め、GCP で実行されるバックエンド サービスとアプリの間のレイテンシを短縮できます。

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

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

アプリへの通知の送信

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

Firebase Cloud Messaging

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

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

  • 1 台のデバイス、複数デバイスのグループ、トピックに登録された複数デバイスのいずれかを選択して、クライアント アプリにメッセージを配信。
  • 2 KB までの通知と 4 KB までのデータ ペイロードを配信。また、それらの両方を含むメッセージを送信。
  • 信頼性が高く電池の効率がよい FCM の接続チャネルを介して、デバイスからサーバーに確認応答、チャット、その他のメッセージを返信。

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

Firebase Notifications

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

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

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

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

Cloud Test Lab

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

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

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

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

Cloud Security Scanner

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

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

Stackdriver Trace

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

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

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

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

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

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

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

Stackdriver Logging

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

Stackdriver Monitoring

Monitoring は、GCP アプリ用にダッシュボードとアラートを提供します。

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

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

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...