モノリス

🐾 猫で例えると？

ベッドで存在感を放つ、一つの大きなサメにゃん。頭やひれを別々に運ぶのではなく、ひとまとまりで扱う姿を、複数の機能を一つのアプリとして配置するモノリスに見立てます。写真の大きさや窮屈さは印象を覚える手掛かりで、モノリスが必ず巨大で扱いにくいという意味ではありません。

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

一つのアプリとして動かすと、ローカルの呼び出しや単一DBのトランザクションを使いやすく、配備や調査をまとめられます。リポジトリの数だけでは分類できず、一つのリポジトリに複数サービスを置く構成もあります。

コードが増えた際の問題は、量だけでなく依存関係の整理や担当範囲に関わります。モジュールの公開部分を絞り、内部を直接呼び合わない規則を設けると、一つのアプリのままでも変更を管理しやすくなります。

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

機能ごとに異なる台数で配備するのは難しい一方、アプリ全体を複製したり処理を最適化したりして拡張できます。どこまで十分かは負荷と費用次第です。モノリスだから拡張できない、とは言えません。

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

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

モジュラーモノリスの例
  一つの配備単位
    ├ ユーザーモジュール
    ├ 注文モジュール
    └ 決済モジュール
  各モジュールの公開窓口を通じて連携

サービスへ分割した例
  ユーザー、注文、決済を別の配備単位へ
  通信・認証・再試行・データ整合性の管理が加わる

分割すると一部だけを増強・配備しやすくなりますが、他サービスの障害が呼び出し元へ伝わる場合もあります。タイムアウトや縮退、依存先の管理が必要で、分割だけで障害が隔離されるとは限りません。

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

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

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

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