マイクロサービス
Microservices
1つの大きなアプリを、独立してデプロイできる小さなサービス群に分割する設計。各サービスは1つの責務を持ち、別々に開発・スケール・障害分離できる。
たとえ話: 専門店街 vs デパート
- モノリシック = 1つの巨大デパート。すべての売り場が同じ建物・同じシステムにある。改装(デプロイ)するときは全館を止める。1か所の火災(障害)が全館に及ぶ。
- マイクロサービス = 専門店が並ぶ商店街。パン屋・本屋・花屋がそれぞれ独立。1店だけ改装でき、1店が休業しても他は営業できる。
図を描画中...
各サービスが自分のDBを持ち、自分のペースでデプロイ・スケールできるのがポイントです。フィードへのアクセスが急増したら、フィードサービスだけを増強できます。
メリット
- 独立デプロイ: 1サービスの修正で全体を止めなくていい。
- 障害分離: 1サービスが落ちても他は動き続けられる(設計次第)。
- 独立スケール: 混んでいるサービスだけ増やせる。
- 技術選択の自由: サービスごとに最適な言語・DBを選べる。
- チーム分割: サービスごとにチームが並行開発。
デメリット(つまずきポイント)
- 分散システムの難しさ全部乗せ: ネットワーク遅延、部分障害、データの整合性…これらは1枚岩なら悩まなかった問題。
- 運用が重い: 監視・ログ・デプロイ・障害追跡の対象が一気に増える。
- サービス間のデータ整合性: 1つのトランザクションで全部更新…ができなくなり、結果整合性で設計する必要が出る。
- 分割しすぎ問題: 細かく分けすぎると通信だらけになり、かえって遅く・複雑に。最初はモノリシックで始め、必要に応じて切り出すのが定石(『モノリスファースト』)。
📊 図解
モノリシック vs マイクロサービスの構成
図を描画中...