Azure Container Service をスケールする

  • [アーティクル]

Azure には、多様なワークロード、アーキテクチャ、ビジネス要件に対応するように設計されたさまざまなコンテナー ホスティング サービスが用意されています。 このコンテナー サービスの選択ガイドは、ワークロードのシナリオと要件に最適な Azure Container Service を理解するのに役立ちます。

Note

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

このガイドの使用方法

このガイドには、この概要記事と、すべてのワークロードの種類に共通の考慮事項に関する記事の 2 つの記事が含まれています。

Note

コンテナ化にまだコミットしていない場合は、ワークロードのホストに使用できるその他のコンピューティング オプションの詳細について、「Azure コンピューティング サービスの選択」を参照してください。

この紹介記事では、このガイドの対象となる Azure コンテナー サービスと、構成可能性と独自のソリューション (顧客管理アプローチと Microsoft 管理アプローチなど) の間のトレードオフの観点からサービス モデルをどのように比較するかについて説明します。 サービス モデルのユーザー設定に基づいて候補となるサービスを特定したら、次の手順では、ネットワーク、セキュリティ、運用、信頼性に関する共通の考慮事項に関する記事を確認して、ワークロード要件に照らしてオプションを評価します。

このガイドでは、ワークロードの技術面の要件、サイズ、複雑さ、ワークロードのチームの専門知識に基づいて、行う必要があるトレードオフを考慮します。

このガイドの対象となる Azure Container Service

このガイドでは、Azure が現在提供しているコンテナー サービスのサブセットに焦点を当てています。 このサブセットは、Web アプリケーションと API、ネットワーク、可観測性、開発者ツール、および操作のための高度な機能セットを提供します。 次のコンテナー サービスを比較します。

Container Apps ロゴ

Azure Container Apps は、フル マネージドの Kubernetes ベースのアプリケーション プラットフォームであり、インフラストラクチャを調整することなく、コードまたはコンテナーから HTTP アプリと非 HTTP アプリをデプロイするのに役立ちます。 詳細については、Azure Container Apps のドキュメントを参照してください。

AKS ロゴ

Azure Kubernetes Service (AKS) は、コンテナ化されたアプリケーションを実行するためのマネージド Kubernetes サービスです。 AKS を使用すると、マネージド アドオンと拡張機能を利用して、最も広範なレベルの構成可能性を維持しながら、機能を追加できます。 詳しくは、AKS についてのドキュメントをご覧ください。

App Service ロゴ

Web App for Containers は、Azure App Service の機能で、組み込みのインフラストラクチャ メンテナンス、セキュリティ パッチの適用、スケーリング、診断ツールを使用して HTTP ベースの Web アプリをホストするために完全に管理されたサービスです。 詳細については、App Service のドキュメントを参照してください。

すべての Azure Container Service の全一覧については、「コンテナー サービスの製品カテゴリページ」を参照してください。

サービス モデルに関する考慮事項

サービス モデルは、全体的なシンプルさと使いやすさと引き換えに、Azure Container Service が提供する柔軟性と制御のレベルに関する幅広い分析情報を提供します。

サービスとしてのインフラストラクチャ (IaaS) やサービスとしてのプラットフォーム (PaaS) など、サービス モデルに関する用語と概念の一般的な概要については、「クラウドにおける共同責任」を参照してください。

Azure コンテナー ソリューションのサービス モデルの比較

AKS

IaaS と PaaS のハイブリッドである AKS はシンプルさよりも制御を優先します。 AKS は基になるコア インフラストラクチャの管理を効率化しますが、VM ベースのプラットフォームであるため引き続きアプリケーションに公開されており、セキュリティとビジネス継続性を確保するために、ファイルの部分置換を適用するなどの適切なガードレールとプロセスが必要です。 コンピューティング インフラストラクチャは、Azure Load Balancer など、サブスクリプションで直接ホストされる追加の Azure リソースによってサポートされます。

AKS は Kubernetes API サーバーへのアクセスも提供します。これにより、コンテナー オーケストレーションをカスタマイズし、Cloud Native Computing Foundation (CNCF) からプロジェクトをデプロイできます。 そのため、Kubernetes を初めて使用するワークロード チームは、適応に時間がかかる可能性があります。 コンテナ化されたソリューションを初めて使用する場合は、この適応までにかかる時間が抑止力になる可能性があります。 次の PaaS ソリューションの方が、エントリの障壁は低いでしょう。 要件によって移行する必要が生じたら、Kubernetes に移行できます。

Azure Container Apps

PaaS オファリングである Container Apps は、コントロールとシンプルさのバランスの取れたサービスです。 サーバーレスコンピューティング オプションと専用のコンピューティング オプションの両方が用意されており、オペレーティング システムにパッチを適用したり、アプリケーションの周りにガードレールを構築したりする負担が取り除かれます。 また、Container Apps はコンテナー オーケストレーション API を完全に抽象化し、チームが既に理解している可能性がある Azure API を通じて、主要な機能のサブセットを提供します。 さらに、レイヤー 7 のイングレス、トラフィックの分割、A/B テスト、アプリケーション ライフサイクル管理はすべて、すぐに使用できます。

Web App for Containers

Web App for Containers も PaaS オファリングですが、Container Apps よりもシンプルで制御機能が少なくなります。 コンテナー オーケストレーションは抽象化されますが、適切なスケーリング、アプリケーション ライフサイクル管理、トラフィック分割、ネットワーク統合、可観測性が提供されます。

ホスティング モデルに関する考慮事項

AKS クラスターなどの Azure リソースを使用して、複数のワークロードをホストできます。 これにより、運用を効率化し、全体的なコストを削減できます。 このパスを選択した場合、いくつかの重要な考慮事項を次に示します。

  • AKS は、一般的に複数のワークロードまたは異なるワークロード コンポーネントをホストするために使用されます。 名前空間、アクセス制御、ネットワーク制御などの Kubernetes ネイティブ機能を使用して、セキュリティ要件を満たすことで、これらのワークロードとコンポーネントを分離することができます。

    Kubernetes API で提供される追加機能が必要で、ワークロード チームが Kubernetes クラスターを運用するのに十分な経験がある場合は、単一ワークロード シナリオで AKS を使用することもできます。 Kubernetes の経験が浅いチームでも、Azure マネージド アドオンやクラスターの自動アップグレードなどの機能を利用して運用オーバーヘッドを削減することで、独自のクラスターを正常に運用できます。

  • Container Apps は、共有セキュリティ境界を持つ単一のワークロードをホストするために使用する必要があります。 Container Apps には、コンテナー アプリ環境と呼ばれる最上位レベルの論理境界が 1 つあり、セキュリティが強化された境界としても機能します。 詳細なアクセス制御を追加するためのメカニズムはありません。 たとえば、環境内の通信は無制限であり、すべてのアプリケーションが 1 つの Log Analytics ワークスペースを共有します。

    ワークロードに複数のコンポーネントと複数のセキュリティ境界がある場合は、複数の Container Apps 環境をデプロイするか、代わりに AKS を使用することを検討してください。

  • Web App for Containers は、App Service の機能です。 App Service では、アプリケーションを App Service プランと呼ばれる課金境界にグループ化します。 アプリケーション レベルでロールベースのアクセス制御 (RBAC) の範囲を設定できるため、1 つのプランで複数のワークロードをホストしたいと思われるかもしれません。 しかし、ノイジーネイバー問題を回避するために、プランごとに 1 つのワークロードをホストすることをお勧めします。 1 つの App Service プラン内のすべてのアプリは、同じ割り当てられたコンピューティング、メモリ、ストレージを共有します。

    ハードウェアの分離を検討する場合は、App Service プランは通常、他の Azure 顧客と共有されているインフラストラクチャで実行されることを認識する必要があります。 専用 VM には Dedicated レベルを、専用仮想ネットワーク内の専用 VM には Isolated レベルを選択できます。

一般に、すべての Azure Container Service は、複数のコンポーネントを持つ複数のアプリケーションをホストできます。 ただし、Container Apps と Web App for Containers は、1 つのチームがアプリケーションを所有して実行する場合、単一のワークロード コンポーネントまたは同様のライフサイクルを共有する複数の高度に関連するワークロード コンポーネントに適しています。

関連のない可能性があるさまざまなアプリケーション コンポーネントまたはワークロードを 1 つのホストでホストする必要がある場合は、AKS を検討してください。

制御と使いやすさのトレードオフ

AKS は最も様々な構成が可能ですが、この構成可能性の高さにより他のサービスと比較して運用オーバーヘッドが増加します。 Container Apps と Web App for Containers はどちらも、Microsoft が管理する機能のレベルが似ている PaaS サービスですが、Web App for Containers では、インターフェイスを使い慣れている既存の Azure PaaS のお客様を対象としており、シンプルさが強調されています。

大まかな指針

一般に、よりシンプルなサービスは、インフラストラクチャよりも機能開発に重点を置くお客様に適している傾向があります。 高い構成可能性を必要とし、独自のインフラストラクチャを管理するために必要なスキル、リソース、および業務上の正当な理由があるお客様には、より多くの制御を提供するサービスが適している傾向があります。

すべてのワークロード共通の考慮事項

ワークロード チームは特定のサービス モデルを好む場合がありますが、そのモデルは組織全体の要件を満たしていない可能性があります。 たとえば、開発者は運用上のオーバーヘッドを減らしたいと思うかもしれませんが、セキュリティ チームにとってこの種のオーバーヘッドは、コンプライアンス要件を満たすために必要だと考えるかもしれません。 適切なトレードオフを行うために、チームで共同作業を行う必要があります。

共通の考慮事項は広範囲に及ぶことに注意してください。 ワークロードの種類だけでなく、組織内でのお客様の役割によって、サブセットのみが関連する場合もあります。

次の表は、サービス機能の比較を含む考慮事項の概要を示しています。 各カテゴリの考慮事項を確認し、お客様のワークロードの要件と比較してください。

カテゴリ 概要
ネットワークに関する考慮事項 Azure Container Service でのネットワークは、シンプルさと構成可能性の好みによって異なります。 AKS は高度に構成可能であり、ネットワーク フローを広範に制御できますが、より多くの運用作業が必要です。 Container Apps には、Azure で管理されるネットワーク機能が用意されています。 これは、App Service に精通しているお客様向けに調整された AKS と Web App for Containers の中間的なサービスです。

ワークロードを再デプロイせずに変更することは困難なため、ネットワーク設計上の決定によっては長期的な結果を招く可能性があることを認識することが重要です。 IP アドレスの計画、負荷分散の責任、サービス検出方法、プライベート ネットワーク機能など、いくつかの要因は、サービスによって異なります。 サービスが特定のネットワーク要件を満たす方法を慎重に確認する必要があります。
セキュリティに関する考慮事項 Container Apps、AKS、Web App for Containers はすべて、Azure Key Vault やマネージド ID などの主要な Azure セキュリティ 製品との統合が可能です。 AKS には、ランタイム脅威保護やネットワーク ポリシーなどの追加機能が用意されています。 Container Apps のような PaaS サービスでは提供されるセキュリティ機能が少ないように見えるかもしれませんが、これはひとつには、基になるインフラストラクチャ コンポーネントの多くが Azure によって管理され、顧客に公開されないためにリスクが軽減されることによるものです。
操作上の考慮事項 AKS は最もカスタマイズ性が高いですが、より多くの運用作業が必要です。 これに対し、Container Apps や Web App for Containers などの PaaS ソリューションでは、Azure で OS の更新などのタスクを処理できます。 スケーラビリティとハードウェア SKU の柔軟性は非常に重要です。 AKS には柔軟なハードウェア オプションが用意されているのに対し、Container Apps と Web App for Containers は予め構成されています。 AKS でのアプリケーションのスケーラビリティは、唯一お客様が責任を負う部分です。 Container Apps と Web App for Containers では、より合理化されたアプローチが提供されます。
信頼性に関する考慮事項 Web App for Containers と Container Apps の正常性プローブ設定は、使い慣れた Azure Resource Manager API を使用するため、AKS の構成よりも合理化されています。 AKS では、Kubernetes API を使用する必要があります。 また、アプリケーション インスタンスを適切にスケジュールするために、Kubernetes ノード プールのスケーラビリティと可用性を管理する追加の責任を負う必要があります。 これらの要件により、AKS のオーバーヘッドが増えます。

さらに、AKS ではコントロール プレーンとノード プールがそれぞれ独自の SLA があり、それに応じて複合化する必要があるため、Container Apps と Web App for Containers の SLA は AKS の SLA よりも簡単です。 すべてのサービスは、それを提供するデータセンターでゾーン冗長性が提供されています。

上記の考慮事項を確認しても、最適なサービスが見つからない場合があります。 それは完全に正常です。

トレードオフの評価

クラウド サービスの選択は簡単ではありません。 クラウド コンピューティングの複雑さ、多くのチーム間での共同作業、人、予算、時間を含むリソースの制約を考えると、すべてのソリューションにトレードオフがあります。

特定のワークロードでは、一部の要件が他の要件よりも重要になる可能性があることに注意してください。 たとえば、アプリケーション チームは Container Apps のような PaaS ソリューションを選択したくても、セキュリティ チームが Kubernetes ネットワーク ポリシーを使用する AKS 専用の機能である、コロケーションされたワークロード コンポーネント間の既定で拒否するネットワーク制御が必要なため、AKS を選択することがあります。

最後に、上記の共通の考慮事項は、最も一般的な要件が含まれていますが、すべてを網羅しているわけではでありません。 決定を確定する前に、ワークロード チームの責任として希望するサービスの機能セットに対してすべての要件を調査してください。

まとめ

このガイドでは、Azure Container Service を選択するときに直面する最も一般的な考慮事項について説明します。 これは、ワークロード チームが十分な情報を得たうえでの決定を行えるように設計されています。 このプロセスは、クラウド サービス モデルの選択から始まります。これには、どの程度の制御レベルが必要なのかを決定することが含まれます。 制御を求めれば、シンプルさが犠牲になります。 言い換えると、これは自己管理インフラストラクチャと Microsoft が管理するインフラストラクチャの間で適切なバランスを見つけるプロセスなのです。

どのサービス モデル (PaaS か IaaS か) を希望するのかということだけに基づいて Azure Container Service を選択できるワークロード チームもいれば、 サービス固有の機能がワークロードまたは組織の要件にどのように対処するかを決定するために、さらなる調査が必要となるチームもあります。

やり直しが難しい決定を回避するために、デュー デリジェンスを組み込むだけでなく、すべてのワークロード チームがこのガイドを使用する必要があります。 ただし、開発者がサービスを試して理論ではなく経験に基づいて決定するまで、決定は確定されません。

共同作成者

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

プリンシパルの作成者:

その他の共同作成者:

次のステップ

この記事で取り上げたサービスの共有アーキテクチャに関する考慮事項について説明します。

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