IT 技書の森

マイクロサービス

1 つの大きなアプリケーションを複数の小さなサービスに分割し、それぞれが独立してデプロイ・スケール可能な状態で協調動作するアーキテクチャパターン

アーキテクチャ分散システム

マイクロサービスとは

マイクロサービスは、1 つの大きなアプリケーションを複数の小さなサービスに分割し、それぞれが独立してデプロイ・スケール可能な状態で協調動作するアーキテクチャパターンである。各サービスは特定のビジネスドメインに対応し、API を通じて他のサービスと通信する。

モノリシックアーキテクチャでは、すべての機能が 1 つのコードベースに集約されるため、変更の影響範囲が広がりやすく、デプロイのたびにアプリケーション全体を再デプロイする必要がある。マイクロサービスはこの課題を解決し、チームごとに独立した開発・デプロイサイクルを実現する。

マイクロサービスの特性

Martin Fowler と James Lewis が定義した特性が広く参照されている。

  • サービスによるコンポーネント化: ライブラリではなく、独立したプロセスとしてデプロイされるサービスで構成する
  • ビジネス機能に基づく組織化: 技術レイヤー (フロントエンド、バックエンド、DB) ではなく、ビジネス機能 (注文、決済、在庫) でチームを編成する
  • スマートエンドポイントとダムパイプ: ビジネスロジックはサービス内に置き、通信インフラ (メッセージバス) はシンプルに保つ
  • 分散データ管理: 各サービスが独自のデータストアを持つ (Database per Service)
  • インフラの自動化: CI/CD パイプライン、コンテナ、IaC による自動化が前提

モノリスとの比較

観点 モノリス マイクロサービス
デプロイ 全体を一括デプロイ サービス単位で独立デプロイ
スケーリング アプリケーション全体をスケール サービス単位でスケール
技術選択 統一された技術スタック サービスごとに最適な技術を選択可能
データ整合性 トランザクションで保証 結果整合性が基本
運用の複雑さ 低い 高い (監視、デバッグ、ネットワーク)
開発の初速 速い 遅い (インフラ整備が必要)

実務での判断ポイント

チーム規模が 10 人以下の小規模プロジェクトでは、マイクロサービスの運用コストがメリットを上回ることが多い。サービス間通信のレイテンシ、分散トランザクションの複雑さ、監視基盤の整備、サービスメッシュの運用など、モノリスにはない運用負荷が発生する。

「モノリスファースト」のアプローチ - まずモノリスで構築し、ドメインの理解が深まった段階でサービスを分割する - が実務的に推奨されることが多い。

「マイクロサービスアーキテクチャ」(Sam Newman 著) が定番の入門書として位置づけられている。「マイクロサービスパターン」(Chris Richardson 著) は実装パターンを網羅的に解説している。

AWS でのマイクロサービス

パターン 構成
Lambda ベース API Gateway → Lambda → DynamoDB
コンテナベース ALB → ECS Fargate → Aurora
イベント駆動 EventBridge → Lambda → SQS

サービス間通信

// EventBridge でイベントを発行 (疎結合)
await eb.send(new PutEventsCommand({
  Entries: [{ Source: 'order-service', DetailType: 'OrderCreated', Detail: JSON.stringify(order) }],
}));

理論と実装の両面から学ぶなら関連書籍が参考になる。

関連用語