この記事では、単一のリージョンで Azure App Service 上で Web アプリケーションを実行する方法について学習するための基本的なアーキテクチャについて説明します。
重要
このアーキテクチャは、運用アプリケーションで使用するためのものではありません。 これは、学習や概念実証 (POC) の目的で使用できる入門アーキテクチャとなることを目的としています。 運用環境の Azure App Service アプリケーションを設計する場合は、「ベースライン高可用性ゾーン冗長 Web アプリケーション」を参照してください。
重要
このガイダンスは、Azure でのこの基本的な App Service 実装を紹介する実施例によって裏付けられています。 この実装は、Azure App Service の操作を体験するための POC の基盤として使用できます。
Architecture
図１: Azure App Service の基本的なアーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
- ユーザーは、azurewebsites.net 上の App Service の既定のドメインに HTTPS 要求を発行します。 このドメインは、App Service の組み込みパブリック IP を自動的にポイントします。 TLS 接続はクライアントからアプリサービスに直接確立されます。 証明書は Azure によって完全に管理されます。
- Azure App Service の機能である Easy Auth により、サイトにアクセスするユーザーが Microsoft Entra ID で認証されることが保証されます。
- App Service にデプロイされたアプリケーション コードにより要求は処理されます。 たとえば、そのコードは、アプリ設定として構成された App Service で構成された接続文字列を使用して、Azure SQL Database インスタンスに接続する場合があります。
- App Service への元の要求と Azure SQL Database への呼び出しに関する情報が Application Insights に記録されます。
コンポーネント
- Microsoft Entra ID は、Microsoft のクラウドベースの ID およびアクセス管理サービスです。 Web アプリケーションにアクセスするユーザーのアクセス許可とロールを管理するための単一の ID コントロール プレーンを提供します。 App Service と統合され、Web アプリの認証と認可を簡素化します。
- App Service は、Web アプリケーションをビルド、デプロイ、スケーリングするためのフル マネージド プラットフォームです。
- Azure Monitor は、デプロイ全体のテレメトリ データを収集して分析し、アクションを実行する監視サービスです。
- Azure SQL Database は、リレーショナル データ用のマネージド リレーショナル データベース サービスです。
推奨事項と考慮事項
このアーキテクチャにリストされているコンポーネントは、Azure Well-Architected サービスガイドにリンクしています。 サービスガイドには、特定のサービスに関する推奨事項と考慮事項が詳細に記載されています。 このセクションでは、このアーキテクチャに適用される主要な Azure Well-Architected Framework の推奨事項と考慮事項を強調して、そのガイダンスを拡張します。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
この基本的なアーキテクチャは、運用環境へのデプロイを目的としたものではありません。 このアーキテクチャでは、Azure App Service を評価して学習できるように、機能性よりもシンプルさとコスト効率を重視しています。 次のセクションでは、この基本的なアーキテクチャのいくつかの欠陥と、推奨事項と考慮事項について説明します。
[信頼性]
信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。
このアーキテクチャは運用環境へのデプロイ用に設計されていないため、このアーキテクチャでは省略されている重要な信頼性機能の一部を次に説明します。
- App Service プランは、Azure 可用性ゾーンがサポートされていない
Standardレベル用に構成されています。 インスタンス、ラック、またはインスタンスをホストしているデータセンターに問題が発生した場合、App Service は利用できなくなります。 - Azure SQL Database は、ゾーン冗長性をサポートしない
Basicレベル用に構成されています。 つまり、データは Azure 可用性ゾーン間でレプリケートされず、障害が発生した場合にコミットされたデータが失われるリスクがあります。 - ほとんどのデプロイ手法では実行中のインスタンスをすべて再起動する必要があるため、このアーキテクチャへのデプロイではアプリケーションのデプロイでダウンタイムが発生する可能性があります。 このプロセス中に、ユーザーは 503 エラーを経験する可能性があります。 これは、ベースライン アーキテクチャのデプロイ スロットを通じて対処されます。 同時スロット デプロイをサポートするには、慎重なアプリケーション設計、スキーマ管理、およびアプリケーション構成の処理が必要です。 この POC を使用して、スロットベースの運用デプロイ手法を設計および検証します。
- この基本的なアーキテクチャでは自動スケーリングは有効になっていません。 利用可能なコンピューティング リソースの不足による信頼性の問題を防ぐには、最大の同時処理能力を処理するのに十分なコンピューティングを常に実行できるようにオーバープロビジョニングする必要があります。
これらの信頼性に関する懸念を克服する方法については、「ベースラインの高可用性ゾーン冗長 Web アプリケーションの信頼性」セクションを参照してください。
このワークロードで最終的に複数リージョンのアクティブ/アクティブまたはアクティブ/パッシブ アーキテクチャが必要になる場合は、App Service でホストされるワークロードを複数リージョンにデプロイするためのガイダンスとして、「可用性の高い複数リージョンの Web アプリケーション」を参照してください。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。
このアーキテクチャは運用環境へのデプロイ用に設計されていないため、このアーキテクチャでは省略されている重要なセキュリティ機能の一部と、その他の信頼性に関する推奨事項と考慮事項を次に説明します。
この基本的なアーキテクチャでは、ネットワーク プライバシーは実装されません。 Azure App Service や Azure SQL Server などのリソースのデータ プレーンと管理プレーンには、パブリック インターネット経由でアクセスできます。 プライベート ネットワークを省略すると、アーキテクチャのアタック サーフェスが大幅に増加します。 プライベート ネットワークを実装することで次のセキュリティ機能が確保される仕組みについては、「ベースライン高可用性ゾーン冗長 Web アプリケーションのネットワーク」セクションを参照してください。
- クライアント トラフィックの単一の安全なエントリ ポイント
- ネットワーク トラフィックは、パケット レベルと DDoS レベルの両方でフィルタリングされます。
- Private Link を使用して Azure にトラフィックを保持することで、データ流出は最小限に抑えられます
- ネットワーク リソースは論理的にグループ化され、ネットワークのセグメント化によって互いに分離されます。
この基本的なアーキテクチャには、Azure Web アプリケーション ファイアウォールのデプロイは含まれません。 Web アプリケーションは、一般的な悪用や脆弱性に対して保護されていません。 Azure App Services アーキテクチャで Azure Application Gateway を使用して Web アプリケーション ファイアウォールを実装する方法については、「ベースライン実装」を参照してください。
この基本的なアーキテクチャでは、Azure SQL Server 接続文字列などのシークレットがアプリ設定に保存されます。 アプリ設定は暗号化されていますが、運用環境に移行するときは、ガバナンスを強化するために、シークレットを Azure Key Vault に保存することを検討してください。 さらに優れた解決策は、認証にマネージド ID を使用し、接続文字列にシークレットを保存しないことです。
開発中または概念実証フェーズでは、リモート デバッグと Kudu エンドポイントを有効のままにしておいても問題ありません。 運用環境に移行するときは、不要なコントロール プレーン、デプロイト、またはリモート アクセスを無効にする必要があります。
開発段階または概念実証段階では、FTP および SCM サイトのデプロイに対してローカル認証方法を有効のままにしておいても問題ありません。 運用環境に移行するときは、それらのエンドポイントへのローカル認証を無効にする必要があります。
概念実証フェーズでは、Microsoft Defender for App Service を有効にする必要はありません。 運用環境に移行するときは、セキュリティ体制を強化し、App Service に対する複数の脅威を検出するために実装する必要があるセキュリティ推奨事項を生成するために、Defender for App Service を有効にする必要があります。
Azure App Service には、追加料金なしで
azurewebsites.netのサブドメインに SSL エンドポイントが含まれています。 HTTP 要求は既定で HTTPS エンドポイントにリダイレクトされます。 運用環境のデプロイでは、通常、App Service デプロイの前にあるアプリケーション ゲートウェイまたは API 管理に関連付けられたカスタム ドメインを使用します。App Service の統合認証メカニズム ("EasyAuth") を使用します。 EasyAuth を使用すると、ID プロバイダーを Web アプリに統合するプロセスが簡略化されます。 Web アプリの外部で認証が処理されるため、コードを大幅に変更する必要はありません。
ワークロード ID にはマネージド ID を使用します。 マネージド ID を使用すると、開発者は認証資格情報を管理する必要がなくなります。 基本的なアーキテクチャでは、接続文字列内のパスワードを使用して SQL Server に認証します。 Azure SQL Server への認証にはマネージド ID の使用を検討してください。
その他のセキュリティの考慮事項については、Azure App Service でのアプリのセキュリティ保護に関するページを参照してください。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。
次のセクションでは、App Service アプリケーションの構成、監視、およびデプロイに関するガイダンスを提供します。
アプリの構成
基本的なアーキテクチャは運用環境向けではないため、構成値とシークレットを格納するために App Service 構成が使用されます。 PoC フェーズでは、App Service 構成にシークレットを保存しても問題ありません。 実際のシークレットを使用しておらず、運用ワークロードに必要なシークレット ガバナンスは必要ありません。
構成に関する推奨事項と考慮事項は次のとおりです。
- 概念実証のデプロイでは、App Service 構成を使用して構成値と接続文字列を保存することから始めます。 アプリの設定と接続文字列は、アプリの起動時にアプリに挿入される直前に暗号化および復号化されます。
- 運用フェーズに移行するときは、シークレットを Azure Key Vault に保存します Azure Key Vault を使用すると、次の 2 つの方法でシークレットのガバナンスが向上します。
- シークレットのストレージを Azure Key Vault に外部化すると、シークレットのストレージを一元化できます。 秘密を管理する場所は 1 か所です。
- Azure Key Vault を使用すると、シークレットにアクセスしたすべての時間を含む、シークレットとのすべてのやり取りをログに記録できます。
- 運用環境に移行すると、Key Vault 参照を使用することで、Azure Key Vault と App Service 構成の両方の使用を維持できます。
診断および監視
概念実証フェーズでは、キャプチャ可能なログとメトリックについて理解することが重要です。 概念実証フェーズでの監視に関する推奨事項と考慮事項は次のとおりです。
- すべての項目のログソースの診断ログを有効にします。 すべての診断設定の使用を構成すると、すぐに使用できるログとメトリック、およびアプリケーションコードでログ記録フレームワークを使用して埋める必要があるギャップを理解するのに役立ちます。 運用環境に移行するときは、価値を追加せず、ワークロードのログシンクにノイズとコストを追加しているログソースを削除する必要があります。
- Azure Log Analytics を使用するようにログ記録を構成します。 Azure Log Analytics は、クエリが簡単に行えるログ記録を一元管理するスケーラブルなプラットフォームを提供します。
- Application Insights または別のアプリケーション パフォーマンス管理 (APM) ツールを使用してテレメトリとログを出力し、アプリケーションのパフォーマンスを監視します。
展開
以下に、App Service アプリケーションのデプロイに関するガイダンスを示します。
- アプリケーションのデプロイを自動化するには、「Azure Pipelines を使用した Azure Web アプリの CI/CD」のガイダンスに従います。 PoC フェーズでデプロイメントロジックの構築を開始します。 開発プロセスの早い段階で CI/CD を実装すると、運用環境に移行する際にアプリケーションを迅速かつ安全に反復処理できます。
- ARM テンプレートを使用して、Azure リソースとその依存関係をデプロイします。 このプロセスを PoC フェーズで開始することが重要です。 運用環境に移行すると、インフラストラクチャを自動的にデプロイする機能が必要になります。
- さまざまな ARM テンプレートを使用し、Azure DevOps サービスと統合します。 この設定により、さまざまな環境を作成できます。 たとえば、運用環境に似たシナリオやロード テスト環境を必要なときにだけレプリケートして、コストを節約できます。
詳細については、Azure Well-Architected Framework の DevOps に関するセクションを参照してください。
Containers
基本的なアーキテクチャを使用すると、サポートされているコードを Windows または Linux インスタンスに直接デプロイできます。 また、App Service は、コンテナー化された Web アプリケーションを実行するためのコンテナー ホスティング プラットフォームでもあります。 App Service はさまざまな組み込みコンテナーを提供します。 カスタム アプリまたはマルチコンテナー アプリを使用してランタイム環境をさらに微調整したり、ネイティブでサポートされていないコード言語をサポートしたりする場合は、コンテナー レジストリを導入する必要があります。
コントロール プレーン
POC フェーズでは、Kudu サービスを通じて公開される Azure App Service のコントロール プレーンに慣れてください。 このサービスは、ZIP デプロイなどの一般的なデプロイ API を公開し、生のログと環境変数を公開します。
コンテナーを使用する場合は、高度なデバッグ機能をサポートするためにコンテナーへの SSH セッションを開く Kudu の機能を必ず理解してください。
パフォーマンス効率
パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。
このアーキテクチャは運用環境へのデプロイ用に設計されていないため、このアーキテクチャでは省略されている重要なパフォーマンス効率機能の一部と、その他の推奨事項と考慮事項を次に説明します。
概念実証の結果により、ワークロードに適していると推定される SKU を選択する必要があります。 ワークロードは、App Service プランにデプロイされたコンピューティング インスタンスの数を調整することで、水平スケーリングを通じて需要を効率的に満たすように設計する必要があります。 需要に合わせてコンピューティング SKU を変更することに依存するようなシステムを設計しないでください。
- この基本的なアーキテクチャの App Service には自動スケーリングは実装されていません。 サービスは、需要に効率的に対応するために動的にスケールアウトまたはスケールインしません。
- SQL Database にさらに高いサービス レベルまたはパフォーマンス レベルが必要な場合は、アプリケーションのダウンタイムなしに個々のデータベースをスケールアップするためのガイダンスに従って対処してください。
このシナリオのデプロイ
このガイダンスは、Azure での基本的な App Service 実装を紹介する実装例によって裏付けられています。
次のステップ
関連リソース
製品ドキュメント:
- App Service の概要
- Azure Monitor の概要
- Azure App Service プランの概要
- Azure Monitor の Log Analytics の概要
- Microsoft Entra ID とは
- Azure SQL Database とは何ですか?
Microsoft Learn モジュール：