MuleSoftとMarkLogicで接続性の高いアジャイルなデータアーキテクチャを構築

MuleSoftは、API管理用のiPaaS（Integration Platform as a Service）のリーダーです。MarkLogicは、データの統合・管理用のデータハブプラットフォームのリーダーです。MuleSoftとMarkLogicを一緒に使用することで、APIおよびデータの全体像を把握できるので、すばやくデータから価値を生み出すことができます。

全2回のブログの第1回めとして、今回は「MarkLogicとMuleSoftの概要」と「これらを一緒に使うことのメリット」をご紹介します。また一緒に使う方法について、ショッピングアプリケーションの例で説明します。

概要

MuleSoftとMarkLogicを一緒に使うと、ユニークな方法でデータを統合できます。

MuleSoftは、ESBに基づくデータ統合およびAPI主導の接続におけるリーダーです。コネクタが備わっており、実質上あらゆるシステムをデータ移動ワークフローに組み込めます。

MuleSoftはAPI管理ツールであり、RESTに基づくアプリケーションの定義/保護/管理/デプロイ用のさまざまなツールを提供します。これに加えて統合ツールでもあり、データ移動用の標準的なメッセージ指向アプローチを提供します。 また、データを移動せずにそのままの場所で扱えるようにも設計されています。

MarkLogicデータハブは、エンタープライズデータの統合および管理用のマルチモデルデータプラットフォームのリーダーです。MarkLogicデータハブは、エンタープライズデータを統合/キュレーション/格納し、トランザクショナル（業務用）および分析用のアプリケーションの両方に活用できます。MarkLogicデータハブは、マルチモデルのデータ管理、ACIDトランザクション、エンタープライズ仕様のデータセキュリティを実現するMarkLogicサーバーに基づいています。

これら両方のプラットフォームを統合することにより、MuleSoftであらゆるアプリケーションと接続し、一元化された統合場所であるMarkLogic（スケーラブルかつトランザクショナルで安全）にデータを移動できます。

MuleSoftのアプローチ

まずMuleSoftがもたらす価値について説明します。MuleSoft以前は、さまざまなソースシステムからデータを統合するには、ポイントツーポイント統合を複数行わなければなりませんでした。この結果、図1のようなスパゲッティ状のコードになってしまいます。MuleSoftでは、API主導の接続およびESBメッセージモデルで標準化および再利用することにより、ポイントツーポイント統合を最小限に抑えます。MuleSoftでは、図2のように整然とした再利用可能なAPIが提供されており、これで多くのシステムにアクセス可能です。またシステム固有のメッセージ入力・出力は標準化されます。

SoE（システム・オブ・レコード）内のソースデータを移動させることなく、ソースシステムへの変換を利用したAPI呼び出しで、必要なデータを取り出します。ここで前提となっているのは、データ構造およびセキュリティモデルの両方は、多様なプラットフォームにおいてさまざまな形態となっているということです。

図1：ポイントツーポイント統合による「スパゲッティ」コーディング。出典：https://blogs.mulesoft.com/dev/api-dev/what-is-api-led-connectivity/

図2：API主導の接続。主要なAPI層を表示。出典：同上

MuleSoftのAPI主導アプローチでは、Muleアプリケーションワークフローの呼び出し/やり取りを実現するAPIを作成/管理/デプロイします。

MuleSoftでは、REST APIは「experience」と「process」の2つに分類されます。experience APIはエンドユーザーAPI層であり、process APIとやり取りします。process APIは、system API経由でソースシステムと相互運用されます（通常は各ソースシステムに特化した標準装備のAPIです）。これらのREST API層はネットワークを形成します。このネットワークを、オープンAPI定義（OpenAPI仕様やRAMLなど）を使用してMuleSoft内部に含めることができます。またREST API層は、スタック内におけるデータ操作にセキュリティ（認証や認可）を適用し評価する場所でもあります。MuleSoftは、API保護用およびこれらの層を移動するデータへのアクセス用のさまざまなツールやプロトコルを提供しています。

エンドユーザーは通常、experience APIとやり取りします。ユーザーが実行したいタスク（あるいは要求しているデータビュー）に応じて、1つあるいは複数のprocess APIが呼び出されます。これらのAPIはMuleフローに基づいています。これは操作のワークフローを設定するもので、いくつかの処理や変換によって構成されています。こういったプロセスはいずれもワークフロー操作経由でsystem APIを活用しており、ソースシステムに対して直接作業できます。

MuleSoft実装の例

ビジネスアナリストが、顧客の注文のデータを分析する必要があるとします。

アナリストは、最初にMuleSoftのexperience APIを使用します。これにより、さまざまなprocess APIが利用できます。これらのprocess APIは、SAP、Salesforce、OrdersソースシステムのAPIからデータを取得するフローに基づいています。これら3つのソースシステムから生データを取得する際に、このフロー内の操作として、多様なデータを、RESTリクエストのレスポンス形式に準拠した1つあるいは複数のシリアライゼーションに変換します。

このデータ取得のフローは、各リクエストおよび各ユーザーごとに何度も繰り返されます。REST APIの観点から見た場合、ソースのSoR（システム・オブ・レコード）のセキュリティやデータモデルは元の場所にあります。つまり変換されたデータは、他の場所でさらに永続化されることはありません。

REST APIのセキュリティ層では、下流のさまざまなソースシステムに関するアクセス制御を定義します（このフローがAPIへのレスポンス用にデータを変換・操作します）。

MuleSofのアプローチでは、ビジネス部門が管理する多種多様な業務用SoEを柔軟に扱えます。またデータモデルの柔軟性も促進します。巨大なリレーショナルデータモデルを開発する必要はありません。複数のシステムに存在するデータをまとめて1つの全体像を得るために、ソースシステム上のレイヤーで継続的にデータを取得・処理するさまざまな抽出・変換ルーティンを開発できます。

MarkLogicのアプローチ

次に、データ統合に関するMarkLogicのアプローチについて見てみましょう。MarkLogicはデータ層にフォーカスしています（アプリケーション層やミドルティアではなく）。

MarkLogicデータハブでは、まずビジネスコンセプトを表現する「エンティティ」を定義します。これが終わったら、ビジネス部門は分断された多数のソースシステムからのデータを「ステージング」に簡単に置くことができます（＝データをインポートできます）。この際、データが多種多様なデータモデルおよびセキュリティモデルに由来していても大丈夫です。

データをステージングに置いたならば、データハブは複数のステージング済みソースシステムからのエンティティをハーモナイズ（「カノニカル化」）してドキュメント（JSONかXML）にまとめます。これによりビジネスデータが1つのビューとして表現されます。これは下流での分析において重要です。また他のシステムは、これにシンプルにアクセスできます。

段階的ハーモナイゼーションはサイクル的なプロセスです。通常、データ要素のマッピング、データガバナンス、データリネージ、出自、エンリッチ、グラフ/関係性の適用、スマートマスタリングなどを行います。これが完了した時点で、MarkLogicに備わっているエンタープライズ仕様のセキュリティモデルで、ドキュメントを永続化し保護します。

その後、MarkLogicデータハブを使ってデータにシンプルにアクセスできます。その際、ビルトインおよびカスタマイズしたREST API/SQL/SPARQL/ビルトイン検索を利用できます。MarkLogicのセキュリティモデルは、すべてのアクセスエンドポイントに対して適用されます。永続化されたデータのセキュリティにより、あらゆる機密データを安全に保護します。データハブの大きな目的は、データの一元化、下流における他システムおよびユーザーによるシンプルな利用、元のソースシステムにおける作業量の削減などです。MarkLogicデータハブは、これらの目標を実現します。

図3：MarkLogicデータハブでは、データをアズイズで読み込み、キュレーションし、セキュリティとガバナンスを適用し、アクセス可能にする。柔軟性が高いため、モデリングを一度に全部行う必要がない。またデータや業務の変化に応じて手作業でETLを行う必要がない。

MarkLogicとMuleSoftを一緒に使う理由

MuleSoftは、移動中のデータへのアジリティを「API層」で提供します。MarkLogicは、アジリティとデータの永続性を「データ層」で提供します。

MarkLogicは、データを統合して持続性のあるデータアセットを作成することにより、MuleSoftが扱うデータを一元化されたビューとしてシンプルに表現します。多数のシステムとやりとりしてサイロに分断されたデータを扱う代わりに（下図参照）、MarkLogicはキュレーション済みで一貫性のあるハイパフォーマンスのバックエンドシステムを提供します。

MuleSoftの一般的な課題を解決する

具体的に見ていきましょう。MuleSoftでサービスネットワークを構築する際によく見られる問題点のうち、MarkLogicが解決できるものを挙げていきます。

1.各リクエストごとのデータの再処理 – ソースシステムのAPI呼び出しから返されたデータは、各リクエストごとに継続的に再処理されなければならないことがあります。MuleSoftでレスポンスを作成する際に毎回これを行うと、処理が遅くなる可能性があります。

MarkLogicによる解決策 – MarkLogicには、集約化されたソースからのリクエストを処理するための高速かつスケーラブルなクエリエンジンがあります。

2.複雑な重複 – 異なるソースシステムにおいて重複がみられることがよくあります。これらのレコードのマッチ＆マージは、APIで管理したり各リクエストごとに処理すべきではありません。

MarkLogicによる解決策 – MarkLogicのスマートマスタリング機能により、重複データのマッチ＆マージが楽になります。AIを使用しており、データを永続化し、さまざまな用途で利用できるようにします。

3.データの大量発生 – 複数のソースシステムを対象として、大量のユーザーが何度も集計や分析を行うことがあります。このような場合、MuleSoft以外に個別のデータウェアハウスを準備することが一般的です。

MarkLogicによる解決策 – 他にデータウェアハウスを立てる必要はありません。MarkLogicは、データの集計や高度な分析を行うことができます。またBIツールやその他のユースケース用にSQLビューを提供します。優れたセマンティックグラフ機能も提供しています。

4.ガバナンスのトラッキング – 中間的なデータストアに永続化する場合、データが安全に格納されることが重要です。さまざまなソースからのデータは、ソースシステムのセキュリティモデルの範囲外で結合されるため、これは特に重要です。

MarkLogicによる解決策 – MarkLogicはデータのセキュリティとガバナンスを集約し、データの変更をエンドツーエンドでトラッキングするので、開発者の負担が減ります。

どのように行うのか

簡単に言うと、MuleSoftとMarkLogicデータハブを一緒に使う場合、データをソースシステムから移動させ（差分を捕捉し）、MuleSoftのフローで生データを処理し、MuleSoft用のMarkLogicコネクタを使ってMarkLogicにデータを書き込みます。

データはMarkLogicデータハブ内に永続化され保護されます。その際、堅牢でカスタマイズ可能なロールベースのセキュリティモデルが使用されます。次にMuleSoftのフローを使って、MarkLogicデータハブ内のデータに対する処理（データのマッピング/マッチ/マージなど）のオーケストレーションを行うことができます。最後に、MuleSoftのAPIはMuleSoft用のMarkLogicコネクタあるいはデータハブが公開しているデータサービスを使って、データにアクセスします。

ここにおいて、ソースシステムは依然としてSoR（システム・オブ・レコード）のままであることに注意してください。このアーキテクチャでは、MarkLogicはインサイトおよびエンゲージメントのシステムの役割を担っています。つまり、MarkLogicは一元化された統合ポイントを提供することで、さまざまなシステムからのデータに対して業務上重要なデータの基準的なビューを提供し、各APIリクエストごとの変換パターンを最小限に減らします。

MarkLogicデータハブの強みは、異なるソースからのデータを分析/レポート/マスタリングする際の、データのアクセスおよび取得を楽にすることにあります。インサイトを得るために、さまざまなビジネスエンティティに関するカノニカル化（基準化）されマスタリングされたデータの像を提供することにより、下流でのエンゲージメントが促進されます。

MuleSoftおよびMarkLogicデータハブはさまざまなユースケースを扱えますが、他の現代的なデータ管理技術とも相性がいいので、既存のデータウェアハウスやデータレイクと一緒に活用できます。

例えば、MuleSoftを使ってソースシステムをデータレイクに統合したあと、MarkLogicでデータ移動とハーモナイズをオーケストレーションして、外部のサービス利用者に提供したり、あるいは分析構造をデータウェアハウスに渡したりできます。

MuleSoftとMarkLogicを使ったショッピングアプリケーションの例

もう一度、「API主導の接続性」の図に戻ります（図3）。これはショッピングアプリケーションの例です。

このショッピングアプリケーションのアーキテクチャでは、顧客レコードを扱うシステムが複数あり、重複が見られます。このため、MarkLogicデータハブを追加してこういった顧客の重複を解消し（マスタリングし）、個々の注文および過去の注文履歴をトラッキング・分析するといいでしょう。

図4：ソースAPI/システムとprocess API間のレイヤーとしてのデータハブの役割を図示した論理図。ソースシステムのデータがデータハブに入り、ハーモナイズされセキュリティが適用される。これに下流でアクセス可能。system APIは依然としてサービスネットワーク内で利用可能。これは、クライアントからソースシステムへの同期的なアクセスが必要な場合が想定されるため。

発送情報もMarkLogicに入れれば、発送ステータスの変更をアラートとして顧客に提供できるほか、ある期間内の注文と発送を分析することで、顧客データの真の360ビューが得られます。

このデータハブにより、これまでは複雑あるいは不可能だったMuleSoftのprocess APIの実装が可能になります。しかしデータハブを追加したことで、process APIがsystem APIに直接接続できなくなるわけではありません。

同期的/非同期的なデータ操作

もう一度図4に戻ります。データハブとAPIの存在が、MuleSoftアプリケーションネットワーク内の既存のprocess APIやexperience API（セキュリティメカニズムを含む）の使用を妨げないことに注意してください。実際のところ、MuleSoftを長年使っている人なら「process APIと、MarkLogicデータハブのFinalデータベースが公開するAPIの使い分けはどうしたらいいのか」という疑問が湧くでしょう。MuleSoftの既存のAPI（特に同期的なデータ操作用）を変更する必要はありません。これらはこれまでと同様に呼び出すことができ、データハブを呼び出す必要はありません。データハブはどちらかというと非同期的なデータ操作（複数のビジネスエンティティを対象とした分析やマスタリングなど）に利用されることが多いため、ハブのAPIおよびセキュリティは、通常そのような業務を扱います。

こうなると、長年MarkLogicやMuleSoftを使っている人には「どのコンポーネントにセキュリティを適用したらよいのか」という疑問が湧くでしょう。これはとても重要な問いです。というのも、両製品とも堅牢なセキュリティを提供しており、どちらか一方だけでもあらゆる状況において機密情報を保護できるからです。前述のとおり、これら2つの主な違いは、MuleSoftは移動中のデータに対してセキュリティを適用するのに対して、MarkLogicは主に格納中のデータに対してセキュリティを適用する（ロールベースのアクセス制御による）ということです。私たちは、移動中および格納中のデータの両方にセキュリティを適用することを推奨しています。これら2つのアプローチは相互補完的であり、アプリケーション全体のセキュリティを強化するものだからです（例外として、ODBCやXDBCプロトコルでMarkLogicに直接アクセスする場合には、MarkLogicの前にMuleSoftのAPIおよびセキュリティを実装しません）。

セキュリティの強化

MuleSoftのセキュリティでは、フロントエンドのMarkLogicアプリケーションに対して、OAuth 2.0（OpenID経由）、属性ベースのアクセス制御、リクエストスロットリング、IPホワイトリストなどを提供します。MarkLogicのセキュリティモデルは、永続化されたドキュメントに対するロールベースのアクセス制御、コンパートメントセキュリティ、格納時の暗号化、要素レベルのセキュリティなどによってMuleSoftの機能を強化します。また、リダクションは両方でサポートされています。

図5のように、MuleSoftのexperience APIとOrders用のアプリケーションワークフロー（MarkLogicデータハブ上にある）に関わる、両方のコンポーネントに対して認証（authentication）と認可（authorization）をHTTPSで各REST API上に適用します。MarkLogicにはアイデンティティおよびアクセス用の管理プロバイダが備わっています。これを両方のコンポーネントに使ってサーティフィケート経由でユーザーの認証情報を確認・検証できます。MuleSoft用のMarkLogicコネクタは、双方向TLSハンドシェイクによるサーティフィケートベースの認証に利用できます。

図5：MuleSoftおよびMarkLogicコンポーネントにおける、サーティフィケートベースの認証とアプリケーションセキュリティ（外部のアイデンティティプロバイダプラットフォーム経由）。  『MuleSoft’s API Security Best Practices』ホワイトペーパーより作成（https://www.mulesoft.com/lp/whitepaper/api/protect-apis）。

この例では、OrdersチームのJanetが注文の分析データ（データハブ内でハーモナイズ済み）にアクセスしたいとします。JanetはまずHTTPS経由でMuleアプリケーションにアクセスします。そこでMuleSoftのセキュリティがアイデンティティプロバイダプラットフォームとやり取りし、Janetを認証してサーティフィケートを与えます。このサーティフィケートは、注文にアクセスするためのMarkLogicへのリクエストの一部となります。次にMarkLogicセキュリティが、データハブ内のOrders APIが内部セキュリティと外部セキュリティのどちらを使用しているのかを判断します。内部セキュリティが使用されていて、JanetがMarkLogic内のユーザーとなっている場合、彼女は認証され、データへのアクセスが許可されます。外部セキュリティが使用されている場合、MarkLogicはアイデンティティプロバイダと一緒に、Janetのサーティフィケートの有効性を検討します。あるいは彼女のサーティフィケートのSubject DNに基づいて彼女を認証することも可能です。次にこういったロールをアプリケーションサーバーで使用し、ドキュメントレベル/要素レベルのセキュリティ制御、コンパートメントセキュリティ、リダクションなどでJanetに対して表示する内容を決めることができます。

まとめ

MarkLogicデータハブは、キュレーション済みのガバナンスが効いた安全で持続性のあるデータアセットをAPI主導のアジャイルな環境に提供することで、MuleSoftの機能を強化します。MuleSoftは、ソースシステムへの接続および統合済みデータにアクセスするための頑健なAPI管理を提供することで、 MarkLogicデータハブの機能を強化します。この結果、業務におけるデータのフル活用をこれまでにないほど短期間で実現します。

第2回では具体的な実装方法をご紹介し、MarkLogicとMuleSoftを一緒に利用する方法についてさらに詳しくご紹介します。