データ統合パターンのトップ5

データは貴重なビジネスアセットです。しかしアクセスやオーケストレーション、解釈は得てして難しいものです。

データがシステム間で移動する場合、そのデータが標準的な形式であるとは限りません。データ統合によってデータをシステムに依存しない形式にすると、アクセスと取り扱いが容易になります。

データを一層便利に、すばやく利用するための方法として、データ統合パターンを使用して統合プロセスを標準化するやり方があります。

ハイキングコースと同じように、パターンは使用している中で発見され、確立するものです。パターンは常に一定の完成度を備えていますが、解決する必要のあるビジネスニーズにもとづいて最適化したり、採用したりできます。ビジネスのユースケースは、パターンのインスタンス化として捉えることができます。つまり、データの移動や取り扱いに関する一般的なプロセスの使用事例と言えます。 

データ統合パターンには、ビジネスのユースケースとクラウド統合のパターン別に見ると5つのパターンがあります。

 

データ統合パターン1:移行

データ統合パターン

移行とは、データをあるシステムから別のシステムに移動することです。移行では、実行前にデータが存在するソースシステム、移行するデータの範囲を決定する条件、データセットが処理される変換、データが挿入される宛先システム、および最終的な状態と目的の状態を比較するために結果をキャプチャする機能が必要になります。

移行のメリット

どのデータシステムにおいても絶対不可欠なのが、データの移行です。企業では、データの作成と維持に膨大な時間を費やします。移行は、そのデータを、作成や閲覧、管理に使用するツールに依存しないようにするための鍵となります。移行を行わないと、ツールを変更する度に蓄積してきたデータすべてを失うことになり、デジタル世界での生産性を維持できなくなります。

移行が有効なケース

データの移行は、あるシステムから別のシステムへの移動、既存のシステムの別のインスタンスやより新しいインスタンスへの移動、既存のインフラストラクチャの拡張のための新しいシステムの稼働、データセットのバックアップ、データベースクラスタへのノードの追加、データベースのハードウェアの交換、システムの統合など、さまざまな状況で行われます。

 

データ統合パターン2:ブロードキャスト

ブロードキャストは、「1対多の一方向同期」とも呼ばれ、継続的かつリアルタイム(またはほぼリアルタイム)に、単一のソースシステムから多数の宛先システムにデータを移動することを指します。

時間の経過に伴い、複数のシステム間でデータを最新状態に保つ必要がある場合には、ブロードキャスト、双方向同期、または相関のいずれかのパターンを使用する必要があります。ブロードキャストパターンでは、移行パターンと同様に、データをソースから宛先へ、一方向にのみ移動します。移行パターンとは異なり、ブロードキャストパターンはトランザクション型です。

ブロードキャストは、範囲内のすべてのアイテムにメッセージプロセッサーのロジックを実行するのではなく、最近変更されたアイテムにのみロジックを実行することを意味します。引き違い窓のようなものと捉えることができ、前回のブロードキャストが実行されてから変更されたフィールド値を持つアイテムのみをキャプチャします。

もう1つの主な違いは、パターン実装の設計方法です。移行の際は、大量のデータを取り扱い、多数のレコードを並行して処理するように調整され、失敗のケースが少なくなることを目指すでしょう。ブロードキャストパターンは、レコードをすばやく処理するよう最適化されており、信頼性が高く、転送中に重要なデータが失われないようになっています。

ブロードキャストのメリット

ブロードキャストパターンは、システムAに存在するか、そこで作成された情報を、ほぼリアルタイムでシステムBに共有する必要がある場合にきわめて効果的です。たとえば、複数のブロードキャストアプリケーションの宛先であるリアルタイムレポーティングダッシュボードを作成して、複数のシステムの状況に関する更新をリアルタイムで受け取る場合などです。

どのチャネルから受注するかにかかわらず、CRM、eコマースツール、または受注処理システムが一元化されている社内ツールから送信される注文の処理を即座に始めたい場合や、蒸気タービンの温度の通知を100ミリ秒ごとに監視システムに送信したい場合、普段受診している患者が救急処置室に運び込まれたときに、個人開業医の患者管理システムに情報を配信したい場合など、データを生成元のシステムから転送して、他のシステムに配信したい状況の例は、数え切れないほどあります。

ブロードキャストが有効なケース

ブロードキャストパターンの必要性は、以下の基準で容易に確認できます。

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

最初のチェック項目で、リアルタイムのデータが必要かどうかによって、移行パターンまたはブロードキャストパターンを使用する必要性が判断できます。おおむね1時間よりも短い間隔で検知する場合は、ブロードキャストパターンが適している傾向があります。ただし、データの量によっては例外もあります。

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

最後のチェック項目で、2つのデータセットを統合する必要があるかどうかを確認できます。統合すると2つのシステム間で同期が行われるようになり、これは双方向同期と呼ばれます。ニーズによって必要となるデータ統合パターンは異なりますが、ブロードキャストパターンでは非常に柔軟なアプリケーションの組み合わせが可能なため、双方向同期アプリケーションよりも、2つのブロードキャストアプリケーションを使用することをお勧めします。

 

データ統合パターン3:双方向同期

双方向同期のデータ統合パターンは、2つのデータセットを2つの異なるシステムで組み合わせることです。これにより、異なるデータセットとして存在する必要性を尊重しながら、2つのデータセットが単一のデータセットとして機能します。このタイプの統合は、同じデータセット上で異なる機能を実行するために、さまざまなツールやシステムを使用する必要がある場合に有効です。

たとえば、受注と受注管理を行うシステムと、カスタマーサポートのシステムが異なる場合などがそれに該当します。これら2つのシステムがそれぞれ最高峰のものであり、両方の機能と共有のデータベースを備えたスイートよりも、それぞれのシステムを使用することが重要な場合があります。双方向同期を使用してデータセットを共有すると、両方のシステムで一貫したリアルタイムのデータ表示を維持しながら、いずれのシステムも使用することができます。

双方向同期のメリット

双方向同期は何かを達成するための手段にも、何か起きたときの救出手段にもなりますが、どちらになるかはニーズが発生する状況によります。1つの現実に対して、2つ以上の独立し、かつ隔離された表現がある場合は、双方向同期を使用することで処理を最適化できます。

製品スイートの中には連携機能がすばらしいのに各個の機能面で劣るものがありますが、双方向同期を利用すれば、最適な製品を選んでMuleSoftのAnypoint Platformなどのエンタープライズ統合プラットフォームで独自の統合スイートに移行することが可能です。

双方向同期が有効なケース

双方向同期の統合アプリケーションは、現実のオブジェクト表現に包括性と一貫性を持たせたい場合に有効です。たとえば、顧客を単一のビューで表示したい場合、顧客の概念の表現を持つすべてのシステムへのアクセス権を全員に与えることで、手動で解決できます。ただし、より効率的な解決法は、その顧客オブジェクトのどのフィールドを、どのシステムで表示する必要があるか、およびそのオブジェクトのオーナーはどのシステムであるかを一覧にすることです。

ほとんどのエンタープライズシステムでは、オブジェクトを拡張することができ、顧客オブジェクトのデータ構造を変更してこれらのフィールドを含めることができます。その後、シンプルなソリューションの場合は(一般的な統合プラットフォームを使用して)ポイントツーポイントのアプリケーションとして、または複数のシステムを運用している場合はPub/Subやキュールーティングモデルなどのより高度なルーティングシステムとして、それぞれ統合アプリケーションを作成できます。

たとえば、営業担当者は配送状況を把握する必要がありますが、配送元の倉庫についての情報は不要です。同様に、配送担当者は配送先の顧客名を知っておく必要がありますが、顧客が支払った金額を知る必要はありません。双方向同期では、これらの担当者の双方が、必要なシステムを通して同じ顧客をリアルタイムに閲覧することができます。

 

データ統合パターン4:相関

相関データ統合パターンは、2つのデータセットの共通部分を特定し、そのアイテムが両方のシステムで自然に発生する場合にのみ、その範囲内のデータセットに対して双方向同期を行うように設計されています。双方向パターンで範囲内のデータセットの統合を同期するのと同様に、相関パターンでは共通部分を同期します。

相関パターンの場合、両方のシステムに存在するアイテムが、各システム上で手動で作成されている可能性があります。たとえば、2人の営業担当者が両方のCRMシステムで同じ連絡先を入力した場合などです。または、これらが別の統合によってもたらされたデータである可能性もあります。相関パターンでは、こうしたオブジェクトの由来は考慮されません。これらが両方のシステムに存在するかぎり、同じように同期されます。

相関のメリット

相関データ統合パターンは、2つのグループまたはシステムがデータを共有する場合に有効です。ただしこれは、実際に両方に同じアイテムや人を表すレコードがある場合に限られます。たとえば、医療機関のグループで、同じ町に2つの病院がある場合、2つの病院の間でデータを共有し、患者がいずれかの病院を利用した場合に、両方の病院でどんな治療を受けたかの最新のレコードを取得することができます。

このような統合を実現する方法として、1つは病院Aから病院Bへ、もう1つは病院Bから病院Aへと、2つのブロードキャストパターン統合を作成することができます。ただしこの場合、データを同期できるようになる一方で、2つの統合アプリケーションを管理する必要も出てきます。

病院AとBの間で双方向同期パターンを使用すれば、2つのアプリケーションを管理する負担がなくなります。ただし、効率を向上させるには、病院Bの患者が病院Aに関わりがない場合、同期の際にその患者のレコードを取得しないようにし、患者のレコードが作成されるとリアルタイムでそのレコードを取得できるようにする必要があります。相関パターンのメリットは、常にすべての範囲のデータセットを双方向で移動するのではなく、関連性のある場合にのみオブジェクトを双方向で同期できることです。

相関が有効なケース

相関データ統合パターンは、「不要な」データを除外できるため、余分なデータが有益である以上に費用がかかる場合に最も有効です。たとえば、大規模な大学システムの一部の大学で、学生全員のレポートを作成する場合などです。

その大学に出席したことのない多数の学生をレポートに含める必要はありませんが、学生がその大学システム内の他の大学で履修した単位は含める必要があるとします。このような場合、相関パターンにより、両方の大学に出席したことのある学生の情報のみを同期することができるため、統合やレポート作成の労力を大幅に削減することができます。

 

データ統合パターン5:集約

集約は、複数のシステムからデータを収集したり、受け取ったりして、1つに統合することです。たとえば、3つの異なるシステムを使って顧客データの統合を行い、データアナリストがすべてのシステムのデータを使ってレポートを作成するとします。この場合、各システムからデータリポジトリへの毎日の移行を作成し、その後、データベースに対してその移行をクエリすることができますが、これにより、管理および同期する必要のあるデータベースが増えてしまいます。

さらに、他の3つのシステムに変更が加えられた場合、データリポジトリを定期的に更新する必要が出てきます。もう1つの欠点は、データは1日前のものであるため、リアルタイムのレポートを作成するには、手動で移行を実行するか、1日待つ必要があることです。この場合、3つのブロードキャストアプリケーションを設定して、レポートデータベースで各システムの最近の変更を反映し、常に最新状態にすることはできます。ただしこのデータベースは、頻繁にクエリできるよう、複製されたデータのみを保管しているため、やはりメンテナンスの必要があります。さらに、データベースを数分おきに最新状態に更新するため、無駄なAPI 呼び出しが多数実行されることになります。

ここで、集約パターンの登場です。アプリケーションを構築する場合や、あらかじめ用意されたテンプレートをアプリケーションに使用する場合に、複数のシステムへのオンデマンドでのクエリや、データセットのマージを思い通りに実行できます。

たとえば、統合アプリを構築して、さまざまなシステムへのクエリやデータのマージを実行し、レポートを生成することができます。こうすることで、データベースを別に用意する必要がなくなり、.csvやその他の形式でレポートを生成できるようになります。また、レポートを直接、保管場所に保存することができます。

集約のメリット

集約パターンのメリットは、単一の統合されたアプリケーションで、複数のシステムからデータを抽出して処理できることです。つまり、必要なときに最新のデータを取得でき、複製が生成されないだけでなく、そのデータを処理またはマージすることで必要なデータセットを生成できます。

集約が有効なケース

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

最後に、コンプライアンスまたは監査の目的で使用するシステムで、複数のシステムの関連データが必要な場合です。集約パターンは、コンプライアンスデータを単一のシステムで管理しながら、このデータを複数のシステムの関連データを組み合わせて生成する必要がある場合に役に立ちます。これにより、状況の把握のために、多数のシステムで必要となる知識を学ぶ労力を節約することができます。