企業間／企業内データ連携
エンタープライズのシステムでは、古くからEDI（Electronic Data Interchange」電子データ交換）という考え方がありました。例えば、金融機関であれば、送金や入金などのデータを他の銀行と連携する為にも必ず企業間でのデータ連携が必要になります。
また、大規模な業務システムの場合などでは、本社サーバへのデータアクセスは必要な場合のみネットワーク接続が許可されるということが一般的な時代もありました。
つまり、企業という単位や事業所という単位でサービスが完全に独立して存在していたケースが、エンタープライズシステムには多く存在したのです。これは、インターネット前の時代から疎結合同士のシステム間においてデータ連携をどうすべきかというノウハウがあるということになります。
そして、それらの役割を担うためのシステムに、これから紹介するESB（エンタープライズ・システム・バス）やEAI（エンタープライズ・アプリケーション・インテグレーション）というシステムがあります。
ESB／EAIシステム
ESBとEAIは非常に似たシステムであり、図14にあるように異なる責任範囲やセキュリティ範囲が異なる別システムの間でデータ連携をする際に主に用いるアーキテクチャです。
例えば、それぞれのシステムで一方はデータをAmazon S3で管理し、もう一方はRDBで管理していたとしても、それらのデータ連携をする際に、ESB／EAIシステムをはさむことでデータ連携部分を実装せずに連携できるようになります。これが例えば、HTTPからWebSocketに変わっても、SOAPになっても、FTPになっても、データ仕様が変わらなければ、それらの接続インターフェースは簡単に変更が可能です。
そして、これは実際のデータを管理する部分でもこの接続インターフェースが変わらなければRDBからAmazon S3に変えることなども理論上は可能になります。つまり、どうやってシステム間でデータ連携するかは後で決めてもよく、また、外部要因による変更や追加があっても、それらの影響をESB／EAIで吸収してくれます。そのため、自社システムが外部と連携しやすく、かつ、外部要因による変化も受けにくくなるので他のシステム影響を考えずにシステム構築がしやすくなります。
もちろん、理想的にはそのような環境が作れますが、実際には必ずしもそんなに簡単に連携できるとは限りません。それは、データ連携とは単に1つのデータを右から左に移動できればよいというわけではないためです。それが、ここまで説明してきたことに関係があります。
ここまでのパイプラインやデータ作成や変換の部分も、実は、ESBやEAIを想定して説明してきました。つまり、ESBやEAIというツールの表面的な機能ではなく、その仕組みや原理、設計する上での特徴や制限については、これまで説明が分かっていれば、ESB／EAI導入の敷居が格段に下がります。
しかし、マイクロサービスを前提とした場合には、このようなアーキテクチャにフォーカスされることはあまりありません。また、これまで説明してきたようなデータ処理の概念への理解がないままに、表面的にESBやEAIというツールを見るとむしろ、理解が難しくなる場合もあります。
なんとなく便利なようで、データ連携だけで別システムを入れる現実としてのメリットがわからないという実感をもつ方もいると思います。また、現場でも限定的な使い方になっていることも多く、少し複雑なことをしようとすると、途端にわからなくなるということもよくあるはずです。
これらの原因はやはり、システム構築後にESB／EAIを導入しようとした場合に多く見られると思いますが、外部システムと連携する際にデータ連携の勘所が分かっていれば、必要になったタイミングでESB／EAIを導入しやすくなるはずです。
また、ESB／EAIはどちらも基本概念は同じですが、利用目的やそれにともなう制限等の違いがあります。以下に、筆者がもつイメージを図15として示しました。
ESBは会社間でのデータや第三者サービスと連携することが主な利用用途であり、導入後すぐに使えるようにするための機能もすでにそろっているシステム連携ツールです。
導入すればすぐに効果が分かるという事もあり、比較的分かりやすい製品として存在します。例えば、以下のようなツールが発売されています。
どちらも、ノーコード開発をサポートしており、エンジニアが存在しないと使えないというものではありません。ただし、先ほど、商品購入処理をすべてデータ連携のパイプライン処理だけで作ったときのように、プログラムであれば簡単な記述であっても、ノーコード開発にすると複雑になってしまうという課題があります。
利用の中心的な用途として、たくさんあるサービスと素早く連携したいというケースが主な利用用途になると思います。
一方、EAIは、社内システム連携などに使われることを想定しています。標準的なプロトコルを使って、各システム間のデータ連携ルールのみに着目しプログラミングしていくというケースが主な利用用途になるでしょう。そのため、製品と言うよりはミドルウェアに近く、以下のようなツールがあります。
オープンソースではありますが、Red Hat社などもその機能を包括した製品であるRed Hat Fuseに組み込んで利用しています。
ただし、実際にはESBは多くの個別ニーズに応える為にEAI化していき、EAIは導入後すぐに使えるように第三者サービス接続の拡充を図るためにESB化していくというように、相互の境界は曖昧です。したがって、これらについて厳密な違いはあまり気にする必要がありません。
なお、クラウド利用として社外にESB／EAIを置く場合には、社内システム間連携はセキュリティ等の問題により難しくなります。一方、どのような役割や効果があるのかを素早く体感するのにまずはクラウドで試してみるのも良いと思います。
ESB／EAIを利用するメリット
どちらも、それぞれの機能をブロックとして組み合わせて考える点では共通です。そして、これまで問題になってきた、プロトコル対応や事前データ準備のための依存管理やスケジュール管理などの機能も標準で備わっています。実装が難しい部分については対応済みということです。
つまり、ESBやEAIを利用することで、システム間データ連携ならではの難しさから解放され、よりデータ連携の部分のみに集中して設計が可能になるわけです。
最後に
ITアーキテクチャを考える上で、小さく、汎用的に、依存性を低くすることでさまざまなところで再利用しやすいように作る方法については、これまでにもいろいろと議論されてきたと思います。しかし、それらを効率的に組み合わせるアーキテクチャについてはあまり話を聞いたことがありません。そのためなのか、ESBやEAIのような仕組み自体が存在することを知らない方も多くいるようです。
筆者が今回、述べたかったことは、ESBやEAIを導入しましょうということではなく、システム間におけるデータ連携においても、これまで培われた知識と経験がすでに世の中に多く存在するということです。もちろん、そういったシステムを導入することで理解もしくは実現できることもあるのですが、こういった知識を得ることでマイクロサービスは難しいと思っている方に何かヒントを得てもらえればと思いました。
次回は、もうすこし複雑なニーズや利用する上で現実的に生じやすい悩みなどについて説明します。
