モノリシックアプリケーションとは
モノリシックアプリケーションは、複数の機能に対応するユーザーインターフェース層とデータアクセス層を1つのアプリケーションに統合したものです。通常、モノリシックアプリケーションは、組織内の複数のチームが変更を加える単一のコードベースとして存在し、各チームが保守するすべての機能を含む単一のユニットとしてデプロイされます。
モノリシックアプリケーションは、コンポーネントが緊密に統合されているため、開発やデプロイが容易な場合が少なくありません。しかし、アプリケーションの規模が拡大し、パフォーマンス要件が高まるにつれて、モノリスの保守やスケーリングが難しくなる可能性があります。
モノリシックアプリケーションアーキテクチャの例
モノリシックシステムは、迅速なスケーリングや定期的なメンテナンスを必要としない、小規模で複雑性の低いアプリケーションに適している場合があります。以下に、一般的にモノリシックな基盤を採用しているアプリケーションの例をいくつか示します(ただし、新しい機能は、よりコンテナ化されたインフラストラクチャを基盤としている場合があります)。
- Eコマースプラットフォーム – Eコマースでは、インフラストラクチャ(オンラインストアの構築、注文処理、決済処理、カスタマーサービス)を一度構築すれば、アーキテクチャの更新はほとんど必要ないため、モノリシックアプリケーションが一般的に採用されています。
- コンテンツ管理システム(CMS)– この用語集の項目も、モノリシックアプリケーション(WordPress)によって作成されています。CMSアプリケーションには、デプロイ時に、Webページ形式のコンテンツを管理するために必要なすべての機能が含まれています。
- 銀行システム – 多くの金融システムは、エントリーポイントが限られているため、セキュリティを確保しやすいモノリシックアプリケーションとして構築されています。また、デプロイ時点で、コードベースには、金融取引の管理、決済処理、追跡など、利用者がオンラインバンキングに期待するすべての機能が含まれています。
モノリシックアーキテクチャの利点
モノリシックアーキテクチャには時代遅れになった側面もありますが、今なお多くの用途と利点があります。
モノリスには、次のような利点があります。
- シンプルさ – 一元化されたアーキテクチャにより、モノリスは、より複雑なアーキテクチャ(マイクロサービスアーキテクチャなど)と比べて、開発、デプロイ、保守が容易です。
- テストの迅速化 – すべてのコンポーネントを1つのプログラムに統合することで、モノリシックアプリケーション全体を迅速にテストできます。複数の小規模なコンポーネントで構成されるアーキテクチャ(例:マイクロサービス)とは異なり、複雑な通信プロトコルや複数のコードリポジトリに伴う追加のテストは不要です。
- セキュリティ – 悪意のある攻撃者の侵入口が少ないため、一般にモノリシックアプリケーションはセキュリティを確保しやすくなります。また、複数のセキュリティ構成を管理する場合に比べ、単一のアプリケーション全体にセキュリティプロトコルを適用しやすいという利点もあります。
- コスト – モノリスは単一のユニットとしてデプロイされるため、追加の通信プロトコルのデプロイとセキュリティ確保、接続用インフラストラクチャの拡充、より専門的なスキルとトレーニングを備えた従業員の採用に伴う追加コストを削減できます。
モノリシックアーキテクチャのデメリット
モノリシックアーキテクチャは、単一構造であることが利点となる一方、問題を引き起こす場合もあります。
モノリスには、次のようなデメリットがあります。
- 複雑性の増大 – 時間の経過とともにアプリケーションが成長し、機能が追加されることで、モノリシックアーキテクチャは大規模かつ複雑になる可能性があります。このような肥大化により、プログラム全体の円滑な動作を支える単一のコードベースが、アップデートによって損なわれるリスクが高まります。
- スケーラビリティの欠如 – アプリケーションの特定の機能や領域を水平スケーリングする必要がある場合、追加のリソースを必要としないサブシステムも含め、大規模なアプリケーション全体をスケーリングしなければなりません。その結果、デプロイに時間がかかるためスケーリングが遅くなるほか、マイクロサービスと比べて各インスタンスの実行に必要なハードウェア要件が大きくなり、コストが増加する可能性があります。
- レジリエンス – モノリシックアーキテクチャでは、すべてのアプリケーションコンポーネントが密接に結合され、単一のコードベースで実行されます。そのため、1つのコンポーネントに障害が発生すると、アプリケーション全体が停止する可能性があります。
- 全面的な再デプロイ – アプリケーション全体が単一のコードベースで構成されるモノリシックアーキテクチャでは、1つのコンポーネントを変更または更新するたびに、全面的な再デプロイが必要です。
- テクノロジースタック – 使用するツールや言語がモノリスに適合することを開発者が確認する必要があるため、選択肢が限られます。また、多くのモノリシックアプリケーションは、クラウドコンピューティングやコンテナ化など、より新しく効率的なテクノロジーとの完全な互換性がない形で記述されています。
- 開発速度の低下 – 複数の開発チームが1つの大規模なコードベースで作業する場合、インターフェースとドメイン境界を尊重し、維持するために細心の注意が必要です。コードによって複雑な結合が生じ、チーム間の依存関係が原因で、新機能の開発や重大な問題の修正が遅れることもあります。
マイクロサービスアーキテクチャとは
モノリシックアーキテクチャとは対照的なものとして、マイクロサービスアーキテクチャがあります。マイクロサービスとは、小さなコンポーネントを組み合わせて大規模で複雑なアプリケーションを構築するソフトウェアアーキテクチャのアプローチです。各コンポーネントは、認証、通知、決済処理などの単一機能を実行することも、モノリス内で複数をまとめて動作させることもできます。「マイクロサービス」(単に「サービス」とも呼ばれます)は、こうした小さなコンポーネント自体を指す用語でもあります。
モノリシックアプリは密結合(コンポーネント同士が相互に接続されている状態)であるのに対し、マイクロサービスアプリは分散型(各コンポーネントが独立して動作できる状態)です。アプリケーションの大規模化と複雑化に伴い、多くの組織がモノリスからの移行や、新しいアプリへのマイクロサービス形式の採用を検討しています。
NGINXでは、モノリシックアーキテクチャとマイクロサービスについて検討されている方に向けて、以下の無料学習リソースをご用意しています

