モノリスとは？

「モノリス」(monolith) とは、主に2つの文脈で使用される用語です。以下にそれぞれの意味を解説します。

1. 一般的な意味

「モノリス」は一般的に「一枚岩」や「一体化した大きな物体」を指します。特に建築や彫刻、または自然に形成された巨大な岩石を表す際に使用されます。例えば、イースター島のモアイ像やユタ州のモノリス事件などがその例です。

2. ソフトウェア開発における意味

ソフトウェア開発における「モノリス」とは、すべての機能やコンポーネントが一体化したシステムアーキテクチャを指します。この形態は、アプリケーションの全ての機能を単一のプロジェクトやコードベースに集約して実装することを特徴としています。

モノリシックアーキテクチャは、開発が容易で、リソースの管理がシンプルという利点があります。しかし、アプリケーションが大きくなるにつれて、変更の影響範囲が広くなり、デプロイやスケールアップが困難になることがあります。

この記事ではソフトウェア開発におけるモノリスについて解説していきます。

アプリケーションの開発に当たっては、マイクロサービスとモノリスの選択肢を検討する必要があります。ユースケースにどちらのコンセプトが適しているかがわかれば、コーディングの計画やプロジェクトの調整もしやすくなります。

この記事では、モノリスとマイクロサービスの主な違いを踏まえて、マイクロサービスアプローチに期待できる内容とモノリシックアプリケーションの可能性をご紹介します。

マイクロサービスとモノリシックサービスの比較

モノリシックサービスはオールインワンのアプリケーションを指すのに対し、マイクロサービスは一元化された方法で一緒に機能するスタンドアロンのアプリケーションを指します。

• モノリシック : 多くのサービス機能を持つ1つのユニットとして構築されたソフトウェア

• マイクロサービス : 一緒に機能する複数のアプリケーション

かつてはモノリシックなサービスの人気が高く、モノリシックの場合には、商品選択のカルーセル表示から購入完了後の決済カートでのクレジットカード請求まで、開発者や開発チームがeコマースプラットフォームのコードを一度に書いてしまうようなこともできました。これに対し、マイクロサービスは、ウェブサイトを独立した機能を持つサービスに分割し、これらサービスをまとめたものです。どちらの戦略でも似たような目標を達成するシステムを設計することができますが、それぞれのアプローチに明確な長所と短所があります。

モノリスとマイクロサービスのアプローチの主な違い

モノリシックアプリケーションとマイクロサービスアプリケーションはそれぞれ構築方法が異なるため、機能にも違いがあり、アプローチがソフトウェア全体の目標達成に役立つ方法も異なります。今日では、柔軟性と適応性の高いマイクロサービスの人気が高まっていますが、ユースケースによってはモノリシックソフトウェアの方が適切な場合もあり、開発チームの選択肢となる可能性も大いにあります。

こうした2つのアプローチの違いと採用すべきポイントを把握しておくことで、将来的なメンテナンスが楽になり、プロジェクト全体を効果的に計画することができます。

マイクロサービスアプローチの利点

マイクロサービスは個別に管理できるため、時間の経過と共にソフトウェアを拡張、メンテナンス、適応させていく上での柔軟性が高まり、信頼性の確保、追加リソースの投入、プロジェクトの簡素化などがしやすくなります。

• ソフトウェアの拡張 : ニーズの変化に応じてコンテナーを簡単にスケールアップできるため、ソフトウェアに対する需要が供給能力を超える心配がありません。サービスを個別に拡張することもでき、システムを適宜カスタマイズすることができます。

• リソースの管理 : リソースの使用が明確に定義されており、各マイクロサービスにのみ関連するため、リソースの使用状況が明確になります。

• デプロイの簡素化 : 基本的に各サービスを単体でデプロイするため、デプロイの複雑さを削減できます。

• メンバーが個別のサービスに注力可能 : チーム内でマイクロサービスを分担することで、メンバーが各自の領域に集中することができます。

• 信頼性の向上 : 1つのノードが故障してもシステム全体がダウンすることはなく、高い信頼性が求められる場合には大きなメリットとなります。

マイクロサービスアプローチの欠点

マイクロサービスを導入する際には、プロセス間の点をつなぎ合わせ、プロセスごとに異なるデータベース間の点を線にするため、複数のプロセスが使用するデータを個別に管理し、必要とするプロセスにうまく転送する必要があります。

• プロセス間の調整 : マイクロサービスでは、プロセスの調整を慎重に検討する必要があります。個別に開発されたものを含め、すべてのプロセスを連動させなければなりません。モノリシックアプリケーションの場合には、こうしたプロセスを始めから一緒に開発します。

• サービスの変更が困難 : 複数のマイクロサービスを変更・更新した場合、変更をロールアウトするのが難しくなることもあります。モノリスの場合には、1つのアプリケーションを変更するだけですべてのサービスに変更が反映されます。

• データベースが複数 : モノリスでは単一のデータベースを使用しますが、マイクロサービスではデータベースが複数で、管理対象も多くなります。マイクロサービスはすべて、個別のデータ管理が必要な独立したアプリケーションです。

マイクロサービスアプローチを使うべきタイミング

低レイテンシや運用上の間接費の低減よりも、回復力、信頼性や拡張性が重視されるユースケースの場合には、モノリスよりもマイクロサービスのアプローチが適しています。

また、マイクロサービスは、アプリケーション内の個々のサービスを時間をかけて大幅に変更したい場合にも適しています。こうした場合、モノリスでは、変更対象のサービスに直接関係ないコードも含め、既存のコードの大半を書き換えたり変更したりする必要が生じます。

マイクロサービスソフトウェアの例

• ライドシェアアプリ : 支払いを処理する請求マイクロサービス、請負ドライバーがやり取りするドライバー UI、乗客 UI に加え、移動の調整、ユーザーへの課金や通知の作成を行うマイクロサービスなどが含まれます。

• コンテンツストリーミングサービス : コンテンツ管理システムは、ユーザーが次に視聴する内容を予測する分析システムなどの他のサービスと相互作用します。お気に入りの番組の連続視聴にはバックエンドで数百ものマイクロサービスが関与していることもあります。

• E コマースサイト : 購入ボタン、消費税計算ツール、決済ゲートウェイや検索バーなどの個別のマイクロサービスが使われている可能性があり、世界最大級の EC サイトであれば、数百のサービスを使用しているかもしれません。

モノリシックアプローチの利点

モノリシックシステムの利点は分かりやすさにあります。コードが一か所にまとまっているので考慮すべき要素の数が少なくて済み、複数のシステムを調整することなく、1つのアプリケーションでさまざまな機能を管理することができます。こうした利点から、場合によっては人気のマイクロサービスよりも従来型のモノリシックソフトウェアが適していることもあります。

• ネットワークコールの不在 : モノリシックソフトウェアではマイクロサービス間のようなネットワークコールを待つ必要がないため、技術面ではマイクロサービスソフトウェアよりも迅速に配信でき、モノリシックアプリケーション内での遅延が全体的に減少します。

• 単一のコードベース : 作成、管理や維持対象のコードベースが1つしかないため、複数のアプリケーションの管理より手軽な場合もあります。

• テストの合理化 : デプロイ前に多数のアプリケーションをテストする必要がなく、1つのソフトウェアを対象に性能などの基準をテストすれば十分です。

モノリシックアプローチの欠点

モノリスの設計は単純なため、アプリケーションの拡張、変更や管理などの面で柔軟性が低くなります。アップデートのたびに新たなデプロイからやり直す必要があり、定期的に作業が発生することになります。

不具合が発生するとアプリケーションの停止につながりかねないため、新しい変更を加える際には細心の注意を払う必要があり、アップデートの際にはリソースと時間を追加投入する覚悟が求められます。

モノリスアプローチを使うべきタイミング

アプリケーション開発初期や、非常に単純なアプリケーションを開発している場合、ソフトウェアを迅速に立ち上げたい場合には、モノリスが候補に上がります。

また、将来的に高度なスケーリングが不要と分かっているプロジェクトでは、モノリシックアーキテクチャを使い続けることでニーズを充足することができます。

モノリスソフトウェアの例

• 概念実証やプロトタイプ用アプリケーション : 製品の初回発売に先立って概念を実証する小規模なアプリケーション

• 社内用プロジェクト : 社内ユーザーが組織内で利用するシステム

• 従来型のウェブサイトプラットフォーム : 小規模市場向けに設計された新しいオンラインアプリケーション (後にマイクロサービスアーキテクチャへのリファクタリング計画がある場合もあり)

ソフトウェア開発に対する組織としてのアプローチ

モノリスアプローチとマイクロサービスアプローチのどちらを選択するかは、組織としての IT や DevOps に対する考え方と今後のアプリケーションの計画により大きく異なります。開発に着手する際には、プロジェクトの要件、ステークホルダーの意見やプロジェクト全体の計画を必ず考慮に入れるようにしましょう。