マイクロサービスアーキテクチャ#
概要#
マイクロサービスアーキテクチャ(Microservices Architecture)は、アプリケーションを小さな独立したサービスの集合として構築するアーキテクチャスタイル。
各サービスは独自のプロセスで実行され、軽量なメカニズム(通常はHTTP API)で通信する。
モノリスとの比較#
モノリシックアーキテクチャ#
┌────────────────────────────────┐
│ │
│ モノリシック │
│ アプリケーション │
│ │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │UI │ │Logic │ │Data │ │
│ └──────┘ └──────┘ └──────┘ │
│ │
└────────────────────────────────┘
単一デプロイメント
マイクロサービスアーキテクチャ#
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│User │ │Order │ │Payment │ │Shipping │
│Service │ │Service │ │Service │ │Service │
│ │ │ │ │ │ │ │
│┌───────┐│ │┌───────┐│ │┌───────┐│ │┌───────┐│
││ DB ││ ││ DB ││ ││ DB ││ ││ DB ││
│└───────┘│ │└───────┘│ │└───────┘│ │└───────┘│
└────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘
│ │ │ │
└────────────┴────────────┴────────────┘
API Gateway / Service Mesh
マイクロサービスの特徴#
メリット#
1. 開発サイクルが早い
各サービスの開発は小規模なチームが行い、敏捷に開発サイクルを回すことができる
2. デプロイが容易
各サービスは他のサービスに影響を与えずに独立してデプロイ可能
3. 耐障害性
サービスの独立性により、アプリケーションの耐障害性が向上
4. 技術的な自由
サービスごとに最適な技術を選択可能。
デメリット#
複雑性の増加
分散システムの複雑さ
サービス間の通信管理
データの一貫性
分散トランザクションが困難
結果整合性を受け入れる必要
テストの難しさ
統合テストが複雑
エンドツーエンドテストの環境構築が大変
運用コスト
多数のサービスの監視・ログ管理
デプロイメントパイプラインの複雑化
ネットワーク遅延
サービス間通信のオーバーヘッド
データの重複
サービスごとにデータを持つため、重複が発生
いつマイクロサービスを選ぶべきか#
マイクロサービスが適している場合#
大規模で複雑なシステム
異なる部分が異なる速度で変更される
異なる部分が異なるスケーリング要件を持つ
複数の独立したチームが開発
段階的な技術移行が必要
モノリスが適している場合#
小規模なアプリケーション
単一チームでの開発
初期段階のスタートアップ
シンプルなビジネスロジック
分散システムの経験が少ない
マイクロサービスを導入しているサービスの例#
Amazon.com#
ジェフ・ベゾスの「Two Pizza Team(ピザが 2 枚で足りるくらい小さな、通常は 5 ~ 10 人のチームが理想、という考え)」という思想に基づき、小さいチームで開発する