ESB／EAIとは何か？ 疎結合なサービス同士のデータ連携を実現する仕組みと考え方

エンタープライズシステムのためのマイクロサービスアーキテクチャの実現　第2回

　前回、マイクロサービスでシステムを作ったものの、事業が成長してそれらの疎結合が課題になってしまうケースがあり得るということを示しました。今回、それらを未然に防ぐための知識や考え方、そして、それらの技術やアーキテクチャについて紹介します。

想定するマイクロサービスでの課題

　前回、マイクロサービスの大きな課題点は疎結合ゆえに生じる課題が多いということを説明しました。

　例えば、図1のように現在ログインしているユーザに従ってお勧め商品の一覧を表示したいという機能を考えてみます。機能が分割しているために、複数のサービスの横断が必要になってしまい、何度もリクエストしなければならないことから、複雑になってしまうケースをよく見かけます。

図1：マイクロサービスで生じやすい課題

　こういった環境では、操作の煩雑さだけではなくパフォーマンス上の問題も発生しやすく、想定しない事象が発生したときに問題の解決方法がわかりにくくなります。しかし、その一方で、その疎結合がマイクロサービスのメリットであるので、単純に結合型アーキテクチャとしてすべて作り直せばいいというものではありません。

　また、既に作ったシステムを運用ニーズが変わる度に作り直す、というのも現実的な考え方ではありません。また、実際にシステムを作り直してしまうと、そのシステムのやり方を元に別の業務最適化も行われ、このループが終わらないという状況に陥ります。

　それでは、既存のシステム資産を生かして、できるだけニーズに応えた連携を実現するには、どのようにしたらよいでしょうか。

連携を担うシステム拡張の方向性

　既存のシステムを生かした形でシステムを連携する場合、できるだけ既存システムに手を加えずに問題解決するならば、まず考えられることがあります。図2のように、それぞれのサービスを横断的にアクセスする代理機能を設ける方法です。

図2：代理機能を設ける

　この場合、単純に機能を作っては、UI/UXを担当していたところの複雑性がそのまま、代理サービス側に移動したに過ぎません。そのため、できるだけ同じ処理は繰り返さず、必要なデータはできるだけ事前に準備したくなります。

　また、同じ処理の中で同じサービスに対して異なるリクエストが何度も発生することも避けたいため、やはり、そういう観点からもデータを事前に作成しておくというやり方が考えられます。

　図では「キャッシュデータ」と記述しましたが、ここでのキャッシュとは、各サービスがもつデータを使っていつでも同じデータが復元できるという意味でのキャッシュになります。従って、結果データの再利用という狭義の意味でのキャッシュという意味も含みますが、一時データという程度に捉えてください。

　もう一つのケースは、図3のように中核的事業機能を担うサービスを結合型アーキテクチャ型に成長させていくというケースです。

図3：中心的役割を担うサービスをもうける

　こちらは前回「アーキテクチャの選択パターン」で示した内容とかぶっているところもありますが、事業におけるメインビジネスを担う機能はやはり、複雑化していく傾向にあるため、最初からこのようなことを想定して作る方が、その後の対応がしやすいと筆者は思っています。