オフライン・データ同期

モバイル・アプリでのこの極めて重要な課題に対処するための戦略

Comments

最新のモバイル・アプリケーションが複雑化し続ける中、強力なサーバーへの接続が不可欠となっています。大容量のデータ・ストレージと高度な計算能力を備えたサーバーにオンラインで接続しなければ、コグニティブ要素、音声および画像認識、チャットボット、地図用のジオデータなどの情報を使用するのは事実上不可能です。このことから極めて重要な機能となるのが、オフライン・データ同期です。

ほとんどの人々にとって、信頼できるネットワーク・サービス・エリアはほぼ常に利用できます。多くのアプリは継続的なオンライン・アクセスに依存するため、この状況は好都合です。けれども多くの企業では、オンライン接続を限られた時間しか、あるいはまったく利用できないとしても、従業員が作業できるようにしなければなりません。例えば、緊急支援活動を考えてみてください。モバイル・ネットワークが停電やその他の災害のシナリオで停止した場合、あるいは大量の使用によってブロックされた場合でも、支援活動を行う必要があります。別の例としては、地下の建設現場や沖合のウィンド・パークといった、ネットワークにつながらないリモートの場所で作業する場合も挙げられます。このような場合、オフライン・データを処理するにはインテリジェントなデータ同期メカニズムが必要になります。こうしたビジネス環境に対応したモバイル・ソリューションを構築する上で、オフライン・データ同期は最も難しい課題となることは珍しくありません。

モバイル・ソリューションに適用できるデータ同期の手法はたくさんあります。けれども非常に重要な点は、特殊なビジネス・ニーズに適切な手法を選択することです。多くのプロジェクトでは、クライアントが理想的なソリューションを期待するものです。つまり、オフラインでもすべてのデータを常に利用できて、常にデータが最新の状態で、考えられるあらゆるアプリの機能に支障なくデータがバックグラウンドで同期されるといったソリューションです。あいにく、こうしたソリューションはテクノロジー上の制約 (同期対象のデータがあまりにも多すぎるなど) と相容れません。また、複雑なデータ同期ロジックを効率的に処理する上での計算能力の制限とも対立します。

オンライン・データ同期に有効な戦略を立てるには、具体的なビジネス要件を調査して理解し、適切な手法を選択する必要があります。あらゆる場合に通用するソリューションというものはありません。以降のセクションで、典型的なシナリオを探り、それらのシナリオに対処するのに適切な方法を提案します。

基本的な戦略

まずは、オフライン・データ同期に対処する際の基本的な戦略を見ていきましょう。基本的な戦略には以下が含まれます。

  • 大量のデータ
  • 同期のサイクルと優先順位付け
  • 差分同期: 事前処理またはオンデマンド

1 大量のデータ

アプリをオフラインで使用する際に大きな中核的問題となるのは、大量のデータが必要だということです。作業者には広大な領域のジオデータ、何千件もの作業指示書、数百個のパーツからなる複雑なアセットといったものが必要になる場合があります。この問題に対処するうえで明らかに重要な点は、データを減らすことです。データ削減については後で掘り下げますが、オフラインで使用できるようにギガバイト単位のデータを保管するという事態を避けられないことも珍しくありません。

このような事態に迫られた場合は、ユーザーが高速のデータ接続を使用する時間帯と頻度、そして作業スケジュール内のどの時間枠でデータをダウンロードするのが適切であるかを調査する必要があります。接続の状態が良ければ、それだけダウンロードの時間枠が縮小されます。

1 つのシナリオとして、作業者たちが終日オフライン状態で作業をしなければならないとします。朝、作業者たちはオフィスに集まり、作業の計画と調整を行ってから作業着に着替えます。この約 15 分間の時間枠を使用してデバイス上のデータを更新することにしました。オフィスに高速 WLAN 接続を確立し、この時間枠で最大 1 ギガバイトのデータをダウンロードできるようにします。別のシナリオとしては、ユーザーが自宅にいる間に、ユーザー専用のインターネット接続を使用して夜間にかけてデータを更新します。

大量のデータに対処するという問題を解決するためには、パフォーマンスの最適化とデータの削減を追求するだけでなく、ビジネス・プロセスと仕事場の構成も調査する必要があります。ユーザーが必要とするデータをダウンロードする時間枠を、日次あるいは週次の作業スケジュールに組み込むのに最適な方法を考えなければならないためです。さらに、主要な場所で高性能ネットワーク接続を利用可能にするか確立して、ダウンロードに必要な帯域幅を提供する必要もあります。

2 同期のサイクルと優先順位付け

必要不可欠な調査事項は、オフライン・データをどれくらいの頻度で更新するか、そしてデータの更新にどのように優先順位を付けるかという点です。理想的には、すべてのデータを常に最新の状態にしたいところですが、この理想的な状態が保証されることはめったにありません。実際には、データを複数の塊に分けて、ビジネス・ニーズに応じてそれぞれの塊に優先順位を付ける必要があります。データによっては、1 年に一度だけ更新するものもあれば、1 日に数回更新しなければならないものもあります。したがって、ビジネス・ルールに基づいて、データの塊ごとに異なる同期サイクルを定義することになります。頻繁に更新しなければならないデータ・パッケージは小さければ小さいほど好都合です。

クライアントにとって、頻繁に更新する必要がないデータがどれであるかを決めるのは難しい場合があります。そのような場合に役立つツールは、それぞれのデータの塊に対する強制的ランク付けです。事業主にランクを付けさせることで、ビジネス・ニーズとデータ同期の技術的実現可能性について議論を開始し、この 2 つの間の妥協点を見つけられる可能性が生まれます。

3 差分同期: 事前処理またはオンデマンド

次は、バックエンドに目を向けましょう。通常は、モバイル・デバイスとバックエンド・システムの間で同期するデータを準備する必要があります。これは特に、すべてのデータを同期するのではなく、デバイス上の現在のデータとサーバー上のデータの差分だけを同期する場合に言えることです。このような差分を計算するのはサーバーにとって極めて複雑なタスクであり、その処理時間は、データを交換する場合に必要な時間を大幅に上回ることもあります。さらに、多数のクライアントが個々の差分をサーバーに対して同時に要求するとなると、処理時間はますます長くなります。オンデマンドの個別の差分計算は一見したところ洗練されたソリューションのように思えますが、このような計算を実際に適用できる場合は限られるのが常です。

それよりも適切な手法は、すべてのクライアントと共有する差分をサーバーで事前処理することでしょう。例えば前日の作業による更新に基づいて、夜間にサーバーでデータの塊の差分を事前処理します。翌朝には、すべてのクライアントがこの差分ファイルのコピーをリクエストして、前日の変更をクライアントのデータに適用して更新することができます。ただしこの場合も、クライアントのビジネス・ニーズと制限事項をとことん理解していなければ、適切な事前処理戦略を定義することはできません。

事前処理とは別に考慮すべき概念には、レプリケーションも挙げられます。レプリケーションが役立つのは、バックエンド・システムのアクセスと差分の処理機能が制限されている場合です。そのような場合は、モバイル・ミドルウェア内の専用データ・ストアに差分を複製するという方法を取ることができます。こうすれば、コアのバックエンド・システムを煩わせることなく、モバイル・クライアント用にデータを準備または事前処理できます。この手法には柔軟性があり、モバイル・アプリケーションに依存することもありませんが、データ・レプリケーションから受け継がれる新しい課題が伴います。

高度な戦略

これまで、オフライン・データ同期に対処する際の基本的な戦略を紹介してきました。次は、より高度な戦略の調査に移り、オフライン・データの変更と更新や共有データの処理といったトピックを取り上げます。高度な戦略には以下が含まれます。

  • オフライン・データの変更
  • 共有データの同期
  • 自動同期または手作業による同期
  • プッシュまたはプル

1 オフライン・データの変更

モバイル・デバイスをオフラインで使用するには、デバイス上でデータを取得する必要があるだけでなく、オフラインでのデータの変更にも対処する必要があります。もちろん、オフラインでのユーザーによるデータ変更アクションが許可されていないか制限されていれば、それが最善です。ビジネス・シナリオによっては、こうした制限を設けられる場合もあります。停電などの緊急時にユーザーにとって第一に必要となるのは、停電から復旧するために必要なすべてのデータをオフラインで使用できることです。この場合、データを変更する差し迫った必要はありません。一方、アセットの保守となると状況は異なってきます。ユーザーはオフライン状態でもアセットの保守タスクを完了して文書化したいはずです。

その主要な特性から、オフライン・データを変更する目的は、通常は文書化のみであって、他の作業者との共同作業のために変更されるわけではありません。したがって、変更したデータをキャッシュに入れて、ユーザーが次回オンラインに接続したときにサーバーに再生すれば十分です。ユーザーにとってとりわけ都合が良いのは、これがバックグラウンドでシームレスに行われることですが、ユーザーもある程度、データをサーバーに再生するかどうか、再生する場合はいつにするかを制御する必要があるか、あるいはユーザーへの再生の通知が必要であるかどうかを考えてください。

2 共有データの同期

オフライン・データを変更する場合、ネットワーク接続が再び利用可能になるまで変更後のデータをキャッシュに入れる必要があります。作業指示書や担当業務などといった特定のユーザー専用のデータについては、簡単にデータの変更に対処できます。けれども真の課題は、共有データにあります。ある特定のユーザーが共有データを変更できるとしたら、他の多数のユーザーも変更できることになります。例えば、グループに割り当てられた作業指示書、ユーザーが自身に割り当てる作業指示書のプール、あるいは複数のユーザーが同じアセットを扱ってステータス情報を変更しなければならない場合を考えてください。

このようなシナリオでオフライン機能を使用できるようにすることには、数々のリスクが伴います。この問題の本質からすると、競合は避けられません。ユーザーがオフライン状態の場合、変更したデータを他のユーザーも使用できるようにするのは、どう考えても不可能です。そのため、あるユーザーが同じデータを処理していることを知らずに、別のユーザーがそのデータを同時に処理して変更する可能性があります。こうしたシナリオを避けられない場合、どうしても複数のユーザーがオフラインで共有データを処理しなければならないビジネス・ニーズがあるとしたら、例外を処理すること、そして例外の処理方法に関するビジネス・ルールを定義することに重点を置く必要があります。多くのシナリオで適用できる 1 つの手法は、データ・セットの最初の更新だけを残し、それ以降のデータに対する更新はすべて無視することです。

もう 1 つの重要な考慮事項として、基礎となる作業プロセスによって回避できる競合、あるいは対処しやすい競合を調査してください。複数のユーザーが保守タスクの作業指示書を共有する一方、ユーザーの作業場所がそれぞれに異なる場合は、作業プロセスを定義することによってデータ競合を回避します。あるいは、ユーザーがアセットを追跡する際はそのアセットをストレージから取り出すことにすれば、他のユーザーは同じアセットをストレージから取り出すことはできません。そのアセットは物理的に存在しなくなっているためです。このようにすれば、例外の処理が大幅に単純化されます。同様のシナリオを調査して、オフライン機能によって共有データで発生する可能性のある競合を明確にするときは、それらのシナリオを考慮してください。

3 自動同期または手作業による同期

最近のアプリによって、ユーザーはバックグラウンドで実行される自動同期プロセスに慣れてきています。自動同期プロセスに慣れているユーザーは、データの更新についてまったく気にせず、作業を中断されることもありません。これは非常に便利で、最近の多くのクライアントはこの手法が標準的に取られているものと期待します。けれども、複雑な同期のシナリオでは、これが最善の手法ではないこともあります。例えば同期プロセスに長い時間がかかるとすると、アプリが矛盾した状態になる可能性があります。バックグラウンドで同期プロセスが実行されている間にユーザーがデータを処理できるとしたら、この可能性はますます高くなります。処理するのが難しい、さまざまな新しい例外処理のシナリオが生まれる可能性があります。大量のデータを同期する必要がある場合、同期でダウンロードが開始されるタイミングと場所をユーザーが制御できるようでなければなりません。さらに、データの変更をキャッシュに入れる場合、その変更を特定の時間内 (シフト勤務の終了前など) に確実にサーバーに戻して反映させるよう、ユーザーが制御する必要があります。

多くの場合、こうしたシナリオのすべてで推奨されるのは、ユーザーが制御できる手作業による同期プロセスを適用することです。手作業による同期によってアプリをブロックすれば、多くの厄介な競合を回避できます。また、ユーザーはどのデータがいつ同期されるかについて、より確実に把握できるようにもなります。一例として、ユーザーが朝出勤して現場に赴く準備をするときに、手作業で同期を開始します。同期が完了した時点で、ユーザーはデータが最新の状態であることに確信を持てるので、その日が終わるまでオフライン状態であることを懸念する必要がなくなります。

4 プッシュまたはプル

もう 1 つの主要な考慮事項は、同期を開始する方法です。主な手法には、サーバーによる同期のプッシュとクライアントによる同期のプルの 2 つがあります。

通常、小さな変更にはプッシュが使用され、小さなデータが変更されるたびにサーバーがプッシュ通知をすべてのクライアントに送信します。この手法の利点は、必要なときにだけデータが同期され、極めて短時間で更新されることです。ただし、この手法を使用するかどうかは慎重に検討しなければなりません。標準的なプッシュ・メカニズムでは、クライアントが通知を受け取ることも、いつ受け取るかも保証されません。また、複数の通知がキューに入れられる場合、送信順序も保証されません。その上、クライアントがしばらくオフライン状態になると、通知が紛失したり、キューがかなりの大きさになったりする可能性もあります。

オフラインの期間が長かったためか、多数の小さな変更がサーバーから配信されたためかに関わらず、キュー内に多数の通知が入れられると通常は問題になります。クライアント・デバイス上でキューをステップスルーしてすべてのデータ更新を処理するにはかなりの時間がかかるためです。また、処理順序と待ち時間が異なることから、各クライアントでの結果が大幅に異なってくる可能性もあります。

信頼性にかけては、もう一方の手法 (プル・メカニズム) のほうが優れています。プル・メカニズムでは、クライアントがサーバーにアクセスして、前回のリクエスト以降のすべてのデータ更新をリクエストします。クライアントによるプルは、定義された間隔で自動的に行うことも、ユーザーが手作業で開始することもできます。欠点としては、プル・リクエストが行われてから次のリクエストが行われるまでクライアント・データが同期状態でなくなることが挙げられますが、多くのシナリオではこの欠点よりも信頼性の高さのほうが優先されます。私たちがプッシュ・メカニズムを使用して功を奏した唯一のケースは、モバイル・ミドルウェア内にデータを格納するバックエンド・システムの同期です。けれども、多数のモバイル・クライアントのみを同期する場合は、プル・メカニズムのほうが遥かに信頼性に優れていることが実証されています。

多くのビジネス・シナリオにおいて、オフライン・データの処理とデータ同期は複雑なトピックです。実行可能なソリューションを実現するには、組織が技術上の選択肢を調査するだけでなく、ビジネス要件のあらゆる詳細を簡単に理解する必要があります。技術的に機能し、使いものになる、ビジネス要件とユーザーのプロセスに沿ったソリューションにするためには、一見して最先端の手法ではないように思えるものも含め、あらゆる手法を検討することが唯一の方法となります。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Mobile development
ArticleID=1066583
ArticleTitle=オフライン・データ同期
publish-date=08292019