モノリス

Monolith

Web開発

UI、ビジネスロジック、データアクセスなど、全ての機能が1つの巨大なコードベース（一枚岩）として統合されている伝統的なシステム構造のこと。初期開発は容易ですが、規模が大きくなると運用が困難になります。

🐾 猫で例えると？

巨大なサメにゃんのぬいぐるみがキャットタワーのベッドを占領し、アメショが後ろで窮屈そうにいじけている様子 — 巨大な塊がリソースを占有し、他のプロセスを圧迫する状態

キャットタワーの快適なベッドを、巨大なサメにゃんのぬいぐるみが完全に占領し、アメショが後ろでいじけています。これはまさに、全ての機能が一つにまとまって巨大化した「モノリス」なシステムがサーバーのリソース（メモリやCPU）を食いつぶし、他の小さな機能や新しい動きを圧迫して身動きが取れなくなっている状態そのものです。

🐾 猫あるある：IT現場の日常

1匹の大きな猫がリソースを独占：一つの巨大なアプリケーションが稼働し、サーバーのメモリやCPUリソースを大量に消費する状態。
一つのベッドで全匹が一緒に寝る：画面表示、内部処理、DB接続などの全機能が同じコードベース内に密結合して混在する構造。
おもちゃを1つ動かすだけで部屋全体が大惨事：一部分のコードを変更・修正しただけでも、システム全体を再ビルドして丸ごとデプロイし直さなければならない仕組み。

💻 IT現場における「モノリス」とは？

モノリシック（Monolithic）は「一枚岩」を意味します。Web開発の歴史において、長らく標準とされてきたアーキテクチャです。立ち上げ初期のプロジェクトでは、機能が1つのリポジトリにまとまっているため、開発のセットアップが簡単で、テストやデプロイもシンプルに行えるという大きなメリットがあります。

しかし、サービスが成長してコード量が膨大になると、全容を把握できるエンジニアがいなくなります。一部の小さなバグ修正が、全く関係ない別の機能に致命的なエラーを引き起こす（密結合による副作用）など、改修の難易度が跳ね上がります。まさに、サメにゃんが大きくなりすぎて、ちょっと動かすだけでもタワー全体が揺れてしまうような状態です。

⚠️ モノリスの仕組みと注意点

モノリスの最大の弱点は「スケーラビリティ（拡張性）」の低さです。特定の機能（例えば「決済処理」だけ）にアクセスが集中して負荷が高まった場合でも、その機能だけを個別に拡張することができず、システム全体を複製してサーバーを増やすしかありません。これは非常にコストパフォーマンスが悪い状態です。

マイクロサービスとの対比

モノリスの課題を解決するために登場したのが「マイクロサービスアーキテクチャ」です。巨大なぬいぐるみを、小さな部品（機能）ごとに独立させて連携させる手法です。

// モノリス（1つのアプリ内に全機能が混在）
const app = express();
app.use('/users', userRoute);
app.use('/orders', orderRoute);
app.use('/payments', paymentRoute);
app.listen(3000);

// マイクロサービス（別々のサーバー/コンテナで稼働）
// ユーザーサービス: ポート3001で稼働
// 注文サービス: ポート3002で稼働
// 決済サービス: ポート3003で稼働

マイクロサービスに分割すれば、決済処理だけを強化したり、特定の機能がダウンしてもシステム全体を止めずに済むといった利点があります。

🛠️ モノリスを賢く使うためのポイント

「モノリス＝悪」ではありません。複雑なマイクロサービスを最初から導入して失敗するケースも多いため、状況に応じた選択が必要です。

最初はモノリスから始める： 新規サービス立ち上げ時は、開発スピードを優先してモノリスで構築し、ビジネスモデルが固まるのを待つ。
モジュラーモノリスを意識する： 1つのコードベース内でも、機能ごとにディレクトリやクラスを明確に分け、内部的な依存関係（密結合）を減らしておく。
適切な分割タイミングを見極める： チームの人数が増え、デプロイの競合やビルド時間の長さがボトルネックになり始めたら、機能単位での切り出しを検討する。

巨大なサメにゃん（モノリス）にベッドを占領されていじけているアメショですが、寒さをしのぐにはこの大きな塊に寄り添うのが一番手っ取り早いこともあります。システム開発も同じで、プロジェクトの規模やフェーズに合わせて、大きくてシンプルな一枚岩と、小さくて機敏な独立部隊のどちらを選ぶか、賢く使い分けていきましょう。