コンテナーとマイクロサービス ベースのアプリケーションの設計
ヒント
このコンテンツは eBook の「コンテナー化された .NET アプリケーションの .NET マイクロサービス アーキテクチャ」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。
マイクロサービスは大きな利点がありますが、大きな新しい課題を発生させます。 マイクロ サービス アーキテクチャ パターンは、マイクロサービス ベースのアプリケーションを作成するときの基本的な柱です。
このガイドの前半では、コンテナーと Docker の基本的な概念を学習しました。 これは、コンテナーの使用を開始するために必要な最小限の情報でした。 コンテナーはマイクロサービスを実現するものであり、最適なものですが、マイクロサービス アーキテクチャに必須ではありません。 このアーキテクチャ セクションでのアーキテクチャの概念の多くは、コンテナーなしで適用できます。 しかし、既に導入されているコンテナーの重要性から、このガイドでは両方の共通部分に焦点を当てます。
エンタープライズ アプリケーションでは、複雑になることがあり、多くの場合 1 つのサービス ベースのアプリケーションではなく、複数のサービスで構成されます。 このような場合、マイクロサービス、特定のドメイン駆動型設計 (DDD) パターン、コンテナー オーケストレーションの概念など、その他のアーキテクチャの手法を理解する必要があります。 この章では、コンテナー上のマイクロサービスだけでなく、コンテナー化されたアプリケーションについても説明することに注意してください。
コンテナー設計の原則
コンテナー モデルでは、コンテナー イメージのインスタンスは 1 つのプロセスを表します。 コンテナー イメージをプロセス境界として定義することで、プロセスのスケーリングやバッチ処理に使用できるプリミティブを作成できます。
コンテナー イメージをデザインするときには、ENTRYPOINT 定義が Dockerfile に表示されます。 この定義によって、その有効期間がコンテナーの有効期間を制御するプロセスが定義されます。 プロセスが完了すると、コンテナーのライフサイクルが終了します。 コンテナーは、Web サーバーなどの実行時間の長いプロセスを表す場合がありますが、以前は Azure の WebJobs として実装される場合があったバッチ ジョブなどの有効期間が短いプロセスも表すことができます。
プロセスが失敗した場合、コンテナーが終了し、Orchestrator が引き継ぎます。 Orchestrator が 5 つのインスタンスの実行を維持するように構成され、1 つが失敗した場合、Orchestrator は、失敗したプロセスを置換する別のコンテナー インスタンスを作成します。 バッチ ジョブで、プロセスはパラメーターを指定して開始されます。 プロセスが完了すると、作業が完了します。 このガイダンスでは、後でオーケストレーターについてドリル ダウンします。
1 つのコンテナーで複数のプロセスが実行されているシナリオが見られる場合があります。 このシナリオでは、コンテナーごとに 1 つのエントリ ポイントのみが存在できるため、必要な数のプログラムを起動するスクリプトをコンテナー内で実行できます。 たとえば、スーパーバイザーまたは同様のツールを使用して、1 つのコンテナー内で複数のプロセスの起動を処理できます。 ただし、コンテナーごとに複数のプロセスを保持するアーキテクチャを探すことは可能ですが、その方法はあまり一般的ではありません。