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

ヒント

このコンテンツは eBook の「コンテナー化された .NET アプリケーションの .NET マイクロサービス アーキテクチャ」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。

PDF のダウンロード

モノリシックに展開された単一の Web アプリケーションまたはサービスを構築し、それをコンテナーとして展開することができます。 アプリケーション自体は内部的にはモノリシックではありませんが、複数のライブラリ、コンポーネント、さらにはレイヤー (アプリケーション レイヤー、ドメイン レイヤー、データアクセス レイヤーなど) として構成される場合があります。 しかし、外部的には単一のコンテナーです。つまり、単一のプロセス、単一の Web アプリケーション、または単一のサービスです。

このモデルを管理するには、アプリケーションを表す単一のコンテナーを展開します。 容量を増やすには、スケールアウトします。つまり、手前のロード バランサーを使ってさらにコピーを追加するだけです。 単一のコンテナーまたは VM で単一の展開を管理することで、このように簡単になります。

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

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

このアプローチの欠点は、アプリケーションが大きくなり、スケーリングする必要が出てきた場合に顕著になります。 アプリケーション全体をスケーリングすることができれば、実際には問題ではありません。 ただし、ほとんどの場合、スケーリングする必要があるネックはアプリケーションのごく一部であり、他のコンポーネントはそれほど使用されません。

たとえば、一般的な e コマース アプリケーションでは、製品を購入する顧客よりも製品を閲覧する顧客の方が多いため、製品情報サブシステムをスケーリングする必要性が高くなります。 より多くの顧客が、支払いパイプラインではなくバスケットを使用します。 コメントを追加したり、購入履歴を表示したりする顧客はそれほどいません。 また、コンテンツとマーケティング キャンペーンを管理する必要がある従業員数はほんの一握りだとします。 モノリシック設計をスケーリングする場合、このようなさまざまなタスクのすべてのコードは同じグレードで複数回展開され、拡張されます。

アプリケーションをスケーリングするには、水平方向の複製、アプリケーションのさまざまな領域の分割、類似したビジネス コンセプトやデータの分割など、複数の方法があります。 ただし、すべてのコンポーネントをスケーリングする問題に加えて、単一のコンポーネントを変更するには、アプリケーション全体を完全に再テストし、すべてのインスタンスを完全に再展開する必要があります。

ただし、モノリシック アプローチは一般的です。なぜなら、初期段階ではアプリケーションの開発はマイクロサービス アプローチよりも簡単だからです。 したがって、多くの組織はこのアーキテクチャ アプローチを使用して開発しています。 十分に良い結果が得られる組織もあれば、限界に達する組織もあります。 多くの組織は、このモデルを使用してアプリケーションを設計していました。これは、何年も前にはツールとインフラストラクチャによってサービス指向アーキテクチャ (SOA) の構築が非常に困難だったためと、アプリケーションが大きくなるまで SOA の必要性がわからなかったためです。

インフラストラクチャの観点から説明すると、図 4-2 に示すように、各サーバーは同じホスト内で多数のアプリケーションを実行可能であり、リソース使用量の許容される効率があります。

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

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

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

図 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 などの他のサービスに切り替えて、詳細な制御を行い、ご利用のアプリケーションに必要なコンポーネントやフレームワークをインストールする必要がありました。

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

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

前へ次へ