データ統合の代表的な５パターン

データは貴重なビジネス資産です。また、異なるデータを接続・連携・統合することにより、その資産価値が上昇することは多くの方が同意することでしょう。しかし、異なるソースに存在するデータを接続・連携・統合することは、決して簡単ではありません。

データがシステム間を移動するとき、そのデータが（互換性の高い）標準的なフォーマットであるとは限りません。適切なインテグレーションが実装されてはじめて、データがシステムに依存しなくなり、アクセスと取り扱いが容易になるのです。

データを、より便利に使いやすくするために、確立されたインテグレーションパターンを踏襲することで、データ統合のプロセスを標準化することができます。

『パターン』というものは、（目的までの）行程を通じて発見・確立・更新されるものです。そして『パターン』と呼べるものは、一定以上の完成度を備えています。もちろん、目的完遂のための改善や最適化は常に行われるべきでしょう。ビジネスに置き換えて考えた場合、ユースケースは『パターン』のインスタンス化として捉えられます。つまり、データの移動や取り扱いプロセスについての一般的な使用事例と考えることができます。

データインテグレーションのパターンは、以下に記す5つのパターンが代表的と言えるでしょう。

『移行（Migration）』とは、データをあるシステムから別のシステムに移動することです。『移行』のためには、「実行前にデータが存在するソースシステム」「移行させるデータ範囲を決める条件」「データセットが処理される変換（形式）」「データの移行先である宛先システム」そして「実際と計画の状態を比較するために結果をキャプチャする機能」が必要となります。

データの移行は、データを扱うすべてのシステムにとって不可欠です。すべての社員がデータの作成と管理に膨大な時間を費やしています。そして、この『移行』パターンこそ、それらのデータをツールに依存せずに作成や閲覧、管理できるようにするための鍵なのです。『移行』しないと、ツールを変更するたびに蓄積データが失われてしまい、デジタル世界での生産性が損なわれてしまうのです。

データの『移行』は、さまざまな状況で行われます。例をあげると、「あるシステムから別のシステムへ動かすとき」「既存システムの別インスタンスや新しいインスタンスへ動かすとき」「既存のインフラストラクチャを拡張するための新しいシステムを稼働させるとき」「（データベース（DB）などの）データセットをバックアップするとき」「DBクラスタにノードを追加するとき」「DBのハードウェアを交換するとき」「システムを統合するとき」等など、枚挙にいとまがありません。

『ブロードキャスト（Broadcast）』は「1対多型同期」や「1対多の一方向同期」とも呼ばれています。具体的には、データを単一のソースシステムから多数の宛先システムへ、継続的かつリアルタイム（または、ほぼリアルタイム）に移動させることを指しています。

複数のシステム間でデータを常に最新に保つ必要がある場合（つまりリアルタイム同期が必要な場合）、『ブロードキャスト』『双方向同期（パターン③）』『相関（パターン④）』のいずれかのパターンを採用しなければなりません。『ブロードキャスト』は『移行（パターン①）』と同じく、同期元から同期先への一方向の移動のみとなります。

『ブロードキャスト』はトランザクション型です。つまり、スコープ内にある全項目にメッセージプロセッサのロジックを実行するのではなく、最近変更された項目だけにロジックを実行します。前回の『ブロードキャスト』の実行時から変更された値を持つ項目のみをキャプチャします。

『ブロードキャスト』の設計思想も特徴的と言えるでしょう。『移行（パターン①）』では、大量データを扱い、多数のレコードを並行処理するように調整され、エラーなく実装することが一般的なゴールとなります。『ブロードキャスト』では、レコードをすばやく処理するように最適化されています。そのため、信頼性が高く、転送中に重要なデータが喪失されないようになっています。

システムAに存在する情報を、ほぼリアルタイムでシステムBに共有する必要がある場合、ブロードキャストパターンが非常に効果的です。リアルタイムダッシュボードが好例でしょう。すなわち、複数システムの状況や更新情報をリアルタイムで受信できるアプリケーションが複数必要となります。

あるシステムで作られたデータを別のシステムに『ブロードキャスト』する例も、数多く存在しています。CRMやECツール、他の社内ツールから送信された注文のフルフィルメントを即座に開始したいケースもあるでしょう。蒸気タービンの温度を100msごとに監視システムに通知する、開業医の患者管理システムに常連の患者が緊急入院したことを知らせる、など。『ブロードキャスト』のパターンを利用すべきユースケースは本当に多数存在しています。

下のチェック項目は、『ブロードキャスト』パターンを当てはめるべきかを見極めるために有効です。

• イベントが発生するとすぐにシステムBに知らせる必要がある：YES
• 人が介在せずに、AからBにデータを自動的に移動する必要がある：YES
• システムBのオブジェクトの状況を、システムAで検知する必要がある：NO

最初のチェック項目はリアルタイムデータの必要性に基づいて、『移行（パターン①）』または『ブロードキャスト（パターン②）』のどちらを採用すべきかを判断するために役立ちます。およそ１時間よりも短い間隔で検知する場合、『ブロードキャスト』が適している傾向があります。ただ、扱うデータ量によっては例外も存在します。

2つ目のチェック項目から「オンデマンド」アプリケーションが除外されます。一般的に、『ブロードキャスト』はプッシュ通知またはスケジュール設定されたジョブによって開始されるため、人の手を介することはありません。

最後のチェック項目では、2つのデータセットを統合する必要があるかを確認します。2つのシステム間で同期が必要ならば、『双方向同期（パターン③）』を採用しなければなりません。『ブロードキャスト』では、柔軟なアプリケーションの組み合わせが可能なため、『双方向同期（パターン③）』よりもブロードキャストアプリケーションを2つ使用することを推奨します。

『双方向同期（Bi-Directional Sync.）』は、2つの異なるシステムにある2つのデータセットを組み合わせるパターンです。2つの異なるデータセットが存在すべきであることを承認し、それぞれ単一のデータセットとして機能することを可能にします。このパターンは、同じデータセットを使って異なる機能を実行するために、さまざまなツールやシステムを使用しなければならないケースに有効です。

たとえば、受注処理と受注管理のためのシステムと、カスタマーサポートのためのシステムが異なる企業は少なくないでしょう。組織のIT戦略上、あらゆる機能を包括的に備えるスイート製品ではなく、「ベスト・オブ・ブリード」に基づいてシステムを選択する場合、こういったアーキテクチャになる傾向にあります。『双方向同期』に基づいてデータセットを共有すると、2つのシステムで同じリアルタイムデータの保有・表示を実現させつつ、どちらか一方のシステムを使用することが可能になります。

『双方向同期』とは、何かを達成するための手段にも、何かが起きたときの救出手段にもなることができます。2つ以上の独立・分離した形で一つの現実を表現するならば、双方向同期パターンによりプロセスを最適化することができます。『双方向同期』を利用すれば、機能毎に最適な製品を選定し、独自の統合スイートをMuleSoftの『Anypoint Platform』などのiPaaS（エンタープライズ統合プラットフォーム）上に作り上げることが可能です。

現実のオブジェクト表現に包括性と一貫性を持たせたい場合、『双方向同期』の統合アプリケーションが有効になります。たとえば、顧客の単一ビューが必要ならば、顧客に関するデータや情報を持つすべてのシステムへのアクセス権を付与することで、個人で解決することができます。しかし、より効率的な解決策は、「どのシステムでその顧客オブジェクトを表示すべきか」「どのシステムが所有者なのか」「どのフィールドを表示する必要があるのか」をリストアップすることです。

ほとんどのエンタープライズシステムはオブジェクトの拡張が可能であり、顧客オブジェクトのデータ構造を変更させ、加えたいフィールドを追加することができます。その後、シンプルなソリューションであればポイントツーポイントのアプリケーションとして、一般的な統合プラットフォームを使用すれば十分です。一方、複数システムを運用している場合は、Pub/Subやキュー・ルーティング・モデルなどの高度なルーティングシステムとして、適切な統合アプリケーションを構築することもできます。

たとえば、営業担当者は配送状況を把握すべきですが、配送先の倉庫に関する情報は不要です（必要だとしても、配送先のアドレスや倉庫名称で十分でしょう）。同様に、配送担当者は配送先の顧客名を知らなければなりませんが、配送先への請求額を知る必要はありません。『双方向同期』により、それぞれの担当者が同じ顧客について必要な情報のみを、リアルタイムで参照することができるようになります。

『相関（Correlation）』は、2つのデータセットの共通のデータ項目を特定し、その項目が両方のシステムで自然に発生する場合にのみ、その範囲内のデータセットに対して『双方向同期』を行うように設計するパターンです。前述の『双方向同期（パターン③）』だと対象範囲内のデータセットのインテグレーションを同期するのと同様に、『相関』では共通部分を同期します。

『相関』パターンの場合、2つのシステムに存在する項目が、各システムにおいて手動で作成されている可能性があります。たとえば、2人の営業担当が両方のCRMシステムに同じ連絡先を入力した場合やデータをマージしたときに、この事象が発生したかもしれません。『相関』では、こうしたオブジェクトの作成由来は考慮しません。両方のシステムに存在するかぎり、これらのデータは不可知的に同期されます。

『相関』パターンは、2つのシステムがデータを共有する場合に有効ですが、両システム内に同じ項目や人を表すレコードがある場合に限定されます。たとえば、ある医療機関が近隣に2つの病院を持つ場合、2つの病院間でデータを共有し、患者がいずれかの病院を利用した場合に、どんな治療を受けたか最新のレコードを両方の病院が閲覧できるようにすることが可能です。

このデータインテグレーションを実装する場合、「病院Aから病院Bへ」と「病院Bから病院Aへ」という2つの『ブロードキャスト（パターン②）』を採用・作成することもできます。しかし『ブロードキャスト』だとデータ同期はできますが、インテグレーションアプリケーションを2つ管理しなければなりません。

病院AとBの間で『双方向同期（パターン③）』を使用すれば、2つのアプリケーションを管理する負担はなくなります。しかし、病院Bの患者が病院Aに関わりがない（利用していない）場合は、その患者のレコードを取得しないように設定しなければなりません。またその患者のプロフィールが作成されてはじめて、患者に関するレコードを病院Aと病院Bがお互いに取得できるような設定も必要です。これでは、あまり効率的なインテグレーションとは言えないでしょう。『相関』パターンは、データセットの全範囲を常に双方向移動させるのではなく、「必要がある」オブジェクトだけを双方向に同期させるのです。データ利用者に必要な部分のみがアップデートされるため、ユーザにとってメリットが大きい（混乱を引き起こさない）インテグレーションパターンです。

『相関』は「必要ない」データを除外できるため、その必要ないデータを保有することのメリットよりも保有するための費用が大きい場合には有効です。全てを保有する必要がないデータや極稀にしかアップデートされないデータがこれに当たります。

たとえば、大規模な学生管理システム（オムニバス型）を利用しているとある大学が、学生全員のレポートを作成する場合を考えてみましょう。その大学に出席したことのない多数の学生をレポートに含める必要はありません。しかし、単位互換制度を希望する学生が他の大学で履修した単位を、当該大学の履修証明や成績として反映する必要があるかもしれません。このような場合、『相関』パターンは両方の大学に出席したことのある学生の情報のみを同期できるため、インテグレーションを簡便化することができます。当然、その学生についてのレポート作成の労力を大幅に削減することも実現できます。

『集約』とは、複数のシステムからデータを取り出したり、受け取ったりして、1つのシステム内に統合することです。たとえば、3つの異なるシステムにある顧客データが散財しているとしましょう。そして、アナリストがその3つのシステム内のデータを統合させて、レポートを毎朝作成すると想定します。この場合、各システムからデータをリポジトリに毎日移行させ、その後にDBにクエリを実行することがレポート作成処理として考えられます。しかし、この処理では追跡と同期を行うためのDBを別に用意しなければなりません。

さらに顧客データを持つ3つのシステムに変更があると、データリポジトリも常に最新の状態に保つ必要があります。また、データは前日のものであるため、リアルタイムのレポートが必要な場合、アナリストは3つのシステムから手動でデータを集めなければなりません。3つのブロードキャストアプリケーションを構築し、レポートデータベースが各システムの最近の変更を常に取り入れ、最新状態をキープすることも考えられます。ただし、このDBは頻繁なクエリに対応できるように、複製データのみを保管しているため、メンテナンスが欠かせません。DBを最新状態に更新するため、必要ない（無駄な）API 呼び出しが何度も実行されることになります。

ここで、この『集約』パターンが登場します。アプリケーションを構築する場合や事前に用意されたテンプレートをアプリケーションに使用する場合に、複数のシステムへのオンデマンドのクエリや、データセットのマージを好きなように実行できます。

たとえば、様々なシステムへのクエリやデータをマージして、レポートを作成するインテグレーションアプリを構築することができます。これにより個別のDBを新たに用意する必要がなくなり、csvなどの好きなフォーマットでレポートを生成できるようになります。もちろん、レポートを共有ストレージに保存することも可能です。

複数のシステムからデータを抽出し、単一の統合アプリケーションで処理することを可能にすることは、『集約』の大きなメリットです。つまり、データは必要なときに最新の状態に保たれ、複製されることなく、必要なデータセットを作成するために加工や結合を行うことができるのです。

『集約』パターンは、オーケストレーションAPIを作成して、レガシーシステムを「モダナイズ」する場合に非常に役立ちます。複数システムからデータを取得し、単一のレスポンスに統合するAPIを作成する際には特に有効となるでしょう。もう1つのユースケースとしては、複数のシステムからデータを取得し、そのデータを使用してエクスペリエンスを作成するアプリケーションやレポート、ダッシュボードを提供する場合が考えられます。

最後に、コンプライアンスや監査のために使用するシステムでも、『集約』が有効になります。こういったシステムは一般的に、複数の異なるシステム内の関連データを集める必要があります。複数システムの関連データを組み合わせて生成したコンプライアンスデータを単一のシステムで管理する場合、この『集約』パターンが効率的かつ有効となります。すなわち、さまざまなシステム間で必要となる学習の量を減らし、何が起こっているかを確実に把握することができるようになるのです。