コンテナーとマイクロサービス ベースのアプリケーションの設計

マイクロサービスには大きな利点がありますが、大きな新しい課題も発生します。 マイクロサービス ベースのアプリケーションを作成する際、マイクロサービス アーキテクチャ パターンは基本的な柱です。

このガイドの前半では、コンテナーと Docker に関する基本的な概念について学習しました。 この情報は、コンテナーの使用を開始するために必要な最小限の情報でした。 コンテナーはマイクロサービスの有効化機能であり、マイクロサービスに最適ですが、マイクロサービス アーキテクチャでは必須ではありません。 このアーキテクチャ セクションのアーキテクチャの概念の多くは、コンテナーなしで適用できます。 ただし、このガイドでは、コンテナーの重要性が既に導入されているため、両方の共通点に焦点を当てています。

エンタープライズ アプリケーションは複雑な場合があり、多くの場合、1 つのサービス ベースのアプリケーションではなく、複数のサービスで構成されます。 このような場合は、マイクロサービスや特定の Domain-Driven Design (DDD) パターン、コンテナー オーケストレーションの概念など、他のアーキテクチャアプローチを理解する必要があります。 この章では、コンテナー上のマイクロサービスだけでなく、コンテナー化されたアプリケーションについても説明します。

コンテナー設計の原則

コンテナー モデルでは、コンテナー イメージ インスタンスは 1 つのプロセスを表します。 コンテナー イメージをプロセス境界として定義することで、プロセスのスケーリングやバッチ処理に使用できるプリミティブを作成できます。

コンテナー イメージを設計すると、Dockerfile に ENTRYPOINT 定義が表示されます。 この定義は、プロセスの有効期間がコンテナーの有効期間を制御することを説明しています。 プロセスが完了すると、コンテナーのライフサイクルが終了します。 コンテナーは、Web サーバーのような実行時間の長いプロセスを表す場合がありますが、以前は Azure WebJobs として実装されていたバッチ ジョブなどの有効期間の短いプロセスを表すこともできます。

プロセスが失敗すると、コンテナーが終了し、オーケストレーターが引き継ぎます。 オーケストレーターが 5 つのインスタンスを実行したままにするように構成されていて、1 つが失敗した場合、オーケストレーターは、失敗したプロセスを置き換える別のコンテナー インスタンスを作成します。 バッチ ジョブでは、プロセスはパラメーターを使用して開始されます。 プロセスが完了すると、作業が完了します。 このガイダンスでは、オーケストレーターの詳細をその後で掘り下げて説明します。

1 つのコンテナーで複数のプロセスを実行するシナリオが見つかる場合があります。 そのシナリオでは、コンテナーごとに 1 つのエントリ ポイントしか存在しないため、必要な数のプログラムを起動するスクリプトをコンテナー内で実行できます。 たとえば、 Supervisor などのツールを使用して、1 つのコンテナー内で複数のプロセスを起動できます。 ただし、コンテナーごとに複数のプロセスを保持するアーキテクチャが見つかる場合でも、そのアプローチはあまり一般的ではありません。