Azure Container Apps は、Azure 上でマイクロサービスとコンテナー化されたアプリケーションを実行するフル マネージドのサーバーレス コンテナー サービスです。 これは、ゼロへのスケールを含む組み込みの自動スケーリングを提供し、複数のプログラミング言語とフレームワークをサポートします。 Container Apps は、高度なネットワークと監視のために Azure Kubernetes Service (AKS) と統合されます。 また、基になるインフラストラクチャを管理する必要なく、コンテナー化されたアプリケーションのシームレスなデプロイと管理を提供します。 HTTP ベースのアプリケーションとイベントドリブン アプリケーションの両方をサポートするため、最新のスケーラブルで回復性の高いクラウドネイティブ アプリケーションを構築するのに最適です。
この記事では、アーキテクトとして、 コンピューティング デシジョン ツリー を確認し、ワークロードのコンピューティング プラットフォームとして Container Apps を選択していることを前提としています。 この記事のガイダンスでは、Well-Architected Framework の柱の原則にマップされるアーキテクチャに関する推奨事項を示します。
重要
このガイドの使用方法
各セクションには、設計チェックリスト があり、テクノロジ スコープにローカライズされた設計戦略と共に、関心のあるアーキテクチャ領域が示されています。
また、これらの戦略の具体化に役立つテクノロジ機能の推奨事項も含まれています。 推奨事項は、Container Apps とその依存関係で使用できるすべての構成の完全な一覧を表すわけではありません。 代わりに、設計パースペクティブにマップされた主要な推奨事項が一覧表示されます。 推奨事項を使用して概念実証を構築するか、既存の環境を最適化します。
主要な推奨事項を示す基本アーキテクチャ: Azure Container Apps を使用したマイクロサービス。
技術の範囲
このレビューでは、次の Azure リソースに関する相互に関連する決定に焦点を当てます。
- コンテナー アプリ
信頼性
信頼性の柱の目的は、十分な回復性を構築 し、障害から迅速に回復する機能をして継続的な機能を提供することです。
信頼性設計の原則、個々のコンポーネント、システム フロー、およびシステム全体に適用される高度な設計戦略を提供します。
設計チェックリスト
信頼性 の設計レビュー チェックリストに基づいて、設計戦略を開始します。 アプリケーションのパフォーマンスと信頼性を考慮しながら、ビジネス要件との関連性を判断します。 必要に応じて、より多くのアプローチを含むように戦略を拡張します。
適切な SKU 構成を選択します。 コンテナー アプリのリソースとパフォーマンスの要件に合った環境 SKU を選択します。
冗長性を構築して回復性を向上させます。 イングレス公開 (HTTP または伝送制御プロトコル (TCP) アプリの場合は、可用性を確保するために少なくとも 3 つのレプリカを使用します。 コールド スタートを最小限に抑えるには、常時対応レプリカの最小数を構成します。
単一のリージョンにデプロイするときに可用性を向上させるために、回復性戦略の一部として可用性ゾーンを使用します。 多くの Azure リージョンには、可用性ゾーンがあります。 ゾーンは、それらの間の待機時間が短い接続を確保するのに十分近い位置に配置されていますが、複数のゾーンに影響を与えるローカル停止のリスクを最小限に抑えるために十分に離れています。
重要なワークロードの場合は、複数のリージョンに Container Apps 環境をデプロイし、トラフィック管理に Azure Front Door または Azure Traffic Manager を使用します。 これらのサービスは、高可用性とビジネス継続性を確保するのに役立ちます。 リージョンの停止が発生した場合は、トラフィックをセカンダリ リージョンに自動的にリダイレクトして、ダウンタイムとデータ損失を最小限に抑えることができます。
水平自動スケーリングを実装します。 HTTP 要求、TCP 接続、または CPU やメモリのしきい値などのカスタム メトリックに基づくスケール ルールを使用して、自動スケールを構成します。 カスタム メトリックは、Azure Service Bus、Azure Event Hubs、Apache Kafka、Azure Cache for Redis で定義できます。 自動スケールを使用して、負荷を動的に管理し、ピーク時に高可用性を維持します。
高負荷のサービス レベル目標 (SLO) 内で、コンテナー アプリが引き続き要求を処理できることを確認します。
コンテナー アプリの信頼性と全体的な正常性インジケーターを監視します。 ログとメトリックを収集して正常性を監視し、パフォーマンスと信頼性の傾向を特定し、問題のトラブルシューティングを行います。 ワークロードの信頼性と正常性の監視ソリューションの設計の詳細については、「ワークロード の正常性モデリング」を参照してください。
監視ツールとアラートを実装します。 Azure Monitor や OpenTelemetry などの監視ツールをアクティブ化します。 信頼性に影響を与えるイベントを迅速に検出して対応するようにアラートを設定します。
ヘルスプローブを構成します。 アプリケーションの正常性を監視および維持するために、すべてのサービスのスタートアップ、準備、およびライブネス プローブを設定します。
異常なコンテナー インスタンスを自動的に再起動するように自己復旧メカニズムを構成します。 自動再起動により、アプリケーションの信頼性と可用性が向上します。 これらは、手動による介入なしで障害からの迅速な復旧を保証するのに役立ちます。 正常性プローブを使用して、失敗したコンテナーを検出し、再試行とサーキット ブレーカーを自動的に処理するように回復性ポリシーを構成します。
推奨事項
勧告 | メリット |
---|---|
Container Apps 可用性ゾーンのサポート を有効にして、リージョン内のゾーン間でレプリカを自動的に分散します。 トラフィックはレプリカ間で負荷分散されます。 | ゾーン障害が発生した場合、トラフィックは残りのゾーンのレプリカに自動的にルーティングされます。 |
リソースのクォータと制限を定義します。 | リソースの競合を防ぎ、公平な割り当てを確保し、パフォーマンスの低下を回避します。 時間の経過に伴う監視を使用して、実際のリソース使用量を観察し、それに応じてクォータと制限を調整します。 |
ボリューム マウントを使用して、ステートフル アプリケーション内のコンテナーの外部にデータを格納します。 データの回復性を強化するには、Azure ゾーン冗長ストレージ (ZRS) を使用して、データの高可用性と持続性を確保します。 | コンテナーの再起動と障害の間でデータの永続化と整合性を確保します。 ZRS を使用してゾーン障害からデータ損失を防ぎ、重要なステートフル アプリケーションに堅牢なソリューションを提供します。 |
コンテナーアプリに対して稼働状態、準備状態、および起動時の正常性プローブを実装します。 Liveness プローブは、失敗状態のコンテナーを検出して再起動します。 推奨設定: failureThreshold: 3 、 periodSeconds: 10 、 timeoutSeconds: 5 、 successThreshold: 1 、および initialDelaySeconds: 10 準備プローブは、正常なコンテナーのみがトラフィックを受信することを保証します。 推奨設定: failureThreshold: 60 、 periodSeconds: 1 、 timeoutSeconds: 1 、 successThreshold: 1 、および initialDelaySeconds: 5 起動プローブは、低速起動アプリを適切に初期化できるようにすることで、早期再起動を防ぎます。 推奨設定: failureThreshold: 60 、 periodSeconds: 1 、 timeoutSeconds: 1 、 successThreshold: 1 、および initialDelaySeconds: 0 |
適切なプローブ構成は、コンテナー アプリがスムーズに実行され、トラフィックを処理できるようにするために役立ちます。 プローブ構成が不適切な場合、意図しない再起動やダウンタイムが発生する可能性があります。 |
Container Apps の組み込みの 監視機能 (ログ ストリーミング、コンテナー コンソール、Azure Monitor のメトリックとアラートなど) を使用して、プロアクティブな監視と効率的なデバッグを実現します。 | Container Apps では、.NET アスパイア ダッシュボードや Java メトリックとの統合など、詳細な可観測性のサポートが提供されます。 これらのツールを使用すると、主要なエコシステムの分析情報を強化できます。 OpenTelemetry コレクターを使用して、包括的な分散トレースとメトリックの収集を行うこともできます。 これらの機能により、問題をすばやく特定して解決できるため、アプリケーションの信頼性が向上します。 |
再試行、タイムアウト、サーキット ブレーカーなどのサービス検出 の回復性ポリシーを実装して、サービス要求エラーを事前に防止、検出、復旧します。 | サービス間通信をよりスムーズかつ回復力のあるものにすることで、コンテナー アプリの信頼性を高めます。 |
HTTP 要求、TCP 接続、または CPU やメモリのしきい値などのカスタム メトリックに基づくスケール ルールを使用して、水平方向の 自動スケーリング を実装します。 Service Bus、Event Hubs、Apache Kafka、Azure Cache for Redis でカスタム メトリックを定義できます。 | ワークロードは、負荷を動的に管理し、ピーク時に高可用性を維持できます。 |
安全
セキュリティの柱の目的は、ワークロードに対して機密性、整合性、可用性を保証することです。
セキュリティ設計の原則は、Container Apps の技術的な設計にアプローチを適用することで、これらの目標を達成するための高度な設計戦略を提供します。
設計チェックリスト
セキュリティ の 設計レビュー チェックリストに基づいて設計戦略を開始し、セキュリティ体制を改善するための脆弱性と制御を特定します。 必要に応じて、より多くのアプローチを含むように戦略を拡張します。
セキュリティ ベースラインを確認します。 ワークロードのセキュリティ体制を強化するには、 Container Apps のセキュリティ ベースラインを確認します。
ID とアクセス管理のために Microsoft Entra ID と統合します。 最小限の特権アクセスには、Microsoft Entra ID で ロールベースのアクセス制御 (RBAC) を使用します。
Azure リソースへの安全で資格情報のないアクセスには、Microsoft Entra ID でマネージド ID を使用します。
セグメント化とネットワーク制御を実装します。 プライベート コンテナー アプリ環境をデプロイし、パブリック インターネットからの分離に内部イングレス モードを使用します。
アウトバウンドトラフィックを制御します。 データ流出を防ぐには、コンテナー アプリ環境を、送信トラフィックのセキュリティ保護に役立つユーザー定義ルートを持つカスタム仮想ネットワークに統合します。
強化されたワークロードのソフトウェア サプライ チェーンを維持します。 コンテナー対応のスキャンを、セキュリティで保護された継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインに実装します。 この機能は、脆弱性を検出し、コンテナー イメージの整合性を確保するのに役立ちます。 詳細については、「 コンテナーの安全なサプライ チェーン」を参照してください。
攻撃対象領域を減らします。 コンテナー イメージを強化し、未使用のコンポーネントを削除します。 Alpine や Chiselled Ubuntu イメージなどの無駄のない最小限の基本イメージを使用します。
Microsoft Defender と統合します。 Microsoft Defender for Containers を使用して、Azure Container Registry のイメージをスキャンします。
保存データと転送中のデータを暗号化します。 最新の業界標準の方法を使用して、機密性と整合性を保護します。
Azure Key Vault を使用します。 Key Vault に機密性の高い構成値とシークレットを格納して、承認されていないアクセスから保護します。
相互トランスポート層セキュリティ (mTLS) を有効にします。 mTLS を使用して、サービス間のトラフィックを認証および暗号化します。 この機能は、セキュリティを強化する両当事者を検証します。
HTTPS を適用します。 すべての HTTP トラフィックを HTTPS にリダイレクトするように Envoy プロキシを構成します。 Envoy の既定の構成は
allowInsecure: false
。セキュリティ監視戦略を実装します。 監視と監査のための詳細なログをキャプチャします。 監視と監査のために、システムログとコンソールログを Log Analytics ワークスペース、Event Hubs、または Microsoft 以外のソリューションに送信します。 ログから機密データを削除する。 コンソール ログは、アプリ内の
stderr
ストリームとstdout
ストリームから生成されます。
推奨事項
勧告 | メリット |
---|---|
マネージド ID を使用して、Microsoft Entra ID で保護されたリソースにアクセスします。 キーやパスワードを使用せずに、ストレージ アカウントやキー コンテナーなどの Microsoft Entra ID で保護された Azure リソースにアクセスするために、マネージド ID をコンテナー アプリに割り当てます。 | ID 管理を一元化し、手動で資格情報を管理する必要がなくなります。 Azure リソースへの安全なアクセスを簡素化します。 |
コンテナー アプリを プライベート ネットワーク にデプロイして、既存の仮想ネットワークに統合します。 プライベート アプリケーション接続、ネットワーク セキュリティ グループ (NSG) の添付ファイル、プライベート IP アドレス経由のリソース通信などの機能を使用します。 | パブリック インターネットからの分離を提供し、コンテナー アプリとその他のネットワーク リソース間の安全な通信を可能にします。 |
Key Vault を使用して、セキュリティが強化された証明書とアプリ シークレットを管理します。 Key Vault は、証明書やその他のアプリ シークレットをアプリの構成とは別に保持します。 また、証明書とシークレットの更新、取得、ローテーションの詳細を示すアクセス監査ログも提供されます。 | ログ記録機能と証明書ローテーション機能を使用して、機密情報の保護、コンプライアンスの確保、セキュリティで保護されたシークレット管理のサポートを支援します。 |
Web アプリケーション ファイアウォールを有効にして Azure Application Gateway を使用すると、リバース プロキシ経由でコンテナー アプリを発行するときに HTTP および HTTPS トラフィックをセキュリティで保護できます。 Web アプリケーション ファイアウォールは、受信 HTTP トラフィックをスキャンして、Open Web Application Security Project (OWASP) 攻撃の可能性を探します。 | 一般的な Web 脆弱性から保護し、一元的なトラフィック管理を提供することで、セキュリティを強化します。 |
管理者資格情報の使用を回避するために、 Container Registry に対して Microsoft Entra ID を使用して認証します。 RBAC を使用してアクセスを制御できます。 | コンテナー イメージ管理のために RBAC を使用してきめ細かいアクセス制御を有効にします。これにより、セキュリティで保護された資格情報のない認証を確保できます。 |
NSG ルールを使用して、内部コンテナー アプリ エンドポイントにアクセスするトラフィックをセキュリティで保護します。 NSG ルールを使用すると、コンテナー アプリと通信できる仮想ネットワークをより細かく制御できます。 | 信頼されたネットワークのみにアクセスを制限することでネットワーク セキュリティを強化し、攻撃対象領域を最小限に抑えます。 |
ユーザー定義のネットワーク ルートを使用して送信トラフィックを制御します。 コンテナーがコンテナー環境外のリソースと通信する方法を制御します。 トラフィックは、Azure Firewall、Azure NAT Gateway、または Microsoft 以外のアプライアンスにルーティングできます。 | 高度なルーティングと検査ポリシーをサポートする、制御されたセキュリティで保護された送信トラフィック フローを確保します。 |
Log Analytics ワークスペース、Event Hubs、または Microsoft 以外のソリューションにログを送信するように ログ オプション を構成します。 | 機密データ処理ポリシーへの準拠を確保しながら、一元的な監視、診断、監査をサポートします。 |
コストの最適化
コストの最適化では、支出パターンの検出 、重要な領域への投資の優先順位付け、ビジネス要件を満たしながら組織の予算を満たすために他の での最適化に重点を置いています。
コスト最適化の設計原則は、Container Apps とその環境に関連する技術的な設計において、これらの目標を達成し、必要に応じてトレードオフを行う高度な設計戦略を提供します。
設計チェックリスト
投資のコスト最適化 の 設計レビュー チェックリストに基づいて、設計戦略を開始します。 ワークロードの設計を、そのワークロードに割り当てられた予算に合わせて微調整します。 設計では、適切な Azure 機能を使用し、投資を監視し、時間の経過と同時に最適化する機会を見つける必要があります。
適切な価格プランを選択します。 ワークロードの要件と予想される使用パターンに基づいて、コンテナー アプリの最もコスト効率の高い価格プランを選択します。
1 年または 3 年間の固定時間単価にコミットすることで、 コンピューティングの Azure 節約計画 を活用します。 節約プランを利用することで、従量課金制の価格と比較して最大 17% 節約できます。 予算を最適化し、長期的で予測可能なワークロードの全体的な費用を削減します。
ワークロード コンポーネントのコストを最適化します。 アプリケーションのニーズに合わせて、CPU とメモリの割り当てを定期的に確認して調整します。 この方法では、過剰なプロビジョニングを防ぎ、コストを最小限に抑えます。
マネージド ディスク層を使用します。 ボリューム マウントを使用する場合は、適切なマネージド ディスク層とサイズを選択して、永続データのストレージ コストを最適化します。 必要な分だけ支払います。
合理化された最適化されたコンテナー イメージを使用して 、起動時間とリソース効率を向上させ、ストレージとネットワークのコストを削減します。
スケーリング コストを最適化します。 自動スケール ポリシーを構成して、需要の低い期間中にリソースを自動的にスケールダウンし、ピーク時にスケールアップします。 この方法により、リソースの効率的な使用が保証されます。
ネットワーク コストを最適化します。 ネットワーク パスを最適化して、データ転送コストを最小限に抑えます(特に、帯域幅が多いアプリケーションの場合)。
コスト管理ツールを使用します。 Microsoft Cost Management ツールを使用して、支出の追跡と分析、予算の設定、コスト アラートの作成、リソース間での一貫したタグ付けの実装を行います。
これらのツールは、クラウド支出の詳細な可視性を提供し、コスト削減の機会を特定し、予算の制約に確実に準拠し、特定のワークロード、アプリケーション、および環境に関連するコストの詳細な追跡とレポートを可能にします。
推奨事項
勧告 | メリット |
---|---|
アプリケーションの実際のニーズに合わせて、CPU、メモリ割り当て、その他の メトリック を定期的に確認して調整します。 | リソースがワークロードに対して権利を持っていることを確認することで、過剰なプロビジョニングを防ぎ、不要なコストを削減します。 |
継続的に実行する必要のないアプリに対して、スケールからゼロへの 自動スケール ルールを実装します。 | 非アクティブな期間中のコストを排除します。これにより、リソースが必要な場合にのみリソースに対して支払うことになります。 この方法により、可変または使用頻度の低い使用パターンを持つアプリの費用が大幅に削減されます。 |
ステートフル アプリケーションに適 したマネージド ディスク層 を選択します。 ストレージのパフォーマンスと容量のニーズに基づいて選択し、予測可能なワークロードに予約ディスクを使用することを検討します。 | 必要なストレージパフォーマンスのみに対して支払うことで、過剰にプロビジョニングされたストレージによる無駄なコストを防ぎます。 予約ディスクでは、従量課金制の価格と比較して割引を提供することで、長期的なストレージ要件に対して大幅なコスト削減を実現できます。 |
オペレーショナル エクセレンス
オペレーショナル エクセレンスは主に、開発プラクティス、可観測性、リリース管理の手順に重点を置いています。
オペレーショナル エクセレンス設計原則、ワークロードの運用要件に対してこれらの目標を達成するための高度な設計戦略を提供します。
設計チェックリスト
Container Apps に関連する監視、テスト、デプロイのプロセスを定義するための オペレーショナル エクセレンスの設計レビュー チェックリスト に基づいて、設計戦略を開始します。
コードとしてのインフラストラクチャ (IaC) デプロイ アプローチを実装します。 Bicep や Terraform などのツールを使用して、テンプレート ベースのデプロイを実装します。 すべてのデプロイが反復可能で、トレース可能であり、ソース コード リポジトリに格納されていることを確認します。
インフラストラクチャとワークロードのデプロイを自動化します。 標準のソフトウェア ソリューションを使用して、ワークロードのデプロイを管理、統合、自動化します。
リージョンの停止が発生した場合に、環境を別のリージョンに再デプロイするようにデプロイ パイプラインを設定します。 このアプローチは、重要なデータと構成を別のリージョンに迅速に復元して再デプロイするのに役立ちます。これにより、ディザスター リカバリー機能が強化され、リージョンの障害発生時のダウンタイムが最小限に抑えられます。
CI/CD パイプラインを使用して、必要な構成とデプロイを使用して環境を設定する自動化されたプロセスを構築します。
包括的な監視戦略を実装します。 診断設定を構成して、ログ、メトリック、診断データをキャプチャします。 Azure Monitor や Application Insights などのツールを使用して、アプリケーションの正常性とパフォーマンスを追跡し、パフォーマンスと信頼性の傾向を特定し、問題のトラブルシューティングを行います。
ワークロードのテレメトリを出力します。 監視とトラブルシューティングを容易にするために、ライブラインや準備状態などのテレメトリ データを出力するようにワークロードを設計します。
パフォーマンス メトリックを監視します。 CPU、メモリ、ネットワーク使用量などの主要なパフォーマンス メトリックを継続的に監視して、コストの最適化と運用効率の機会を特定します。
カオス エンジニアリングを実装する。 Azure Chaos Studio などのツールを使用して混乱エンジニアリングプラクティスを適用し、Container Apps 環境内の潜在的な信頼性の問題を特定します。 アプリケーションが予期しない障害に耐えられるように、実験を実施します。 Azure Load Testing などのツールを使用してパフォーマンス テストを実施し、スケーリング ルールがクライアントを中断することなく期待どおりに動作することを確認します。
すべてのコンテナー アプリとその他のワークロード リソースに対して、一貫したリソース タグ付けを実装します。 一貫性のあるタグ付けにより、効率的なリソース管理、コスト追跡、自動化が容易になります。
ワークロード ガバナンスを適用する。 Azure Policy は、組織の標準に一貫したコンプライアンスを確保し、ポリシーの適用を自動化し、ワークロードのリソースの一元的な可視性と制御を提供します。
推奨事項
勧告 | メリット |
---|---|
Container Apps 環境の構成を IaC として格納し、リージョンの停止が発生した場合に別のリージョンに環境を再デプロイするようにデプロイ パイプラインを設定します。 | 重要なデータと構成を別のリージョンに迅速に復元して再デプロイできることを確認します。これにより、ディザスター リカバリー機能が強化され、リージョンの障害発生時のダウンタイムが最小限に抑えられます。 |
リビジョンを使用して、ブルーグリーンデプロイまたはカナリアデプロイを実装します。 改訂では、コンテナーイメージに適切にタグを付けてバージョンを指定する必要があります。 ユーザー受け入れテストや制限付きプレビューなど、共有を容易にするために、リビジョンでラベルを使用できます。 |
安全なロールアウトと迅速なロールバックを可能にすることで、ダウンタイムを最小限に抑え、リリース中のリスクを軽減します。 |
Azure Monitor と Application Insights を構成します。 | コンテナー アプリのパフォーマンスと正常性を追跡し、アプリケーションのパフォーマンスと信頼性に関する詳細な分析情報を提供します。 これらの分析情報を使用して、問題を事前に検出して解決します。 |
パフォーマンス効率
パフォーマンス効率とは、容量の管理により、負荷が増加してもユーザー エクスペリエンスを維持することです。 この戦略には、リソースのスケーリング、潜在的なボトルネックの特定と最適化、ピーク パフォーマンスの最適化が含まれます。
パフォーマンス効率設計の原則、予想される使用に対してこれらの容量目標を達成するための高度な設計戦略を提供します。
設計チェックリスト
Container Apps の主要業績評価指標に基づいてベースラインを定義するための パフォーマンス効率の設計レビュー チェックリスト に基づいて、設計戦略を開始します。
過剰なプロビジョニングを回避しながら、さまざまな負荷を処理するのに十分なリソースがコンテナー アプリに確保されるように、詳細な容量計画を作成します。 容量計画は、コストとパフォーマンスを最適化するのに役立ちます。
コンテナー アプリの適切なリソース割り当て、自動スケール設定、およびフェールオーバー戦略を文書化するように計画を定期的に更新します。 このアプローチにより、重要なデータと構成を別のリージョンに迅速に復元および再デプロイできます。これにより、ディザスター リカバリー機能が強化され、リージョンの障害発生時のダウンタイムが最小限に抑えられます。
自動スケールを有効にします。 自動スケール ポリシーを構成して、リアルタイムの需要に基づいてコンテナー インスタンスの数を自動的に調整します。これにより、ピーク時とピーク時以外の最適なパフォーマンスが保証されます。
リソースの割り当てを最適化します。 パフォーマンス メトリックに基づいて CPU とメモリの割り当てを継続的に監視および調整し、リソースの効率的な使用を確保し、過剰プロビジョニングを防ぎます。
ロード テストを実施する。 定期的なロード テストを実行して、さまざまな条件下でコンテナー アプリのパフォーマンスとスケーラビリティを評価します。 テストは、コンテナー アプリが予想されるトラフィック レベルを処理できることを確認するのに役立ちます。
ワークロードを分離します。 ノイズの多い近隣の問題を回避するために、重要で機密性の高いワークロードを別々の Container Apps 環境にデプロイします。 複数の環境にワークロードを分散して、重要なアプリケーションに専用のリソースを確保します。 また、この方法により、重要度の低いアプリケーションのパフォーマンス要求が重要なアプリケーションに影響を与えなくなります。
推奨事項
勧告 | メリット |
---|---|
自動スケール ポリシーを構成して、リソースの需要に応じてコンテナー インスタンスの数を自動的に調整します。 | アプリケーションのパフォーマンスとコスト効率の維持に役立ちます。 リソースが必要なときに使用でき、不要な場合は節約できることを確認します。 Azure Load Testing を使用してロード テストの実験を行い、必要に応じて自動スケール ポリシーを調整します。 |
予測可能なパフォーマンスと保証されたリソース割り当てを必要とするアプリケーションには、 ワークロード プロファイル 専用レベルを使用します。 | 重要なアプリケーション専用のリソースを提供します。これにより、一貫性のあるパフォーマンスが確保され、リソース競合のリスクが軽減されます。 |
アプリケーション固有のデータに基づくメトリックなどのカスタム スケーリング メトリックを使用して、自動スケールの決定を推進します。 | スケーリング アクションが関連するワークロードの需要に基づいて行われるようにします。これにより、コンテナー アプリの効率と応答性が向上します。 |
Azure ポリシー
Azure には、Container Apps とその依存関係に関連する広範な組み込みポリシー セットが用意されています。 上記の推奨事項の一部は、Azure Policy を使用して監査できます。 たとえば、次のことを確認できます。
診断設定を有効にする必要があります。 Container Apps 環境 (
microsoft.app/managedenvironments
) のカテゴリ グループ別のログ記録を有効にして、Storage に情報を送信します。 この設定により、Storage は監視、トラブルシューティング、コンプライアンスのためのログとメトリックを一貫して収集します。Container Apps の認証を有効にする必要があります。 認証を有効にして、匿名の HTTP 要求を防止し、コンテナー アプリ環境に到達する前にトークンを使用して要求を認証します。
Container Apps 環境では、ネットワークインジェクションを使用する必要があります。 仮想ネットワークインジェクションを使用して Container Apps 環境を構成して、パブリック インターネットから分離し、オンプレミスまたはその他の Azure 仮想ネットワークのリソースとのネットワーク統合を有効にし、ネットワーク トラフィックをきめ細かく制御します。
パブリック ネットワーク アクセスを無効にする必要があります。 内部ロード バランサーを介して Container Apps 環境を公開することで、パブリック ネットワーク アクセスを無効にしてセキュリティを強化します。 この方法では、環境内のすべてのコンテナー アプリへのインターネット アクセスがブロックされます。
外部ネットワーク アクセスを無効にする必要があります。 コンテナー アプリの受信通信が Container Apps 環境内の呼び出し元に制限されるように、内部専用イングレスを強制します。
HTTPS を適用する必要があります。 ネットワーク層の傍受攻撃から転送中のデータを保護するために、コンテナー アプリに HTTPS 経由でのみアクセスできることを確認します。
マネージド ID を有効にする必要があります。 Microsoft Entra ID 認証をサポートするリソースに対して安全に認証するには、Container Apps 環境のマネージド ID が必要です。
包括的なガバナンスについては、 Container Apps の Azure Policy 組み込み定義 と、ネットワークのセキュリティに影響する可能性があるその他のポリシーを確認します。
Azure Advisor の推奨事項
Azure Advisor は、Azure デプロイを最適化するためのベスト プラクティスに従うのに役立つ、パーソナライズされたクラウド コンサルタントです。
詳細については、Azure Advisor に関するページを参照してください。