マイクロサービス

マイクロサービスとは

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

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

マイクロサービスの特性

James Lewis と Martin Fowler が 2014 年 3 月に公開した記事で挙げた 9 つの特性が、共通の参照点として使われている。原典は形式的な定義ではなく共通して観察される性質の列挙であり、以下は実務で影響が大きい 5 つである。

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

モノリスとの比較

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

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

実務での判断ポイント

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

Martin Fowler が 2015 年 6 月の記事で説いた「モノリスファースト」(まずモノリスで構築し、ドメインの境界が見えた段階でサービスを分割する) が実務的な定石とされる。境界を見誤ったまま分割すると、サービス間の同期呼び出しが連鎖してモノリスより脆い構成になるためである。

「マイクロサービスアーキテクチャ」(Sam Newman 著・オライリー・ジャパン・2016 年刊、2022 年 11 月に第 2 版) が定番の入門書として位置づけられている。「マイクロサービスパターン」(Chris Richardson 著・インプレス・2020 年刊) は実装パターンを網羅的に解説している。

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

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