Azure コンテナー サービスを選択するためのアーキテクチャに関する一般的な考慮事項

この記事では、Azure コンテナー サービスを選択するプロセスについて説明します。 一部のワークロードで一般的で重要な機能レベルの考慮事項の概要を示します。 これは、ワークロードが信頼性、セキュリティ、コストの最適化、オペレーショナル エクセレンス、およびパフォーマンス効率の要件を満たしていることを確認するための決定を下すのに役立ちます。

概要

この記事の考慮事項は、次の 4 つのカテゴリに分かれています。

アーキテクチャとネットワークに関する考慮事項

• オペレーティング システムのサポート
• ネットワーク アドレス空間
• トラフィック フローについて
• サブネットの計画
• 使用可能なイングレス IP の数
• ユーザー定義ルートと NAT ゲートウェイのサポート
• プライベート ネットワーク統合
• プロトコルカバー率
• 負荷分散
• サービス検出
• カスタム ドメインとマネージド TLS
• 相互 TLS
• 特定の Azure サービスのネットワークの概念

セキュリティに関する考慮事項

• ネットワーク ポリシーを使用したクラスター内トラフィックのセキュリティの提供
• ネットワーク セキュリティ グループ
• Azure Key Vault の統合
• マネージド ID のサポート
• Defender for Containers を使用した脅威保護と脆弱性評価
• セキュリティ ベースライン
• Azure Well-Architected セキュリティフレームワーク

運用上の考慮事項

• 更新プログラムとパッチ
• コンテナー イメージの更新
• 垂直インフラストラクチャのスケーラビリティ
• 水平インフラストラクチャのスケーラビリティ
• アプリケーションのスケーラビリティ
• 可観測性
• オペレーショナル エクセレンスのための Well-Architected フレームワーク

信頼性に関する考慮事項

• サービスレベル契約
• 可用性ゾーンを使用した冗長性
• ヘルスチェックと自己修復
• ダウンタイムが発生しないアプリケーションのデプロイ
• リソース制限
• 信頼性のための Well-Architected フレームワーク

この記事では、Web アプリケーションと API、ネットワーク、可観測性、開発者ツール、および操作用の成熟した機能セットを提供する Azure コンテナー サービスのサブセット (Azure Kubernetes Service (AKS)、AKS Automatic、Azure Container Apps、Web App for Containers に焦点を当てています。 すべての Azure Container Service の全一覧については、「コンテナー サービスの製品カテゴリページ」を参照してください。

アーキテクチャに関する考慮事項

このセクションでは、大幅なダウンタイムや再デプロイを必要とせずに、逆引きまたは修正が困難なアーキテクチャ上の決定について説明します。 ネットワークやセキュリティなどの基本的なコンポーネントについては、この考慮事項を念頭に置く必要があります。

これらの考慮事項は、Well-Architected Framework の柱に固有ではありません。 ただし、Azure コンテナー サービスを選択する場合は、企業の要件に対する追加の調査と評価が必要です。

オペレーティング システムのサポート

ほとんどのコンテナー化されたアプリケーションは Linux コンテナーで実行されます。これは、すべての Azure コンテナー サービスでサポートされています。 Windows コンテナーを必要とするワークロード コンポーネントでは、オプションが制限されます。

*Web App for Containers の混合 OS サポートには、Windows と Linux 用の個別の Azure App Service プランが必要です。

ネットワークに関する考慮事項

セキュリティとコンプライアンスの制約と課されたガイドラインにより、計画プロセスの早い段階でネットワーク設計を理解することが重要です。 一般に、このガイドで取り上げる Azure サービスの主な違いは、ユーザー設定によって異なります。

• Container Apps は、サービス検出、内部マネージド ドメイン、仮想ネットワーク制御など、Azure で管理される多くのネットワーク機能を提供する PaaS オファリングです。
• AKS は、3 つのサービスの中で最も構成可能であり、ネットワーク フローを最も制御できます。 たとえば、Kubernetes ネットワーク ポリシーを使用して、カスタムイングレス コントローラーとクラスター内トラフィックの制御を提供します。 ワークロード チームは、さまざまな Azure マネージド ネットワーク アドオンを利用できるほか、広範な Kubernetes エコシステムからアドオンをインストールして運用できます。
• Web App for Containers は、App Serviceの機能です。 したがって、ネットワークの概念 、特にプライベート ネットワーク統合は、App Service に非常に固有です。 このサービスは、App Service を既に使用しているワークロード チームにはなじみがあります。 App Service の経験がなく、より使い慣れた Azure 仮想ネットワーク統合を必要とする Teams は、Container Apps を検討することをお勧めします。

ネットワークは基盤となるインフラストラクチャ レイヤーであることに注意してください。 多くの場合、ワークロードを再デプロイせずに設計を変更することは困難であり、ダウンタイムにつながる可能性があります。 そのため、ワークロードに特定のネットワーク要件がある場合は、Azure コンテナー サービスの選択を絞り込む前に、このセクションをよく確認してください。

ネットワーク アドレス空間

アプリケーションを仮想ネットワークに統合する場合は、コンテナー インスタンスで十分な IP アドレスを使用できるように、いくつかの IP アドレス計画を実行する必要があります。 このプロセスでは、更新プログラム、青/緑のデプロイ、および追加のインスタンスがデプロイされ、追加の IP アドレスを消費する同様の状況に対して、追加のアドレスを計画します。

AKS の要件は、選択したネットワーク プラグインによって異なります。 AKS の一部のネットワーク プラグインでは、より広範な IP 予約が必要です。 詳細については、この記事の範囲外です。 詳細については、「AKS のネットワーク概念」を参照してください。

トラフィック フローについて

ソリューションに必要なトラフィック フローの種類は、ネットワーク設計に影響を与える可能性があります。

次のセクションでは、さまざまなネットワーク制約に関する情報を提供します。 これらの制約は、必要かどうかに応じて、追加のサブネットをデプロイする必要性に影響します。

• 複数の併置ワークロード。
• 私的および/または公共のアクセス。
• クラスター (Container Apps と AKS の場合) または仮想ネットワーク内 (すべての Azure コンテナー サービスの場合) 内の東西トラフィックのアクセス制御フロー。

サブネットの計画

ワークロードにアプリケーションのインスタンスを含めるのに十分な大きさのサブネットがあることを確認することは、これらのアプリケーションがデプロイされるネットワークフットプリントを決定する唯一の要因ではありません。

*技術的な制限ではなく、ベスト プラクティスについて説明します。

Container Apps の場合、サブネット統合は 1 つの Container Apps 環境にのみ適用されます。 各 Container Apps 環境は、パブリックまたはプライベートの 1 つのイングレス IP に制限されます。

各 Container Apps 環境は、依存アプリケーションが併置される 1 つのワークロードのみを対象としています。 そのため、パブリックイングレスとプライベートイングレスの両方が必要な場合は、イングレス負荷分散用の追加の Azure ネットワーク アプライアンスを導入する必要があります。 たとえば、Azure Application Gateway や Azure Front Door などがあります。 また、複数のワークロードを分離する必要がある場合は、追加の Container Apps 環境が必要になるため、環境ごとに追加のサブネットを割り当てる必要があります。

AKS は、Kubernetes ネットワーク ポリシーの形式でクラスター内で詳細な東西ネットワーク フロー制御を提供します。 このフロー制御を使用すると、同じクラスター内で異なるネットワーク セキュリティ境界を持つ複数のワークロードをセグメント化できます。

Web App for Containers の場合、サブネットが十分な大きさである限り、1 つのサブネットと統合できるアプリの数に制約はありません。 同じ仮想ネットワーク内の Web アプリ間のアクセス制御に関するベスト プラクティスはありません。 各 Web アプリは、仮想ネットワークまたはインターネットからの東西または南北のトラフィックのアクセス制御をそれぞれ個別に管理します。

使用可能なイングレス IP の数

次の表では、前のサブネット計画セクションを考慮して、Azure コンテナー サービスの 1 つのデプロイでホストされる任意の数のアプリケーションに対して公開できる IP の数を定義します。

Container Apps では、環境ごとに 1 つの IP (パブリックまたはプライベート) が許可されます。 AKS では、パブリックまたはプライベートの任意の数の IP を使用できます。 App Service Environment の外部にある Web App for Containers では、App Service プラン内のすべてのアプリに対して 1 つのパブリック IP と、Azure プライベート エンドポイントを使用する複数の異なるプライベート IP が許可されます。

App Service Environment に統合されている Web アプリは、App Service Environment に関連付けられている単一のイングレス IP (パブリックまたはプライベート) を介してのみトラフィックを受信する点に注意してください。

ユーザー定義ルートと NAT ゲートウェイのサポート

ワークロードで詳細なネットワーク制御のためにユーザー定義ルート (UDR) と NAT ゲートウェイ機能が必要な場合、Container Apps では、ワークロード プロファイルを使用する必要があります。 UDR と NAT ゲートウェイの互換性は、ACA の従量課金専用プランでは使用できません。

AKS と Web App for Containers は、標準の仮想ネットワーク機能または仮想ネットワーク統合を通じて、これら 2 つのネットワーク機能をそれぞれ実装します。 詳しく説明すると、App Service 環境の AKS ノード プールと Web App for Containers は、既に仮想ネットワーク リソースを直接提供しています。 App Service Environment にない Web App for Containers は、UDR および NAT ゲートウェイを仮想ネットワーク統合 およびを介してサポートします。 仮想ネットワーク統合では、リソースは技術的には仮想ネットワークに直接存在しませんが、その送信アクセスはすべて仮想ネットワークを通過し、ネットワークに関連付けられている規則は想定どおりにトラフィックに影響します。

プライベート ネットワーク統合

イングレスとエグレスの両方に厳密なレイヤー 4 プライベート ネットワークを必要とするワークロードの場合は、Container Apps、AKS、シングルテナント App Service Environment SKU を検討する必要があります。この SKU では、ワークロードがセルフマネージド仮想ネットワークにデプロイされ、カスタムの詳細なプライベート ネットワーク制御が提供されます。

Web App for Containers を使用したプライベート ネットワーク

Web App for Containers には、この記事で説明する他の Azure サービスと同じように表示されない追加のネットワーク機能が用意されています。 厳密なプライベート ネットワーク要件を実装するには、ワークロード チームがこれらのネットワークの概念を理解する必要があります。 これらのネットワーク機能を慎重に確認します。

• プライベート エンドポイント
• 仮想ネットワークの統合

PaaS ソリューションが必要で、複数の Azure ソリューション間で共有されるネットワークの概念を好む場合は、Container Apps を検討する必要があります。

プロトコルカバー率

ホスティング プラットフォームの重要な考慮事項は、受信アプリケーション要求 (イングレス) でサポートされるネットワーク プロトコルです。 Web App for Containers は、HTTP と HTTPS のみをサポートする最も厳密なオプションです。 Container Apps では、受信 TCP 接続も許可されます。 AKS は、自己選択されたポートでの TCP と UDP の制約のない使用をサポートする、最も柔軟です。

*Container Apps 環境では、クラスター内通信用の任意のポート で、 HTTP/S を公開できます。 このシナリオでは、CORS やセッション アフィニティなどの組み込みの Container Apps HTTP 機能は適用されません。

Container Apps と Web App for Containers の両方で、組み込みの HTTPS イングレスに対して TLS 1.2 がサポートされています。

負荷分散

Container Apps と Web App for Containers を使用すると、Azure はレイヤー 4 とレイヤー 7 のロード バランサーを完全に抽象化します。

一方、AKS では、Kubernetes API とやり取りしてワークロード チームが構成する基になる Azure インフラストラクチャを Azure が管理する共有責任モデルが使用されます。 AKS のレイヤー 7 負荷分散の場合は、AKS マネージド アプリケーション ルーティング アドオン や Application Gateway for Containersなど、Azure で管理されるオプションを選択したり、選択したイングレス コントローラーをデプロイして自己管理したりできます。

サービス検出

クラウド アーキテクチャでは、ランタイムをいつでも削除して再作成してリソースを再調整できるため、インスタンスの IP アドレスは定期的に変更されます。 これらのアーキテクチャでは、信頼できる一貫性のある通信のために完全修飾ドメイン名 (FQDN) が使用されます。

Web Apps for Containers では、パブリック イングレス (南北通信) FQDN がすぐに使用できます。 追加の DNS 構成は必要ありません。 ただし、他のアプリ間のトラフィックを容易にしたり制限したりする組み込みのメカニズムはありません (東西通信)。

Container Apps では、パブリック イングレス FQDN も提供されます。 ただし、Container Apps は、アプリの FQDN を公開できるようにし、 環境内でのみトラフィックを制限することでさらに進みます。 この機能により、東西通信の管理が容易になり、Dapr などのコンポーネントが有効になります。

Kubernetes デプロイは、最初はクラスター内またはクラスター外から検出できません。 Kubernetes API で定義されている Kubernetes サービスを作成し、アドレス指定可能な方法でアプリケーションをネットワークに公開する必要があります。

カスタム ドメインとマネージド TLS

Container Apps と Web App for Containers の両方に、カスタム ドメインと証明書管理用のすぐに使えるソリューションが用意されています。

AKS ユーザーは、カスタム ドメインの DNS、クラスター構成、TLS 証明書を管理する責任があります。 AKS ではマネージド TLS は提供されていませんが、お客様は Kubernetes エコシステムのソフトウェアを利用できます。たとえば、一般的な cert-manager を使用して TLS 証明書を管理できます。

相互 TLS

受信トラフィックを制限するもう 1 つの代替手段は、相互 TLS (mTLS) です。 相互 TLS は、通信中のクライアントとサーバーの両方が認証されるようにするセキュリティ プロトコルです。 認証を実現するために、データが送信される前に、両方の当事者が証明書を交換して検証します。

Web App for Containers には、着信クライアント接続に対する mTLS サポートが組み込まれています。 ただし、アプリケーションは、App Service プラットフォームが転送する HTTP ヘッダーにアクセスして証明書を検証する必要があります。

Container Apps には、mTLS のサポートも組み込まれています。 クライアント証明書は、X-Forwarded-Client-Cert HTTP ヘッダー内のアプリケーションに転送されます。また、自動 mTLS を簡単に有効にして、1 つの環境で アプリ間の内部通信を行うこともできます。

AKS の相互 TLS は、Istio ベースのサービス メッシュを介してマネージド アドオンとして実装できます。これには、受信クライアント接続とサービス間のクラスター内通信のための mTLS 機能が含まれます。 ワークロード チームは、Kubernetes エコシステムから別のサービス メッシュ オファリングをインストールして管理することもできます。 これらのオプションにより、Kubernetes での mTLS の実装が最も柔軟になります。

サービス固有のネットワークの概念

前のセクションでは、考慮すべき最も一般的な考慮事項について説明します。 詳細と、個々の Azure コンテナー サービスに固有のネットワーク機能の詳細については、次の記事を参照してください。

• Container Apps でのネットワーキング
• AKS のネットワークの概念
• App Service のネットワーク機能

前のセクションでは、ネットワーク設計に焦点を当てています。 ネットワーク セキュリティとネットワーク トラフィックのセキュリティ保護の詳細については、次のセクションに進んでください。

セキュリティに関する考慮事項

セキュリティ リスクに対処しないと、不正アクセス、データ侵害、機密情報の漏洩につながる可能性があります。 コンテナーは、アプリケーション用にカプセル化された環境を提供します。 ただし、ホスティング システムと基になるネットワーク オーバーレイには、追加のガードレールが必要です。 Azure コンテナー サービスを選択するには、各アプリケーションを個別にセキュリティで保護するための特定の要件をサポートし、不正アクセスを防ぎ、攻撃のリスクを軽減するための適切なセキュリティ対策を提供する必要があります。

セキュリティ比較の概要

Container Apps、AKS、Web App for Containers を含むほとんどの Azure サービスは、Key Vault やマネージド ID などの主要なセキュリティ オファリングと統合されます。

このガイドのサービスのうち、AKS は、基になるコンポーネントを表示することによって、最も構成性と拡張性を提供します。これは、多くの場合、構成オプションを使用してセキュリティで保護できます。 たとえば、Kubernetes API サーバーへのローカル アカウントを無効にしたり、構成オプションを使用して基になるノードの自動更新を有効にしたりできます。

AKS 自動クラスターには、多くのクラスター、アプリケーション、およびネットワーク セキュリティ設定が既定で有効になっている、強化された既定の構成が用意されています。 これらの初期構成は、デプロイ時間を短縮するだけでなく、事前に検証された標準化された構成をユーザーに提供するため、ユーザーは 2 日目の運用責任の強固な基盤を確保できます。 この基盤は、テクノロジを初めて使用するチームの長期的なクラスター管理の学習曲線を短縮するのに役立ちます。

詳細な比較については、次の考慮事項を慎重に確認して、ワークロードのセキュリティ要件を満たしていることを確認してください。

Kubernetes コントロール プレーンのセキュリティ

AKS は、この記事で検討されている 3 つのオプションのうち最も柔軟性が高く、コンテナー オーケストレーションをカスタマイズできるように Kubernetes API へのフル アクセスを提供します。 ただし、Kubernetes API へのこのアクセスは、重要な攻撃面を表しており、セキュリティで保護する必要があります。

ID ベースのセキュリティ

お客様は、API への ID ベースのアクセスをセキュリティで保護する責任があります。 Kubernetes には、独自の認証および承認管理システムが用意されています。また、アクセス制御を使用してセキュリティ保護する必要があります。

Azure での ID とアクセスの管理に 1 つのプレーンを利用するには、Kubernetes 固有のローカル アカウント を無効に し、代わりに AKS で管理される Microsoft Entra 統合 を Kubernetes 用Azure RBAC と共に実装 することをお勧めします。 このベスト プラクティスを実装する場合、管理者は複数のプラットフォームで ID とアクセス管理を実行する必要はありません。

Container Apps を使用するお客様は、Kubernetes API にアクセスできません。 Microsoft は、この API のセキュリティを提供します。

ネットワーク ベースのセキュリティ

Kubernetes コントロール プレーンへのネットワーク アクセスを制限する場合は、2 つのオプションを提供する AKS を使用する必要があります。 1 つ目のオプションは、プライベート AKS クラスターを使用することです。このクラスターでは、API サーバーのプライベート ネットワークと AKS クラスターのプライベート ネットワークの間の Azure Private Link が使用されます。 2 番目のオプションは、API Server VNet 統合 (プレビュー) です。API サーバーは委任されたサブネットに統合されます。 詳細については、ドキュメントを参照してください。

Kubernetes API へのネットワーク制限付きアクセスの実装には結果があります。 特に、管理はプライベート ネットワーク内からのみ実行できます。 通常、これは、Azure DevOps または GitHub Actions 用にセルフホステッド エージェントをデプロイする必要があります。 その他の制限事項については、製品固有のドキュメントを参照してください。

これらの考慮事項は、Container Apps には適用されません。 PaaS であるため、Microsoft は基になるインフラストラクチャを抽象化します。

データ プレーンのネットワーク セキュリティ

次のネットワーク機能を使用して、ワークロードとの間、およびワークロード内へのアクセスを制御できます。

ネットワーク ポリシーを使用してクラスター内トラフィックのセキュリティを提供する

一部のセキュリティ体制では、複数のアプリケーションまたは多層アプリケーションをホストするためにマルチテナント環境を使用する場合など、環境内 ネットワーク トラフィックの分離 が必要です。 これらのシナリオでは、AKS を選択し、Kubernetes クラスター内でのレイヤー 4 ネットワークの詳細な構成を可能にするクラウドネイティブ テクノロジである ネットワーク ポリシーを実装する必要があります。

この記事で説明する 3 つの Azure サービスのうち、クラスター内でのワークロードの分離をサポートするのは AKS だけです。 ネットワーク ポリシーは、Container Apps または Web App for Containers ではサポートされていません。

ネットワーク セキュリティ グループ

すべてのシナリオで、ネットワーク セキュリティ グループを使用して、より広い仮想ネットワーク内のネットワーク通信を規制できます。これにより、仮想ネットワーク レベルでイングレスとエグレスを規制するレイヤー 4 トラフィック ルールを使用できます。

イングレスに対する組み込み IP 制限

Container Apps と Web App for Containers では、個々のアプリケーションのイングレス トラフィックに対する組み込みのソース IP 制限が提供されます。 AKS は同じ機能を実現できますが、Kubernetes Service api-resource を使用して Kubernetes ネイティブ機能が必要です。ここで、loadBalancerSourceRangesの値を設定できます。

アプリケーション レベルのセキュリティ

ワークロードは、ネットワークおよびインフラストラクチャ レベルだけでなく、ワークロードとアプリケーション レベルでもセキュリティで保護する必要があります。 Azure コンテナー ソリューションは Azure セキュリティ オファリングと統合され、アプリケーションのセキュリティ実装と制御を標準化するのに役立ちます。

Key Vault の統合

シークレット、キー、証明書を Key Vault などのキー管理ソリューションに格納して管理することをお勧めします。これにより、これらのコンポーネントのセキュリティが強化されます。 シークレットをコードまたは Azure コンピューティング サービスに格納して構成する代わりに、すべてのアプリケーションを Key Vault と統合する必要があります。

Key Vault の統合により、アプリケーション開発者はアプリケーション コードに集中できます。 この記事で説明する 3 つの Azure コンテナー サービスはすべて、Key Vault サービスからシークレットを自動的に同期し、通常は環境変数またはマウントされたファイルとしてアプリケーションに提供できます。

詳細については次を参照してください:

• Azure Container Apps でシークレットを管理する
• Key Vault を AKS と統合する
• Azure App Service で Key Vault 参照をアプリ設定として使用する

マネージド ID のサポート

マネージド ID は、キーやシークレットを使用しなくても、アプリケーションで Microsoft Entra ID で保護されたサービスに対する認証に使用できます。 Container Apps と Web App for Container では、アプリケーション レベルのマネージド ID に対する組み込みの Azure ネイティブ サポートが提供されます。 AKS のアプリケーション レベルのマネージド ID のサポートは、Entra Workload IDによって実現されます。 AKS には、Kubelet、コントロール プレーン、およびさまざまな AKS アドオンのクラスター操作を許可するために、インフラストラクチャ関連のマネージド ID も必要です。

詳細については次を参照してください:

• AKS でマネージド ID を使用する
• AKS を使用する Microsoft Entra ワークロード ID
• Azure Container Apps のマネージド ID
• App Service のマネージド ID を使用する方法

Defender for Containers を使用した脅威保護と脆弱性評価

脆弱性に対する脅威の防止も重要です。 Defender for Containersを使用することはベストプラクティスとしてお勧めします。 脆弱性評価は Azure コンテナー レジストリでサポートされているため、この記事で説明されているだけでなく、任意の Azure コンテナー サービスで使用できます。 ただし、Defender for Containers ランタイム保護は AKS でのみ使用できます。

AKS はネイティブ Kubernetes API を公開するため、Kubernetes エコシステムから Kubernetes 固有のセキュリティ ツールを使用してクラスター のセキュリティを評価することもできます。

詳細については、「Defender for Cloud のコンテナー サポート マトリックス」を参照してください。

コンテナー イメージの脆弱性評価はリアルタイム スキャンではありません。 Azure Container Registry は一定の間隔でスキャンされます。

セキュリティ ベースライン

一般に、ほとんどの Azure コンテナー サービスは Azure セキュリティ オファリングを統合します。 全体として、セキュリティ機能セットはクラウド セキュリティの実装のごく一部に過ぎないことに注意してください。 コンテナー サービスのセキュリティの実装の詳細については、次のサービス固有のセキュリティ ベースラインを参照してください。

• Container Apps の Azure セキュリティ ベースライン
• Azure Kubernetes Service のための Azure セキュリティ ベースライン
• App Service 用の Azure セキュリティ ベースライン

セキュリティのための Well-Architected フレームワーク

この記事では、ここで説明するコンテナー サービス機能の主な違いに焦点を当てます。

AKS の詳細なセキュリティ ガイダンスについては、「Well-Architected Framework のレビュー - AKS」を参照してください。

運用上の考慮事項

運用環境でワークロードを正常に実行するには、チームは、一元的なログ記録、監視、スケーラビリティ、定期的な更新と修正プログラムの適用、イメージ管理などのオペレーショナル エクセレンス プラクティスを実装する必要があります。

更新プログラムとパッチ

アプリケーションの基になる OS が更新され、定期的に修正プログラムが適用されていることが重要です。 ただし、すべての更新でエラーが発生するリスクがあることに注意してください。 このセクションと次のセクションでは、お客様とプラットフォーム間の共有責任に関する 3 つのコンテナー サービスの主な考慮事項について説明します。

マネージド Kubernetes サービスとして、AKS はノード OS およびコントロール プレーン コンポーネントの更新されたイメージを提供します。 ただし、ワークロード チームは、クラスターに更新プログラムを適用する責任があります。 更新プログラムを手動でトリガーしたり、クラスターの自動アップグレード チャネル 機能を利用して、クラスターが最新の状態であることを確認したりできます。 AKS クラスター の修正プログラム適用とアップグレードについては、AKS Day-2 操作ガイドを参照してください。

コンテナー アプリと Web App for Containers は PaaS ソリューションです。 Azure は更新プログラムとパッチの管理を担当するため、お客様は AKS アップグレード管理の複雑さを回避できます。

コンテナー イメージの更新

Azure コンテナー ソリューションに関係なく、お客様は常に独自のコンテナー イメージを担当します。 コンテナーベースイメージのセキュリティパッチがある場合は、イメージをリビルドする必要があります。 これらの脆弱性に関するアラートを取得するには、コンテナー レジストリでホストされているコンテナー Defender for Containers を使用します。

スケーラビリティ

スケーリングは、需要に合わせてリソース容量を調整するために使用され、パフォーマンスを確保するために容量を追加し、コストを節約するために未使用の容量を削除します。 コンテナー ソリューションを選択する場合は、インフラストラクチャの制約とスケーリング戦略を考慮する必要があります。

垂直インフラストラクチャのスケーラビリティ

垂直スケーリング は、既存のインフラストラクチャ (コンピューティング CPU とメモリ) を増減する機能を指します。 ワークロードが異なると、必要なコンピューティング リソースの量が異なります。 Azure コンテナー ソリューションを選択する場合は、特定の Azure サービスで使用できるハードウェア SKU オファリングに注意する必要があります。 これらは異なり、追加の制約を課す可能性があります。

AKS の場合は、Azure ドキュメントの仮想マシンのサイズとリージョンごとの AKS の制限を確認してください。

これらの記事では、他の 2 つのサービスの SKU オファリングについて詳しく説明します。

• Container Apps でのワークロードプロファイル
• App Service 価格

水平インフラストラクチャのスケーラビリティ

水平スケーリング とは、VM ノードなどの新しいインフラストラクチャを使用して容量を増減する機能を指します。 スケーリングの増減中に、コンテナーアプリの消費層が基盤となる仮想マシンを隠蔽します。 残りの Azure コンテナー サービスについては、標準の Azure Resource Manager API を使用して水平スケーリング戦略を管理します。

スケールアウトとスケールインにはインスタンスの再分散が含まれるため、ダウンタイムのリスクも発生することに注意してください。 リスクは、垂直スケーリングの対応するリスクよりも小さいです。 ただし、ワークロード チームは、アプリケーションが障害を確実に処理できるようにし、ダウンタイムを回避するためにアプリケーションの正常なスタートアップとシャットダウンを実装する責任を常に負います。

アプリケーションのスケーラビリティ

インフラストラクチャとアプリケーションのスケーリングをトリガーする一般的なメジャーは、リソース消費量 (CPU とメモリ) です。 一部のコンテナー ソリューションでは、HTTP 要求など、アプリケーション固有のコンテキストを使用してメトリックに対してコンテナー インスタンス数をスケーリングできます。 たとえば、AKS と Container Apps では、KEDA を介してメッセージ キューに基づいてコンテナー インスタンスをスケーリングしたり、スケーラーを介して他の多くのメトリックに基づいてコンテナー インスタンスをスケーリングしたりできます。 これらの機能は、アプリケーションのスケーラビリティ戦略を選択する際に柔軟性を提供します。 Web App for Containers は、Azure によって提供されるスケーラビリティ オプションに依存します。 (次の表を参照)。Web App for Containers では、KEDA などのカスタム スケーラー構成はサポートされていません。

AKS Automatic では、水平ポッドオートスケーラー、Kubernetes イベント ドリブン自動スケール (KEDA)、および垂直ポッドオートスケーラー (VPA) が既定で有効になります。

可観測性

業務負荷計測システム

複雑なアプリケーションや多層アプリケーションのメトリックを収集するのは困難な場合があります。 メトリックを取得するには、次の 2 つの方法でコンテナー化されたワークロードを Azure Monitor と統合します。

• 自動インストルメンテーション。 コードの変更が不要な方法。
• 手動インストルメンテーション。 SDK やクライアントを統合して構成するために必要な最小限のコード変更。

*AKS および Web App for Containers では、アプリケーション言語に応じて、Linux および Windows ワークロードの特定の構成に対する自動インストルメンテーションがサポートされます。 詳細と例については、次の記事をご覧ください。

• 自動インストルメンテーションでサポートされている環境、言語、リソース プロバイダー
• Kubernetes のゼロ インストルメンテーション アプリケーションの監視

アプリケーション コード内のインストルメンテーションはアプリケーション開発者の責任であるため、Azure コンテナー ソリューションとは無関係です。 ワークロードでは、次のようなソリューションを使用できます。

• Application Insights SDK
• OpenTelemetry ディストリビューション

ログとメトリック

すべての Azure コンテナー サービスには、アプリケーションとプラットフォームのログとメトリックの機能が用意されています。 アプリケーション ログは、ワークロードによって生成されるコンソール ログです。 プラットフォーム ログは、スケーリングやデプロイなど、アプリケーションの範囲外のプラットフォーム レベルで発生するイベントをキャプチャします。 メトリックは、ある時点のシステムの一部の側面を表す数値であり、システムのパフォーマンスと正常性を監視してアラートを生成できます。

Azure Monitor は、これらのサービスと統合される Azure の主要なログ記録およびメトリック サービスです。 Azure Monitor では、リソース ログ を使用して、さまざまなソースからログをカテゴリに分離し、メトリックを収集してリソースのパフォーマンスに関する分析情報を提供します。 各 Azure サービスから使用できるログとメトリックを決定する 1 つの方法は、各サービスのリソース ログ カテゴリと使用可能なメトリックを確認することです。

Container Apps では、すべての内部 Kubernetes ログが、ワークロード コンテナー ログを含むコンソール ログと、プラットフォーム関連のすべてのログを含むシステム ログという 2 つのカテゴリに抽象化されます。 メトリックの場合、Container Apps は Azure Monitor と統合して標準メトリックを収集し、高度なシナリオ向けの Dapr 統合を通じてカスタム メトリックをサポートします。

AKS では、Kubernetes 関連のログと、ログに記録される内容をきめ細かく制御できます。 AKS は、kubectl などのログ ストリーミング用の Kubernetes クライアント ツールとの完全な互換性を維持します。 メトリックの場合、AKS は Azure Monitor と統合してクラスターとノードのメトリックを収集します。 Prometheus と Grafana での視覚化を使用したカスタム メトリックの収集は可能ですが、手動でのセットアップと構成が必要です。

自動化された AKS には、特定の監視ツールが事前に構成されています。 メトリックの収集には Managed Prometheus を、視覚化には Managed Grafana を使用します。 クラスターとアプリケーションのメトリックは自動的に収集され、視覚化できます。 AKS Automatic は、ログとメトリックの収集のために Azure Monitor と統合されます。

Web App for Containers では、そのプラットフォーム (App Service) がコンテナー ワークロード専用でないため、リソース ログのいくつかのカテゴリが提供されます。 内部 Docker プラットフォームを管理するコンテナー固有の操作では、AppServicePlatformLogs ログ カテゴリが提供されます。 もう 1 つの重要なカテゴリは、スケーリングや構成の変更などのイベントをログに記録する AppServiceEnvironmentPlatformLogs です。 メトリックは Azure Monitor を使用して収集されるため、アプリケーションのパフォーマンスとリソース使用率を監視できます。

オペレーショナル エクセレンスのための Well-Architected フレームワーク

この記事では、ここで説明するコンテナー サービス機能の主な違いに焦点を当てます。 以下のサービスのオペレーショナル エクセレンス ガイダンス全体を確認するには、次の記事を参照してください。

• AKS
• コンテナ用ウェブアプリ

信頼性

信頼性 とは、障害に対応し、完全に機能し続けるシステムの能力を指します。 アプリケーション ソフトウェア レベルでは、ワークロードはキャッシュ、再試行、サーキット ブレーカー パターン、正常性チェックなどのベスト プラクティスを実装する必要があります。 インフラストラクチャ レベルでは、Azure は、ハードウェア障害や停電などの物理的な障害をデータセンターで処理する役割を担います。 エラーは引き続き発生する可能性があります。 ワークロード チームは、適切な Azure サービス レベルを選択し、可用性ゾーン間の自動フェールオーバーを実装するために必要な最小インスタンス構成を適用する必要があります。

適切なサービス レベルを選択するには、サービス レベル アグリーメント (SLA) と可用性ゾーンのしくみを理解する必要があります。

サービスレベル契約

信頼性は、一般に、SLA や復旧時間目標 (RTO) などの復旧メトリック ビジネス主導のメトリックによって測定されます。

Azure には、特定のサービス用の SLA が多数用意されています。 100% サービス レベルは存在しません。障害は常にソフトウェアとハードウェアで発生し、本質的には暴風雨や地震などで発生する可能性があるためです。 SLA は保証ではなく、金銭的に支援されたサービスの可用性に関する契約です。

最新の SLA と詳細については、Microsoft ライセンス Web サイトから Microsoft Online Services ドキュメント の最新の SLA をダウンロード。

無料プランと有料プラン

一般に、無料レベルの Azure サービスでは SLA が提供されないため、非運用環境に対してコスト効率の高い選択肢になります。 ただし、運用環境では、SLA を持つ有料レベルを選択することをお勧めします。

AKS のその他の要因

AKS には、コンポーネントと構成ごとに異なる SLA があります。

• コントロール プレーン。 Kubernetes API サーバーには個別の SLA があります。
• データ プレーン。 ノード プールでは、基になる VM SKU SLA が使用されます。
• 可用性ゾーン。 AKS クラスターで可用性ゾーンが有効になっている と、可用性ゾーン間で複数のインスタンスを実行する に応じて、2 つのプレーンに対して異なる SLA があります。

複数の Azure サービスを使用する場合、複合 SLA は、個々のサービス SLA とは異なり、より低くなる可能性があることに注意してください。

可用性ゾーンによる冗長性

可用性ゾーン は、1 つのリージョン内に独立した電力、冷却などを備える個別のデータセンターです。 結果として得られる冗長性により、複数リージョンアーキテクチャを実装する必要なく、障害の許容度が向上します。

Azure には、Azure がデータセンター リージョンを運用するすべての国/リージョンに可用性ゾーンがあります。 コンテナーの複数のインスタンスが可用性ゾーンをまたがることを許可するには、可用性ゾーンのサポートを提供する SKU、サービス レベル、リージョンを必ず選択してください。

たとえば、ハードウェアがホストされている可用性ゾーンで問題が発生した場合、1 つのインスタンスを実行するように構成されたアプリケーションまたはインフラストラクチャは使用できなくなります。 可用性ゾーンのサポートを完全に使用するには、コンテナーの最小構成が 3 つのゾーンに分散されたワークロードをデプロイする必要があります。

ヘルスチェックと自己修復

正常性チェック エンドポイントは、信頼性の高いワークロードにとって非常に重要です。 ただし、これらのエンドポイントの構築はソリューションの半分にすぎません。 残りの半分は、ホスティング プラットフォームの動作と、障害が発生した場合の方法を制御することです。

ヘルスプローブの種類をよりよく区別するには、Kubernetes の組み込み型プローブを見てください。

• Startup。 アプリケーションが正常に開始されたかどうかを確認します。
• 準備。 アプリケーションが受信要求を処理する準備ができているかどうかを確認します。
• Liveness。 アプリケーションがまだ実行中で応答性が高いかどうかを確認します。

もう 1 つの重要な考慮事項は、これらの正常性チェックがアプリケーションから要求される頻度 (内部粒度) です。 これらの要求の間隔が長い場合は、インスタンスが異常と見なされるまでトラフィックの処理を続ける可能性があります。

ほとんどのアプリケーションでは、HTTP(S) プロトコルを使用した正常性チェックがサポートされています。 ただし、これらのチェックを実行するために、TCP や gRPC などの他のプロトコルが必要な場合もあります。 正常性チェック システムを設計するときは、この点に注意してください。

正常性チェックは、Web App for Containers で実装するのが最も簡単です。 いくつかの重要な考慮事項があります。

• そのスタートアップ プローブは組み込まれており、変更することはできません。 コンテナーの開始ポートに HTTP 要求を送信します。 アプリケーションからの応答はすべて、正常な開始と見なされます。
• 準備プローブはサポートされていません。 スタートアップ プローブが成功した場合、コンテナー インスタンスは正常なインスタンスのプールに追加されます。
• ヘルスチェックは 1 分間隔で送信されます。 間隔を変更することはできません。
• 異常なインスタンスを内部負荷分散メカニズムから削除するために設定できる最小しきい値は 2 分です。 異常なインスタンスは、正常性チェックに失敗した後、少なくとも 2 分間トラフィックを取得します。 この設定の既定値は 10 分です。

一方、Container Apps と AKS ははるかに柔軟であり、同様のオプションを提供します。 具体的な違いについては、AKS には、Container Apps では使用できない正常性チェックを実行するための次のオプションが用意されています。

• gRPC のサポート
• 名前付きポート
• 実行コマンド

自動修復

無効なコンテナー インスタンスを特定し、それに対するトラフィックの送信を停止することは、開始です。 次の手順では、自動復旧を実装します。 自動復旧 は、異常な状態から復旧しようとしてアプリケーションを再起動するプロセスです。 3 つのコンテナー サービスの比較を次に示します。

• Web App for Containers では、正常性チェックが失敗した直後にコンテナー インスタンスを再起動するオプションはありません。 インスタンスが 1 時間失敗し続けた場合は、新しいインスタンスに置き換えられます。 もう 1 つの機能として、インスタンスを監視して再起動させる「自動復旧」がにあります。 健康診断とは直接関係ありません。 メモリ制限、HTTP 要求期間、状態コードなど、さまざまなアプリケーション メトリックが使用されます。
• コンテナー アプリと AKS は、ライブネス プローブが定義済みの障害しきい値に達した場合に、コンテナー インスタンスの再起動を自動的に試みます。

ダウンタイムが発生しないアプリケーションのデプロイ

ユーザーのダウンタイムを発生させずにアプリケーションをデプロイして置き換える機能は、信頼性の高いワークロードにとって非常に重要です。 この記事で説明する 3 つのコンテナー サービスはすべて、ダウンタイムゼロのデプロイをサポートしていますが、さまざまな方法でサポートされています。

アプリケーション アーキテクチャでは、ダウンタイムなしのデプロイもサポートする必要があることに注意してください。 ガイダンスについては、Azure Well-Architected Framework の を参照してください。

リソース制限

信頼できる共有環境のもう 1 つの重要なコンポーネントは、コンテナーのリソース使用量 (CPU やメモリなど) を制御することです。 1 つのアプリケーションがすべてのリソースを占有し、他のアプリケーションを不適切な状態のままにするシナリオを回避する必要があります。

• Web App for Containers: 1 つの App Service プランで複数のアプリケーション (コンテナー) をホストできます。 たとえば、2 つの CPU コアと 4 GiB の RAM を備えたプランを割り当てて、コンテナーで複数の Web アプリを実行できます。 ただし、いずれかのアプリを一定量の CPU またはメモリに制限することはできません。 これらはすべて、同じ App Service プラン リソースと競合します。 アプリケーション リソースを分離する場合は、追加の App Service プランを作成する必要があります。
• Container Apps: 環境内のアプリケーションごとに CPU とメモリの制限を設定できます。 ただし、許可される CPU とメモリの組み合わせは制限されます。 たとえば、1 つの vCPU と 1 GiB のメモリを構成することはできませんが、1 つの vCPU と 2 GiB のメモリを構成できます。 Container Apps 環境は、Kubernetes 名前空間に似ています。
• AKS: ノードにサポートするハードウェアがある限り、vCPU とメモリ の任意の組み合わせ選択できます。 クラスターをそのようにセグメント化する場合は、名前空間レベル でリソースを制限することもできます。

信頼性のための Well-Architected フレームワーク

この記事では、Azure のコンテナー サービス機能の主な違いについて説明します。 特定のサービスの完全な信頼性ガイダンスを確認する場合は、次の記事を参照してください。

• AKS の Well-Architected Framework のレビュー
• Container Apps の信頼性
• Azure App Service とその信頼性

結論

適切に設計されたソリューションは、ワークロードを成功させるために基盤を設定します。 ワークロードが増加し、チームがクラウドの取り組みを進めるにつれてアーキテクチャを調整できますが、特にネットワークに関する一部の決定は、大幅なダウンタイムや再デプロイなしでは取り消しが困難です。

一般に、Azure コンテナー サービスを比較すると、最も基盤となるインフラストラクチャが AKS によって表面化され、最も優れた制御と構成可能性が提供され、AKS Automatic は多くの運用タスクを自動化することで制御とシンプルさのバランスを取ります。

運用上のオーバーヘッドと複雑さの量は、AKS ワークロードにとって大きく変動します。 一部のチームでは、Microsoft マネージド アドオンと拡張機能、および自動アップグレード機能を使用することで、運用上のオーバーヘッドを大幅に削減できます。 他のお客様は、Kubernetes と CNCF エコシステムの完全な拡張性を活用するために、クラスターの完全な制御を好む場合があります。 たとえば、Microsoft ではマネージド GitOps 拡張機能として Flux を提供していますが、多くのチームは代わりに ArgoCD を独自にセットアップして操作することを選択します。

たとえば、CNCF アプリケーションを必要としない、運用経験が少ない、またはアプリケーション機能に集中することを好むワークロード チームは、PaaS オファリングを好む場合があります。 最初に Container Apps を検討することをお勧めします。

Container Apps と Web App for Containers はどちらも、同様のレベルの Microsoft が管理するインフラストラクチャを提供する PaaS オファリングですが、主な違いは、Container Apps が Kubernetes に近く、サービス検出、イベントドリブン自動スケーリング、dapr 統合などの追加のクラウドネイティブ機能 提供することです。 ただし、これらの機能を必要とせず、App Service のネットワークモデルとデプロイ モデルに精通しているチームは、Web App for Containers を好む場合があります。

一般化は、考慮する Azure コンテナー サービスの一覧を絞り込むのに役立ちます。 ただし、個々の要件を詳細に調べて、サービス固有の機能セットと照合することで、選択内容を確認する必要があることにも注意してください。

貢献者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

• Andre Dewes | シニア カスタマー エンジニア
• Xuhong Liu | シニア サービス エンジニア
• Marcos Martinez | シニア サービス エンジニア
• Julie Ng | シニア エンジニア

その他の共同作成者:

• Mick Alberts | テクニカル ライター
• Martin Gjoshevski | シニア カスタマー エンジニア
• Don High | プリンシパル カスタマー エンジニア
• Nelly Kiboi | サービス エンジニア
• Faisal Mustafa | シニア カスタマー エンジニア
• Walter Myers | プリンシパル カスタマー エンジニアリング マネージャー
• Sonalika Roy | シニア カスタマー エンジニア
• Paolo Salvatori | プリンシパル カスタマー エンジニア
• Victor Santana | プリンシパル カスタマー エンジニア

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

• AKS のドキュメント
• Container Apps のドキュメント
• App Service のドキュメント

関連リソース

• AKS - 設計と運用を計画する
• Azure Container Apps を使用してマイクロサービスをデプロイする