アプリ分割の設計では、既存システムを分析しマイクロサービス化の対象を探し出す。サービス化の過程では、アクティビティー図やシーケンス図などが重要になる。非同期メッセージングの活用で、インターフェースや性能、可用性が分離できる。
今回はアプリケーションをマイクロサービス化するための設計手法を解説します。手順を説明した後に、例に基づき、マイクロサービス化を進めます。
設計手順は、（1）既存システム分析、（2）マイクロサービス化対象機能の発見、（3）マイクロサービス化設計、（4）リスク評価と検証の4ステップで進めます。
マイクロサービス化はシステムのアーキテクチャーを段階的に変更していきます。まずは現状のシステムのアーキテクチャーの正しい把握が求められます。アーキテクチャーとは「システムを構成する要素」と「その要素同士の関係性」を示したものです。システム全体を俯瞰する資料を作成した後に、より細かい検討が必要な部分があれば深掘りしていく必要があります。これを表現するのに適しているのがアクティビティー図、シーケンス図、コンポーネント図などです。
特に重視すべきなのはアクティビティー図やシーケンス図など、時間軸に沿った資料です。マイクロサービス化では機能間の呼び出し箇所だけではなく、そのタイミング、回数、通信量やそれらの依存関係などを正しく把握する必要があります。コンポーネント図のような時間軸を記載しない図しかないと、機能間に引かれた線の意味が正しく理解できなくなります。
マイクロサービス化対象機能の発見
マイクロサービスは、機能の変更速度を上げるために導入します。つまり、「システムを構成する機能」と「各機能に求められる変更スピード」を理解し、その機能の単位でサービスとして分割していくことを検討します。注意すべきは、機能というのは、あくまでもビジネス的な観点であり、システム的な「プレゼンテーション」「ビジネスロジック」「データベース」といったレイヤーではない点です。機能の全体像を表現するのはユースケース図が適しています。ユースケース図を作ったうえで機能ごとに要求されるリリースサイクルを定義して変更スピードを把握します。
対象となる機能が明確になったら、実際にサービスとして切り出していく検討を行います。マイクロサービスでは、サービス間を疎結合にしていくことが求められまずが、その疎結合のレベルは慎重に設計しなければなりません。本連載で何度も述べているように、疎結合であるほどサービスの独立性が高まり、そのサービスの変更が他のサービスに影響を与えなくなります。しかし、疎結合であるほどデータの一貫性が失われる可能性が高まります。一般に、アプリの分割より、データの分割のほうが難易度は高くなります。
マイクロサービス化設計は、紙の上で行いますが、もちろん、それだけではうまくいきません。システムのアーキテクチャーの変更にはリスクが伴います。設計された構成に対してリスク評価を行い、検証によりリスクを顕在化し、対応を決定する必要があります。表1が一般的な検証方法に対する利用タイミングと目的です。検証方法には時間的な制約が大きい場合があるので、期間を決定し、そこでやるべき作業を限定して実施します。
