モノリシックとは?意味・メリット・マイクロサービスとの違い

モノリシックとは(結論から)

**モノリシック(Monolithic)**とは、ログイン・決済・検索などシステムに必要な機能をすべて1つの大きなプログラムとしてまとめて作る設計方式のことです。「一枚岩の」という意味の英単語がそのまま名前になっています。対になる考え方が「マイクロサービス」で、こちらは機能ごとに小さく分割して作る方式を指します。

以下で、この2つの違いをもう少し詳しく見ていきます。

そもそも何がどう違うのか

モノリシック(Monolithic、「一枚岩の」という意味)とマイクロサービス(Microservices)とは、どちらもシステムの**作り方(設計方針)**を表す言葉です。

• モノリシック:ログイン機能、決済機能、検索機能など、システムに必要な機能をすべて1つの大きなプログラムとしてまとめて作る方式
• マイクロサービス:機能ごとに小さな部品(サービス)に分割し、それぞれを独立したプログラムとして作り、互いに通信させながら1つのシステムとして動かす方式

「一軒家」と「集合住宅」で考える

この2つの違いは、建物の作り方に例えるとイメージしやすくなります。

• モノリシックは、すべての部屋(機能)が1つの建物の中に一体となって作られている「一軒家」のようなもの
• マイクロサービスは、それぞれ独立した部屋(サービス)が、廊下(通信の仕組み)でつながっている「集合住宅」のようなもの

一軒家は全体の作りがシンプルで見渡しやすい一方、集合住宅は各部屋を独立して増改築でき、1つの部屋の工事が他の部屋にほとんど影響を与えません。

それぞれのメリット・デメリット

なぜマイクロサービスが注目されるようになったのか

事業の規模が大きくなり、関わる開発チームの人数が増えてくると、モノリシックな作り方では「1つの機能を直すために、全体のテストや公開作業が必要になる」といった非効率が目立ってきます。そこで、機能ごとに独立してチームが開発・公開できるマイクロサービスの発想が、大規模なサービスを中心に広まってきました。

どちらを選ぶべきか

• サービス開始直後で、要件や機能の境界線がまだ固まっていない段階では、モノリシックでシンプルに始める判断も有効
• 事業が拡大し、複数のチームが同時並行で異なる機能を開発するようになった段階では、マイクロサービスへの移行を検討する価値がある

多くの成長したサービスでは、最初はモノリシックで始め、規模の拡大に応じて段階的にマイクロサービスへ移行していく、という道をたどっています。

これは、フレームワークとライブラリの選び方の記事で触れた「最初から最適解を狙うより、段階的に選ぶ方がうまくいく」という考え方とも通じるところがあります。将来の拡張性を見越して最初から複雑な構成を組むより、今の規模に見合った選択をして、必要になった時に移行する方が、結果的に無駄が少なくなることが多いです。

マイクロサービスを支える周辺技術

マイクロサービスは「分割する」という設計方針だけでは成り立たず、それを実現するための周辺技術とセットで語られることがほとんどです。

• コンテナ:それぞれのサービスを軽量な箱(コンテナ)に詰めて、環境に依存せず動かせるようにする技術。仮想マシンとの違いは別の記事で解説しています
• CI/CD:サービスごとに独立して開発・公開できる恩恵を最大限に活かすため、テストや公開作業を自動化する仕組み。詳しくはCI/CDとは何かの記事をご覧ください
• API:分割されたサービス同士が通信し合うための「窓口」の役割。APIとは何かの記事で身近な例をもとに解説しています

これらの技術が組み合わさって、はじめてマイクロサービスは実用的な選択肢になります。逆に言えば、コンテナやCI/CDの整備が追いついていない状態でサービスだけを細かく分割してしまうと、かえって管理の手間が増え、モノリシックより扱いにくくなってしまうケースも少なくありません。

分割したことで生まれる新しい課題

サービスを分割すると、今度は「サービス同士の通信がうまくいかなかった時、どうするか」という新しい課題が生まれます。たとえば、決済サービスが一時的に不調になった際、それを呼び出す他のすべてのサービスが連鎖的に待たされ、システム全体が巻き込まれて止まってしまうことがあります。こうした連鎖を防ぐために考え出されたのが「サーキットブレーカー」という設計パターンです。電気のブレーカーが異常時に回路を遮断するのと同じ発想で、不調なサービスへの呼び出しを一時的に止め、被害の拡大を防ぎます。詳しくはサーキットブレーカーパターンの記事で解説しています。

実務で意識しておきたい移行の進め方

いきなり全体をマイクロサービスへ作り直すのは、リスクもコストも大きい判断です。実務でよく採用されているのは、以下のような段階的な進め方です。

1. まずはモノリシックで全体を作り、サービスとして軌道に乗せる
2. 機能ごとの利用頻度や、チーム間の依存関係を観察する
3. 特に独立性が高く、頻繁に変更が発生する機能(決済処理や通知機能など)から、優先的に切り出していく
4. 切り出した部分の運用が安定したら、次の機能へと段階的に広げていく

一度にすべてを切り替えるのではなく、影響範囲の小さい部分から少しずつ試すことで、想定外のトラブルを最小限に抑えながら移行を進められます。移行の具体的な進め方は、ストラングラーパターンとはで詳しく解説しています。

「作り直す」のではなく、「少しずつ移す」

すでに、モノリシックなシステムがあり、それをマイクロサービスなど、別の作り方に移したい場合、一度に全部作り直すのは、リスクが大きい方法です。完成するまで成果が見えず、切り替えの日に、問題が集中するからです。

そこで使われるのが、入口で振り分けながら、機能ごとに少しずつ、新しいシステムへ置き換えていく方法です。詳しくは、ストラングラーパターンとはで解説しています。

また、技術の選び方については、**「新しいから」ではなく、「5年後も、自分たちで運用できるか」**で判断することを、おすすめします。マイクロサービスは、分割することで、運用する部品が増え、運用の負担が増えることがあります。既存のシステムが、安定して動き、運用担当者が新しい仕組みに慣れていない場合は、モノリシックのまま、改善を続けるほうが、現実的なこともあります(コンテナとVMの違い、フレームワークは「流行っているから」で選ばない)。

選択に迷ったら、まずここだけ見る

モノリシックとマイクロサービスは、それぞれ「シンプルさ」と「柔軟な拡張性」という異なる強みを持つ、システムの設計思想です。どちらが優れているというより、事業の規模やチーム体制に応じて選ぶべき、適材適所の関係にあります。具体的な判断基準は、フレームワークは「流行っているから」で選ばないの「5つの観点」(規模・運用できる人・学習コスト・自由度・やめやすさ)が、そのまま使えます。