マイクロサービス

マイクロサービスとは

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

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

マイクロサービスの特性

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

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

モノリスとの比較

モノリスとの主な違いを以下に比較する。

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

実務での判断ポイント

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

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

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

AWS でのマイクロサービス

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) }],
}));

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