コンテナー化は、アプリを最新にするための一般的な方法です。 高度なワークロードには、Azure Kubernetes Service の使用を検討する場合もあります。また、単純な Web アプリケーションのような単純なコンテナー ワークロードには、Azure Container Instances を使用できます。 この記事では、Application Gateway がファイアウォールとして使用されている場合に、インフラストラクチャレベルで Container Instances のサーバーレスの自動化を実装することに焦点を当てています。
まず、一般的なシナリオから始めます。 Azure コンテナー インスタンスをセキュリティで保護するには、Azure Container Instances でコンテナー グループを使用します。 コンテナー グループを使用すると、コンテナーが Azure プライベート エンドポイント経由で他のプライベート リソースや他の Azure サービスにアクセスできるように、Azure コンテナー インスタンスを仮想ネットワークにデプロイできます。 Web アプリケーションをホストしている場合は、バックエンド プールとして Azure Container Instances を使用しながら、受信トラフィックに対処するために、Azure Application Gateway のような Web アプリケーション ファイアウォールを使用することが一般的です。 最初に、「コンテナー グループの静的 IP アドレスの公開」という記事を参照することをお勧めします。
この方法で考えられる 1 つの問題点は、非静的プライベート IP アドレスをバックエンド プールとして使用することです。 プライベート IP はメンテナンス中にローテーションされる可能性があり、クラウド管理者が手動でバックエンド プールを再構成することが必要になります。 スケーリングのために新しいコンテナーを追加した場合も、管理者はトラフィックが適切なバックエンド プールにルーティングされるように、再構成する必要があります。 また、liveness probe および readiness probe は、コンテナー グループではサポートされていないため、ワークロードのダウンタイムを特定することが難しくなります。
この記事では、プライベート IP の自動ローテーションを実行するための Azure Functions を監視および使用するために Application Insights と Azure Monitor を導入することによる、これらの一般的な問題に対処するための機能強化について説明します。 この方法では、ワークロードの冗長性が向上します。
考えられるユース ケース
このアーキテクチャは、以下の場合に最適です。
- サーバーレス デプロイ。
- 自動化によるクラウドネイティブ ワークロードに対する最小限の操作。
- 高度なコンテナー オーケストレーションを必要としない単純なコンテナー ワークロード。
- 自動再構成が行われる、高度に冗長な、外部に接続されたワークロード。
- Azure プライベート エンドポイントによって公開されているリソースのようなプライベート リソースへのアクセスを必要とするコンテナー ワークロード。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
データフロー
パート 1: 一般的な Web アプリケーションのトラフィック フロー
1a. Application Gateway には、Web アプリケーション ファイアウォールの機能があります。これは、パブリックに公開されているトラフィックがバックエンドのワークロードに到達する前のフロントエンドとして最適です。 Application Gateway はパブリック IP アドレスを公開するため、Azure DDoS Protection は別の保護レイヤーを提供します。
1b. Application Gateway のバックエンド プールは、コンテナー グループ内の Azure コンテナー インスタンスのプライベート IP アドレスを使用して構成されます。 コンテナー グループ内の Azure コンテナー インスタンスには完全修飾ドメイン名 (FQDN) が付いていないため、IP アドレスを使用する必要があります。
1c. Azure Container Instances 内のコンテナーは、プライベート リンク経由で Azure Cosmos DB のようなプライベート リソースを使用できます。
パート 2: 自動化による機能強化
2a. Application Gateway には、"正常なホストの数" メトリックが含まれています。Container Instances のコンテナー グループで liveness probe または readiness probe がサポートされていない場合は、これを Azure コンテナー インスタンスの liveness probe として使用できます。
2b. Application Insights は、ハート ビートなどのその他のメトリックを収集するためにコンテナーで使用されます。これらのメトリックは、カスタム スレッドを介して監視するために、Application Insights に送信できます。
2c. 手順 2a. および 2b. で定義したしきい値レベルに基づいて、アラートを構成できます。 たとえば、システムに 3 つのコンテナー インスタンスがバックエンド プールとして実行されているとします。 アラートを、"正常なホストの数" が 3 未満の場合に発生するように構成できます。 アラート ルールのアクション グループでは、アクションの種類として Azure 関数を使用して、カスタム アクションをトリガーできます。
2d. Azure 関数では、Azure SDK を使用して、既存のコンテナー インスタンスの構成を取得し、同じインスタンスを再作成します。 この関数は、手順 2c. で定義されたアラートによってトリガーされます。 この関数の実行には、セットアップの複雑さによっては長い時間がかかることがあります。 Azure 関数はタイムアウトになることがあるため、Azure Durable Functions を使用すると、実行時間の長いプロセスを処理し、状態の更新を取得できます。
Components
Automation
- Azure Durable Functions: Azure Functions とは異なり、Durable Functions はステートフルで、いくつかのステートフル ワークフロー パターンをサポートしています。 この例では、モニター パターンが使用されています。
- Azure SDK: Azure SDK は、任意のプログラミング言語で Azure サービスと対話するために使用できるライブラリのコレクションです。 SDK を使用すると、自動化を実行するロジックをより柔軟に統合できます。
監視
- Azure Monitor メトリック: Azure Monitor のこの機能により、Azure サービスから定義済みの数値データが収集されます。
- アクション グループ: アクション グループは、リソースの所有者によって定義された通知設定のコレクションです。 トリガーされたアラートに基づいて、通知チャネルとアクションを定義できます。
ネットワーク
- Azure DDoS Protection: Azure DDoS (Basic) Protection は無料で、すべてのパブリック IP で有効です。 Azure DDoS ネットワーク保護には、他の場所へのログの取り込みや、DDoS Protection の Rapid Response チームへの協力などのその他の機能も用意されています。
- Azure Application Gateway: Azure Web Application Firewall は、パブリックに公開されているアプリケーションを SQL インジェクションや XSS 攻撃などの悪用から保護します。
- Azure Private Link: Azure Private Link を使用すると、Microsoft バックボーンのプライベート エンドポイントを通じて Azure PaaS サービスにアクセスできます。これにより、ネットワーク アクセスのセキュリティがさらに強化されます。
Application
- Azure Container Instances: Azure Container Instances は、他のインフラストラクチャをセットアップしなくても、コンテナー イメージをシームレスに実行できます。 高度なコンテナー オーケストレーションのためには、Azure Kubernetes Service (AKS) を検討する必要があります。
- Azure Cosmos DB: Azure Cosmos DB は、SQL、Cassandra、MongoDB などの複数のプラットフォームをサポートする、完全に管理された NoSQL データベースです。
- Azure Key Vault: セキュリティのベスト プラクティスとして、開発者は接続文字列をクリア テキストとしてアプリケーション ソース コードに保存しません。 Azure Key Vault は、強化されたセキュリティでシークレットを格納するための一元的な場所として機能します。 アプリケーションは、セキュリティが強化された方法で、必要なキーを取得できます。
代替
前のシナリオでは、Application Gateway のバックエンド プールが更新されます。 別の方法として、Azure プライベート DNS ゾーンを Application Gateway のターゲット バックエンドとして使用し、Azure 関数を利用して、Application Gateway で変更を行うのではなく、レコードを更新することができます。 この代替方法では、デプロイ時間が短縮されます。 一方で、Application Gateway メトリックがホスト数を特定できなくなります。これは、DNS によって抽象化されるためです。 そのため、この自動化は、Application Insights や Azure Monitor などのアプリケーション監視ソリューションを通じて直接トリガーする必要があります。
Azure には、Azure Kubernetes Service や Azure App Service など、コンテナーベースのワークロードをホストするための複数のオプションが用意されています。
Azure Kubernetes Service は、Container Instances では利用できない、サービス リソースなどの高度なコンテナー オーケストレーションとネットワーク機能を提供します。 この参照アーキテクチャによって、この要件に対処できます。
App Service は、コンテナー ワークロードをホストすることもできます。また、App Service Environment を使用すると、開発者は Azure Virtual Network に App Service をデプロイできます。 Container Instances の価格体系は、App Service と比較して、小規模なワークロードでは魅力があります。
考慮事項
可用性
liveness probe と readiness probe は、コンテナー グループではサポートされていないため、監視には Azure Monitor メトリックと Azure Application Insights を使用することをお勧めします。 コンテナーの正常性とアップタイムは、システム全体が動作しているかどうかを判断するための決定論的なアプローチではありません。
Operations
Container Instances でエラーが発生した場合、またはコンテナー グループのプライベート IP が変更された場合、インフラストラクチャを再構成するには、Azure Durable Functions を使用します。 ドキュメントに記載されているように、プロビジョニング プロセスにかかる時間は少し長くなります。 コンテナーの準備が間に合わない場合、ユーザーに最小限のダウンタイムが発生する可能性があります。
このアーキテクチャでは、回復性のレイヤーが追加されます。 それでも、アプリケーションで監視を構成し、プラットフォームのエラーに関して Azure の状態を監視することをお勧めします。
スケーラビリティ
CPU とメモリの要件はコンテナーが作成されるときに定義されるため、垂直スケーリングを直接実行することはできません。 コンテナー グループにコンテナーを追加して、水平スケーリングすることはできます。 ただし、コンテナー グループ内の各コンテナーが 1 つのプライベート IP を使用するため、プロビジョニングされたサブネット サイズによる制限があることに注意してください。
スケーリングに関するもう 1 つの重要な考慮事項は、アプリケーションの状態です。 アプリケーションは、オンデマンドでのスケーリングによってアプリケーションのデータ損失が発生しないことを確認するために、ローカルに、または Azure Cache for Redis のような外部サービスを使用して、状態を処理する必要があります。
セキュリティ
PaaS を仮想ネットワークにデプロイする機能 (VNet インジェクション) は、構成が正しく設定されていない場合はセキュリティを向上させません。 VNet インジェクションにより、ネットワーク セキュリティ グループが強化されたり、パブリックに公開されていないリソースを使用できたりするメリットが得られるので、管理者はネットワークをより広く制御できます。
Private Link は、プライベート エンドポイントを仮想ネットワークに射影します。これにより、アプリケーションはプライベート IP アドレスを通じて Azure PaaS に直接アクセスできるようになります。 同時に、管理者は、関連する Azure PaaS にアクセスできるユーザーをさらに詳細に制御できます。
コンテナー イメージを Azure Container Registry に格納する場合は、コンテナー レジストリ用 Microsoft Defender を有効にして、コンテナー イメージの脆弱性スキャンを実行できます。
このシナリオのデプロイ
Azure Functions で自動化を実行するサンプル ソース コードは、GitHub で入手できます。
サービス プリンシパル (クライアント ID とシークレット) が必要になります。 これは、Azure Resource Manager の操作を実行するために、Azure Functions によって使用されます。 このサービス プリンシパルには、Application Gateway を更新して Azure コンテナー インスタンスを作成できるように、リソース グループの少なくとも所有者権限が必要です。 サンプルでは、単純な Python アプリケーションが作成され、コンテナー化されて Container Registry に格納されます。 独自のアプリケーションで、レジストリを更新してください。
価格
Azure リソースのコストを見積もるには、Azure 料金計算ツールを使用します。
上の実装のこの例を参照してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Marcus Tee | 技術戦略およびロードマップ
次のステップ
関連リソース
以下のアーキテクチャを参照してください。
関連するガイダンス: