モノリシック アプリケーションのコンテナー化

モノリシックにデプロイされた単一の Web アプリケーションまたはサービスを構築し、コンテナーとしてデプロイすることができます。 アプリケーション自体は内部的にはモノリシックではなく、複数のライブラリ、コンポーネント、またはレイヤー (アプリケーション層、ドメイン層、データ アクセス層など) として構造化されている可能性があります。 ただし、外部的には、1 つのコンテナー (1 つのプロセス、1 つの Web アプリケーション、または 1 つのサービス) です。

このモデルを管理するには、アプリケーションを表す 1 つのコンテナーをデプロイします。 容量を増やすには、スケールアウトします。つまり、コピーを追加し、その前にロードバランサーを配置するだけで済みます。 簡単な方法は、1 つのコンテナーまたは VM で 1 つのデプロイを管理することです。

図 4-1 コンテナー化されたモノリシック アプリケーションのアーキテクチャの例

図 4-1 に示すように、各コンテナーに複数のコンポーネント、ライブラリ、または内部レイヤーを含めることができます。 モノリシック コンテナー化されたアプリケーションは、内部レイヤーまたはライブラリを含む 1 つのコンテナー内にその機能の大部分を備え、複数のサーバー/VM 上でコンテナーを複製することによってスケールアウトします。 ただし、このモノリシック パターンは、コンテナーの原則 "コンテナーは 1 つの処理を行い、1 つのプロセスで実行する" と競合する可能性がありますが、場合によっては問題ありません。

このアプローチの欠点は、アプリケーションが拡大し、スケーリングが必要な場合に明らかになります。 アプリケーション全体をスケーリングできる場合は、実際には問題になりません。 ただし、ほとんどの場合、アプリケーションのごく一部だけがスケーリングを必要とするチョーク ポイントですが、他のコンポーネントの使用は少なくなります。

たとえば、一般的な e コマース アプリケーションでは、多くの顧客が製品を購入するよりも多くの顧客が製品を参照するため、製品情報サブシステムをスケーリングする必要があります。 支払いパイプラインを使用するよりも多くの顧客がバスケットを使用しています。 コメントを追加したり、購入履歴を表示したりする顧客が少なくなります。 また、コンテンツとマーケティング キャンペーンを管理する必要がある従業員はほんの一部である可能性があります。 モノリシック 設計をスケーリングすると、これらの異なるタスクのすべてのコードが複数回デプロイされ、同じグレードでスケーリングされます。

アプリケーションの水平方向の重複をスケーリングし、アプリケーションのさまざまな領域を分割し、同様のビジネス概念またはデータをパーティション分割する方法は複数あります。 ただし、すべてのコンポーネントのスケーリングの問題に加えて、1 つのコンポーネントに対する変更には、アプリケーション全体の完全な再テストと、すべてのインスタンスの完全な再デプロイが必要です。

ただし、モノリシック アプローチは一般的です。アプリケーションの開発は、最初はマイクロサービス アプローチよりも簡単であるためです。 したがって、多くの組織は、このアーキテクチャ アプローチを使用して開発します。 十分な結果を得ている組織もあれば、制限に達している組織もあります。 多くの組織では、このモデルを使用してアプリケーションを設計しました。これは、ツールとインフラストラクチャが何年も前にサービス指向アーキテクチャ (SOA) を構築するのが難しすぎて、アプリケーションが成長するまでニーズが見られなかったためです。

インフラストラクチャの観点から見ると、図 4-2 に示すように、各サーバーは同じホスト内で多数のアプリケーションを実行でき、リソースの使用効率に許容できる比率を持ちます。

図 4-2 モノリシック アプローチ: 複数のアプリを実行するホスト(各アプリがコンテナーとして実行されている)

Microsoft Azure のモノリシック アプリケーションは、インスタンスごとに専用 VM を使用してデプロイできます。 さらに、 Azure 仮想マシン スケール セットを使用すると、VM を簡単にスケーリングできます。 Azure App Service では、モノリシック アプリケーションを実行し、VM の管理を必要とせずにインスタンスを簡単にスケーリングすることもできます。 2016 年以降、Azure App Services では Docker コンテナーの単一インスタンスも実行できるため、デプロイが簡単になります。

QA 環境または限られた運用環境では、図 4-3 に示すように、複数の Docker ホスト VM をデプロイし、Azure バランサーを使用してバランスを取ることができます。 これにより、アプリケーション全体が 1 つのコンテナー内に存在するため、粒度の粗いアプローチでスケーリングを管理できます。

図 4-3 1 つのコンテナー アプリケーションをスケールアップする複数のホストの例

さまざまなホストへのデプロイは、従来のデプロイ手法を使用して管理できます。 Docker ホストは、 docker run などのコマンドや、手動で実行 docker-compose 、または継続的デリバリー (CD) パイプラインなどの自動化を使用して管理できます。

モノリシック アプリケーションをコンテナーとしてデプロイする

コンテナーを使用してモノリシック アプリケーションのデプロイを管理する利点があります。 コンテナー インスタンスのスケーリングは、追加の VM をデプロイするよりもはるかに高速で簡単です。 仮想マシン スケール セットを使用する場合でも、VM の起動には時間がかかります。 コンテナーではなく従来のアプリケーション インスタンスとしてデプロイする場合、アプリケーションの構成は VM の一部として管理されます。これは理想的ではありません。

Docker イメージとして更新プログラムをデプロイすると、はるかに高速でネットワーク効率が向上します。 Docker イメージは通常、数秒で開始され、ロールアウトが高速化されます。 Docker イメージ インスタンスの破棄は、 docker stop コマンドを発行するのと同じくらい簡単で、通常は 1 秒未満で完了します。

コンテナーは設計上不変であるため、破損した VM について心配する必要はありません。 これに対し、VM の更新スクリプトでは、ディスク上に残されている特定の構成またはファイルを考慮し忘れる場合があります。

モノリシック アプリケーションは Docker の恩恵を受けることができますが、利点に触れるだけです。 コンテナーを管理するその他の利点は、コンテナー オーケストレーターを使用してデプロイすることで、各コンテナー インスタンスのさまざまなインスタンスとライフサイクルを管理することです。 モノリシック アプリケーションを個別にスケーリング、開発、デプロイできるサブシステムに分割することは、マイクロサービスの領域へのエントリ ポイントです。

単一コンテナー ベースのアプリケーションを Azure App Service に発行する

Azure にデプロイされたコンテナーの検証を取得する場合でも、アプリケーションが単一コンテナー アプリケーションの場合でも、Azure App Service はスケーラブルな単一コンテナー ベースのサービスを提供する優れた方法を提供します。 Azure App Service の使用は簡単です。 Git と優れた統合が提供されるため、コードを簡単に取得し、Visual Studio でビルドし、Azure に直接デプロイできます。

図 4-4. Visual Studio 2022 から Azure App Service への単一コンテナー アプリケーションの発行

Docker を使用しない場合、Azure App Service でサポートされていない他の機能、フレームワーク、または依存関係が必要な場合は、Azure チームが App Service の依存関係を更新するまで待つ必要がありました。 または、Azure Cloud Services や VM などの他のサービスに切り替える必要がありました。ここで、さらに制御を行い、アプリケーションに必要なコンポーネントまたはフレームワークをインストールすることもできます。

図 4-4 に示すように、Visual Studio 2017 以降でのコンテナーのサポートにより、アプリケーション環境に必要なものを含めることができます。 コンテナーで実行しているため、アプリケーションに依存関係を追加する場合は、Dockerfile または Docker イメージに依存関係を含めることができます。

図 4-4 にも示すように、発行フローはコンテナー レジストリを介してイメージをプッシュします。 これは、Azure Container Registry (Azure でのデプロイに近く、Azure Active Directory のグループとアカウントによって保護されたレジストリ)、または Docker Hub やオンプレミス レジストリなどの他の Docker レジストリです。