マイクロサービス・アーキテクチャ(MSA)は、モダンなソフトウエアのあり方を考える際に欠かせない考え方だ。複雑で巨大なソフトウエアを扱いやすいモジュールに分割することで、独立したチームに開発や運用・保守をまかせられるようになる。モジュール間の通信はシンプルなAPIを用いてなされ、それらの仕様さえ理解しておけばモジュール間連係をスマートに実現できる。経済産業省が2018年に発表した「DXレポート～ITシステム『2025年の崖』の克服とDXの本格的な展開～」でも好意的に紹介されていた。
しかし、業務システム開発でMSAを適用する際には注意が要る。業務システムを1個のサービスとみなして、他システムに対するインタフェースを与えることになんら問題はないし意義深い。しかし、業務システムを構成する個々のブロック（サブシステム）を機械的にマイクロサービスの単位とみなすべきではない。更新制御に関する問題を生じやすいだけでなく、業務システム全体に必要な一貫した統制が失われるからだ。
詳しく説明する前に、本稿で言う「業務システム」の意味合いを明確にしておこう。次図は拙書『データモデル大全』からのもので、企業システムの一般的な構造を表している。ただしこれはあくまでも「理想形」であって、実際の企業システムはさまざまな実装上の変異を生じている。たとえば、財務データ管理システム(b)と決算システム(d)は会計パッケージとしてカバーされていることがふつうであるし、組織や社員といったデータを扱う共用データ管理システム(e)が図のように独立していることも稀だろう。それでも、このように企業システムの形態を論理化することで、現実の企業システムの個性や問題を理解しやすくなる。
▼図1.企業システムの一般形
狭義の業務システムは、この図の事業データ管理システム(a)に相当する。図上では１個しか載っていないが、複数の事業を擁する企業は複数の(a)、すなわち(a1),(a2),...を運用することになる(*1)。これら(a1),(a2),...のそれぞれが本稿で言う「業務システム」であると考えてほしい。これらのシステム(a1,a2,...)のそれぞれにマイクロサービスのインタフェースを与えることには、繰り返すがなんら問題はない。問題はこれらのシステムの「内部」を複数のマイクロサービスの組み合わせとして設計することが妥当かどうかである。
さて、個々の業務システム(a1,a2,...)の一般的な規模感としては、50～100程度のテーブルを含んでいるものと考えて異論はないだろう(*2)。これを単一のソフトウエアとみなすには大きすぎるので、なんらかの方針に沿っていくつかに分割したい。凝集度が高く、結合度が低いようなブロック（サブシステム）に分けることで、システムの管理が楽になるし、仕様の見通しも良くなるからだ。
そのために筆者が提唱している分割方針が「CRUD基準によるサブシステム分割」である。概念的には単純なものだ。まず、テーブルとこれを操作するアプリをすべて設計し終わっていると想像してみよう。アプリ数はテーブル数の3～5倍におよぶので、これらの膨大な要素をいくつかにグループ分けしたくなる。その際には「ブロック間をまたぐ更新系操作が存在しない」ような分割基準を適用すればよい（図2）。テーブルとアプリが一体となってブロック化される点がミソだ。
▼図2.テーブル(T01～30)とアプリ(A01～27)をサブシステムに分割する
この基準によって更新系操作(C,U,D)がブロック内部に隠蔽され、3つのブロック間には参照操作(R)しか残らなくなる。結果的に、ブロック間の結合度を抑えられるし、１個のブロックに含まれるテーブル数の上限を定めることで凝集度についても配慮できる。筆者はこのようにサブシステム分割することで日常的に効果をあげている。しかしながらこの基準が広く知られているとはいえないし、せっかくそのように分割してもサブシステムを実体として定義できない開発基盤が多いのが実情ではある。
問題は、このように分割されたブロックがマイクロサービスの粒度として適切かどうかだ。拙書ではマイクロサービスの最小単位となり得ると説明してある。更新操作がブロック内部で完結するからには、マイクロサービス化した際に更新制御上の問題は生じないからだ。しかしこれはあくまでも理屈の上での話で、現実にそれらを安易にマイクロサービス化する方針には問題がある。それについて後編で説明しよう。
*1.この場合でも、b～eは１個ずつで済む点に注意。
*2.ちなみにCOBOLシステムにおける「ファイル」は、筆者の経験ではRDBにおける「テーブル」の4倍以上の数にのぼる。ここではRDBベースの業務システムとして説明している点に注意してほしい。200以上のテーブル数を含むRDBベースのシステムがあるとしたら、COBOLシステムを機械的にコンバージョンしたか、COBOL技術者が昔のやり方でDB設計したかのどちらかの可能性が高い。いずれも保守性は最悪だ。
