マイクロサービスアーキテクチャ#

概要#

マイクロサービスアーキテクチャ(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. 技術的な自由
サービスごとに最適な技術を選択可能。

デメリット#

  1. 複雑性の増加

    • 分散システムの複雑さ

    • サービス間の通信管理

  2. データの一貫性

    • 分散トランザクションが困難

    • 結果整合性を受け入れる必要

  3. テストの難しさ

    • 統合テストが複雑

    • エンドツーエンドテストの環境構築が大変

  4. 運用コスト

    • 多数のサービスの監視・ログ管理

    • デプロイメントパイプラインの複雑化

  5. ネットワーク遅延

    • サービス間通信のオーバーヘッド

  6. データの重複

    • サービスごとにデータを持つため、重複が発生

いつマイクロサービスを選ぶべきか#

マイクロサービスが適している場合#

  • 大規模で複雑なシステム

  • 異なる部分が異なる速度で変更される

  • 異なる部分が異なるスケーリング要件を持つ

  • 複数の独立したチームが開発

  • 段階的な技術移行が必要

モノリスが適している場合#

  • 小規模なアプリケーション

  • 単一チームでの開発

  • 初期段階のスタートアップ

  • シンプルなビジネスロジック

  • 分散システムの経験が少ない

マイクロサービスを導入しているサービスの例#

Amazon.com#

ジェフ・ベゾスの「Two Pizza Team(ピザが 2 枚で足りるくらい小さな、通常は 5 ~ 10 人のチームが理想、という考え)」という思想に基づき、小さいチームで開発する

Netflix#

Spotify#

Uber#