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