Azure App Service (Web Apps) に関する Azure Well-Architected Framework のパースペクティブ
Azure App Service はサービスとしてのプラットフォーム (PaaS) であり、Web アプリケーションを構築、デプロイ、スケーリングするためのフル マネージド ホスティング環境を提供します。 PaaS ソリューションとして、App Service は基になるインフラストラクチャを抽象化します。これにより、アプリケーション開発に集中できます。 App Service の Web Apps 機能は、App Service プランのコンテキストでアプリを実行します。 このプランでは、アプリのホストに使用されるリソース、オペレーティング システム、リージョン、および価格モデル (SKU) が決まります。
この記事では、アーキテクトとして、コンピューティング デシジョン ツリーの を確認し、ワークロードのコンピューティングとして App Service を選択していることを前提としています。 この記事のガイダンスでは、Well-Architected Framework の柱の原則にマップされるアーキテクチャに関する推奨事項を示します。
重要
このガイドの使用方法
各セクションには、設計チェックリスト があり、テクノロジ スコープにローカライズされた設計戦略と共に、関心のあるアーキテクチャ領域が示されています。
また、これらの戦略の具体化に役立つテクノロジ機能の推奨事項も含まれています。 推奨事項は、App Service の Web Apps 機能とその依存関係で使用できるすべての構成の完全な一覧を表すわけではありません。 代わりに、設計パースペクティブにマップされた主要な推奨事項が一覧表示されます。 推奨事項を使用して概念実証を構築するか、既存の環境を最適化します。
主要な推奨事項を示す基本的なアーキテクチャ: App Service ベースライン アーキテクチャ。
テクノロジーの範囲
このレビューでは、次の Azure リソースに関する相互に関連する決定に焦点を当てます。
- App Service プラン
- ウェブアプリ
その他の Azure オファリングは、Azure Functions、Azure Logic Apps、App Service Environment など、App Service に関連付けられています。 これらの内容は、この記事の範囲外です。 App Service Environment は、App Service のコア オファリングの機能またはオプションを明確にするために、時々参照されます。
確実
信頼性の柱の目的は、十分な回復性を構築 し、障害から迅速に回復する機能をして継続的な機能を提供することです。
信頼性設計の原則、個々のコンポーネント、システム フロー、およびシステム全体に適用される高度な設計戦略を提供します。
設計チェックリスト
信頼性 の設計レビュー チェックリストに基づいて、設計戦略を開始します。 App Service とその依存関係の階層と機能を念頭に置いて、ビジネス要件との関連性を判断します。 必要に応じて、より多くのアプローチを含むように戦略を拡張します。
ユーザー フローの優先順位付け: すべてのフローが同じように重要であるとは言えない。 アプリケーションの重要なパスを特定し、各フローに優先順位を割り当てて、設計上の決定を導きます。 ユーザー フローの設計は、App Service プランと構成に対して選択するサービス レベルとインスタンスの数に影響を与える可能性があります。
たとえば、アプリケーションには、メッセージ ブローカーを介して通信するフロントエンド層とバックエンド層が含まれている場合があります。 複数の Web アプリで階層をセグメント化して、独立したスケーリング、ライフサイクル管理、メンテナンスを可能にすることもできます。 大規模なアプリケーションを 1 つのプランに配置すると、信頼性に影響するメモリまたは CPU の問題が発生する可能性があります。
UI 側で最適なパフォーマンスを得るには、フロントエンドにさらにインスタンスが必要になる場合があります。 ただし、バックエンドが同じ数のインスタンスを必要としない場合があります。
潜在的な障害を予測する: 潜在的な障害の軽減戦略を計画します。 次の表に、エラー モード分析の例を示します。
失敗 緩和 基になるまたは抽象化された App Service コンポーネントの失敗 インスタンスと依存関係にコンポーネントの冗長性があります。 インスタンスの正常性、ネットワーク パフォーマンス、ストレージのパフォーマンスを監視します。 外部依存関係の失敗 再試行パターン や サーキット ブレーカー パターンなどの設計パターンを使用します。 外部の依存関係を監視し、適切なタイムアウトを設定します。 トラフィックが不健康なインスタンスにルーティングされることが原因で失敗する インスタンスの正常性を監視します。 応答性を考慮し、異常なインスタンスに要求を送信しないようにします。 詳細については、「Azure アプリケーションのエラー モード分析」を参照してください。
冗長性の構築: アプリケーションとサポート インフラストラクチャの冗長性を構築します。 フォールト トレランスを向上させるために、可用性ゾーン間でインスタンスを分散します。 1 つのゾーンで障害が発生した場合、トラフィックは他のゾーンにルーティングされます。 複数のリージョンにアプリケーションをデプロイして、リージョン全体で障害が発生した場合でもアプリを確実に使用できるようにします。
依存サービスで同様のレベルの冗長性を構築します。 たとえば、アプリケーション インスタンスは BLOB ストレージにバインドされます。 アプリケーションでゾーン冗長デプロイを使用する場合は、関連付けられているストレージ アカウントをゾーン冗長ストレージで構成することを検討してください。
複数のインスタンスを使用する: 1 つのインスタンスでのみアプリを実行すると、直ちに単一障害点が発生します。 高可用性を確保するために、アプリに複数のインスタンスを割り当てます。 1 つのインスタンスが失敗した場合でも、他のインスタンスは受信要求を処理できます。 アプリ コードは、データ ソースからの読み取りやデータ ソースへの書き込み時に、同期の問題なしに複数のインスタンスを処理できる必要があります。
ネットワーク コンポーネントに冗長性があります。 たとえば、ゾーン冗長 IP アドレスとロード バランサーを使用します。
信頼性の高いスケーリング戦略を持つこと: 予期しない負荷がアプリケーションにかかると、信頼性が低下する恐れがあります。 ワークロードの特性に基づいて適切なスケーリング アプローチを検討します。 水平スケーリング(のスケールアウト)を使用すると、負荷を分散するためにインスタンスを追加できます。 垂直方向のスケーリングまたは のスケールアップは、CPU やメモリなどの既存のインスタンスの容量を増やします。 不要なインスタンスを追加すると、具体的なパフォーマンス上の利点なしにコストが増加するため、過剰プロビジョニングには注意してください。
負荷を処理するためにスケールアップできる場合があります。 ただし、負荷が増加し続ける場合は、新しいインスタンスにスケールアウトします。 手動アプローチではなく、自動 (自動スケーリング) アプローチを選択します。 パフォーマンスの低下を防ぐために、スケーリング操作中は常に余分な容量のバッファーを維持します。
選択した App Service プラン レベル は、インスタンスの数とコンピューティング ユニットのスケールに影響します。
新しいインスタンスが迅速にウォームアップし、要求を受け取ることができるように、適切なアプリの初期化を確認します。 可能な限り、ステートレスなアプリケーションを目指しましょう。 新しいインスタンスで状態を確実にスケーリングすると、複雑さが増す可能性があります。 アプリケーションの状態を格納する必要がある場合は、個別にスケーリングできる外部データ ストアを検討してください。 セッション状態をメモリに格納すると、アプリケーションまたは App Service に問題がある場合にセッション状態が失われることがあります。 また、他のインスタンスに負荷を分散する可能性も制限されます。
自動スケールルールを定期的にテストします。 読み込みシナリオをシミュレートして、アプリが予想どおりにスケーリングされることを確認します。 発生する可能性のある問題をトラブルシューティングし、時間の経過と同時にスケーリング戦略を最適化できるように、スケーリング イベントをログに記録する必要があります。
App Service には、プラン内のインスタンスの数に制限があり、スケーリングの信頼性に影響する可能性があります。 これに対処するために、1 つの戦略は、同じスタンプをデプロイし、各スタンプで独自の App Service プラン インスタンスとエンドポイントを実行することです。 すべてのスタンプを外部ロード バランサーで前面に配置し、それらの間でトラフィックを分散することが重要です。 単一ゾーンデプロイには Azure Application Gateway を使用し、複数リージョンのデプロイには Azure Front Door を使用します。 このアプローチは、信頼性が重要な場合にミッション クリティカルなアプリケーションに最適です。 詳細については、「App Service を使用したミッション クリティカルなベースライン」を参照してください。
復旧可能性を計画する: 冗長性は、ビジネス継続性にとって非常に重要です。 1 つのインスタンスに到達できない場合は、別のインスタンスにフェールオーバーします。 インスタンスの自動修復など、App Service の自動復旧機能について説明します。
ネットワーク接続の問題や地域の障害などの大規模なイベントなど、一時的な障害のグレースフルな低下を処理する設計パターンを実装します。 次の設計パターンについて考えてみましょう。
バルクヘッド パターン、障害がシステム全体に影響を与えないように、アプリケーションを分離されたグループに分割します。
Queue-Based 負荷平準化パターン、トラフィックの急増をスムーズにするためのバッファーとして機能する作業項目をキューに格納します。
再試行パターン は、ネットワーク障害、データベース接続の切断、またはビジー状態のサービスによる一時的な障害を処理します。
サーキット ブレーカー パターン は、アプリケーションが失敗する可能性のある操作を繰り返し実行することを防ぎます。
Web ジョブを使用して、Web アプリでバックグラウンド タスクを実行できます。 これらのタスクを確実に実行するには、ジョブをホストするアプリがスケジュールに従って、またはイベント ドリブン トリガーに基づいて継続的に実行されるようにします。
詳細については、信頼性 をサポートするクラウド設計パターンのを参照してください。
信頼性テストを実施する: 負荷の下でアプリケーションの信頼性とパフォーマンスを評価するロード テストを実施します。 テスト 計画には、自動復旧操作を検証するシナリオを含める必要があります。
フォルトインジェクションを使用して、意図的に障害を導入し、自己復旧と自己保存のメカニズムを検証します。 詳細については、Azure Chaos Studio の障害およびアクション ライブラリ を参照してください。
App Service では、ホストされているアプリにリソース制限が課されます。 これらの制限は、App Service プランによって決まります。 テストで、アプリがそれらのリソース制限内で実行されていることを確認します。 詳細については、「App Service の制限」を参照してください。
正常性チェック機能を使用して応答しないワーカーを特定します。 App Service には、Web アプリケーションの特定のパスに定期的に ping を実行する組み込み機能があります。 プラットフォームはこのパスに ping を実行して、アプリケーションが正常かどうかを判断し、要求に応答します。
サイトが複数のインスタンスにスケールアウトされると、App Service は異常なインスタンスを要求の提供から除外します。 このプロセスにより、全体的な可用性が向上します。
アプリの正常性チェック パスは、データベース、キャッシュ、メッセージング サービスなど、アプリケーションの重要なコンポーネントをポーリングする必要があります。 この手順は、正常性チェック パス によって返される状態が、アプリケーションの全体的な正常性を正確に把握するのに役立ちます。
自動修復機能を使用する: アプリケーションで、単純な再起動で解決できる予期しない動作が発生することがあります。 自動修復機能を使用して、自動修復をトリガーする 条件 を定義し、その条件が満たされたときに自動修復が開始する アクションを定義します。 詳細については、「App Service 診断の概要」を参照してください。
App Service の回復性スコア レポート: カスタマイズされたベスト プラクティスの推奨事項を確認するには、App Service 診断の概要を参照してください。
推奨 事項
| 勧告 | 特長 |
|---|---|
| (App Service)運用ワークロード用の App Service プランの Premium v3 レベルを選択します。 容量計画に従って、作業者の最大数と最小数を設定します。 詳細については、「App Service プランの概要」を参照してください。 |
Premium v3 App Service プランでは、高度なスケーリング機能が提供され、障害が発生した場合の冗長性が確保されます。 |
| (App Service) ゾーン冗長を有効にします。 フォールト トレランスを強化するために、3 つ以上のインスタンスをプロビジョニングすることを検討してください。 一部のリージョンにこの機能がない場合は、リージョンのサポートでゾーン冗長性を確認してください。 |
複数のインスタンスが複数のゾーンに分散している場合、アプリケーションは単一のゾーンでの障害に耐えることができます。 トラフィックは、他のゾーン内の正常なインスタンスに自動的に移行し、1 つのゾーンが使用できない場合でもアプリケーションの信頼性を維持します。 |
| (Web Apps)アプリケーション要求ルーティング (ARR) アフィニティ機能を無効にすることを検討してください。 ARR アフィニティは、以前の要求を処理したノードにユーザーをリダイレクトするスティッキー セッションを作成します。 | ARR アフィニティを無効にすると、受信要求は使用可能なすべてのノードに均等に分散されます。 均等に分散された要求により、トラフィックが 1 つのノードを過負荷にするのを防ぐことができます。 ノードが使用できない場合は、要求を他の正常なノードにシームレスにリダイレクトできます。 セッション アフィニティを避けて、App Service インスタンスがステートレスなままになるようにします。 ステートレス App Service インスタンスを使用すると、複雑さが軽減され、ノード間で一貫した動作が保証されます。 App Service がインスタンスを追加または削除して水平方向にスケーリングできるように、スティッキー セッションを削除します。 |
| (Web Apps) 要求数、低速要求、メモリ制限、およびパフォーマンス ベースラインの一部であるその他のインジケーターに基づいて、自動復旧ルール を定義します。 この構成は、スケーリング戦略の一部と考えてください。 | 自動復旧ルールは、アプリケーションが予期しない問題から自動的に回復するのに役立ちます。 構成されたルールは、しきい値に違反したときに復旧アクションをトリガーします。 自動復旧により、自動プロアクティブ メンテナンスが可能になります。 |
| (Web Apps) 正常性チェック機能 を有効にし、正常性チェック要求に応答するパスを指定します。 | 正常性チェックでは、問題を早期に検出できます。 その後、正常性チェック要求が失敗したときに、システムは自動的に是正措置を実行できます。 ロード バランサーは、異常なインスタンスからトラフィックをルーティングし、ユーザーを正常なノードに誘導します。 |
安全
セキュリティの柱の目的は、機密性、整合性、可用性の保証をワークロードに提供することです。
セキュリティ設計の原則、App Service でのホスティングに関する技術的な設計にアプローチを適用することで、これらの目標を達成するための高度な設計戦略を提供します。
設計チェックリスト
セキュリティ の 設計レビュー チェックリストに基づいて設計戦略を開始し、セキュリティ体制を改善するための脆弱性と制御を特定します。 必要に応じて、より多くのアプローチを含むように戦略を拡張します。
セキュリティ ベースラインの確認: App Service プランでホストされているアプリケーションのセキュリティ体制を強化するには、App Service のセキュリティ ベースラインを確認します。
最新のランタイムとライブラリを使用する: 更新を実行する前にアプリケーション ビルドを十分にテストして、問題を早期にキャッチし、新しいバージョンへのスムーズな移行を確実に行うことができます。 App Service では、既存のスタックの更新とサポート終了スタックの廃止に関する 言語ランタイム サポート ポリシー がサポートされています。
分離境界を設定して侵害を抑えるためにセグメンテーションを作成する: アイデンティティセグメンテーションを適用する。 たとえば、ロールベースのアクセス制御 (RBAC) を実装して、ロールに基づいて特定のアクセス許可を割り当てます。 最小限の特権の原則に従って、アクセス権を必要なもののみに制限します。 また、ネットワーク レベルでセグメント化を作成します。 分離のために App Service アプリを Azure 仮想ネットワーク と統合し、トラフィックをフィルター処理するためのネットワーク セキュリティ グループ (NSG) を定義します。
App Service プランは、高度な分離を実現する App Service Environment 層を備えています。 App Service Environment を使用すると、専用のコンピューティングとネットワークを利用できます。
ID にアクセス制御を適用する: Web アプリへの内向きアクセスと、Web アプリから他のリソースへの外部アクセスを制限します。 この構成は、ID にアクセス制御を適用し、ワークロードの全体的なセキュリティ体制を維持するのに役立ちます。
すべての認証と承認のニーズに Microsoft Entra ID を使用します。 Web プラン共同作成者、Web サイト共同作成者、汎用共同作成者、閲覧者、所有者などの組み込みロールを使用します。
ネットワーク セキュリティ制御を適用する: App Service と仮想ネットワークを統合して送信トラフィックを制御します。 プライベート エンドポイントを使用して受信トラフィックを制御し、仮想ネットワーク内から App Service インスタンスへのアクセスを制限し、パブリック インターネット アクセスを無効にします。 詳細については、「ネットワーク ルーティングの」を参照してください。
Web アプリケーション ファイアウォール (WAF) をデプロイして、一般的な脆弱性から保護します。 Application Gateway と Azure Front Door の両方に WAF 機能が統合されています。
目的のレベルのセキュリティと制御を実現するために、リバース プロキシの規則とネットワーク設定を適切に構成します。 たとえば、リバース プロキシからのトラフィックのみを受け入れるように、プライベート エンドポイント サブネットに NSG ルールを追加します。
アプリケーションから他の PaaS サービスへのエグレス トラフィックは、プライベート エンドポイント経由である必要があります。 パブリック インターネットへのエグレス トラフィックを制限するファイアウォール コンポーネントを配置することを検討してください。 どちらの方法も、データ流出を防ぐのに役立ちます。
詳細については、「App Service のネットワーク機能を参照してください。
データの暗号化: エンド ツー エンドトランスポート層セキュリティ (TLS) を使用して転送中のデータを保護するのに役立ちます。 保存データを完全に暗号化するには、カスタマー マネージド キー を使用します。
TLS 1.0 や 1.1 などのレガシ プロトコルは使用しないでください。 すべての Web アプリで HTTPS のみが使用され、TLS 1.2 以降が適用されていることを確認します。 既定の最小 TLS バージョンは 1.2 です。 詳細については、「App Service TLS の概要」を参照してください。
すべての App Service インスタンスには、既定のドメイン名があります。 カスタム ドメインを使用し、証明書を使用してそのドメインをセキュリティで保護します。
エンド ツー エンド TLS 暗号化: エンド ツー エンド TLS 暗号化は、Premium App Service プランで利用できます。 この機能により、トランザクション全体にわたってトラフィックが暗号化され、トラフィックの傍受のリスクが最小限に抑えられます。
攻撃対象領域を減らす: 不要な既定の構成を削除します。 たとえば、リモート デバッグ、ソース管理マネージャー (SCM) サイトのローカル認証、基本認証を無効にします。 HTTP やファイル転送プロトコル (FTP) などのセキュリティで保護されていないプロトコルを無効にします。 Azure ポリシーを使用して構成を適用します。 詳細については、Azure ポリシーの に関するページを参照してください。
制限付きクロスオリジン リソース共有 (CORS) ポリシーを実装する: Web アプリで制限付き CORS ポリシーを使用して、許可されたドメイン、ヘッダー、およびその他の条件からの要求のみを受け入れます。 組み込みの Azure ポリシー定義を使用して CORS ポリシーを適用します。
マネージド ID の使用: 資格情報を管理することなく、App Service インスタンスの マネージド ID を有効にして、他の Azure サービスに安全にアクセスできるようにします。
アプリケーション シークレットを保護する: API キーや認証トークンなどの機密情報を処理する必要があります。 これらのシークレットをアプリケーション コードまたは構成ファイルに直接ハードコーディングする代わりに、アプリ設定で Azure Key Vault 参照を使用できます。 アプリケーションが起動すると、App Service はアプリのマネージド ID を使用して Key Vault からシークレット値を自動的に取得します。
アプリケーションのリソース ログを有効にする: アプリケーションのリソース ログを有効にして、セキュリティ インシデントに続く調査中に貴重なデータを提供する包括的なアクティビティ 証跡を作成します。 詳細については、「Azure Monitor リソースログ」を参照してください。
脅威を評価する際は、脅威モデリング プロセスの一環としてログ記録を検討してください。
推奨 事項
| 勧告 | 特長 |
|---|---|
| (Web Apps) マネージド ID を Web アプリに割り当てます。 分離境界を維持するために、アプリケーション間で ID を共有したり再利用したりしないでください。 必ず、デプロイにコンテナーを使用する場合は、コンテナー レジストリ に安全に接続してください。 |
アプリケーションは Key Vault からシークレットを取得して、アプリケーションからの外部通信を認証します。 Azure は ID を管理するため、シークレットをプロビジョニングまたはローテーションする必要はありません。 細分性を制御するための個別の ID があります。 個別の ID は、ID が侵害された場合に失効を容易にします。 |
| (Web Apps)アプリケーション カスタム ドメイン を構成します。 HTTP を無効にし、HTTPS 要求のみを受け入れます。 |
カスタム ドメインを使用すると、TLS プロトコルを使用して HTTPS 経由のセキュリティで保護された通信が可能になり、機密データの保護が確保され、ユーザーの信頼が構築されます。 |
| (Web Apps)App Service の組み込み認証 が、アプリケーションにアクセスするユーザーを認証するための適切なメカニズムであるかどうかを評価します。 App Service の組み込み認証は、Microsoft Entra ID と統合されます。 この機能は、複数のサインイン プロバイダー間でトークンの検証とユーザー ID 管理を処理し、OpenID Connect をサポートします。 この機能を使用すると、細かいレベルで承認を受けず、認証をテストするメカニズムがありません。 | この機能を使用する場合、アプリケーション コードで認証ライブラリを使用する必要がないため、複雑さが軽減されます。 要求がアプリケーションに到達すると、ユーザーは既に認証されています。 |
| (Web Apps)アプリケーションを仮想ネットワーク統合 用に構成します。 App Service アプリ にのプライベート エンドポイントを使用します。 すべてのパブリック トラフィックをブロックします。 仮想ネットワーク の統合を経由して、 コンテナのイメージプルをルーティングします。 アプリケーションからのすべての 送信トラフィック 仮想ネットワークを通過します。 |
Azure 仮想ネットワークを使用する場合のセキュリティ上の利点を得る。 たとえば、アプリケーションはネットワーク内のリソースに安全にアクセスできます。 アプリケーションの保護に役立つプライベート エンドポイントを追加します。 プライベート エンドポイントは、パブリック ネットワークへの直接公開を制限し、リバース プロキシ経由で制御されたアクセスを許可します。 |
| (Web Apps) セキュリティ強化を実装するには: - Microsoft Entra ID ベースの認証を優先して、ユーザー名とパスワードを使用する基本認証 を無効にします。 - 受信ポートが開かないように、リモート デバッグをオフにします。 - CORS ポリシー を有効にして、受信要求を締め付けます。 - FTPなどのプロトコルを無効にします。 |
セキュリティで保護されたデプロイ方法として基本認証は推奨されません。 Microsoft Entra ID では、OAuth 2.0 トークン ベースの認証が採用されています。この認証には、基本認証に関連する制限に対処する多くの利点と機能強化が用意されています。 ポリシーは、アプリケーション リソースへのアクセスを制限し、特定のドメインからの要求のみを許可し、リージョン間の要求をセキュリティで保護します。 |
| (Web アプリ) 常に Key Vault 参照をアプリ設定として使用すること。 |
シークレットは、アプリの構成とは別に保持されます。 アプリ設定は静止時に暗号化されます。 App Service では、シークレットのローテーションも管理されます。 |
| (App Service) Microsoft Defender for Cloud for App Serviceを有効にします。 | App Service プランで実行されるリソースのリアルタイム保護を取得します。 脅威から保護し、全体的なセキュリティ体制を強化します。 |
| (App Service) 診断ログ を有効にし、アプリにインストルメンテーションを追加します。 ログは、Azure Storage アカウント、Azure Event Hubs、Log Analytics に送信されます。 監査ログの種類の詳細については、「サポートされているログの種類 を参照してください。 | ログ記録では、アクセス パターンがキャプチャされます。 ユーザーがアプリケーションまたはプラットフォームと対話する方法に関する貴重な分析情報を提供する関連イベントを記録します。 この情報は、アカウンタビリティ、コンプライアンス、セキュリティの目的で非常に重要です。 |
コストの最適化
コストの最適化では、支出パターンの検出 、重要な領域への投資の優先順位付け、ビジネス要件を満たしながら組織の予算を満たすために他の での最適化に重点を置いています。
コスト最適化の設計原則、Web Apps とその環境に関連する技術的な設計において、これらの目標を達成し、必要に応じてトレードオフを行う高度な設計戦略を提供します。
設計チェックリスト
投資のコスト最適化 の 設計レビュー チェックリストに基づいて、設計戦略を開始します。 ワークロードの設計を、そのワークロードに割り当てられた予算に合わせて微調整します。 設計では、適切な Azure 機能を使用し、投資を監視し、時間の経過と同時に最適化する機会を見つける必要があります。
初期コストの見積もり: コスト モデリング演習の一環として、Azure 料金計算ツール を使用して、実行する予定のインスタンスの数に基づいて、さまざまなレベルに関連付けられているおおよそのコストを評価します。 App Service レベルごとに、さまざまなコンピューティング オプションが提供されます。
コスト モデルを継続的に監視して支出を追跡します。
割引オプションを評価します。上位レベル 専用のコンピューティング インスタンスが含まれます。 ワークロードに予測可能で一貫性のある使用パターンがある場合は、予約割引を適用できます。 使用状況データを分析して、ワークロードに適した予約の種類を決定してください。 詳細については、「App Service 予約インスタンスを使用したコストの節約」を参照してください。
使用状況メーターを理解する: Azure では、App Service プランの価格レベルに基づいて、秒単位で按分された1時間単位の料金が課金されます。 料金は、VM インスタンスを割り当てた時間に基づいて、プラン内のスケールアウトされた各インスタンスに適用されます。 最適でない SKU の選択や、適切に構成されていないスケールイン構成により、割り当て超過の結果としてコストが増加する可能性がある、十分に使用されていないコンピューティング リソースに注意してください。
カスタム ドメイン登録やカスタム証明書などの追加の App Service 機能により、コストが追加される場合があります。 ソリューションを分離する仮想ネットワークや、ワークロード シークレットを保護するキー コンテナーなどの他のリソースも、App Service リソースと統合してコストを追加できます。 詳細については、「App Serviceの完全な課金モデルを理解する」を参照してください。
密度と分離のトレードオフを考慮してください。 App Service プランを使用して、同じコンピューティング上で複数のアプリケーションをホストできるため、共有環境でのコストを節約できます。 詳細については「トレードオフ」を参照してください。
スケーリング戦略がコストに及ぼす影響を評価します。 自動スケールを実装するときに、スケールアウトとスケールインのために適切に設計、テスト、構成する必要があります。 自動スケールの正確な最大値と最小の制限を確立します。
信頼性の高いスケーリングのためにアプリケーションを事前に初期化します。 たとえば、CPU が 95% 使用量に達するまで待つ必要はありません。 代わりに、スケーリングプロセス中に新しいインスタンスを割り当てて初期化するのに十分な時間を確保するために、約 65% でスケーリングをトリガーします。 ただし、この方法では、使用されていない容量が発生する可能性があります。
スケールアップとスケールアウトのメカニズムを組み合わせてバランスを取うことをお勧めします。たとえば、アプリはしばらくの間スケールアップしてから、必要に応じてスケールアウトできます。 大容量で効率的なリソース使用量を提供する高レベルを調べる。 使用パターンに基づいて、Premium レベルが高いほど、多くの場合、より高いコスト効率が得られます。
環境コストを最適化する: 基本レベルまたは Free レベルを使用して実稼働前環境を実行することを検討してください。 これらのレベルは、低パフォーマンスで低コストです。 Basic レベルまたは Free レベルを使用する場合は、ガバナンスを使用して階層を適用し、インスタンスと CPU の数を制限し、スケーリングを制限し、ログのリテンション期間を制限します。
設計パターンを実装する: この戦略により、ワークロードによって生成される要求の量が減ります。 Backends for Frontends パターン や ゲートウェイ集約パターンなどのパターンを使用して、要求の数を最小限に抑え、コストを削減することを検討してください。
データ関連のコストを定期的に確認します。 拡張データ保有期間またはコストの高いストレージ層では、高いストレージ コストが発生する可能性があります。 帯域幅の使用とログ データの長期保持のために、より多くの費用が蓄積される可能性があります。
データ転送コストを最小限に抑えるために、キャッシュの実装を検討してください。 ローカルのメモリ内キャッシュから始めて、分散キャッシュ オプションを調べて、バックエンド データベースへの要求の数を減らします。 データベースが別のリージョンに配置されている場合は、リージョン間通信に関連付けられている帯域幅トラフィック コストを考慮してください。
デプロイ コストを最適化する: デプロイ スロットを利用してコストを最適化します。 スロットは、運用インスタンスと同じコンピューティング環境で実行されます。 スロットを切り替える青緑色のデプロイなどのシナリオに戦略的に使用します。 この方法では、ダウンタイムを最小限に抑え、スムーズな移行を保証します。
デプロイ スロットは慎重に使用してください。 既存のインスタンスや新しいインスタンスに影響する可能性がある問題 (例外やメモリ リークなど) が発生する可能性があります。 変更を十分にテストしてください。 運用ガイダンスの詳細については、「オペレーショナル エクセレンス を参照してください。
推奨 事項
| 勧告 | 特長 |
|---|---|
| (App Service) 下位環境には 無料レベルまたは Basic レベルを選択してください。 試験的な使用には、これらのレベルをお勧めします。 不要になったレベルを削除します。 | Free レベルと Basic レベルは、上位レベルと比較して予算に優しいレベルです。 これらは、Premium プランの完全な機能とパフォーマンスを必要としない非運用環境向けのコスト効率の高いソリューションを提供します。 |
| (App Service)割引を利用し、次の場合に推奨される価格を確認します。 - 開発/テスト計画がある低い環境。 - Premium v3 レベルと App Service Environment でプロビジョニングする専用コンピューティング用の Azure の予約および Azure 節約プラン。 予測可能な使用パターンを持つ安定したワークロードには、予約インスタンスを使用します。 |
開発/テスト計画では、Azure サービスの料金が削減されるため、非運用環境でコスト効率が高くなります。 予約インスタンスを使用してコンピューティング リソースの前払いを行い、大幅な割引を受けます。 |
| (Web Apps) App Service リソースによって発生するコストを監視します。 Azure portal でコスト分析ツールを実行します。 利害関係者に通知するための予算とアラート を作成します。 |
コストの急増、非効率性、または予期しない費用を早い段階で特定できます。 このプロアクティブなアプローチは、支出超過を防ぐための予算管理を提供するのに役立ちます。 |
| (App Service)需要が減少したときにスケールインします。 Azure Monitor のインスタンス数を減らすために、スケール ルールを定義してスケールインします。 | 無駄を防ぎ、不要な費用を削減します。 |
オペレーショナル エクセレンス
オペレーショナル エクセレンスは主に、開発プラクティス、可観測性、リリース管理の手順に重点を置いています。
オペレーショナル エクセレンス設計原則、ワークロードの運用要件に対してこれらの目標を達成するための高度な設計戦略を提供します。
設計チェックリスト
Web Apps に関連する監視、テスト、デプロイのプロセスを定義するためのオペレーショナル エクセレンス の 設計レビュー チェックリストに基づいて、設計戦略を開始します。
リリースの管理: デプロイ スロットを使用してリリースを効果的に管理します。 スロットにアプリケーションをデプロイし、テストを実行し、その機能を検証できます。 検証後、アプリを運用環境にシームレスに移動できます。 スロットは運用インスタンスと同じ仮想マシン (VM) 環境で実行されるため、このプロセスでは追加コストは発生しません。
プレビュー付きスワップ (複数フェーズ スワップ) 機能を使用します。 プレビューとのスワップを使用すると、ステージング スロット内のアプリを運用環境の設定に照らしてテストしたり、アプリをウォームアップしたりできます。 テストを実行し、必要なすべてのパスをウォームアップした後、スワップを完了できます。 その後、アプリは再起動せずに運用トラフィックを受信します。
自動テストを実行する: Web アプリのリリースを昇格する前に、そのパフォーマンス、機能、および他のコンポーネントとの統合を十分にテストします。 を使用して Azure Load Testingを行います。 これは、パフォーマンス テスト用の一般的なツールである Apache JMeter と統合されています。 機能テスト用のファントムなど、他の種類のテスト用の自動化されたツールについて説明します。
デプロイの自動化: Azure DevOps または GitHub Actions で継続的インテグレーションと継続的デプロイ パイプラインを使用してデプロイを自動化し、手動での作業を減らします。 詳細については、「App Serviceへの継続的デプロイ」を参照してください。
不変ユニットをデプロイする: App Service を不変スタンプに区画化するために デプロイ スタンプ パターンを実装します。 App Service では、本質的に不変であるコンテナーの使用がサポートされています。 App Service Web アプリには カスタム コンテナー を検討してください。
各スタンプは、すばやくスケールアウトまたはスケールインできる自己完結型のユニットを表します。 このスタンプに基づく単位は一時的でステートレスです。 ステートレス設計により、運用とメンテナンスが簡素化されます。 このアプローチは、ミッション クリティカルなアプリケーションに最適です。 詳細については、「App Service を使用したミッション クリティカルなベースライン」を参照してください。
Bicep などのインフラストラクチャをコードとして扱う技術（IaC）を使用して、再現性と一貫性のあるユニットを作成します。
運用環境を安全に保つ: 運用環境と実稼働前環境を実行する個別の App Service プランを作成します。 安定性と信頼性を確保するために、運用環境で直接変更を加えないでください。 別々のインスタンスを使用すると、本番環境に変更を反映する前に、開発とテストを柔軟に行えます。
低環境を使用して、分離された方法で新しい機能と構成を探索します。 開発環境とテスト環境を一時的な状態に保ちます。
証明書の管理: カスタム ドメインの場合は、TLS 証明書を管理する必要があります。
証明書を調達、更新、検証するためのプロセスを用意します。 可能であれば、これらのプロセスを App Service にオフロードします。 独自の証明書を使用する場合は、その更新を管理する必要があります。 セキュリティ要件に最も適したアプローチを選択します。
| 勧告 | 特長 |
|---|---|
| (Web Apps) インスタンス の正常性を監視し、インスタンスの正常性プローブをアクティブ化します。 正常性プローブ要求を処理するための特定のパスを設定します。 |
問題を迅速に検出し、可用性とパフォーマンスを維持するために必要なアクションを実行できます。 |
| (Web Apps) アプリケーションとインスタンスの診断ログ を有効にします。 頻繁にログを記録すると、システムのパフォーマンスが低下し、ストレージ コストが増え、ログに安全でないアクセス権がある場合はリスクが生じる可能性があります。 次のベスト プラクティスに従います。 - 適切なレベルの情報をログに記録します。 - データ保持ポリシーを設定します。 - 承認されたアクセスと未承認の試行の監査証跡を保持します。 - ログをデータとして扱い、データ保護コントロールを適用します。 |
診断ログは、アプリの動作に関する貴重な分析情報を提供します。 トラフィック パターンを監視し、異常を特定します。 |
| (Web Apps)App Service で管理される証明書 を利用して、認定管理を Azure にオフロードします。 | App Service は、証明書の調達、証明書の検証、証明書の更新、Key Vault からの証明書のインポートなどのプロセスを自動的に処理します。 または、Key Vault に証明書をアップロードし、App Service リソース プロバイダーにアクセスすることを承認します。 |
| (App Service) ステージング スロットでアプリの変更を検証してから、本番スロットとスワップします。 | ダウンタイムとエラーを回避します。 スワップ後に問題を検出した場合は、最新の正常な状態にすばやく戻ります。 |
パフォーマンス効率
パフォーマンス効率とは、容量の管理により、負荷が増加してもユーザー エクスペリエンスを維持することです。 この戦略には、リソースのスケーリング、潜在的なボトルネックの特定と最適化、ピーク パフォーマンスの最適化が含まれます。
パフォーマンス効率設計の原則、予想される使用に対してこれらの容量目標を達成するための高度な設計戦略を提供します。
設計チェックリスト
パフォーマンス効率 の設計レビュー チェックリストに基づいて、設計戦略を開始します。 Web Apps の主要業績評価指標に基づくベースラインを定義します。
パフォーマンス インジケーターの識別と監視: 受信要求の量、アプリケーションが要求に応答するのにかかる時間、保留中の要求、HTTP 応答のエラーなど、アプリケーションの主要なインジケーターのターゲットを設定します。 ワークロードのパフォーマンス ベースラインの一部として、主要なインジケーターを検討します。
パフォーマンス インジケーターの基礎となる App Service メトリックをキャプチャします。 ログを収集して、リソースの使用状況とアクティビティに関する分析情報を取得します。 Application Insights などのアプリケーション パフォーマンス監視ツールを使用して、アプリケーションからパフォーマンス データを収集および分析します。 詳細については、「App Service 監視データ リファレンス」を参照してください。
コード レベルのインストルメンテーション、トランザクション トレース、パフォーマンス プロファイリングを含めます。
容量の評価: さまざまなユーザー シナリオをシミュレートして、予想されるトラフィックを処理するために必要な最適な容量を決定します。 ロード テストを使用して、さまざまなレベルの負荷でアプリケーションがどのように動作するかを理解します。
適切なレベルを選択します。 運用ワークロードに専用コンピューティングを使用します。 Premium v3 レベルでは、メモリと CPU の容量が増え、インスタンスが増え、ゾーンの冗長性などのより多くの機能を備えた、より大きな SKU が提供されます。 詳細については、「premium v3 価格レベル 」を参照してください。
スケーリング戦略を最適化する: 可能な場合は、アプリケーションの負荷の変化に応じてインスタンスの数を手動で調整するのではなく、自動スケーリング を使用します。 自動スケールを使用すると、App Service は定義済みのルールまたはトリガーに基づいてサーバー容量を調整します。 適切なパフォーマンス テストを行い、適切なトリガーに適切な規則を設定してください。
初期セットアップ中に簡略化に優先順位を付ける場合は、ルールを定義しなくても、制限の設定のみを必要とする自動スケール オプションを使用します。
最適なパフォーマンスを確保するのに役立つ十分なリソースをすぐに使用できるようにします。 応答時間やスループットなど、パフォーマンス目標を維持するためにリソースを適切に割り当てます。 必要に応じて、リソースの過剰な割り当てを検討してください。
自動スケール ルールを定義するときは、アプリケーションの初期化にかかる時間を考慮します。 すべてのスケーリングの決定を行うときは、このオーバーヘッドを考慮してください。
キャッシュの使用: 頻繁に変更されないリソースから情報を取得し、アクセスにコストがかかる場合は、パフォーマンスに影響します。 結合や複数の参照を含む複雑なクエリは、ランタイムに影響します。 キャッシュを実行して、処理時間と待機時間を最小限に抑えます。 クエリ結果をキャッシュして、データベースまたはバックエンドへのラウンド トリップが繰り返されないようにし、後続の要求の処理時間を短縮します。
ワークロードでのローカルキャッシュと分散キャッシュの使用の詳細については、「キャッシュ」を参照してください。
パフォーマンスのアンチパターンを確認する: Web アプリケーションがビジネス要件に従って実行およびスケーリングされることを確認するには、一般的なアンチパターン を回避します。 次の表では、App Service で修正されるアンチパターンについて説明します。
アンチパターン 説明 ビジー状態のフロント エンド リソースを集中的に使用するタスクでは、ユーザー要求の応答時間が長くなり、待機時間が長くなる可能性があります。
大量のリソースを消費するプロセスを別のバックエンドに移動します。 メッセージ ブローカーを使用して、バックエンドが非同期的に処理するために取得するリソースを大量に消費するタスクをキューに入れます。キャッシュしない 待機時間を短縮するために、バックエンド データベースの前にある中間キャッシュからの要求を処理します。 騒がしい隣人 マルチテナント システムは、テナント間でリソースを共有します。 あるテナントのアクティビティは、別のテナントによるシステムの使用に悪影響を及ぼす可能性があります。 App Service Environment には、App Service アプリを実行するための完全に分離された専用の環境が用意されています。
推奨 事項
| 勧告 | 特長 |
|---|---|
| (App Service) アプリケーションが 1 つの App Service プランを共有する場合に Always On 設定を有効にします。 App Service アプリは、リソースを保存するためにアイドル状態になると自動的にアンロードされます。 次の要求によってコールド スタートがトリガーされ、要求のタイムアウトが発生する可能性があります。 | Always On が有効な状態でアプリケーションがアンロードされることはありません。 |
| (Web Apps) プロトコルの効率を向上させるために、アプリケーションに HTTP/2 を使用することを検討してください。 | HTTP/2 は接続を完全に多重化し、接続を再利用してオーバーヘッドを削減し、ヘッダーを圧縮してデータ転送を最小限に抑えるため、HTTP/1.1 経由で HTTP/2 を選択します。 |
トレードオフ
柱のチェックリストのアプローチを使用する場合は、設計のトレードオフを行う必要がある場合があります。 利点と欠点の例をいくつか次に示します。
密度と隔離
高密度: リソースを最小限に抑えるために、同じ App Service プラン内に複数のアプリを併置します。 すべてのアプリは CPU やメモリなどのリソースを共有するため、コストを節約し、運用の複雑さを軽減できます。 この方法では、リソースの使用も最適化されます。 アプリは、時間の経過と同時に読み込みパターンが変化した場合に、別のアプリのアイドル 状態のリソースを使用できます。
また、リソースの競合などの欠点も考慮してください。 たとえば、アプリの使用量の急増や不安定性は、他のアプリのパフォーマンスに影響を与える可能性があります。 1 つのアプリのインシデントは、共有環境内の他のアプリにも浸透し、セキュリティに影響を与える可能性があります。 高可用性とパフォーマンスを必要とする重要なアプリケーションの場合、App Service Environment v3 などの分離された環境 専用のリソースを提供しますが、コストは高くなります。 クリティカルでないワークロードには共有環境を使用し、ミッション クリティカルなアプリケーションには分離された環境を使用することを検討してください。
高い分離: 分離は干渉を防ぐのに役立ちます。 この戦略は、開発、テスト、運用環境のセキュリティ、パフォーマンス、さらには分離にも適用されます。
App Service Environment では、各アプリに独自のセキュリティ設定を設定できるため、セキュリティとデータ保護をより適切に制御できます。 分離は影響範囲を最小限に抑えるため、環境で侵害を封じ込めることができます。 リソースの競合は、パフォーマンスの観点から最小限に抑えられます。 分離により、特定の需要と個々の容量計画に基づく独立したスケーリングが可能になります。
欠点として、このアプローチはコストが高く、運用上の厳格さが必要です。
信頼できるスケーリング戦略
適切に定義されたスケーリング戦略は、パフォーマンスを損なうことなく、アプリケーションがさまざまな負荷を処理できるようにするのに役立ちます。 ただし、コストのトレードオフがあります。 スケーリング操作には時間がかかります。 新しいリソースが割り当てられると、アプリケーションは要求を効果的に処理する前に適切に初期化する必要があります。 リソース (または運用前のインスタンス) をオーバープロビジョニングして、セーフティ ネットを提供できます。 追加の容量がないと、初期化フェーズ中に要求の処理に遅延が生じる可能性があり、ユーザー エクスペリエンスに影響します。 自動スケール操作は、お客様がリソースを使用するまでに適切なリソース初期化を有効にするために十分な早い段階でトリガーされる可能性があります。
欠点として、過剰にプロビジョニングされたリソースのコストが高くなります。 事前に予約されたインスタンスを含め、すべてのインスタンスに対して 1 秒あたりに課金されます。 上位レベルには、事前に予約されたインスタンスが含まれます。 コストの高いレベルの機能が投資に値するかどうかを判断します。
冗長性 の構築
冗長性は回復性を提供しますが、コストも発生します。 ワークロードのサービス レベル目標 (SLO) によって、許容されるパフォーマンスしきい値が決まります。 冗長性が SLO 要件を超えると無駄になります。 余分な冗長性によって SLO が改善されるか、不要な複雑さが増すのかを評価します。
また、欠点も考慮してください。 たとえば、複数リージョンの冗長性により高可用性が実現されますが、データ同期、フェールオーバー メカニズム、および地域間通信のために複雑さとコストが追加されます。 ゾーンの冗長性が SLO を満たすことができるかどうかを判断します。
Azure ポリシー
Azure には、App Service とその依存関係に関連する広範な組み込みポリシー セットが用意されています。 一連の Azure ポリシーは、上記の推奨事項の一部を監査できます。 たとえば、次のことを確認できます。
適切なネットワーク制御が行われている。 たとえば、仮想ネットワークの挿入を通じて App Service を Azure Virtual Network に配置してネットワークのセグメント化を組み込み、ネットワーク構成をより詳細に制御できます。 アプリケーションにはパブリック エンドポイントがないため、プライベート エンドポイントを介して Azure サービスに接続します。
ID コントロールが用意されています。 たとえば、アプリケーションはマネージド ID を使用して他のリソースに対して自身を認証します。 App Service の組み込み認証 (または Easy Auth) は、受信要求を検証します。
リモート デバッグや基本認証などの機能は、攻撃対象領域を減らすために無効になっています。
包括的なガバナンスについては、Azure Policy の組み込み定義 と、コンピューティング レイヤーのセキュリティに影響する可能性があるその他のポリシーを確認します。
Azure Advisor の推奨事項
Azure Advisor は、Azure デプロイを最適化するためのベスト プラクティスに従うのに役立つ、パーソナライズされたクラウド コンサルタントです。
詳細については、Azure Advisor に関するページを参照してください。
次の手順
この記事で強調表示されている推奨事項を示すリソースとして、次の記事を検討してください。
これらの推奨事項をワークロードに適用する方法の例として、次の参照アーキテクチャを使用します。
- Web アプリをデプロイしていない場合は、「Basic Web アプリケーションの」を参照してください。
- 運用グレードのデプロイの開始点としての基本アーキテクチャについては、ベースラインの高可用性ゾーン冗長 Web アプリケーションを参照してください。
実装の専門知識を構築するには、次の製品ドキュメントを使用します。