マイクロサービス

マイクロサービスとは

マイクロサービスは、1つのアプリケーションを独立して開発・デプロイできる小さなサービスの集合として構築するアーキテクチャです。各サービスは自分専用のデータベースを持ち、[[REST API]] や [[gRPC]] などのネットワーク越しの通信で連携します。

対になる概念がモノリス(一枚岩)で、全機能を1つのアプリケーションとしてまとめて開発・デプロイする従来型の構成を指します。

モノリスとの比較

重要なのは、マイクロサービスが常に優れているわけではないことです。サービス間通信の失敗・分散したデータの整合性・監視対象の増加など、モノリスには無かった問題を引き受けることになります。

支える技術

サービスを多数動かすには、それを支える基盤技術が必要です。

• [[Docker]] — 各サービスをコンテナとして独立してパッケージング・実行する
• [[Kubernetes]] — 多数のコンテナのデプロイ・スケール・自己修復を自動化する
• [[APIゲートウェイ]] — 多数のサービスへの入り口を1つに束ね、認証などを共通化する
• [[メッセージキュー]] — サービス間を疎結合につなぐ非同期通信の要
• [[オブザーバビリティ]] — 分散したサービスをまたぐ障害調査に必須
• [[エラーハンドリングとリトライ設計]] — 通信失敗を前提に、タイムアウトとサーキットブレーカーで守る
• [[分散トランザクションとSaga]] — DBが分かれた先の整合性を補償トランザクションで保つ

初学者向けポイント

• 「まずモノリスで作り、チームや機能が育って必要になったら分割する」が現実的な進め方としてよく推奨されます
• サービスの分け方は業務の単位(注文・在庫・決済など)で切るのが基本で、これを誤ると通信だらけの「分散モノリス」になります
• 面接や設計議論で頻出のテーマなので、利点だけでなく複雑さという代償もセットで説明できるようにしましょう

関連技術とのつながり

• [[APIゲートウェイ]] — 多数サービスの入り口を1つにまとめる定番構成
• [[Docker]] / [[Kubernetes]] — サービス群の実行基盤
• [[メッセージキュー]] — 非同期連携でサービス同士を疎結合に保つ
• [[REST API]] — サービス間の同期通信の標準的な手段
• [[冪等性]] — 通信失敗のリトライで二重処理を起こさないための備え
• [[CAP定理と分散データベース]] — サービスごとにデータを分けた先で向き合う整合性のトレードオフ

Q: マイクロサービスの説明として正しいのはどれ?
- [ ] 全機能を1つのアプリケーションにまとめて一括デプロイする構成
- [x] 独立して開発・デプロイできる小さなサービスの集合として構築する構成
- [ ] データベースを使わないアプリケーションの構成
解説: マイクロサービスはアプリを独立した小さなサービス群に分割する設計です。一括デプロイする従来型はモノリスです。

Q: マイクロサービスの代償として本文で挙げられているのはどれ?
- [x] サービス間通信の失敗やデータ整合性など、運用の複雑さが増す
- [ ] サービスごとに技術選定ができなくなる
- [ ] 障害が必ず全サービスに波及するようになる
解説: 個別デプロイの自由と引き換えに、通信・整合性・監視といった分散システム特有の複雑さを引き受けます。

Q: サービスの分け方について本文で推奨されているのはどれ?
- [ ] ソースコードのファイルサイズが均等になるように切る
- [ ] 使いたいプログラミング言語ごとに切る
- [x] 注文・在庫・決済といった業務の単位で切る
解説: 業務の単位で分割するのが基本です。これを誤ると通信だらけの「分散モノリス」になってしまいます。