次の方法で共有

Azure コンテナーサービスを選択する

  • [アーティクル]

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

メモ

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

このガイドの使用方法

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

メモ

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

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

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

このガイドの対象となる Azure コンテナー サービス

このガイドでは、Azure が現在提供しているコンテナー サービスのサブセットに焦点を当てています。 このサブセットは、Web アプリケーションと API、ネットワーク、監視、開発者ツール、運用に適した成熟した機能セットを提供します。 次のコンテナー サービスを比較します。

Azure Container Apps ロゴ

Azure Container Apps プラットフォームを使用すると、オーケストレーションやインフラストラクチャを気にすることなく、コンテナ化されたアプリケーションを実行できます。 詳細については、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 コンテナー サービスが提供する柔軟性と制御のレベルに関する最も広範な分析情報を提供します。

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

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

AKS

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

AKS は Kubernetes API サーバーへのアクセスも提供します。これにより、コンテナー オーケストレーションをカスタマイズし、Cloud Native Computing Foundation (CNCF) からプロジェクトをデプロイできます。 そのため、Kubernetes を初めて使用するワークロード チームには、習得に多大な労力が求められます。 コンテナー化されたソリューションを初めて使用する場合は、この学習曲線を考慮する必要があります。 次の PaaS ソリューションは、最初の障壁を下げます。 要件が満たされた場合、Kubernetes に移行できます。

AKS Automatic

AKS 自動 は、複雑なクラスター管理タスクを自動化することで Kubernetes の導入を簡素化し、Kubernetes の高度な専門知識の必要性を軽減します。 Kubernetes の柔軟性と拡張性を維持しながら、より合理化された PaaS のようなエクスペリエンスを提供します。 Azure では、クラスターのセットアップ、ノード のプロビジョニング、スケーリング、セキュリティ修正プログラムの適用が処理され、既定でいくつかのベスト プラクティス構成が適用されます。 これにより、運用作業は減りますが、使用可能なトポロジ オプションのセットが制限されます。

メモ

このガイドでは、該当する場合は AKS Standard と AKS Automatic を区別します。 それ以外の場合は、記載された機能は、Standard プランと自動プランの両方で同じ機能を持つと見なすことができます。

Azure コンテナ アプリケーション (Azure Container Apps)

Azure Container Apps は Kubernetes 上の抽象化レイヤーであり、基になるインフラストラクチャを直接管理しなくてもアプリを実行およびスケーリングできます。 Container Apps には、サーバーレスと専用の両方のコンピューティング オプションが用意されており、アプリケーションで使用できるコンピューティング リソースの種類と量を完全に制御できます。 Container Apps では、コンテナー オーケストレーション API を抽象化しながら、レイヤー 7 のイングレス、トラフィックの分割、A/B テスト、アプリケーション ライフサイクル管理などの主要な機能に直ちにアクセスできます。

コンテナ向けWebアプリケーション

Web App for Containers も PaaS で用意されていますが、Container Apps よりもシンプルで制御性が低くなります。 コンテナー オーケストレーションは抽象化されますが、適切なスケーリング、アプリケーション ライフサイクル管理、トラフィックの分割、ネットワーク統合、監視が引き続き提供されます。

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

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

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

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

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

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

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

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

一般に、すべての Azure コンテナー サービスは、複数のコンポーネントを持つ複数のアプリケーションをホストできます。 ただし、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 コンテナー サービスでのネットワークは、シンプルさと構成可能性の好みによって異なります。 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 でのアプリケーションのスケーラビリティはお客様の責任です。つまり、任意の Kubernetes 互換ソリューションを適用できます。 AKS Automatic、Container Apps、Web App for Containers では、よりシンプルなアプローチに重点を置きます。
信頼性に関する考慮事項 Web App for Containers と Container Apps の正常性プローブの構成は AKS と比較して制限されますが、使い慣れた Azure Resource Manager API を使用するため、セットアップは簡単です。 AKS では、Kubernetes API を使用する必要があります。 また、アプリケーション インスタンスを適切にスケジュールするために、Kubernetes ノード プールのスケーラビリティと可用性を管理する追加の責任を負う必要があります。 これらの要件により、AKS の運用作業が増えます。

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

上記の考慮事項を確認した後も、完全に適合するものが見つからなかった可能性があります。 それが正常です。

トレードオフの評価

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

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

最後に、上記の共通の考慮事項には、最も一般的な要件が含まれていますが、包括的ではありません。 最終決定を行う前に、優先サービスの機能セットに対してすべての要件を調査するのは、ワークロード チームの責任です。

結論

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

多くのワークロード チームは、優先されるサービス モデル (PaaS と IaaS との比較) のみに基づいて Azure コンテナー サービスを選択できます。 他のチームは、サービス固有の機能がワークロードまたは組織の要件にどのように対処するかを決定するにあたって、さらに調査する必要があります。

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

貢献者

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

プリンシパルの作成者:

その他の共同作成者:

次のステップ

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

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