次の方法で共有

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

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

メモ

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

概要

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

メモ

コンテナー化にコミットしていない場合は、ワークロードをホストする 別のコンピューティング オプションを選択 します。

この入門記事では、このガイドで取り上げる Azure コンテナー サービスの概要を説明し、構成可能性と、顧客が管理する方法と Microsoft が管理するアプローチなどの定義済みのソリューションに基づいてサービス モデルを比較します。 サービス モデルの基本設定に基づいて候補サービスを特定したら、次の手順では、ネットワーク、セキュリティ、運用、信頼性に関する 共有の考慮事項 に関する記事を確認して、ワークロード要件に照らしてオプションを評価します。

このガイドは、ワークロードの技術的要件、サイズ、複雑さに基づいてトレードオフを評価するのに役立ちます。 また、情報に基づく意思決定を確実にするために、チームの専門知識も考慮します。

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

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

Azure Container Apps ロゴ

Azure Container Apps プラットフォームを使用すると、オーケストレーションやインフラストラクチャを気にすることなく、コンテナ化されたアプリケーションを実行できます。 詳細については、Container Apps のドキュメントを参照してください。

AKS ロゴ

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

App Service ロゴ

Web App for Containers は、Azure App Service の機能です。 App Service は、組み込みのインフラストラクチャ メンテナンス、セキュリティ 修正プログラムの適用、スケーリング、診断ツールを備える HTTP ベースの Web アプリをホストするためのフル マネージド サービスです。 詳細については、App Service のドキュメントを参照してください。

Azure コンテナー サービスの完全な一覧については、「 Azure 上のコンテナー」を参照してください。

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

サービス モデルは、各 Azure コンテナー サービスが提供する柔軟性と制御の量を理解するのに役立ちます。 複雑なサービスでは制御が増えますが、サービスが単純な場合は管理が容易になりますが、カスタマイズは制限されます。

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

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

Azure Kubernetes Service (AKS)

AKS は、シンプルさよりも制御に重点を置く IaaS と PaaS の組み合わせです。 コンテナーを調整するための標準システムである Kubernetes を使用します。 AKS は、基になるコア インフラストラクチャの管理を合理化します。 ただし、この仮想マシン (VM) ベースのプラットフォームはアプリケーションに公開されており、セキュリティとビジネス継続性を確保するために、修正プログラムの適用などの適切なガードレールとプロセスが必要です。 コンピューティング インフラストラクチャは、Azure ロード バランサー、コンテナー レジストリ、アプリケーション ゲートウェイなど、サブスクリプションで直接ホストされる追加の Azure リソースによってサポートされます。

AKS は Kubernetes API サーバーへのアクセスを提供します。これにより、コンテナー オーケストレーションをカスタマイズし、Cloud Native Computing Foundation から補助アプリケーションをデプロイできます。 その結果、Kubernetes を初めて使用するワークロード チームは、重要な学習曲線に直面します。 コンテナー化されたソリューションに慣れていない場合は、この学習曲線を考慮する必要があります。 次の PaaS ソリューションは、エントリの障壁を低くします。 要件に応じて Kubernetes に移行できます。

AKS 自動

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

メモ

このガイドでは、必要に応じて AKS Standard と AKS Automatic を区別します。 それ以外の場合は、説明されている機能が両方のオファリングで一貫していると想定できます。

Container Apps

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

Web App for Containers

Web App for Containers は、コンテナー アプリと比較してコントロールよりもシンプルさを優先する PaaS オファリングです。 スケーリング、アプリケーション ライフ サイクル管理、トラフィックの分割、ネットワーク統合、可観測性を引き続きサポートしながら、コンテナー オーケストレーションを抽象化します。

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

AKS クラスターなどの Azure リソースを使用して、複数のワークロードをホストできます。 このアプローチは、全体的なコストを削減する運用を合理化するのに役立ちます。 このオプションを選択する場合は、次の機能を検討してください。

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

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

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

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

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

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

一般に、すべての Azure コンテナー サービスは、複数のコンポーネントを持つ複数のアプリケーションをホストできます。 ただし、Container Apps と Web App for Containers は、同じようなライフ サイクルを共有し、1 つのチームがアプリケーションを所有して実行する 1 つのワークロード コンポーネントまたは密接に関連する複数のワークロード コンポーネントに最適です。

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

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

AKS は最もコンフィギュラビリティを提供しますが、その構成には他のサービスと比較して、より多くの運用作業が必要です。 Container Apps と Web App for Containers は、どちらも同様のレベルの Microsoft が管理する機能を持つ PaaS サービスです。 Web App for Containers では、インターフェイスに精通している既存の App Service ユーザーである対象ユーザーにサービスを提供するシンプルさに重点を置いています。

ベスト プラクティス

よりシンプルなサービスは、通常、インフラストラクチャ管理ではなく機能開発に重点を置いているお客様に適しています。 より詳細な制御を提供するサービスは、通常、構成性を必要とし、独自のインフラストラクチャを管理するためのスキル、リソース、およびビジネス上の正当な理由を持っているお客様に適しています。

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

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

共有の考慮事項は、さまざまな要因に対応します。 ワークロードの種類に基づいて、一部の考慮事項のみが適用されます。 組織内のロールは、関連する考慮事項にも影響します。

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

カテゴリ 概要
ネットワークに関する考慮事項 Azure コンテナー サービスでのネットワークは、シンプルまたは構成性に関するユーザーの好みによって異なります。 AKS では、ネットワーク フローを広範に制御できますが、より多くの運用作業が必要です。 Container Apps には Azure で管理されるネットワーク機能があり、AKS と Web App for Containers の間に配置されます。これは、App Service を既に使用しているお客様にサービスを提供します。

ネットワーク設計の決定は、多くの場合、ワークロードを再デプロイする必要があるため、長期的な影響を及ぼします。 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) は、AKS SLA よりも簡単に計算できます。 AKS コントロール プレーンとノード プールには、それぞれ独自の SLA があり、これを複合化する必要があります。 すべてのサービスは、それをサポートするデータセンターでゾーン冗長性を提供します。

上記の考慮事項を確認した後も、一般的な完全な適合が見つからない可能性があります。

トレードオフを評価する

クラウド コンピューティングは複雑です。 これには多くのチーム間のコラボレーションが含まれており、人、予算、時間の制約を考慮する必要があります。 これらの要因により、クラウド サービスの選択が困難になり、トレードオフがいっぱいになります。

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

上記の共有の考慮事項は、最も一般的な要件をカバーしていますが、包括的ではありません。 決定を行う前に、優先サービスの機能セットに対してすべての要件を評価する必要があります。

結論

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

多くのワークロード チームは、PaaS と IaaS のどちらを好むかに基づいて、Azure コンテナー サービスを選択します。 他のチームは、サービス固有の機能がワークロードまたは組織の要件にどのように対処するかを決定するにあたって、さらに調査する必要があります。

このガイドを使用して、オプションを慎重に評価し、取り消しが困難な意思決定を行わないようにします。 ただし、開発者がサービスを試して、理論ではなく実践的な経験に基づいて評価するまで、最終的な決定はありません。

貢献者

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

プリンシパルの作成者:

その他の共同作成者:

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