モノリシック アプリケーションとは何か

モノリシック アプリケーションは、複数の機能のユーザー インターフェイスとデータ アクセス レイヤを1つのアプリケーションに統合します。通常、モノリシック アプリケーションは、組織内の複数のチームによって変更される単一のコードベースとして存在し、それらのチームが管理するすべての機能を含む単一のユニットとしてデプロイされます。

モノリシック アプリケーションは、コンポーネントが密結合されているため、多くの場合でより簡単に開発および導入できます。ただし、アプリケーションの範囲とパフォーマンスの需要が増えると、モノリスの保守と拡張が困難になる可能性があります。

モノリシック アプリケーション アーキテクチャの例

モノリシック システムは、迅速に拡張したり、定期的に保守したりする必要のない、小規模で複雑性の低いアプリケーションに適しています。以下に、一般的にモノリシックな基盤を持つアプリケーションの例を示します(ただし、新しい機能は、よりコンテナ化されたインフラストラクチャに基づいている場合があります)。

  • eコマース プラットフォーム – モノリシック アプリケーションは、eコマースでよく見られます。これは、インフラストラクチャ(オンライン ストアの構築、注文処理、決済処理、顧客サービス)がセットアップされると、アーキテクチャの更新がほとんど必要なくなるためです。
  • コンテンツ管理システム(CMS) – この用語集エントリは、モノリシック アプリケーション(WordPress)によって実現されました。導入すると、CMSアプリケーションにはWebページの形式でコンテンツ管理に必要なすべての機能が含まれます。
  • バンキング システム – 多くの金融システムは、エントリ ポイントが制限されているため、モノリシック アプリケーションとして構築され、セキュリティが強化されています。さらに、導入すると、コードベースには、金融取引の管理、支払い処理、追跡など、消費者がオンライン バンキング エクスペリエンスに期待するすべての機能が含まれます。
モノリシック アーキテクチャのメリット

モノリシック アーキテクチャの一部分は時代遅れになってきてますが、依然として多くの用途と長所があります。

モノリスのメリットは次のとおりです。

  • シンプルさ – 一元化されたアーキテクチャにより、マイクロサービス アーキテクチャなどのより複雑なアーキテクチャと比較して、モノリスの開発、導入、保守が容易になります。
  • 迅速なテスト - すべてのコンポーネントを1つのプログラムに統合することで、モノリシック アプリケーション全体を迅速にテストできます。複数の小さなコンポーネント(マイクロサービスなど)で構成されるアーキテクチャとは異なり、複雑な通信プロトコルや複数のコード リポジトリに対する追加のテストは不要です。
  • セキュリティ – 攻撃者が侵入するポイントが少ないため、モノリスは一般的にセキュリティ保護しやすくなっています。また、複数のセキュリティ構成を管理するよりも、1つのアプリケーション全体にセキュリティ プロトコルを適用する方が簡単です。
  • コスト - モノリスは単一のユニットとして導入されるため、追加の通信プロトコルの導入と保護、より接続性の高いインフラストラクチャの構築、より専門的なスキルを持ちトレーニングを受けている従業員の雇用に関連する余分なコストが削減されます。
モノリシック アーキテクチャのデメリット

モノリスの特異的性質にはメリットがありますが、問題を引き起こす可能性もあります。

モノリスのデメリットは次のとおりです。

  • 複雑さの増大 – 時間の経過とともに、アプリケーションの成長と機能の追加により、モノリシック アーキテクチャはより大きく複雑になる可能性があります。この無秩序な増加により、プログラム全体をスムーズに実行し続ける単一のコードベースが更新によって危険にさらされるリスクが増大します。
  • 拡張性の欠如 – アプリケーションの1つの機能または領域を水平方向に拡張する必要がある場合、大規模なアプリケーション全体(追加のリソースを必要としないサブシステムを含む)を拡張する必要があります。これにより、導入に時間がかかるために拡張が遅くなるだけでなく、マイクロサービスと比較して、各インスタンスの実行に対するハードウェア要件が多くなるためコストが増加する可能性があります。
  • レジリエンス – モノリシック アーキテクチャでは、すべてのアプリケーション コンポーネントが緊密にリンクされ、中央のコードベースから実行されます。そのため、1つのコンポーネントに障害が発生すると、アプリケーション全体がダウンする可能性があります。
  • 完全な再導入 – 単一のコードベースでアプリケーション全体を表しているモノリスでは、1つのコンポーネントを変更または更新するたびに完全な再導入を行う必要があります。
  • テクノロジ スタック – 開発者は使用するツールや言語がモノリスに適合することを確認する必要があるため、選択肢が制限されます。また、多くのモノリシック アプリケーションの記述方法は、クラウド コンピューティングやコンテナ化などの新しい、より効率的なテクノロジと完全な互換性があるわけではありません。
  • 開発の遅延 – 複数の開発チームが1つの大規模なコードベースで作業している場合、インターフェイスとドメインの境界が考慮され、維持されるように細心の注意を払う必要があります。コードによって複雑な結合が生じ、チーム間の依存関係によって新機能の開発や重大な問題の修正に遅れが生じる場合があります。
マイクロサービス アーキテクチャとは何か

モノリシック アーキテクチャとは対照的に、マイクロサービス アーキテクチャがあります。マイクロサービスは、大規模で複雑なアプリケーションを小さなコンポーネントから構築するソフトウェア アーキテクチャに対するアプローチです。これらのコンポーネントはそれぞれ単一の機能(認証、通知、決済処理など)を実行したり、モノリス内でバンドルとして機能したりできます。「マイクロサービス」(または単に「サービス」)は、小さなコンポーネント自体を指す用語でもあります。

モノリシック アプリケーションは密結合(つまり、コンポーネントが相互接続)されていますが、マイクロサービス アプリケーションは分散しています(つまり、コンポーネントが独立して動作できる)。アプリケーションが大きくなり複雑になるにつれて、多くの組織がモノリスからの移行、またはマイクロサービス形式での新しいアプリケーションの組み込みを検討しています。

NGINXは、モノリシックおよびマイクロサービスを検討しているお客様のために、以下に示す無料の教育リソースを提供しています。