モノリス ものりす
簡単に言うとこんな感じ！
全部入りの巨大な一体型アプリのことだよ！受付・在庫管理・決済・通知がぜんぶ1つのプログラムにまとまってる状態。小さいうちは便利だけど、大きくなるとどこか直すだけでも全体に影響が出て大変になるんだ！
モノリスとは
モノリス（Monolith） とは、アプリケーションのすべての機能が1つの大きなプログラムとして一体化して動作するソフトウェアアーキテクチャ（設計方針）のことです。ユーザー画面の表示・業務ロジックの処理・データベースへのアクセスが、すべて単一のコードベースにまとまっています。
小規模なうちはシンプルで開発しやすく、特別な工夫なしに動かせるのが強みです。しかし規模が大きくなるにつれて、「一部を修正したら別の機能が壊れた」「アクセスが増えてもシステム全体を丸ごと増強しないといけない」といった課題が出やすくなります。
近年は マイクロサービス（機能を小さな部品に分割する設計）と対比される概念として語られることが多く、「モノリスは古い・悪い」というイメージを持つ人もいますが、実際には小〜中規模のシステムでは今も合理的な選択肢です。
モノリスの構造と特徴
モノリスは通常、以下の3層がひとかたまりになって動作します。
| 層 | 役割 | 例 |
|---|---|---|
| プレゼンテーション層 | 画面表示・ユーザー操作の受付 | HTML生成、APIエンドポイント |
| ビジネスロジック層 | 業務処理・計算・ルール適用 | 在庫計算、割引判定 |
| データアクセス層 | DBへの読み書き | SQL発行、ORマッパー |
これら3層が1つのアプリケーションとして まとめてビルド・デプロイ（リリース） されます。
「一枚岩」で覚えよう
モノリス（Monolith）は英語で「一枚岩」という意味です。ギリシャ語の monos（ひとつ）＋ lithos（石）が語源。まさにシステム全体が一枚岩のように一体化しているイメージです。
モノリスのメリット・デメリット
| 観点 | メリット | デメリット |
|---|---|---|
| 開発 | 環境構築がシンプル・IDE連携が容易 | コードが肥大化すると把握困難に |
| デプロイ | 1回の操作で全機能をリリースできる | 小さな修正でも全体を再デプロイ必要 |
| テスト | 統合テストが書きやすい | ビルド・テスト時間が長くなりがち |
| スケール | 構成が単純で管理しやすい | 部分的なスケールアップができない |
| 障害 | 原因調査の範囲が限定しやすい | 1箇所の不具合がシステム全体に波及 |
歴史と背景
- 1960〜1980年代：コンピュータ黎明期。ソフトウェアはそもそも全部入りで作るのが当然であり、「モノリス」という言葉自体も存在しなかった
- 1990年代：クライアント・サーバー型が普及し、画面と処理を分ける概念が登場。それでも業務アプリの大半は一体型で作られていた
- 2000年代前半：Webアプリの台頭。Ruby on Rails・Java EEなどのフレームワークで「1つのアプリに全部書く」スタイルが標準化
- 2011年頃：Netflixや Amazon がサービスを小さな部品（マイクロサービス）に分割し始め、対比としてこれまでの一体型が「モノリス」と呼ばれるようになる
- 2015年以降：Dockerやクラウドの普及でマイクロサービスが一気に広まり、「モノリス＝レガシー」という誤解も広がる
- 2020年代：「モジュラーモノリス」など、良いとこ取りのアプローチが再評価される流れに
モノリス vs マイクロサービス
モノリスの立ち位置を理解するには、マイクロサービスとの比較が最もわかりやすいです。
どちらを選ぶべきか？
| 状況 | 推奨 | 理由 |
|---|---|---|
| チームが小さい（〜10人） | モノリス | 調整コストが低く開発が速い |
| 要件が固まっていない | モノリス | 設計変更が柔軟にできる |
| 特定機能だけ負荷が高い | マイクロサービス | その機能だけスケールできる |
| チームが大きく独立開発したい | マイクロサービス | チームごとに担当範囲を分けられる |
モジュラーモノリスという第三の道
一体型のまま内部だけを機能ごとにきれいに分割する「モジュラーモノリス」も注目されています。マイクロサービスほど運用が複雑にならず、将来的に分割しやすい構造を保てる現実的な選択肢です。
関連する規格・RFC
※ モノリスはアーキテクチャの概念であり、IETFやISOによる公式規格は存在しないため、このセクションは省略します。