変更要約: 初版
2.4SOAとマイクロサービス
サービス単位で機能を疎結合に連携させるSOAの考え方を発展させ、サービスを独立にデプロイできる粒度まで分割するマイクロサービス、そのドメイン境界での分割判断、そして分散に伴う代償である結果整合性・運用複雑度をどう受け入れるかを学びます。
「マイクロサービスにすれば柔軟でスケーラブルになる」という主張はよく耳にしますが、これは分割の代償を無視した半分だけの真実です。マイクロサービスはサービスごとの独立デプロイ・部分的スケールという利点と引き換えに、サービス間通信の増加、データの結果整合性、運用の複雑化という重い代償を伴います。システムアーキテクトの本質的な役割は「マイクロサービスを選ぶこと」ではなく、要件（リリース頻度・チーム構成・スケール特性）に照らしてモノリスとマイクロサービスのどちらが適切かを判断し、分散の代償を引き受ける準備ができているかを見極めることです。
2.4.1SOAの考え方
- SOA（サービス指向アーキテクチャ）＝業務機能を独立した「サービス」として実装し、標準化されたインタフェース（Webサービス等）を通じて疎結合に連携させる設計思想。サービスを部品として再利用しやすく、既存システムとの統合もしやすい利点がある一方、企業内の共通基盤（ESB＝エンタープライズサービスバス等）に依存しやすく、基盤そのものが単一障害点や変更のボトルネックになりやすいという課題も抱える。
2.4.2マイクロサービスと分割の判断
- マイクロサービス＝SOAの考え方をさらに推し進め、サービスごとに独立してビルド・デプロイ・スケールできる粒度まで分割するアーキテクチャ。各サービスは独自のデータストアを持つのが原則で、チームを機能単位に分割しリリースサイクルを独立させられる利点がある反面、サービス間のネットワーク通信増加、データの整合性維持、分散トレーシング等の運用複雑度という代償を伴う。
- サービスの分割境界は技術的なレイヤ（画面/ロジック/データ）ではなく、業務のドメイン境界（注文・在庫・決済等、変更の理由が独立している単位）で切るのが定石。変更理由が異なる機能を1つのサービスに同居させると、一方の変更が他方に影響し独立デプロイの利点が失われるため、ドメイン駆動設計（DDD）の境界づけられたコンテキストの考え方が分割判断の指針になる。
2.4.3分散の代償：結果整合性と運用複雑度
- マイクロサービスでは各サービスが独自のデータストアを持つため、複数サービスにまたがる更新を単一のトランザクションでACID保証することができない。代わりに、結果整合性（最終的にはすべてのサービスのデータが一致する状態に収束するが、更新直後は一時的にサービス間でデータが食い違い得る）を許容する設計が必要になる。
- 分散化はサービス間通信の失敗（部分的な障害）・処理順序の入れ替わり・重複メッセージの受信といった問題も持ち込む。さらにサービスが増えるほど、デプロイ・監視・障害切り分け・分散トレーシングといった運用負荷が増大するため、この運用複雑度に対応できる組織的な体制（DevOps、監視基盤等）が整っていない状態でのマイクロサービス化はかえって障害対応を遅らせるリスクがある。
「マイクロサービス＝ドメイン境界で分割し独立デプロイできるが結果整合性・運用複雑度という代償を伴う」「分割はドメイン境界で行い技術レイヤでは行わない」「ACIDをまたいだ整合性は保証できず結果整合性を受け入れる設計が必要」が最頻出です。「マイクロサービスにすれば常に良い」という無条件の肯定は誤りです。
あるシステムアーキテクトが、現在モノリスとして運用されているECサイトの基盤刷新を任されました。経営層からは「注文・在庫・決済・配送の各チームが互いに影響を与えずに独立してリリースできるようにしたい」という要望と、「セール時には注文機能だけが突出して負荷が高まるので、そこだけを重点的にスケールしたい」という要望が挙がっています。この2つの要件（独立リリースと部分的スケール）はモノリスでは実現しにくく、機能単位（サービス）ごとに分割・独立デプロイできるマイクロサービスへの移行が妥当な判断です。アーキテクトはサービスの分割境界を検討する際、「画面表示用サービス」「ビジネスロジック用サービス」「データアクセス用サービス」という技術レイヤでの分割は避け、「注文サービス」「在庫サービス」「決済サービス」「配送サービス」という業務ドメインごとの境界で分割する設計を採用しました。これにより、決済ロジックの変更が在庫チームの作業に影響しないなど、変更理由が独立した単位でチームとリリースサイクルを分離できます。次に、注文サービスが在庫サービスに在庫引当を依頼する連携について、単一トランザクションでのACID整合性を諦め、結果整合性を前提とした設計に切り替える必要があります。具体的には、注文確定時に在庫サービスへ引当リクエストを送り、在庫サービス側で引当が完了した時点で「引当完了」イベントを注文サービスへ返す非同期の流れとし、引当が完了するまでの短い時間帯は注文ステータスが「引当処理中」という一時的に不確定な状態を許容します。もし在庫が不足していた場合は「引当失敗」イベントを受けて注文をキャンセルする補償トランザクションの設計も必要になります。さらに、サービス数が4つに増えることで、障害が発生した際にどのサービスが原因かを特定する運用の複雑さが増すため、アーキテクトは分散トレーシングの導入と、各チームがオンコール対応できる監視体制の整備を移行計画に組み込みました。この運用体制の準備なしにマイクロサービス化だけを進めると、障害発生時の原因切り分けが遅れ、可用性がかえって低下するリスクがあるためです。
| 項目 | モノリス | マイクロサービス |
|---|---|---|
| デプロイ単位 | システム全体で一括 | サービスごとに独立 |
| データ整合性 | 単一DBでACID保証しやすい | ==結果整合性==を前提に設計 |
| 部分的スケール | システム全体を一律にスケール | 負荷の高いサービスだけ重点的にスケール可能 |
| 運用複雑度 | 比較的低い | サービス間通信・分散トレーシング等で増大 |
ひっかけ： 「マイクロサービスにすれば常にシステムが柔軟でスケーラブルになる」は誤りです——分割には結果整合性の受け入れ、サービス間通信の増加、運用複雑度の上昇という重い代償が伴い、独立リリース・部分的スケールという要件が薄い状況ではモノリスの方が総合的に適切な場合があります。また「サービスは画面/ロジック/データという技術レイヤで分割すべき」も誤り＝分割は変更理由が独立するドメイン境界で行うのが定石で、技術レイヤでの分割は変更の影響範囲を局所化できません。
2.4.4この節のまとめ
- SOAは標準インタフェースでの疎結合連携、マイクロサービスはさらに独立デプロイ可能な粒度まで分割する
- 分割は技術レイヤでなく業務ドメイン境界（変更理由が独立する単位）で行う
- マイクロサービス化は結果整合性・運用複雑度という分散の代償を伴い、要件次第ではモノリスの方が適切な場合もある
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 経営層から「注文・在庫・決済・配送の各チームが独立してリリースでき、セール時は注文機能だけを重点的にスケールしたい」という要望が挙がった。この要件に対する最も妥当な判断はどれか。
Q2. マイクロサービス化した注文サービスが在庫サービスに在庫引当を依頼する連携で、単一トランザクションでのACID整合性を維持できなくなった。この状況への最も妥当な設計対応はどれか。
Q3. モノリスから4つのマイクロサービスへ分割した結果、サービス間通信・分散トレーシング等により障害時の原因切り分けが困難になるリスクが高まった。このリスクへの最も適切な対応はどれか。