次の方法で共有

Azure Container Service を選択するためのアーキテクチャに関する一般的な考慮事項

  • [アーティクル]

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

メモ

この記事は、Azure Container Service の選択から始まるシリーズのパート 2 です。 これらのアーキテクチャに関する考慮事項のコンテキストを取得するには、まずその概要に関する記事を読むことを強くお勧めします。

概要

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

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

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

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

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

操作上の考慮事項

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

信頼性に関する考慮事項

  • サービス レベル アグリーメント
  • 可用性ゾーンを使用した冗長
  • 正常性チェックと自己復旧
  • ゼロダウンタイムのアプリケーションのデプロイ
  • リソース制限
  • 信頼性用 Well-Architected フレームワーク

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

Note

このガイドでのワークロードという用語は、ビジネス目標またはビジネス プロセスの実行をサポートするアプリケーション リソースのコレクションを指します。 ワークロードは、API やデータ ストアなどの複数のコンポーネントを使用します。このサービスは連携して、特定のエンド ツー エンド機能を提供します。

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

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

これらの考慮事項は、Well-Architected フレームワークの柱に固有ではありません。 ただし、Azure Container Service を選択する場合は、企業の要件に対する追加の調査と評価が必要です。

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

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

コンテナー アプリ AKS Web App for Containers
Linux のサポート ✅ ✅ ✅
Windows のサポート ❌ ✅ ✅
混在 OS のサポート ❌ ✅ ❌*

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

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

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

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

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

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

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

コンテナー アプリ AKS Web App for Containers
専用サブネット 従量課金プラン: オプション
専用プラン: 必須		 必須 省略可能
IP アドレスの要件 従量課金プラン: 「従量課金のみの環境」を参照してください。
専用プラン: 「ワークロード プロファイル環境」を参照してください。		 「AKS の Azure 仮想ネットワーク」を参照してください。 「App Service サブネットの要件」を参照してください。

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

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

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

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

  • 複数の併置ワークロード。
  • プライベート イングレスまたはパブリック イングレス。
  • クラスター (Container Apps と AKS の場合) または仮想ネットワーク内 (すべての Azure Container Service の場合) 内の東西トラフィックのアクセス制御フロー。

サブネットの計画

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

コンテナー アプリ AKS Web App for Containers
サブネット内に併置されたワークロードのサポート* ❌* ✅ なし*

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

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 アプリは、仮想ネットワークまたはインターネットからの東西または南北のトラフィックのアクセス制御をそれぞれ個別に管理します。

Note

リソースがデプロイされているサブネットのサイズを変更することはできません。 ワークロード コンポーネント全体の再デプロイが必要になり、ダウンタイムにつながる可能性がないように、ネットワークを計画するときは細心の注意を払います。

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

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

コンテナー アプリ AKS Web App for Containers
イングレス IP の数 1 つ 多数 App Service Environment: 1 つ
App Service Environment なし: 多数

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 Gateway のサポート

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

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

コンテナー アプリ AKS Web App for Containers
UDR のサポート 従量課金のみのプラン: ❌
ワークロード プロファイル プラン: ✅		 ✅ ✅
NAT Gateway のサポート 従量課金のみのプラン: ❌
ワークロード プロファイル プラン: ✅		 ✅ ✅

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

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

コンテナー アプリ AKS Web App for Containers
仮想ネットワークへのプライベート イングレス ✅ ✅ プライベート エンドポイントを介して
仮想ネットワークからのプライベート エグレス ✅ ✅ 仮想ネットワークの統合を介して
完全に抑制されたパブリック エンドポイント ✅ ✅ App Service Environment のみ
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 を制約なく使用できます。

コンテナー アプリ AKS Web App for Containers
プロトコルとポートのサポート HTTP (ポート 80)*
HTTPS (ポート 443)*
TCP (ポート 1 から 65535、80 と 443 を除く)		 TCP (任意のポート)
UDP (任意のポート)		 HTTP (ポート 80)
HTTPS (ポート 443)
WebSocket のサポート ✅ ✅ ✅
HTTP/2 のサポート ✅ ✅ ✅

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

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

負荷分散

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

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

コンテナー アプリ AKS Web App for Containers
レイヤー 4 ロード バランサー Azure マネージド 共同責任 Azure マネージド
レイヤー 7 ロード バランサー Azure マネージド 共有または自己管理 Azure マネージド

サービス検出

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

コンテナー アプリ AKS Web App for Containers
サービス検出 Azure マネージド FQDN 構成可能なKubernetes Azure マネージド FQDN

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

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

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

重要

Container Apps と AKS のみが、それぞれの環境内の内部 DNS スキームを介してサービス検出を提供します。 この機能により、Dev/Test 環境と運用環境全体の DNS 構成を簡略化できます。 たとえば、環境内またはクラスター内でのみ一意である必要がある任意のサービス名を使用してこれらの環境を作成し、Dev/Test 環境と運用環境で同じにすることができます。 Web App for Containers では、Azure DNS との競合を回避するために、サービス名が異なる環境間で一意である必要があります。

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

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

コンテナー アプリ AKS Web App for Containers
カスタム ドメインを構成する すぐに利用できる BYO すぐに利用できる
Azure FQDN のマネージド TLS すぐに利用できる 該当なし すぐに利用できる
カスタム ドメインのマネージド TLS プレビュー段階 BYO 既定または BYO

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

相互 TLS

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

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

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

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

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

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

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

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

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

セキュリティ比較の概要

Container Apps、AKS、Web App for Containers を含む Azure サービスは、Key Vault やマネージド ID などの主要な Azure セキュリティ 製品と統合します。

このガイドのサービスの中で、AKS は、基盤となるコンポーネントを表面化することによって、最も高い構成可能性と拡張性を提供します。これらのコンポーネントは、多くの場合、構成オプションによって保護できます。 たとえば、顧客は、構成オプションを使用して、Kubernetes API サーバーに対するローカル アカウントを無効にしたり、基盤となるノードへの自動更新を有効にしたりできます。

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

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

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

重要

このセクションは、Azure Resource Manager API をコントロール プレーンとして使用する Web App for Containers には関係ありません。

ID ベースのセキュリティ

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

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

コンテナー アプリ AKS
Kubernetes API アクセス制御 アクセス権なし フル アクセス

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

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

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

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

コンテナー アプリ AKS
Kubernetes API のネットワーク セキュリティ PaaS では構成できません 構成可能: パブリック IP またはプライベート IP

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

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

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

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

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

コンテナー アプリ AKS Web App for Containers
ネットワーク ポリシー 従量課金プラン: ❌
専用プラン: ❌		 ✅ ❌

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

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

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

コンテナー アプリ AKS Web App for Containers
ネットワーク セキュリティ グループ 従量課金プラン: ✅
専用プラン: ✅		 ✅ ✅ VNET 統合アプリ: エグレスのみ

イングレスの IP 制限

通常、ネットワーク トラフィック制限は、上記のレイヤー 4 ルールを介して適用されます。 ただし、仮想ネットワークを統合しないアプリケーションの PaaS シナリオでは、アプリケーション レイヤー上のトラフィックを制限すると便利な場合があります。

Container Apps と Web App for Containers により、個々のアプリケーションでの受信トラフィックに対する組み込みのソース IP 制限が生じます。

コンテナー アプリ AKS Web App for Containers
アプリケーション層のイングレス IP 制限 すぐに利用できる 自己管理型またはマネージド アドオン経由 すぐに利用できる
リソース消費 - クラスター リソースを使用する -

AKS ワークロードの場合、実装は選択したイングレス コントローラーによって異なります。 セルフマネージド と Azure マネージド アプリケーション ルーティング アドオンの両方で、クラスター リソースが消費されます。

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

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

Key Vault の統合

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

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

コンテナー アプリ AKS Web App for Containers
Key Vault の統合 ✅ ✅ ✅

詳細については、以下を参照してください:

マネージド ID のサポート

マネージド ID が割り当てられたアプリケーションは、パスワードなしで Azure リソースにアクセスできます。 このガイドにメンションされているすべてのコンテナー サービスは、マネージド ID をサポートします。

コンテナー アプリ AKS Web App for Containers
マネージド ID のサポート ✅ ✅ ✅

詳細については、以下を参照してください:

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

脆弱性への脅威に対する保護も重要です。 Defender for Containers を使用することをお勧めします。 脆弱性の評価は Azure Container Registry でサポートされているため、この記事で説明されているだけでなく、任意の Azure Container Service で使用できます。 ただし、Defender for Containers ランタイム保護は AKS でのみ使用できます。

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

コンテナー アプリ AKS Web App for Containers
ランタイムの脅威に対する保護 ❌ ✅ ❌

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

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

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

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

セキュリティ ベースラインでは、ハードウェアの暗号化やログ記録など、この記事の範囲外である他の Azure 統合について説明します。

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

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

AKS のより完全なセキュリティ ガイダンスについては、「Well-Architected フレームワークのレビュー - AKS」を参照してください。

操作上の考慮事項

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

更新プログラムとパッチ

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

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

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

コンテナー アプリ AKS Web App for Containers
コントロール プレーンの更新 プラットフォーム 顧客 プラットフォーム
ホストの更新プログラムとパッチ プラットフォーム 顧客 プラットフォーム
コンテナー イメージの更新とパッチ 顧客 Customer 顧客

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

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

スケーラビリティ

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

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

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

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

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

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

水平スケーリング とは、VM ノードなどの新しいインフラストラクチャを使用して容量を増減する機能を指します。 スケーリングの増減中に、Container Apps の従量課金レベルによって、基になる仮想マシンが抽象化されます。 残りの Azure Container Service では、標準の Azure Resource Manager API を使用して水平スケーリング戦略を管理します。

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

コンテナー アプリ AKS Web App for Containers
インフラストラクチャのスケール インとスケールアウト 従量課金プラン:該当なし
専用プラン: 構成可能		 構成可能 構成可能
柔軟なハードウェア プロビジョニング 従量課金プラン:該当なし
専用プラン: ワークロード プロファイルで抽象化		 任意の VM SKU 抽象化。 App Service プランを参照してください。

重要

Container Apps 専用プラン (ワークロード プロファイル) と Web App for Containers (App Service プラン) で使用できるハードウェア プロビジョニング オプションは、AKS ほど柔軟ではありません。 ニーズが満たされていることを確認するには、各サービスで利用可能な SKU について理解する必要があります。

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

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

コンテナー アプリ AKS Web App for Containers
コンテナーのスケールアウト HTTP、TCP、またはメトリックベース (CPU、メモリ、イベントドリブン)。 メトリックベース (CPU、メモリ、またはカスタム)。 手動、メトリックベース、または自動 (プレビュー)。
イベント ドリブンのスケーラビリティ はい。 クラウドネイティブ。 はい。 クラウドネイティブ。 追加の構成が必要です。 はい。 Azure リソース固有。

可観測性

ワークロード インストルメンテーション

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

  • 自動インストルメンテーション。 コードの変更が不要な方法。
  • 手動インストルメンテーション。 SDK やクライアントを統合して構成するために必要な最小限のコード変更。
コンテナー アプリ AKS Web App for Containers
プラットフォームを介した自動インストルメンテーション ❌ ❌ 部分的なサポート*
エージェントを介した自動インストルメンテーション ❌ 部分的なサポート* 該当なし
手動インストルメンテーション SDK または OpenTelemetry 経由 SDK または OpenTelemetry 経由 SDK または OpenTelemetry 経由

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

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

ログ

すべての Azure Container Service には、アプリケーションとプラットフォームのログ機能が用意されています。 アプリケーション ログ は、ワークロードによって生成されるコンソール ログです。 プラットフォーム ログ は、スケーリングやデプロイなど、アプリケーションの範囲外のプラットフォーム レベルで発生するイベントをキャプチャします。

コンテナー サービスのログ機能の主な違いは、プラットフォームのログ記録に関連します。ログに記録される内容と、ログを内部で整理する方法です。 Azure Monitor は、これらのサービスと統合される Azure のメイン ログ サービスです。 Monitor では、リソース ログを使用して、さまざまなソースから取得したログをカテゴリに分けます。 各 Azure サービスから使用できるログを特定する 1 つの方法は、各サービスで使用可能なリソース ログ カテゴリを調べる方法です。

コンテナー アプリ AKS Web App for Containers
ログ ストリーミングのサポート (リアルタイム ストリーミング) ✅ ✅ ✅
Azure Monitor のサポート ✅ ✅ ✅
Azure Monitor リソース ログ コンソールとシステム Kubernetes API サーバー、監査、スケジューラ、クラスター オートスケーラーなど ConsoleLogs、HTTPLogs、EnvironmentPlatformLogs など

テーブル内の各リソース ログの詳細な説明については、テーブル内のリンクを選択します。

コンテナー サービスのログ機能の簡単な概要を次に示します。

  • Container Apps では、内部のすべての Kubernetes ログが 2 つのカテゴリに抽象化されます。 1 つ目はコンソール ログと呼ばれ、ワークロード コンテナー ログが含まれています。 2 つ目のシステム カテゴリには、プラットフォーム関連のすべてのログが含まれています。
  • AKS では、Kubernetes 関連のすべてのログと、ログに記録できる内容をきめ細かく制御できます。 また、kubectl などのログ ストリーミング用の Kubernetes クライアント ツールとの完全な互換性も保持されます。
  • Web App for Containers では、そのプラットフォーム (App Service) がコンテナー ワークロード専用ではないので、リソース ログの多くのカテゴリが提供されます。 内部 Docker プラットフォームを管理するコンテナー固有の操作では、AppServicePlatformLogs ログ カテゴリが提供されます。 もう 1 つの重要なカテゴリは、スケーリングや構成の変更などのイベントをログに記録する AppServiceEnvironmentPlatformLogs です。

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

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

信頼性

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

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

サービス レベル アグリーメント

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

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

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

Free レベルと有料レベル

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

AKS の追加要素

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

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

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

可用性ゾーンを使用した冗長

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

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

機能 コンテナー アプリ AKS Web App for Containers
可用性ゾーンのサポート [完全] [完全] [完全]

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

正常性チェックと自己復旧

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

正常性プローブの種類をよりよく区別するには、Kubernetes のプローブの組み込みタイプを見てください。

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

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

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

コンテナー アプリ AKS Web App for Containers
Startup probe ✅ ✅ 部分的サポート
Readiness probe ✅ ✅ ❌
Liveness probe ✅ ✅ ✅
間隔の細分性 秒 秒 1 分
プロトコルのサポート HTTP(S)
TCP		 HTTP(S)
TCP
gRPC		 HTTP(S)

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

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

一方、Container Apps と AKS では同様のオプションが提供されますが、はるかに柔軟です。 具体的な違いとして、AKS には、コンテナー アプリでは利用できない、健全性チェックを実行するための次のオプションが用意されています。

自動復旧

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

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

ゼロダウンタイムのアプリケーションのデプロイ

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

コンテナー アプリ AKS Web App for Containers
ゼロダウンタイム戦略 ローリング アップデート ローリング アップデートとその他すべての Kubernetes 戦略 デプロイ スロット

アプリケーション アーキテクチャは、ゼロ ダウンタイム展開もサポートしている必要があることに注意してください。 ガイド用に、「Azure Well-Architected フレームワーク」を参照してください。

リソース制限

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

コンテナー アプリ AKS Web App for Containers
リソースの制限 (CPU またはメモリ) アプリ/コンテナーあたり アプリ/コンテナーあたり
名前空間あたり		 App Service プランごと
  • 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 のコンテナー サービス機能の主な違いについて説明します。 特定のサービスの完全な信頼性ガイダンスを確認する場合は、次の記事を参照してください。

まとめ

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

一般に、Azure の各コンテナー サービスを比較すると、ある点が明らかになります。それは、AKS が最も基盤となるインフラストラクチャを明らかにしているため、最も柔軟に構成でき拡張性に優れているということです。 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 Container Service の一覧を絞り込むのに役立ちます。 ただし、個々の要件を詳細に調べて、サービス固有の機能セットと照合することで、選択内容を検証する必要があることにも注意してください。

共同作成者

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

プリンシパルの作成者:

その他の共同作成者:

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

次のステップ