マイクロサービス・アーキテクチャ(MSA)を適用する際に頭を悩ます問題のひとつが「複数サービスにわたる更新操作」である。マイクロサービスを成すソフトウエアのまとまりは、個々に独自のデータストアを持っている。ゆえに複数サービスを横断する更新操作の際、トランザクション管理によるACID特性を保証できなくなる。
この問題に対処するために二相コミットや結果整合性等の考え方があるが、どのやり方でも限界があるし、ある種の制約や余分な手間を受け入れざるを得ない。もっとも穏当な設計方針は「複数サービスに渡る更新が起こるような粒度ではサービスを切り出さない」である。個々のサービスを実装する段になって悩む前に、サービス粒度の設計に関して事前に考慮すべきことがあるということだ。
前回記事で説明した「CRUD基準によるサブシステム分割」は、更新制御の面から見たサービス粒度の設計基準として応用できる。ドメイン駆動設計におけるサービス分割基準である「境界づけられたコンテキスト」よりよほど工学的でもある。じっさい、CRUD基準で分割されたサブシステムは、マイクロサービスを成すソフトウエアの最小粒度となり得るといって間違いではない。
しかし、そのように分割されたサブシステムを、安易にサービス単位として切り出すべきではない。同じ業務システムの構成要素でありながら、異質な設計方針の混在を許してしまうからだ。異なる設計標準、異なるアーキテクチャ、異なる実装言語、異なるデータストアを持つブロックが混在してしまう。
ほとんどの企業にとってこれは辛い。一般的な企業システムの複雑さと規模を考えた場合、開発・保守要員は次図の(a)～(e)のいずれか（ときにはすべて）の専任になると考えられるからだ。(a)～(e)のそれぞれが内部にいくつもの異質な構成要素を抱えるようでは、保守作業が煩雑になりすぎる。濃厚に連係しているあるサービスのインタフェースを変更したくなってその内部を覗いてみたら、知らない言語やデータストア技術が使われていて途方に暮れた――といった事態を招く。
▼図 企業システムの一般形 
そういったことが起こらないように、各ブロックの設計方針を統制すればよいと思われるかもしれない。しかし、公開されているインタフェースの向こう側をブラックボックスとみなせることこそがMSAの持ち味である。それぞれの内部のあり方について統制をかけていては、わざわざマイクロサービスとして切り出すことの意義が損なわれる。本当に統制したければ、わざわざ分割などせずにモノリシックなソフトウエアとして維持すればよいだけの話だ。
もちろん、サービスとして積極的に切り出すことが有効なケースはある。クックパッドやAmazonをはじめとしたWEB企業を中心にさまざまなマイクロサービスの実践例が報告されている。しかしそれらには「専任チームをあてがえられるほどに、それぞれのブロックが稼いでくれている」という特殊な事情がある。ある種のブロックにたまたま稼ぐ役割がないとしても、ITそのものが利益の源泉となっている事業なので、それぞれに専任保守チームをあてがうことに経済合理性がある。ようするに、MSAの効果はソフトウエアの複雑化と運用管理コスト（保守要員数）の増大によって支えられるということだ。
ITそのもので稼いでいるわけではない大多数の企業ではそうはいかない。そもそも、狭義の業務システムは事業の効率化のためのもので「稼ぎの源泉」ではない。そういう仕組みの維持に大金は使えない。「10個の疎結合なマイクロサービスに切り分けられたモダンな業務システムが完成しました。10チームに分かれてそれぞれ軽快に保守できますよ」「えーっと、保守要員は君を含めて2名なのだが」では笑い話で済まない。10個に分かれていることのオーバーヘッドがその効果を上回ってしまう。注目度の高い技術を用いた開発実績が欲しいだけの技術者と業者の独善以外の何物でもない。
結論。技術的に可能だからといって、流行っているからといって、またある種の事業にとって効果的であるからといって、業務システム(a)の内部を構成するサブシステム群を機械的にマイクロサービス化するやり方に合理性はない。ほとんどの企業にとって、(a)～(e)のそれぞれをサービス単位とみなしてWeb-APIのインタフェースを付与するだけで十分な効果が得られる。それらが企業内で効果的に連係するだけでなく、一部のAPIは取引先に対して公開されて活用されるだろう。しかしその程度では「Web-APIは便利」というだけの話で、MSAを適用したとは言えない。つまるところ、ほとんどの業務システムにとってMSAは無用のバズワードで、「2025年の崖」を克服するための切り札などではない。
