データ統合の名人がマイクロサービス/コンテナ/データガバナンスについて語る

大企業も中小企業も、データ統合を柔軟かつ安全に実現できるソリューションを求めています。その多くは、マイクロサービスやコンテナを利用したデータガバナンスに着目しています。

今回は、MarkLogicの「データ統合名人」の1人であり、これまでに大規模データ統合プロジェクトを6つ手がけているPuneet Rawal（MarkLogic社主席セールスエンジニア）がデータ統合の最近のトレンドに関する知見を共有してくれました。MarkLogic World（2018年5月7～10日）での講演を準備中の彼から話を聴きました。

典型的なデータ統合プロジェクトとはどのようなものですか？

私がお手伝いした会社のいくつかは、長年MarkLogicを使ってきたうえで、そこから別の活用法に展開しています。他の企業、例えばあるメガバンクなどは、まだあまりMarkLogicを使っていませんでした。

MarkLogicのベテランユーザー企業であれば、MarkLogic活用のベストプラクティスやフレームワークができあがっていることが多いです。でも新規のお客様と仕事するのも楽しいですね。というのも初めてのツールでフレッシュなスタートが切れますから。

私がこれまでに携わった企業は、業界を問わず似たような問題を抱えています。データの種類が本当にバラバラなので、データを統合・活用するためのハブが必要なのです。

こういったデータ統合の課題を、MarkLogicはどう解決するのですか？

これまでのお客様たちは、極めて困難なデータ統合問題を解決してきています。マルチモデルのアプローチと柔軟なデータモデリングには大きなアドバンテージがあるので、アプリケーションの採用・導入が簡単にできます。特に、今すぐに効果を出さないといけない大きな組織にとっては導入が簡単になります。

大手のリレーショナル製品の場合、同じようなプロジェクトを行うには数年単位の時間がかかるでしょう。幸いないことに、MarkLogicでは最初のプロジェクトの本番稼働までに2、3か月しかかかりません。

リレーショナルからMarkLogicに切り替えた組織にはどのようなものがありますか？

リレーショナルからMarkLogicに乗り換えた例はたくさんあります。その中から1つご紹介します。

以前大手製造業で一緒に仕事をしたアーキテクトと、最近話をしました。この会社はオラクルでデータを統合しようとしていましたが、2年経っても何も統合できませんでした。「そのままリレーショナルでやっていたら、データ統合プロジェクトが終わるのは自分が定年退職する頃になっていただろう」と彼は言っていました。まだ30代半ばの人ですよ。

この会社は、数十億ドル規模の製造業で、ERPシステムが200以上ありました。 各システムごとに、セールス/購買/注文/在庫管理といったドメインやサブドメインが2000から4000もありましたが、これらのERPシステムを統合して、財務状況を一元管理する必要があったのです。特に規制報告や監査のために、一元化されたビューが必要でした。

MarkLogicを採用したところ、最初のプロジェクトは7か月で本番稼働までいきました。このスピード感は、私が関わったデータ統合プロジェクトでは普通のことです。

ほとんどの会社で同じようなデータ統合問題があると思いますが、どの場合でもMarkLogicの実装方法は似た感じなのでしょうか？

私が携わったプロジェクトはそれぞれ若干異なっています。これはその組織においてどの程度NoSQLの経験があるのかによって変わってきます。また新しいパラダイムを受け入れる準備がどの程度あるのかにもよります。

例えば先ほどの大手製造業の場合、すでにオラクルを使ったデータ統合プロジェクトが始まっていたわけです。他の企業、例えば私がお手伝いしたメガバンクでは、リレーショナルではダメだと気付いていて、すでにMongoDBを使いはじめていました。

この銀行の場合は結構楽でした。というのも、これまでのやり方を変えなければという認識があり、ドキュメントモデルをすでに採用していたからです。この場合、やりたいことを実現できる適切なテクノロジーが必要なだけだったのです。

この銀行の開発者向けに、MarkLogicを他社製品と比較するセッションを何回か行ったら、MarkLogicはMongoDBよりも圧倒的に優れていると思っていただくことができました。例えば、ACIDトランザクションのことを心配しなくて良いとか、似たようなビルトイン検索を利用できるとか、災害復旧やセキュリティがより強固であるということを理解してもらえたのです。

最近マイクロサービスの話題がよく出ますが、これは大企業において大きなトレンドとなっているのでしょうか？　 他にも何かトレンドはありますか？

おっしゃる通り、マイクロサービスの利用は大きなトレンドになっています。従来、大規模なチームが大規模なプロジェクトに取り組んでいたのを、小さな塊に分割するわけです。これで、業務課題を最優先事項として扱えるようになり、インターフェイスのことを考えるようになるのです。従来よりもアジャイルなやり方です。

マイクロサービスの利用を促進するための、コンテナの採用も見受けられます。コンテナの利用は大きなパラダイムシフトです。これほど急速に定着した技術はそうありません。2016年には、半分ちょっとの会社がコンテナに投資していましたが、今では2/3以上の会社がコンテナに投資しています。

また、コンテナの実装を楽にするためのクラウドフレームワークの使用が見受けられます。例えば、PaaSのCloud Foundryはコンテナベースのアーキテクチャで、アプリケーションの短期開発・導入（継続的なデリバリー）を促進するものです。Cloud Foundryはすべての主要クラウドプロバイダ上で実行でき、大組織における開発効率を大きく改善できます。

MarkLogicではマイクロサービスやコンテナを利用できますか？

MarkLogicは、マイクロサービスやコンテナの登場に興奮しています。コンテナやマイクロサービスは、現代的アーキテクチャのためのパラダイムだと思っているからです。どちらもMarkLogicと一緒に効果的に利用できます。

現在、MarkLogicではコンテナ技術のリーダーであるDockerを利用できます（注：本ブログ掲載後、Kubernetesも利用可になっています）。開発/テスト環境でDockerを使いたい方のためのフルサポートも提供しています。またMarkLogicはマイクロサービスの開発もサポートしています。もちろんこれは単なるテクノロジーの話ではなく、アプローチ自体の話となります。

典型的なマイクロサービスアーキテクチャとは、どのようなものですか？

私が携わったお客様ではアプローチが2種類あって、どちらも適切だと思います。

• 1つめのアプローチは、単にMarkLogicを独立したマイクロサービスの一部として使用するものです。
• 2つめのアプローチは、MarkLogicをオペレーショナルデータハブとして使用し、すべてのマイクロサービスがこれをポイントするものです。

独立したマイクロサービスをサポートするアプローチでは、MarkLogicで日常的な処理を行えます。例えば株式ポートフォリオでは値が変化するので、ポートフォリオの値を毎日更新する処理が必要です。この場合、MarkLogicに値を格納して独立したストレージ層として利用できます。アーキテクチャの一部に障害が発生しても、また簡単にスピンアップできます。

オペレーショナルデータハブのアプローチの方は、もっと面白いです。というのも、このハブで多くのソースからのデータを統合して、複数のマイクロサービスからアクセスできるようにするからです。

私がお手伝いする会社では、人事データ、あるいは取引データや保険請求データをまとめたいところもあります。こういったデータはすべて、上流のソースからMarkLogicに読み込まれ、MarkLogic内でハーモナイズされます。それからこのデータに下流のシステムからアクセスして、分析や規制報告などのアプリケーションで利用します。こういったさまざまな繋がりにおいて、マイクロサービスを使用できます。MarkLogicで利用できるさまざまなマイクロサービスモデルについては、このブログを参照してください。

このアーキテクチャでは、API管理プラットフォーム（Mulesoftなど）を使ってオペレーショナルデータハブ（MarkLogic）との接続を管理することもあります。 あるいはHadoopにオフロードすることもあります。またSplunkでログを統合する場合もあります。

どのコンポーネントを使った場合でも、重要なのは、アジリティに基づいた整理と「APIファースト」の考え方です。最短の時間でデータから価値を生み出し、元々のビジネスニーズを満たすAPIを構築するのです。 アプリケーションの機能やパフォーマンスについては、後から考えればいいんです。

とはいえ、データガバナンスを犠牲にするわけではないですよね？

その通りです。セキュリティ、あるいはより一般的に言えばガバナンスは、どんなお客様にとっても極めて重要です。これまでお手伝いしてきたほとんどのお客様では、データの品質保持、機密データの保護、適切なアクセス管理のためのツールやプロセスがすでに存在していました。

例えば、あるお客様はIBM Data Catalogを使っていました。これには情報アナライザやポリシー適用エンジンなどが備わっています。 これはデータガバナンスを一元化できるので素晴らしいです。MarkLogicは、こういったインフラを邪魔しないことを目的としていて、こういったものを強化し、データガバナンスを楽にすることで、これらのツールが管理するポリシーをMarkLogicのデータ層で容易に適用できるようにします。

大規模データ統合プロジェクトについてさらに知りたい場合は、2018年5月7～10日開催のMarkLogic Worldにおける、エトナおよびノーザントラストのセッションに参加しPuneetの話を聴いてください（本ブログの初出：2018年4月）。