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

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

複雑な課題を単純化していくためのプロセス

　現場を担う担当者は、このような抽象的でかつ問題と解決策がケースバイケースになりやすい漠然としたアドバイスをもらったところで、あまり役に立たない、もしくはその程度は分かっているという方も多いかと思います。

　しかし、複雑な課題をそのままの状態で理解して対応するのは難しいものです。そこでここではいったん、問題をより単純にしていくプロセスについて説明していきます。

問題の捉え方の流れ

　問題の捉え方と解決方法の流れとして、図4のように、課題をより単純化して考えるようにし、そして、解決方法を単純なものから複雑なものへと応用していきます。

図4：課題の把握と解決方法の関係について

　このように考える癖は、マイクロサービスの設計においても重要です。

　マイクロサービスでも、機能を考えうるレベルでできるだけ単純化して考えた後、ビジネス上の不変な単位まで分解してから、機能の単位を合理的なものへとまとめていくことで、例え失敗したとしても、リカバリーしやすくなります。作成した個々の機能が単純すぎるために、結合部分で複雑になってしまったのか、もしくは、作った機能が実際のビジネス上の単位よりも大きいために使い勝手がよくないのかなど、失敗した原因が分かりやすくなるのです。

　そもそも複雑な問題をそのまま解決しようとすると、経験や勘、運に頼らざるを得なくなってしまいます。ありきたりではありますが、基本もしくは不変な事実へブレークダウンして、再度、その知識と手段を積み重ねて複雑な問題に取り組んでいく方が、より確実です。

課題の共通部分

　では、実際に先ほど挙げた2つの拡張性の方向を元に、共通した部分を探してみます。すると、図5のように、データ作成においては共通している部分があります。

図5：共通部分について

　例えば、赤い部分のデータ作成においては、主に複数サービス間でのデータを結合や加工がメインになります。それぞれの対象こそ異なりますが、同じような処理をすることがほとんどです。

　そして、それぞれの緑の部分の機能提供部分は、各サービス毎に変わりやすいという面もありますが、複数のシステム間のデータ結合結果の出力をそのままリクエスト元に返せばよいというケースもあります。もちろん、データ作成部分に比べれば共通性は低くなりますが、それでも、共通する部分は多いはずです。

　サービス特有の機能であれば、やはり個別のサービス側で作成する方が理にかなっているので、この機能提供部分ができるだけ共通化できれば、マイクロサービスをより理想的に維持できます。