デジタルトランスフォーメーション（DX）に合わせて導入が進んでいる設計手法がある。「マイクロサービスアーキテクチャー」だ。これを使うことでシステム変更の工数を大きく減らせる。実践で直面する3つの難所と突破法を解説する。
「モノリシック（一枚岩）」と表現される従来型システムは、各機能が密接に結び付いている。そのため1つの機能に変更を加えるだけでも、他機能への影響調査や回帰テスト、リリースタイミングの調整などに時間がかかる。
一方、独立性の高い小さなソフト部品が連係動作するようにアプリケーションを実装しておけば、こうした手間が省け変更のスピードを上げられる。
この仕組みを「マイクロサービスアーキテクチャー」と呼ぶ。特にデジタルトランスフォーメーション（DX）で効果を発揮するため、導入が相次いでいる。
しかし実現のハードルは低くない。マイクロサービス設計での難所は主に3つある。「サービスの粒度（大きさ）」をどう決めるか、「サービス連係」「データ同期」をどう実現するかだ。それぞれの突破法を、経験豊富なITアーキテクトへの取材を基に解説する。
サービス粒度
大きすぎも小さすぎもダメ ビジネスとITの両面検討
サービスをどれくらい小さく切り刻むのか。この粒度設計が最初の難所だ。
サービスの粒度は2つの観点から考える。ビジネス面とIT面だ。
「まずはビジネスニーズの変化のサイクルでサービスを分ける。変更の原因はビジネスニーズなので、その単位に分離していれば、余計な調整は発生しないはず」。グロース・アーキテクチャ＆チームスの鈴木雄介社長は、サービス分割の指針をこう話す。
ビジネスニーズをシステムに落としこむに当たり、マイクロサービスでよく使われる設計手法の1つが「ドメイン駆動設計（DDD）」である。ビジネス領域をモデル化したドメインモデルを中心に、ビジネス用語とコードの整合を取りながらアプリケーションを反復的に開発していく。
日本マイクロソフトの樽沢広亨データ＆クラウドAIアーキテクト統括本部シニアクラウドソリューションアーキテクトはドメインを整理する手法として、「レイヤードアーキテクチャー」と「ヘキサゴナルアーキテクチャー」の組み合わせを薦める。レイヤードは、ユーザーインターフェース、アプリケーション、ドメイン、インフラストラクチャーの4層に分けてシステムを構成する。シンプルで分かりやすい半面、アプリがインフラに依存するので拡張性に乏しい。
そこで「アプリケーションは一番偉い立場にあり、外部から影響を受けないとの考え方」（樽沢シニアクラウドソリューションアーキテクト）を持つヘキサゴナルを組み合わせる。アプリケーションとドメインを中心に据え、ポートやアダプターを介し外部と連係する。アプリケーションとインフラを分離することで拡張性を担保できる。
「ドメイン駆動の境界の概念は分かるが、実践するのは簡単ではないと言われることが少なくない」。こう指摘するのはアクセンチュアの福垣内孝造テクノロジーコンサルティング本部クラウドソリューションアーキテクトだ。サービスの粒度について同氏は「目安としては3つのサービスを呼んで1つの処理が完了する程度だろう。切りすぎると性能が落ちる」と話す。
このように、サービスを分割すべきか否かはIT面からの考察も欠かせない。判断基準の1つが非機能要件だ。
