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

マイクロサービス まいくろさーびす

サービス分割API連携コンテナスケーラビリティモノリシックDevOps
マイクロサービスについて教えて

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

大きなシステムを「注文」「決済」「在庫」みたいに小さな機能ごとに分けて、それぞれ独立して動かす作り方だよ。部品ごとに直せるし、人気の機能だけ増強できるから、変化に強いシステムが作れるんだ！

マイクロサービスとは

マイクロサービス（Microservices）とは、アプリケーションを小さく独立した複数のサービスの集合体として構築するアーキテクチャ（設計手法）のことです。各サービスはそれぞれ独自のプロセスで動作し、API（Application Programming Interface） と呼ばれる窓口を通じてお互いに通信します。たとえばECサイトであれば「商品検索」「カート管理」「決済処理」「在庫管理」を別々のサービスとして開発・運用するイメージです。

従来のモノリシック（一枚岩）アーキテクチャでは、すべての機能が一つの大きなアプリケーションとして動いていました。一部を修正するだけでシステム全体を再デプロイ（配備）する必要があり、規模が大きくなるほど変更が困難になる問題がありました。マイクロサービスはこの課題を解決するために生まれ、特にクラウドやDevOps（開発と運用の連携手法）と親和性が高く、急速に広まりました。

ただし、マイクロサービスは「なんでも解決する魔法」ではありません。サービス間の通信管理・障害対応・データ整合性の確保など運用の複雑さが増すという側面もあり、導入には十分な検討が必要です。

マイクロサービスの構造と特徴

特徴内容
独立デプロイ各サービスを他に影響なく個別にリリースできる
疎結合サービス同士は互いの内部実装を知らず、APIだけで連携する
技術の多様性サービスごとに最適な言語・DBを選べる（ポリグロット）
スケーラビリティ負荷の高いサービスだけリソースを増強できる
障害の局所化一部サービスが落ちても全体が止まりにくい
チーム分割機能ごとに独立したチームが開発・運用を担える

覚え方：「マイクロ＝小分け弁当」

マイクロサービスは小分けにされたお弁当のようなもの。おかずが別々のカップに入っているから、「卵焼きだけ取り換える」「唐揚げを2倍にする」が自由にできます。モノリシックは大皿料理。一度混ざると分けられない！

モノリシック vs マイクロサービス 比較

比較軸モノリシックマイクロサービス
デプロイ単位アプリ全体サービス単位
スケール全体を増強機能ごとに増強
障害影響全体に波及しやすい局所化しやすい
開発速度（小規模）◎ 速い△ 初期コスト高
開発速度（大規模）△ 遅くなりがち◎ 維持しやすい
運用複雑度低い高い
技術の自由度低い（統一）高い（多様）

歴史と背景

  • 2000年代前半 — インターネットサービスの急成長とともに、大規模モノリシックアプリの限界（デプロイ遅延・スケール困難）が顕在化
  • 2010年前後 — NetflixやAmazonが大規模システムをサービス分割して運用するアーキテクチャを実践し、業界に影響を与える
  • 2012年 — James Lewis・Martin Fowlerらが「Microservices」という用語と概念を整理・発表
  • 2013年 — Docker（コンテナ技術）の登場により、小さなサービスを軽量に動かすインフラが整い、マイクロサービス普及を加速
  • 2014年 — Martin FowlerとJames Lewisが「Microservices」の定義論文を公開。概念が広く認知される
  • 2015年前後 — Kubernetes（コンテナ管理ツール）の登場で、多数のマイクロサービスの運用管理が現実的に
  • 2016年〜現在 — クラウドネイティブ開発の標準的手法として定着。一方で「マイクロサービス疲れ」も話題になり、適材適所の議論が続く

関連技術・構成要素との関係

マイクロサービスは単独では成立しません。周辺技術との組み合わせで初めて機能します。

マイクロサービスを支える技術スタック マイクロサービス群 Service A / B / C / D ... APIゲートウェイ 外部からの窓口・振り分け コンテナ/Docker サービスを独立して動かす箱 オーケストレーション Kubernetes等で管理 サービスメッシュ サービス間通信の制御 CI/CDパイプライン 自動テスト・自動デプロイ 分散トレーシング 障害追跡・ログ管理 クラウドインフラ（AWS / Azure / GCP など） スケーラブルな実行環境を提供

APIゲートウェイの役割

APIゲートウェイは、外部（スマホアプリやブラウザ）からのリクエストを受け取り、適切なマイクロサービスへ振り分ける「フロント受付」です。認証・認可やレート制限（アクセス数の上限管理）もここで一元管理します。

サービスメッシュとは

サービスメッシュは、多数のマイクロサービス同士が通信する際の通信管理インフラです。IstioやLinkerdが代表例で、暗号化・リトライ・タイムアウト・障害検知を自動処理します。

関連する規格・RFC

※ マイクロサービス自体は特定のRFC・ISO規格として標準化されていません。ただし、サービス間通信に利用されるプロトコルには以下の規格があります。

規格・RFC番号内容
RFC 7230HTTP/1.1メッセージ構文（サービス間REST通信の基礎）
RFC 7540HTTP/2（gRPC等の高速通信プロトコルの基盤）
RFC 6749OAuth 2.0（サービス間の認可・認証に広く利用）
RFC 7519JWT（JSON Web Token）サービス間認証トークン

関連用語

  • APIゲートウェイ — マイクロサービスへの外部リクエストを一元的に受け付け・振り分けるコンポーネント
  • コンテナ — サービスを独立して実行するための軽量な仮想化技術
  • Kubernetes — 多数のコンテナ化されたマイクロサービスを管理・自動運用するツール
  • CI/CD — コードの変更を自動的にテスト・デプロイするパイプライン。マイクロサービスと相性抜群
  • モノリシックアーキテクチャ — すべての機能を一つのアプリケーションにまとめた従来の設計手法
  • サービスメッシュ — マイクロサービス間通信を制御・監視するインフラ層
  • REST API — マイクロサービス間通信に広く使われるHTTPベースのAPI設計スタイル
  • DevOps — 開発チームと運用チームが連携して高速にリリースを続ける文化・手法