「マイクロサービス」という言葉は求人票や技術記事でよく見かけますが、対になる「モノリシック」との違いまで説明しようとすると言葉に詰まる人も多いはずです。結論から言うと、マイクロサービスとは、1つの大きなアプリケーションを機能ごとに独立した小さなサービスに分割し、それぞれを別々に開発・運用する設計の考え方で、モノリシック（モノリシックアーキテクチャ）はその逆に、1つのアプリケーションとしてまとめて作る従来からの方式を指します。この記事では、両者の違いを比較しながら、未経験からどう関わっていくかまで整理します。
マイクロサービスとは何か
マイクロサービスは、注文管理・会員管理・決済処理といった機能を、それぞれ独立したサービスとして分けて作る考え方です。各サービスは別々のプログラムとして動き、サービス同士はAPIを通じて必要なデータだけをやり取りします。1つのサービスだけを直して公開しても、他の機能に影響が出にくいのが大きな特徴で、サービスごとにチームを分けて並行で開発を進められる点も、規模の大きなシステムで採用される理由になっています。
モノリシックアーキテクチャとは
モノリシックは、注文管理も会員管理も決済処理も含めて、1つのプログラムとしてまとめて作る方式です。歴史的にはこちらが標準的な作り方で、今も多くのシステムがモノリシックで動いています。機能同士が1つのプログラムの中にあるため、開発の初期段階では構成がシンプルで把握しやすく、デプロイ（公開作業）も1回で済みます。一方で、システムが大きくなるほど、1つの機能の修正が他の部分に影響しやすくなるという特徴があり、改修のたびに全体のテストや公開が必要になりがちです。
マイクロサービスとモノリシックの違いを比較する
どちらが優れているというものではなく、何を優先するかで選び方が変わります。
| 項目 | モノリシック | マイクロサービス |
|---|---|---|
| 構成 | 1つのプログラムにまとめる | 機能ごとに独立したサービスに分ける |
| デプロイ | 全体を1回でまとめて公開 | サービスごとに個別に公開できる |
| 初期の作りやすさ | シンプルで把握しやすい | サービス間の連携設計が必要 |
| 規模が大きくなったとき | 影響範囲が広がりやすい | 影響範囲をサービス単位に抑えやすい |
| 運用の複雑さ | 比較的低い | サービスの数だけ監視・連携管理が増える |
コンテナ（Docker）を使うと、サービスごとに動かす環境を分けやすくなるため、マイクロサービスと相性のよい技術としてよく一緒に語られます。どちらの方式で作られたシステムでも、現場に入ってから最初に求められるのは「今どの部分が動いていて、どこが止まっているか」を把握することなので、構成の違いはまず知識として押さえておけば十分です。
マイクロサービスのメリットとデメリット
マイクロサービスを選ぶときは、良い面と負担が増える面の両方を理解しておく必要があります。
- メリット: サービス単位で改修・公開できるため、他機能への影響を抑えながら頻繁にリリースしやすい
- メリット: サービスごとにチームを分けられるため、大規模な開発を並行して進めやすい
- デメリット: サービスの数が増えるほど、サービス間の通信やデータの整合性を管理する手間が増える
- デメリット: 動かすサービスの数が多いため、監視や障害発生時の原因の切り分けが複雑になりやすい
現役でインフラの現場にいる立場から言うと、「分けた分だけ監視と運用の手間も増える」ことを理解していないまま導入すると、運用側が苦しくなることが多い部分です。サービスの数が増えた環境では、どのサービスがどう連携しているかを把握したうえで監視できる体制があってはじめて、マイクロサービスの利点を活かせます。
未経験がマイクロサービスとどう関わっていくか
未経験からすぐにマイクロサービスの設計を任されることはほとんどありません。まずは動いているシステムの運用に関わる中で、少しずつ理解を深めていくのが一般的な流れです。
- 監視: どのサービスが落ちているかをログやアラートから見つける
- 連携の理解: サービス間がどんな単位でやり取りしているかを図や設定から読み取る
- 公開の仕組み: サービスごとにCI/CDで個別に公開されている流れを知る
サービスの数が多い環境では、Kubernetesのようなツールで多数のコンテナをまとめて管理していることも多く、まずは1つずつの仕組みから理解を広げていく姿勢が大切です。最初から全体像を一度に理解しようとするとつまずきやすいため、担当するサービス1つの動きを追えるようになってから、周辺のサービスとの関係を広げていく順番がおすすめです。
InfraDojoで学ぶ
InfraDojoなら、ブラウザ上の演習環境でコンテナやコマンド操作の基礎から学べるため、マイクロサービスの土台になる「サービスを分けて動かす」感覚を早い段階からつかめます。何から学び始めればいいか迷う場合は、AWSの学習ロードマップを確認しておくと、クラウド上でのサービス構成の学び方も判断しやすくなります。
よくある質問
Q. マイクロサービスとモノリシックはどちらが主流ですか？
明確にどちらかが主流というわけではありません。小規模なシステムや開発初期はモノリシックで作られることが多く、サービスの規模が大きくなり、チームも増えてきた段階でマイクロサービスへの移行が検討されるケースが目安として多く見られます。
Q. 未経験でもマイクロサービスの現場に関われますか？
直接設計を任されることは少ないですが、監視や運用の立場から関わる機会はあります。サービスごとに何が動いているかを理解しながら経験を積んでいくことで、徐々にマイクロサービスの考え方に慣れていけます。
Q. マイクロサービスを学ぶにはまず何から始めればいいですか？
まずはコンテナの基本的な仕組みを理解することから始めるのがおすすめです。1つのサービスを1つのコンテナとして動かす感覚がつかめると、サービスを分けて運用するマイクロサービスの考え方も理解しやすくなります。
