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