モノリスとは

モノリスとは

システムの全機能を1本のプログラムとして開発し、一括で稼働させ、一括でリリースする作り方です。
受注、在庫、請求といった業務の機能が同じプログラムの中にあり、通常は1つのデータベースを共有します。
対になるのは機能ごとに独立したサービスへ分割するマイクロサービスです。

章ごとに区分して1冊に綴じた社内規程集と似ています。
必要な章だけ開けば読めますが、改訂版は1冊まるごと刷り直して配布します。
章をまたいで条文が互いを参照し合うようになると、1条を改訂するたびに、全条文への影響を確認することになります。

語としては構成の形を指すだけで良し悪しを含みません。
ただ開発会社との打ち合わせでは、旧来の改修しにくいシステムを指す否定的な意味で使われることが多いです。
1つのプログラムとして一括でリリースする点は変えずに、中を業務単位のモジュールに区切る構成もあります。
モジュール同士は公開した呼び出し口だけを通してやり取りし、データも担当するモジュールしか直接書き換えません。
この構成はモジュラーモノリスと呼ばれます。
リリースの単位が1つなので、これもモノリスの一種になります。

システムを複数のサービスに分割すると、サービス同士の通信、分散したデータの整合、障害が発生したサービスを特定する監視といった仕事が新たに発生します。
モノリスはこれらが不要な最も単純な形で、初期構築と運用の費用が小さいです。
機能をまたぐ変更も1回の修正とリリースで完了し、障害の発生時に調査する対象も1つのプログラムに限定されます。
データが1つのデータベースにあるので、分析基盤へデータを取り込むときの取得元も1か所になります。
少人数でも全体を把握でき、保守を担う人を確保しやすいです。

分割の負担に見合うのは開発チームが多く、チームごとに独立してリリースしたい会社だけです。
この見方は広く共有されています。
分割した構成を1つにまとめ直した例もあります。
Amazonの動画配信Prime Videoのチームは、配信映像の品質を監視するサービス1つについて、サーバーレスのサービスを組み合わせた分散構成を1つのプログラムにまとめ直しました。
これにより、当該サービスのインフラ費を約9割削減したと2023年に公表しました。

中を区切った状態を維持する

業務の区切りが保たれている状態の例は、請求の機能が在庫のデータを直接書き換えず、在庫の機能に変更を依頼する作りです。
区切りが守られていれば、在庫の担当は請求側を気にせず在庫の中身を修正でき、1か所の修正で離れた業務に不具合が発生することも少ないです。
担当範囲が区切りごとに確定し、新たに加わった人が覚える範囲も限定されます。

区切りの維持は大きな会社でも困難です。
EC（Electronic Commerce）プラットフォームのShopifyは、大きなモノリスを業務単位に区切り直す取り組みの途中経過を2020年に公表しています。
区切りを引いた後も区切り同士が中身を直接参照し合う箇所が多く残存しました。
そこで区切りを越える参照を変更のたびに自動で検出して阻止する仕組みを自社で開発しました。
公表の時点でこの仕組みを適用できていたのは、37の区切りのうち約3分の1でした。

一部をいずれ再構築する前提で開発するのも合理的な選択になります。
再構築を前提とした設計でも区切りが保たれていれば、全体でなく区切り単位で入れ替えられます。

モノリスの弱み

障害が業務をまたいで広がる

同じプログラムを複数のサーバーで稼働させておけば、1台が停止しても残りの台で処理を継続できます。
ただ全台が同じプログラムを稼働させているため、ある機能の不具合や不備のあるリリースは全台に同時に及びます。
請求の機能の不具合で受注の画面まで停止する、といった形で影響が業務をまたぎます。
全機能が1つのデータベースに依存しているので、データベースが停止すればシステム全体が停止します。

サーバーを増やしてもデータベースが先に詰まる

アクセスが増加したとき、サーバーの台数を追加して対応できるのは、ログイン状態や入力途中のデータを個々のサーバーで保有しない作りの場合に限ります。
台数を追加できても全台が同じデータベースを利用するため、先に詰まるのはたいていデータベースになります。
一部の機能だけに負荷が集中しても、増やすのは全体を稼働させるサーバーになります。

区切りは放っておくと崩れる

納期に追われると別の業務のデータを直接書き換える近道を選ぶ場面が繰り返し発生します。
そうした箇所が積み重なると、1か所の修正が思わぬ場所に不具合を起こすようになり、修正のたびに確認する範囲が拡大します。
区切りを保つには設計の決まりを守らせる担当者が必要になり、その人件費は導入後も継続します。

言語や外部の構成要素といったプログラムの基盤も、全体で一括して更新することになります。
手間がかかるため先送りされやすく、先送りが続くとサポートの終了した構成要素を利用し続ける状態になります。

崩れは少しずつ進行するので、次のような変化で察知します。
テストとリリースにかかる時間が以前より延びている、修正が他の業務の機能に不具合を起こす障害が増えている、施策がリリースの順番待ちで予定より遅れている、といった状態です。
こうした変化があれば区切りが崩れ始めています。

よくある誤解

モノリスは旧来の作り方でレガシーシステムと同じ意味

モノリスは構成の形を指す語で、新旧を意味しません。
新規に開発するシステムでも規模やチーム数に見合えばモノリスが選ばれます。
レガシーシステムは変更が困難になり事業の足かせになった状態を指します。
レガシーシステムにモノリスが多いのは、長く利用されてきたシステムの多くがこの形で構築されたためです。

モノリスでは複数のチームで分担して開発できない

区切りごとに担当チームを決定すれば、1つのプログラムでも分担できます。
前述のShopifyでは2020年の時点で数百人の開発者が同じモノリスで開発していました。