次の方法で共有

June 2016

Volume 31 Number 6

モバイル開発 - MBaaS プラットフォームを使用したモバイル開発の高速化

Paras Wadehra | June 2016

モバイル アプリ開発のコストの大半はバックエンドの統合にかかります。また、ほとんどのアプリの中核となる一連の機能は同じようなものがたくさんあります。したがって、アプリケを開発するたびに同じ機能やコンポーネントを毎回最初から作り直すのではなく、重要な機能を (ビルドしないで) 他のアプリから流用し、優れたモバイル アプリ (UX) にすることに専念できるとしたらどうでしょう。まさに、「サービスとしてのモバイル バックエンド」(MBaaS: Mobile Backend as a Service) の背後にあるのがこの考え方です。MBaaS では、このように重要でありながらよく使うアプリ機能がサービスとして提供され、利用できるようになっています。この MBaaS を使用することで、優れたエクスペリエンスをユーザーに提供する作業に専念しながら、アプリの開発期間を大幅に短縮する (コストを抑える) ことができるようになります。

MBaaS プラットフォームにより、アプリの開発で毎回無駄な作業に時間を費やす必要がなくなるだけでなく、アプリのフロントエンドとバックエンドを分けて開発する「分離型」の開発アプローチを採用できるようになります。その結果、フロントエンドとバックエンドを同時にビルドできるようになり、双方の開発完了時には「まるでスイッチを切り替える」かのように双方を接続できます。

今回は、サンプル エンタープライズ アプリの開発プロセスの主な手順を、DIY (Do It Yourself) のアプローチと MBaaS のアプローチについてそれぞれ調べた後、この 2 つを比較して各アプローチに適したシナリオの種類を考えます。今回のユース ケースの大まかな要件は以下のとおりです。

  1. ユーザーを Active Directory フェデレーション サービス (AD FS) に対して認証する必要がある。
  2. SharePoint インスタンスに接続してそのデータを表示する必要があるが、SharePoint のレコード セットをすべて表示するのではなく、データのフィルター処理が必要。
  3. オフライン時にユーザーがデータを閲覧できるようにする。
  4. オフライン時にユーザーがレコードを新規追加できるようにし、オンライン復帰時に追加したレコードをサーバーと自動同期する。
  5. 新規レコードや更新済みレコードが SharePoint に正常保存されたことを示すプッシュ通知を受信する。
  6. ユーザーが写真を撮影でき、その写真を作成中のレコードに添付してサーバーにアップロードできる。

これらの要件が提示され、モバイル アプリをビルドするように依頼されたとします。どこから手をつければよいでしょう。まずは、選択肢を見てみましょう。

1 つのオプションは、ファイル (今回は写真) をホストするサーバーと、AD FS や SharePoint のようなバックエンド サービスを稼働させることです。この場合、AD FS や SharePoint の上位にサービスをビルドして、モバイル アプリから接続して対話できるようにすることも必要です。その後、フロントエンド モバイル アプリをビルドして、このようなバックエンド サービスに接続します。

もう 1 つは、まず、フロントエンド モバイル アプリをビルドし、最初は仮のデータや認証ソースと対話するようにしてから、バックエンド サービスを稼働させて、実際のデータや認証ソースと対話するようにモバイル アプリを更新する方法です。ただし、この場合は、モバイル アプリのビルドに使用できる仮のデータや認証システム、またはサービスを作成する必要があります。

どちらの DIY オプションも、フロントエンド アプリはバックエンドと同じ言語で対話する必要があります。またバックエンドが変わると機能しなくなり、アプリの修正にコストや時間がかかる可能性があります。

対照的に、MBaaS プラットフォームを利用すれば、フロントエンドのモバイル アプリとバックエンドのサービスを別のチームが同時に作成できます。つまり、市場への投入までの時間が短縮されます。フロントエンド アプリとバックエンド サービスは、MBaaS プラットフォーム自体を使って相互に接続できます。このアプローチの数あるメリットの 1 つは、データや認証ソースを模倣する仮のサービスの作成を考える必要がないことです。

MBaaS プラットフォームでは、ネイティブ プラットフォーム向けにもハイブリッド プラットフォーム向けにも SDK が提供されます。選択したプラットフォーム向けの SDK を開発環境に統合し、この SDK に対してコーディングするだけで、バックエンド サービスを簡単に利用できるようになります。アプリから利用する最も重要な MBaaS 機能の 1 つは、バックエンド データや ID ソースとの統合機能です。MBaaS プラットフォームでは抽象層も提供されるため、バックエンドの複雑さがフロントエンド モバイル アプリから隠ぺいされます。

ここからは、これらの各オプションの特徴を詳しく見ていきます。アプリに必要な機能をそれぞれ調べてから、最初は DIY アプローチを使用した実装に注目し、その後 MBaaS アプローチを使用した実装と比較します。こうした説明の最後に、2 つのアプローチを全体的に比較します。

認証

DIY アプローチでは、まず AD FS へのコネクタをビルドしてから、このコネクタを使用してユーザーを認証します。このコネクタはモバイル アプリから利用でき、認証のためにアプリからユーザー名とパスワードを Active Directory に渡すことができる必要があります。Active Directory がユーザーを正しく認証したら、認証トークンが返されます。この認証トークンは、その後の呼び出しに使用するために、解析し、暗号化して、保存する必要があります。さらに、認証プロバイダーが更新トークンをサポートする場合は、認証トークンの有効期限が切れたときにトークンを自動更新するコードも作成する必要があります。

MBaaS では、以下のように、クライアント SDK を使用して認証呼び出しを行い、ユーザーを認証します。

MBaaS.login(redirectURI);

認証の種類に応じて、認証プロバイダーが (OAuth スタイルの) 独自のログイン画面を表示する場合も、MBaaS プロバイダーが独自バージョンのログイン画面を表示する場合もあります。すべての MBaaS プロバイダーは、AD FS に限らず、エンタープライズ ID ソースに最低でもなんらかのコード不要のコネクタを提供します。MBaaS クラウド ポータルで構成パラメーターをいくつか指定して、AD FS のインスタンスと対話するように MBaaS を構成します。指定する構成パラメーターの種類には、プロバイダーのログイン URI、ログアウト URI、証明書テキスト、リダイレクト URI と認証トークンの有効期限 (TTL) を伴う名前 ID 形式の URI などがあります。開発時には、企業の AD FS 管理者からこのような値をすべて入手できなければなりません。このような構成パラメーターを設定するだけで、AD FS インスタンスへの接続が作成されます。

認証プロセス全体を実装する複雑な部分が、この 1 行のコードに簡略化されています。認証ハンドシェイク、認証トークンの取得、認証トークンの暗号化と格納など、バックエンドの複雑な部分はすべて、MBaaS プラットフォームと対応する SDK によって処理されます。

データ アクセス

DIY によるデータのフェッチは一見簡単そうに思えますが、実際に試してみると複雑なことがわかります。データの上位に利用可能な Web サービスを既定で公開するデータ ソースも悪くはありませんが、Web ベースのアプリからデータ ソースに直接接続する方が簡単な場合もあります。ただし、一般に、モバイル プラットフォームには Web アプリとして利用できるエンタープライズ データ ソースへの同一コネクタがありません。つまり、カスタム コネクタを作成する必要があります。最も可能性があるカスタム コネクタは、データ ソースと対話し、GET、PUT、POST、DELETE のような標準 HTTP 動詞を使用してデータを公開する Web サービスです。さらに、このコネクタをホストする場所も必要です。多くの場合、作成するアプリには社外のネットワークからアクセスされることになるため、作成する Web サービスは、ファイアウォールの内側にある社内ネットワークだけでなく、社外ネットワークとも対話できなければなりません。これを実現しようとすると、ファイアウォールに抜け穴を作ることになります。カスタム コネクタを作成した後に、モバイル アプリからそのカスタム コネクタに接続して、すべてのデータ操作を適宜実行します。しかし、ユーザーのクエリに応じて特定のレコード セットのみをフェッチできるようにしなければならないとしたらどうでしょう。そのためには、Web サービスでクエリ機能をビルドする必要があります。その結果 Web サービスは複雑になります。特に、ユーザーが複雑なクエリを実行できるようにする必要がある場合はその傾向が顕著になります。

大半の MBaaS システムは、複数のエンタープライズ データ ソースに既製のコネクタを用意しています。つまり、コネクタを作成する必要はなく、構成するだけです。サンプル ユース ケースの場合、SharePoint 用のコネクタを構成するには、SharePoint のインスタンスに接続するためのホスト URL、ユーザー名、パスワードといった構成パラメーターを指定します。モバイル アプリ内で SharePoint のデータを利用する場合は、以下のコードを 1 行記述するだけです。

MBaaS.data.get(NameofDataCollection [,QueryParams] [,Options]);

これにより、通常はデータ ソースから JSON オブジェクトの配列が返されます。MBaaS プロバイダーの既製コネクタを利用するメリットの 1 つは、このようなコネクタがデータ ストアですべてのオブジェクトを見つけてくれるので、SharePoint リストをすべて見つけて、モバイル アプリからアクセスする対象を選択するだけで済みます。また、SharePoint から返されるフィールドをフィルターを使って整理して、モバイル アプリが必要とするフィールドだけを返すことができます。そのため、実際にはアプリで一部のデータしか必要としない場合に大量のデータ セットがモバイル デバイスに送信されるのを防ぐことができます。このフィルターはカスタム コードを作成しなくても適用できるため、モバイル開発者にとっては大きな価値提案です。MBaaS が提供するこのような機能セットがなければ、データのフィルター選択や整理は、モバイル アプリで行うか、サーバー側でスクリプトを作成して、ホストし、管理する必要があります。前者の場合は、デバイスでの帯域幅やバッテリーの使用が多くなり、モバイル ユーザーにとって適切なエクスペリエンスにはなりません。後者の場合は、運用中の作業やメンテナンスが必要になります。上記コード行では、メソッドへの QueryParams 入力にクエリベースのパラメーターを渡すだけで、ユーザーのニーズや入力に基づいてレコードの検索やフィルター処理が可能です。

一般に、MBaaS プラットフォームは、プラットフォーム自体に組み込みのデータ ストアとファイル ストアも提供します。独自のデータ ソースを利用しないアプリは、MBaaS 組み込みのデータ ストアを使用してデータを格納および利用できます。

オフライン データ

データをオフラインで利用できるようにするだけならば、DIY アプローチでも実に簡単です。ローカル デバイスのローカル ストレージやデータ ストア (SQLite など) にデータを格納し、ユーザーがアプリ内でデータへのアクセスを試みたら、そこからデータを読み取るだけです。

ただし、オフラインで編集した既存のデータやオフラインで追加した新しいデータをサーバーと同期し、その過程で起こるかもしれない競合を処理するのは簡単ではありません。競合を解決するコードを実装した経験がある開発者ならば、これが楽な仕事でないことはご存知でしょう。ローカルとサーバーで同時に変更されたエンティティをチェックし、両者で変更されたエンティティの属性を調べます。同じエンティティの同じ属性がクライアントとサーバーの両方で変更されていたら、どちらを優先するかを判断し、優先する変更をレコードの値として保存する必要があります。

MBaaS プロバイダーのクライアント SDK を使用すると、アプリ内でのオフライン データ利用の実現が大幅に容易になります。先ほどのデータ利用の例を使用すると、以下のように、特定のオプション値を呼び出しに渡すだけです。

MBaaS.data.get(NameofDataCollection [,QueryParams] , Data.Offline, Data.EncryptFull);

このコードは、データの暗号化と、デバイスのオフライン データ ストレージを有効にします。SDK によるオフライン利用を目的としたデータの格納方法はプロバイダーごとに異なりますが、その実装方法が MBaaS SDK との対話方法に影響することはありません。SDK が、オフラインの実装に関連する複雑な部分をすべて担当します。さらに、暗号化を有効にするのも簡単で、オプションをセットアップするだけです。暗号化は多くのエンタープライズ アプリにとって重要な要件で、オフライン データ ストアのセキュリティを確保します。MBaaS SDK は、ユーザー操作や画面表示のためにデータの暗号化を自動的に解除し、ユーザーが入力したデータをデバイスに格納する前に自動的に暗号化します。通常、オフライン編集や新しいデータの追加も SDK が処理します。ただし、これを想定どおり機能させるには、バックエンド システムではレコードごとに LastUpdatedTime を実装しなければなりません。同様に、競合を解決するオプションをセットアップして、クライアント側とサーバー側の両方でレコードが更新された場合に、どちらを優先するかを決定します。

プッシュ通知

DIY プロジェクトでのプッシュ通知のセットアップは難しくなる可能性があります。図 1 に示すように、プッシュ通知チャネルを正しくセットアップしてプッシュ通知を送信するには、複数の手順が必要です (詳細については、https://msdn.microsoft.com/ja-jp/windows/uwp/controls-and-patterns/tiles-and-notifications-windows-push-notification-services--wns--overview を参照してください)。

  1. ユニバーサル Windows プラットフォーム (UWP) アプリから OS にプッシュ通知チャネルを要求します。
  2. 新しい通知チャネルが Windows Notification Service (WNS) によって作成され、Uniform Resource Identifier (URI) 形式で呼び出し元デバイスに返されます。
  3. 通知チャネル URI が、Windows からアプリに返されます。
  4. アプリでは、URI を独自のクラウド サービス (URI の格納場所) に送信するため、通知の送信時際にこの URI にアクセスできます。
  5. 送信する通知をクラウド サービスが保持しているときは、先ほど登録した URI を使用するように WNS に指示します。これを実行するには、Secure Sockets Layer (SSL) 経由で HTTP POST 要求 (通知ペイロードなど) を発行します。
  6. WNS が要求を受け取り、通知を適切なデバイスにルーティングします。

プッシュ通知を設定し、送信するためのフロー
図 1 プッシュ通知のセットアップと送信のフロー

また、チャネル URI の期限が切れることがあり、以前のチャネル URI が依然有効であることは保証されないため、アプリが起動するたびにチャネルを要求する必要があります。返されたチャネル URI が使用していた URI と異なる場合、クラウド サービス内の URI を更新する必要があります。また、ユーザー向けにチャネル URI をデバイス ID にマップして、サーバー上の適切なチャネル URI を更新できるようにすることも必要です。

優れた MBaaS プラットフォームは、プッシュ通知のセットアップを簡単に行う方法を用意しています。UWP アプリにプッシュ通知を送信する正しい手順は先ほど示しました。図 2 をご覧ください。ここに示しているのは、MBaaS プラットフォームを使用すれば実行する必要のない手順です。

プッシュ通知複雑さはMBaaSによって考慮します
図 2 MBaaS が受け持つプッシュ通知の複雑さ

MBaaS はプッシュ通知のセットアップ、管理、ユーザーへの送信に関する複雑さをすべて隠します。このような処理はすべて、クライアント側の SDK を使用して以下のような呼び出しを 1 つ実行するだけで行われます。

MBaaS.registerForPush();

その後、MBaaS プラットフォーム内で実行するサーバー側のビジネス ロジックを作成します。たとえば、プッシュ通知を送信するタイミングの決定や、事前に定義したメソッドを呼び出して適切なユーザーにプッシュ通知を送信するなどの処理を行います。

ファイル サーバー

DIY アプローチでは、独自のファイル サーバーをホストして管理し、ユーザーがデバイスを使って撮影した写真をサーバーにアップロードして、このようなファイルのユーザー アクセス権を管理し、他のユーザーのファイルにアクセスできないようにする必要があります。また、スケーラビリティ、パフォーマンス、セキュリティ更新プログラムだけでなく、サーバーの稼働時間も管理する必要があります。

MBaaS プラットフォームでは、クラウドでファイルをホストするために、おそらく何も実装する必要はありません。MBaaS プラットフォームの特徴の 1 つは、すぐにファイル ストアにアクセスできる点です。CDN 完全対応のファイル ストアを入手して、PDF、画像、動画、Office ドキュメントなど、よく使われるファイル種類をホストします。他の機能と同様、MBaaS SDK のメソッドに対してシンプルな呼び出しを行い、クラウドに格納されているファイルを操作するだけです。ファイル API により、以下のような呼び出しを使用して、ファイル ストアとのファイルのアップロード、ダウンロード、およびストリーミングが可能になります。

MBaaS.File.upload(FileName);
MBaaS.File.download(FileName or FileID);

これは、格納されているファイルの数やサイズにもよりますが、巨大なファイル サーバーを管理する手間を省きます。たとえば、特定の時点のニーズに応じたストレージの拡大/縮小や、稼働時間とファイル アクセスの待ち時間の両方の管理といった手間を省きます。

MBaaS のその他の機能

冒頭で、サンプル アプリの機能セットを説明しましたが、ここではアプリ開発に役立つ MBaaS プラットフォームの他の機能にも目を向けます。

サーバー側のビジネス ロジックにより、クライアント デバイスの処理能力を利用することなく、サーバー側で負荷の高いデータ処理を実行できます。また、データ ソースから送信されるデータにフィルターをかけ、モバイル デバイスが必要とするデータだけを送信して帯域幅を節約できます。さらに、MBaaS プラットフォームとの間で双方向に行われる呼び出しをインターセプトすることもできます。

サーバー側のキャッシュにより、1 秒以内の UX シナリオを実現できます。従来のエンタープライズ データ ソースでは、クエリの応答に数秒かかることがよくありましたが、モバイル ユーザーはこれよりも高速の応答を期待します。アプリの読み込みに時間がかかると、そのアプリはアンインストールされ、競合他社のアプリに乗り換えてしまいます。サーバー側キャッシュ機能を使えば、エンタープライズ データ ソースのデータを MBaaS プラットフォーム内にキャッシュして、モバイル アプリの要求に迅速に応答できるようになります。そのキャッシュは、バックグラウンドで本来のデータ ソースから自動更新されます。

まとめ

DIY アプローチと MBaaS アプローチはどちらもアプリの開発に有効です。MBaaS プラットフォームを使用するメリットは明白ですが、DIY アプローチを使用する方が適切な場合もあります。たとえば、単発の開発プロジェクトで、データと ID ソースに接続するために必要なサービスがすべて既に用意されているような場合です。このようなシナリオでも、データや ID ソースへのサービス接続がまだ用意されておらず、複数のアプリから利用できるようにする必要がある場合は、MBaaS プラットフォームを利用すれば、バックエンド統合の最も複雑な機能も既製の機能を利用できるため、モバイル開発の速度が上がります。MBaaS プラットフォームのサポートにより、データや ID ソースの統合、暗号化、オフライン実装、競合の解決、プッシュ通知のセットアップなど、モバイル アプリの基本的かつ重要なコンポーネントを気にすることなく、アプリの UX に専念できます。

最終的には、MBaaS プラットフォームが提供するメリットは抽象化にあり、バックエンド データや ID ソースを好きなだけ変更できます。また、アプリのコードを 1 行も書き直さないで、サーバー側のビジネス ロジックを変更することもできます。MBaaS プラットフォームが提供するモバイル SDK は、この抽象化を駆使してアプリの実行をサポートし、アプリの更新、テスト (単体テスト、統合、および回帰テスト)、配置や、ストアの承認を再度受けるために待機する手間を省きます。

デメリットの 1 つは、MBaaS プラットフォームを使用することにより、コネクタの実装がユーザーに対して抽象化されるため、プラットフォームの変更が難しくなる可能性がある点です。DIY アプローチでは、すべてのコネクタのコードを開発者が所有するため、将来のニーズに合わせてカスタマイズするのは簡単です。

MBaaS では、モバイル アプリをビルドする際に、時間と労力の両面で大幅にコストを節約できます。また、関連するサービスやサーバーの運用中のメンテナンス、セキュリティ、維持の視点でもコスト削減につながります。

Paras Wadehra は、Web、デスクトップ、およびモバイルのプラットフォーム間で機能するアプリケーションの作成中に発生する問題を解決する、熟練のソフトウェア アーキテクトです。iOS、Android、Windows などの主要モバイル プラットフォームを対象に開発を行った経験があります。C#、Node.js、JavaScript、SQL、Swift など、さまざまな環境でコードを作成しています。現在、Windows 開発の Microsoft MVP です。さまざまな業界のイベントやカンファレンスで講演を行っています。Twitter での連絡先は @ParasWadehra で、LinkedIn からフォローすることもできます。

この記事のレビューに協力してくれた技術スタッフの Hermit Dave (Associated Press Limited, UK)、Kurt Monnier (Kinvey, Inc.)、および Arun Nagarajan (Uber) に心より感謝いたします。
Hermit Dave は、エンタープライズとコンシューマー分野で 15 年以上の経験がある Windows 開発者です。

Kurt Monnier は、Kinvey, Inc. でソリューションおよびカスタマー サクセスのシニア ディレクターを務めており、2007 年からエンタープライズ カスタマー向けのモバイル アプリのビルドをサポートしています。

Arun Nagarajan は、Uber でエンジニアリング マネージャーを務めています。