モノリス
全機能をひとつのアプリケーションとして構築する構成。単純さが最大の武器。
概要
モノリス（monolith、一枚岩）とは、ユーザー管理も商品検索も決済も通知も、システムの全機能をひとつのアプリケーションとして構築する構成です。コードベースはひとつ、ビルドの成果物もひとつ、デプロイの単位もひとつ。サーバ 上ではひとつの プロセス として動き、機能同士は同じメモリ空間の中で関数呼び出しによって連携します。
「アーキテクチャの一種」というより、素直にアプリケーションを作るとまずこうなる、という自然な形です。Ruby on Rails や Django、Laravel といった定番のWebフレームワークで作られたアプリケーションの多くはモノリスであり、世の中で動いているシステムの大半は今もこの形をしています。
この言葉が意識されるようになったのは、対になる マイクロサービス という概念が登場してからです。分割された構成と比較する文脈で「分割されていない側」に名前が必要になった、という経緯を押さえると、この語彙の立ち位置が理解しやすくなります。
なぜ生まれたか
厳密には、モノリスは「生まれた」ものではなく、もともとの当たり前の姿です。むしろ問うべきは「なぜ当たり前だった形に、わざわざ名前が付いたのか」です。
2010年代、Amazon や Netflix のような巨大サービスが、数百人規模の開発組織で単一のコードベースを触ることの限界に直面しました。誰かの変更が全体のデプロイを止め、一部の機能のためにシステム全体を スケーリング しなければならない。その解決策として機能ごとにサービスを分割するマイクロサービスが提唱され、ブームになります。このとき比較対象として「モノリス」という呼び名が広まり、一時は「遅れた設計」の代名詞のように否定的に扱われました。しかしその後、分散化の複雑さに苦しむ事例が積み重なり、「小さなチームにはモノリスのほうが合理的」という揺り戻しが起きます。現在では、モノリスは克服すべき過去ではなく、明確な利点を持つ選択肢のひとつとして再評価されています。
詳細
単純さがもたらす具体的な強さ
モノリスの利点は、開発のあらゆる工程が単純になることです。機能をまたぐ処理は関数呼び出しで書け、ネットワーク越しの通信のような失敗を考えなくて済みます。複数のテーブルにまたがる更新も、ひとつのデータベースの トランザクション で確実に整合させられます。デバッグではスタックトレースが処理の全体を教えてくれ、開発環境はアプリをひとつ起動すれば整い、テスト も全体を通しで実行できます。デプロイはひとつの成果物を配置するだけです。この「認知しやすさ」は、人数の少ないチームでは決定的な生産性の差になります。
マイクロサービス と構成を並べると、この単純さの正体が見えます。モノリスではデプロイの単位もデータベースもひとつですが、分割した途端、機能間の連携はすべてネットワーク越しになります。
モノリスでもスケールはできる
「モノリスはスケールしない」というのは誤解です。同じアプリケーションを複数台に複製し、ロードバランサ で分散すれば水平 スケーリング は成立します。制約は粒度にあります。負荷が高いのが検索機能だけでも、アプリ全体を複製するしかなく、機能単位での増強はできません。とはいえ実際には、この粒度の粗さが問題になる規模のサービスは多くありません。
本当の敵は「密結合」
モノリスが破綻するとき、原因はモノリスであること自体ではなく、内部の構造の崩壊です。機能間の境界が曖昧になり、どこを触っても別のどこかが壊れる「泥団子（big ball of mud）」化。これはコードベースが単一かどうかとは別の問題で、内部をモジュールとして規律正しく分割した「モジュラーモノリス」という設計が、その対策として注目されています。モジュール間の依存を明示的な API（インターフェース）に限定し、デプロイ単位はひとつのまま、コードの境界だけをサービス分割並みに厳格に保つ、という考え方です。
限界のサインと移行の定石
モノリスの限界が近いサインは、技術よりも組織に現れます。チームが増えてデプロイの調整が会議になる、リリース頻度が落ちる、ビルドとテストに時間がかかりすぎる——こうした痛みが出た段階で、痛んでいる境界からサービスを切り出すのが現代の定石です。Martin Fowler の「MonolithFirst（まずモノリスで作れ）」という指針が有名で、最初からマイクロサービスで始めた場合、まだ正しい境界が分からないうちに分割してしまい、後から境界を引き直す羽目になりがちだと指摘されています。業務の境界は、動くモノリスを運用して初めて見えてくるものだからです。
実務での位置づけ
新規プロダクト、少人数のチーム、要件がまだ流動的なドメインでは、モノリスがほぼ常に正解です。逆に、数十チームが独立に動く必要のある大組織や、機能ごとに負荷特性・技術要件が極端に異なるシステムでは、分割の複雑さを支払う価値が出てきます。「モノリスかマイクロサービスか」は技術の優劣ではなく、組織の規模と成熟度に対する適合の問題である——これがこの語彙を実務で使うときの核心です。