全2542文字
PR

 小さなサービスを疎結合に連携する「マイクロサービス・アーキテクチャー」を取り入れるITシステムが増えてきた。システムの変更速度を上げ、ビジネスの変化を素早くキャッチアップする狙いがある。ただしマイクロサービスに取り組むとき、誰もが同じ悩みに突き当たる。その1つが「サービス粒度の設計」である。

 「モノリシック(一枚岩)」と表現される従来型システムは、各機能が密接に結び付いている。そのため、ある機能に変更を加えようとすると、他機能への影響調査やリグレッション(回帰)テスト、リリース・タイミングの調整などに多大な時間がかかる。

 一方、小さなマイクロサービスとして実装し独立性を高めておけばこうした手間が省け、変更スピードを上げられる。ここでの考えどころが、いったいサービスをどれくらい小さく切り刻むのかという、サービス粒度の設計である。その手法を探っていこう。

ビジネスニーズを優先

 サービスの粒度を決定するうえでは、2つの観点から考える必要がある。1つがビジネス面、もう1つがIT面だ。

 「まずはビジネスとしてのニーズの変化のサイクルでサービスを分ける。結局、改修の原因はビジネス上のニーズなので、その単位に分離されていれば、余計な調整は発生しないはず」。グロース・アーキテクチャ&チームスの鈴木雄介社長は、サービス分割の指針をこう話す。

 ビジネスニーズをシステムに落としこむに当たり、マイクロサービスでよく使われる設計手法の1つが「ドメイン駆動設計(DDD:Domain Driven Design)」である。ビジネス領域をモデル化したドメイン・モデルを中心に、ビジネス用語とコードの整合性を取りながら、アプリケーションを反復的に開発していく。

 日本マイクロソフトの樽沢広亨シニア・インダストリー・テクノロジー・ストラテジストはドメインを整理する手法として、「レイヤード・アーキテクチャー」と「ヘキサゴナル・アーキテクチャー」の組み合わせを勧める。レイヤードは、ユーザーインターフェース、アプリケーション、ドメイン、インフラストラクチャーの4つの層に分けてシステムを構成する。シンプルで分かりやすい半面、アプリがインフラに依存しているので拡張性に乏しい弱点がある。

 ここに、「アプリは一番偉い立場にあり、外部からの影響を受けないという考え方」(樽沢ストラテジスト)を持つヘキサゴナルを組み合わせる。アプリとドメインを中心に据え、入出力はポートやアダプターを介して連携する。アプリとインフラが分離されるので、拡張性を担保できる。

レイヤーとヘキサゴナル・アーキテクチャーによるドメイン整理の例
レイヤーとヘキサゴナル・アーキテクチャーによるドメイン整理の例
(出所:日本マイクロソフト)
[画像のクリックで拡大表示]

 「ドメイン駆動の境界の概念は分かるが、実践するのは簡単ではないと言われることが少なくない」。ドメイン駆動設計を実際のプロジェクトに適用する難しさを指摘するのがアクセンチュアの福垣内孝造テクノロジーコンサルティング本部 テクノロジーアーキテクチャグループ クラウドソリューションアーキテクトだ。サービスの粒度について福垣内クラウドソリューションアーキテクトは「こう切れば美しいという手本はないが、目安としては3つのサービスを呼んで1つの処理が完了する程度だろう。切り過ぎるとパフォーマンスが落ちる」と話す。

 このように、サービスを分割すべきか否かはIT面からの考察も欠かせない。判断基準の1つが非機能要件である。