// シス担のミカタ
アーキテクチャパターン

SOA（サービス指向アーキテクチャ） えすおーえー

サービス指向アーキテクチャWebサービスESBマイクロサービスSOAPインテグレーション
SOAって何？マイクロサービスと何が違うの？

簡単に言うとこんな感じ！

SOAはシステムを「機能ごとの部品（サービス）」に分けて、それをネットワーク越しに組み合わせる設計思想だよ。レゴブロックみたいに「在庫管理」「注文処理」「請求」を別々に作って、必要なときだけ呼び出して組み合わせるイメージ。モノリス（一枚岩）なシステムの反省から生まれたんだ！

SOAとは

SOA（Service-Oriented Architecture、サービス指向アーキテクチャ） とは、ソフトウェアシステムを「サービス」という独立した機能単位に分割し、それらをネットワーク経由で連携させる設計アプローチです。各サービスは明確に定義されたインターフェース（APIや通信仕様）を持ち、互いの内部実装を知らなくても呼び出し合えるように作られます。

2000年代初頭に広く普及したSOAは、それまでのモノリシックアーキテクチャ（すべての機能が一つの巨大なシステムに詰め込まれた設計）の問題を解決するために生まれました。特に大企業の基幹システム同士を連携させる「エンタープライズ統合」の文脈で広く採用されました。たとえば、人事システム・販売管理システム・会計システムをバラバラのまま連携させるときに、SOAが接着剤の役割を果たしました。

SOAの核心にあるのは「疎結合（そけつごう）」という概念です。部品同士をガッチリくっつけるのではなく、緩やかにつなぐことで、一部を変更・交換しても全体が壊れないようにします。この考え方は、現代のマイクロサービスやクラウドネイティブな設計思想にも受け継がれています。

SOAの4大原則

SOAを構成する設計原則を押さえておくと、なぜこのアーキテクチャが有効なのか理解しやすくなります。

原則意味身近な例え
疎結合（Loose Coupling）サービス同士が互いに依存しすぎない電源コンセント：家電を変えても配線は変えない
抽象化（Abstraction）内部の実装を隠して、インターフェースだけ公開自販機：中の仕組みは知らなくてもボタンで買える
再利用性（Reusability）同じサービスを複数のシステムから使い回す共通の「住所確認サービス」を注文・配送・請求で共用
自律性（Autonomy）各サービスが自分のデータとロジックを管理部署ごとに独立した予算管理

SOAを構成する主要コンポーネント

┌──────────────────────────────────────────────────┐
│              サービス消費者（クライアント）         │
│         （Webアプリ / モバイルアプリ / 他システム）  │
└───────────────────┬──────────────────────────────┘
                    │ サービス要求
                    ▼
┌──────────────────────────────────────────────────┐
│         ESB（Enterprise Service Bus）            │
│    ルーティング・変換・オーケストレーション        │
└──────┬─────────────┬────────────────┬────────────┘
       │             │                │
       ▼             ▼                ▼
  ┌─────────┐  ┌─────────┐    ┌─────────┐
  │在庫管理  │  │注文処理  │    │ 請求    │
  │サービス  │  │サービス  │    │サービス  │
  └─────────┘  └─────────┘    └─────────┘

ESB（Enterprise Service Bus） はSOAの「交換台」のような存在で、サービス間のメッセージ受け渡し・形式変換・ルーティングを一手に引き受けます。

SOAでよく使われる通信仕様

仕様説明特徴
SOAPXMLベースのプロトコル厳格・企業向け・WSDLで定義
WSDLサービスのインターフェース定義言語「このサービスは何ができるか」を記述
UDDIサービスの登録・検索ディレクトリ「サービスの電話帳」的存在
RESTHTTP準拠の軽量API近年のSOAでも採用増

歴史と背景

  • 1990年代後半 — 企業システムの増殖期。部門ごとに異なるシステムが乱立し、連携が困難に。「スパゲッティ統合」と呼ばれる混乱状態が発生
  • 2000年 — Gartnerが「Service-Oriented Architecture」という用語を提唱。システム統合の新しい考え方として注目される
  • 2002〜2004年 — SOAPやWSDLなどWebサービス標準が整備され、主要なIT企業がSOA製品を投入。IBMのWebSphere、BEAのWebLogicなどESB製品が登場
  • 2006〜2008年 — 大企業での大規模導入が進む。一方でESBへの集中が「新たなボトルネック」になるという批判も出始める
  • 2010年代 — クラウド・アジャイル開発の普及とともに、SOAの「重厚さ」が課題視される。マイクロサービスアーキテクチャがSOAの後継・進化形として台頭
  • 現在 — SOAの概念自体はマイクロサービス・APIエコノミーに受け継がれ、「サービスを組み合わせる」という思想はより広く普及している

SOA vs マイクロサービス：何が違う？

SOAとマイクロサービスは混同されがちですが、粒度・通信方式・組織体制が大きく異なります。

SOA vs マイクロサービス 比較図 SOA サービス消費者 （Webアプリ / 他システム） ESB（中央バス） ルーティング・変換・制御 在庫 サービス 注文 サービス 請求 サービス ● 粒度：大きめ（ビジネス機能単位） ● 通信：SOAP / ESB経由 ● 管理：中央集権的 マイクロサービス APIゲートウェイ （軽量・ルーティングのみ） 在庫 DB付き 注文 DB付き 請求 DB付き 通知 DB付き 直接通信（HTTP/MQ） ● 粒度：小さめ（1機能1サービス） ● 通信：REST / メッセージキュー ● 管理：分散・自律的
比較軸SOAマイクロサービス
サービスの粒度大きい（ビジネス機能単位）小さい（1機能1サービス）
通信方式SOAP / ESB経由が主流REST API / メッセージキュー
データ管理DBを共有することも多いサービスごとに独立したDB
デプロイまとめてリリースが多いサービス単独でリリース可能
向いている組織大企業・レガシー統合アジャイルチーム・クラウドネイティブ
代表的なミドルウェアESB（IBM MQ、MuleSoftなど）Kubernetes、Kafka、Istio

SOAは「企業システム同士をつなぐ統合基盤」、マイクロサービスは「新しいシステムを小さく作って速く動かす」 というニュアンスの違いがあります。どちらが優れているというわけではなく、目的とシステム規模によって使い分けます。

関連する規格・RFC

規格・RFC番号内容
RFC 4825XCAP（XMLベースの設定プロトコル）。SOAのXMLサービス基盤に関連
RFC 3261SIP（セッション開始プロトコル）。SOAのサービス連携に用いられるケースあり

関連用語