マイクロサービスアーキテクチャ まいくろさーびすあーきてくちゃ
簡単に言うとこんな感じ！
大きなシステムを「小さな専門チーム」に分割して作る設計スタイルだよ！「注文」「在庫」「決済」それぞれを独立したサービスとして動かすから、1か所直しても全部止まらないんだ。便利で柔軟なシステムの作り方ってこと！
マイクロサービスアーキテクチャとは
マイクロサービスアーキテクチャ（Microservice Architecture）とは、アプリケーションを「小さく独立した複数のサービス」に分割して構築・運用する設計思想のことです。それぞれのサービスは単一の業務機能（例：ユーザー管理・決済・通知など）を担い、API（アプリケーション間の接続口） を通じて互いに連携します。
従来の「モノリシックアーキテクチャ（一枚岩型）」では、すべての機能が1つの大きなプログラムとして動いていました。これに対しマイクロサービスは、機能ごとに独立してデプロイ（リリース）・スケール（拡張）・障害対応ができる点が最大の特徴です。
ビジネスの観点では、「特定の機能だけ素早く改修して本番リリースできる」「負荷が高い部分だけサーバーを増強できる」といったスピードと柔軟性が魅力です。ただし設計・運用の複雑さも増すため、チームの規模や技術力に合った採用判断が重要になります。
モノリシックとマイクロサービスの違い
| 比較項目 | モノリシック（一枚岩） | マイクロサービス |
|---|---|---|
| 構造 | 全機能が1つのプログラム | 機能ごとに独立したサービス |
| デプロイ | 全体を一度にリリース | サービス単位で個別リリース |
| スケール | 全体をまとめて拡張 | 必要な部分だけ拡張 |
| 障害の影響 | 1か所の不具合が全体に波及 | 該当サービスのみ影響 |
| 開発チーム | 一元管理 | サービスごとに分散チーム |
| 技術スタック | 統一 | サービスごとに選択可能 |
| 向いている規模 | 小〜中規模、機能が安定 | 中〜大規模、頻繁な機能変更 |
覚え方：「コンビニのレジ vs 専門店の集合体」
モノリシックは「なんでも一人でこなすスーパー店員」。マイクロサービスは「パン屋・肉屋・魚屋が集まったマーケット」のイメージ。専門店が並んでいるから、魚屋だけ閉めても他は営業できる！
マイクロサービスの構成要素
- サービス本体：単一機能を担う小さなアプリ（例: 注文サービス、在庫サービス）
- API Gateway（ゲートウェイ）：外部からの入り口となる窓口。各サービスへリクエストを振り分ける
- サービスディスカバリ：サービス同士が互いの場所（アドレス）を自動で見つける仕組み
- メッセージブローカー：サービス間の非同期通信を仲介する（例: Kafka、RabbitMQ）
- コンテナ/オーケストレーション：各サービスを独立して動かすDockerやKubernetesなどの技術
歴史と背景
- 2000年代前半：大規模Webサービスの台頭により、モノリシックなシステムの限界（デプロイの遅さ・スケールの非効率）が顕在化
- 2005年頃：SOA（サービス指向アーキテクチャ）の概念が普及。サービスを分割する考え方の前身となる
- 2011〜2012年：「Microservices」という言葉がソフトウェアアーキテクトたちのカンファレンスで使われ始める
- 2014年：MartinFowler氏とJames Lewis氏がマイクロサービスの定義を整理した記事を公開。一気に注目を集める
- 2014〜2015年：Dockerの普及によりコンテナ化が容易になり、マイクロサービスの実践が加速
- 2016年以降：KubernetesがGoogleからOSS化。コンテナオーケストレーションの標準として定着し、大規模マイクロサービス運用が現実的に
- 現在：Netflix・Amazon・Uber・楽天など大規模サービスの多くがマイクロサービスを採用。一方で「マイクロサービス疲れ」として複雑性の課題も認識され始め、「適切な粒度」の議論が続く
アーキテクチャ構造とAPI連携の全体像
マイクロサービスは、外部からのリクエストをAPI Gatewayが受け取り、各サービスへ振り分ける構造をとります。
各サービスは独自のデータベースを持つことが推奨されます（Database per Service パターン）。これにより、あるサービスのDB変更が他サービスに影響しない独立性が保たれます。
マイクロサービスの利点と注意点
メリット
| メリット | 内容 |
|---|---|
| 独立デプロイ | 1つのサービスだけ修正してリリース可能。全体停止が不要 |
| 技術の自由度 | サービスごとに最適な言語・DBを選べる |
| スケールの効率化 | 負荷の高いサービスだけサーバーを増強できる |
| 障害の局所化 | 1サービスが落ちても他サービスは動き続ける |
| 組織との整合性 | チームをサービス単位で分けると開発がスムーズ（Conway’s Law） |
注意点・デメリット
| 注意点 | 内容 |
|---|---|
| 運用の複雑さ | サービス数が増えるほど監視・ログ管理が難しくなる |
| ネットワーク通信コスト | サービス間のAPI呼び出しが増えると遅延が発生しやすい |
| データ整合性 | 分散DB間でのトランザクション管理が難しい |
| 初期コスト | 設計・インフラ整備に時間とコストがかかる |
| 過剰分割のリスク | 細かく分けすぎると逆に管理が煩雑になる（Nano-service問題） |
関連用語
- モノリシックアーキテクチャ — 全機能を1つのプログラムにまとめる従来の設計スタイル
- API Gateway — マイクロサービスへのリクエストを一元的に受け付ける入り口
- コンテナ — アプリをOS依存なく独立して動かす仮想化技術（Dockerなど）
- Kubernetes — 多数のコンテナを自動管理するオーケストレーションツール
- REST API — マイクロサービス間の通信に広く使われるAPI設計スタイル
- DevOps — 開発と運用を一体化してリリースを高速化する文化・手法
- サービスメッシュ — マイクロサービス間の通信を管理する専用インフラ層
- イベント駆動アーキテクチャ — イベントをトリガーにサービス間を非同期連携する設計パターン