基本的な Web アプリケーション

Azure App Service

Azure Monitor

Azure SQL Database

この記事では、1 つのリージョンでAzure App Serviceで Web アプリケーションを実行する方法について説明する基本的なアーキテクチャについて説明します。

重要

このアーキテクチャは、運用アプリケーション向けではありません。これは、学習と概念実証 (POC) の目的のための入門用セットアップとして機能します。運用 App Service アプリケーションを設計するには、「ベースラインの高可用性ゾーン冗長 Web アプリケーション」を参照してください。

アーキテクチャ

このアーキテクチャの Visio ファイルをダウンロードします。

Workflow

以下のワークフローは、前の図に対応しています。

ユーザーは、 azurewebsites.netの App Service の既定のドメインに HTTPS 要求を発行します。このドメインは、App Service アプリケーションの組み込みのパブリック IP アドレスを自動的に指します。トランスポート層セキュリティ (TLS) 接続は、クライアントから App Service に直接確立されます。 Azureは証明書を完全に管理します。
App Service の機能である Easy Auth を使用すると、サイトにアクセスするユーザーがMicrosoft Entra IDを使用して認証されます。
App Service にデプロイされたアプリケーションコードにより要求は処理されます。たとえば、そのコードは、App Service でアプリ設定として構成された接続文字列を使用して、Azure SQL Database インスタンスに接続できます。
App Service に対する元の要求と SQL Database の呼び出しに関する情報は、Application Insights に記録されます。

コンポーネント

Microsoft Entra ID は、認証と承認の機能を提供するクラウドベースの ID およびアクセス管理サービスです。このアーキテクチャでは、Easy Auth を通じて App Service と統合され、Web アプリケーションにアクセスするユーザーの認証が保証されます。また、大幅なコード変更を必要とせずに認証プロセスを簡略化します。
App Service は、Web アプリケーションを構築、デプロイ、およびスケーリングするためのマネージドプラットフォームです。このアーキテクチャでは、Web アプリケーションコードをホストし、既定の azurewebsites.net ドメインで HTTPS 要求を処理し、構成された接続文字列を使用して SQL Database に接続します。
Azure Monitor は、クラウドおよびオンプレミス環境からのテレメトリデータを収集、分析、および処理する監視サービスです。このアーキテクチャでは、App Service への要求と Application Insights 統合による SQL Database の呼び出しに関する情報をキャプチャして格納します。
SQL Database は、クラウドで SQL Server 機能を提供するマネージドリレーショナルデータベースサービスです。このアーキテクチャでは、データストレージレイヤーとして機能します。これにより、App Service アプリケーションは、アプリ設定で定義されている接続文字列を介して接続できます。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。詳細については、「 Well-Architected Framework」を参照してください。

このアーキテクチャに記載されているコンポーネントは、Well-Architected サービスガイドにリンクされています。サービスガイドには、特定のサービスに関する推奨事項と考慮事項が詳細に記載されています。このセクションでは、このアーキテクチャに適用される主要なWell-Architected Framework の推奨事項と考慮事項を強調することで、そのガイダンスを拡張します。

この基本的なアーキテクチャは、評価と学習のみを目的として設計されています。運用グレードの機能よりも、シンプルさとコスト効率が優先されます。次のセクションでは、このアーキテクチャの主な制限事項を取り上げ、より堅牢なデプロイの計画に役立つ推奨事項と考慮事項を示します。

[信頼性]

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。詳細については、「信頼性の設計レビューチェックリスト」を参照してください。

このアーキテクチャは、運用環境のデプロイ用に設計されていません。このアーキテクチャでは、次の重要な信頼性機能は省略されています。

App Service プランは Standard レベル用に構成されています。これには、Azure 可用性ゾーンのサポートは含まれません。インスタンス、ラック、またはインスタンスをホストするデータセンターで問題が発生した場合、App Service は使用できなくなります。
SQL Database は Basic レベル用に構成されており、ゾーン冗長はサポートされていません。その結果、データはAzure可用性ゾーン間でレプリケートされないため、停止が発生した場合にコミットされたデータが失われるリスクがあります。
このアーキテクチャへのデプロイでは、ほとんどのデプロイ手法で実行中のすべてのインスタンスを再起動する必要があるため、アプリケーションのデプロイでダウンタイムが発生する可能性があります。ユーザーは、このプロセス中に 503 エラーが発生する可能性があります。このデプロイダウンタイムは、デプロイスロットを通じてベースラインアーキテクチャで対処されます。同時スロットデプロイをサポートするには、慎重なアプリケーション設計、スキーマ管理、およびアプリケーション構成の処理が必要です。この POC を使用して、スロットベースの運用デプロイ手法を設計および検証します。
この基本アーキテクチャでは、自動スケールは有効になっていません。コンピューティングリソースの不足による信頼性の問題を回避するには、最大同時需要を処理するのに十分な容量を確保するためにオーバープロビジョニングする必要があります。

これらの信頼性の問題を克服する方法の詳細については、「ベースラインの高可用性ゾーン冗長 Web アプリケーション - 信頼性」を参照してください。

ワークロードで複数リージョンのアクティブ-アクティブまたはアクティブ-パッシブアーキテクチャが必要な場合は、ディザスターリカバリーのためのマルチリージョン App Service アプリのアプローチに関する記事を参照してください。

セキュリティ

セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。詳細については、「セキュリティの設計レビューチェックリスト」を参照してください。

このアーキテクチャは、運用環境のデプロイ用に設計されていません。このアーキテクチャでは、次の重要なセキュリティ機能と、その他の信頼性に関する推奨事項と考慮事項は省略されています。

この基本的なアーキテクチャでは、ネットワークプライバシーは実装されません。 App Service や Azure SQL Server などのリソースのデータと管理プレーンには、パブリックインターネット経由で到達できます。プライベートネットワークを省略すると、アーキテクチャのアタックサーフェスが大幅に増加します。プライベートネットワークを実装して次のセキュリティ機能を確保する方法の詳細については、「ベースラインの高可用性ゾーン冗長 Web アプリケーション - ネットワーク」を参照してください。プライベートネットワークを実装すると、次のセキュリティ機能を提供することで、これらのリスクを軽減できます。
- クライアントトラフィック用の単一のセキュリティで保護されたエントリポイント。
- ネットワークトラフィックは、パケットレベルと分散型サービス拒否 (DDoS) レベルの両方でフィルター処理されます。
- データ流出は、Azure Private Linkを使用してトラフィックをAzureに保つことで最小限に抑えられます。
- ネットワークリソースは論理的にグループ化され、ネットワークのセグメント化によって互いに分離されます。
この基本的なアーキテクチャには、Azure Web Application Firewall のデプロイは含まれません。 Web アプリケーションは、一般的な悪用や脆弱性に対して保護されていません。 App Services アーキテクチャでAzure Application Gatewayを使用してAzure Web Application Firewallを実装する方法については、基準実装を参照してください。
この基本的なアーキテクチャでは、アプリ設定にSQL Server 接続文字列などのシークレットが格納されます。アプリ設定は既定で暗号化されます。ただし、運用環境に移行する場合は、ガバナンスを強化するためにAzure Key Vaultにシークレットを格納することを検討してください。セキュリティを強化し、シークレット管理のオーバーヘッドを軽減するには、接続文字列にシークレットを埋め込む代わりに、マネージド ID を認証に使用することを検討してください。
リモートデバッグと Kudu エンドポイントは、開発中または POC フェーズ中も有効なままにすることができます。運用環境に移行するときは、不要なコントロールプレーン、デプロイト、またはリモートアクセスを無効にする必要があります。
ファイル転送プロトコル (FTP) およびソース管理 (SCM) サイト展開のローカル認証方法は、開発フェーズまたは POC フェーズ中も有効なままにすることができます。運用環境に移行するときは、それらのエンドポイントへのローカル認証を無効にする必要があります。
POCフェーズでMicrosoft Defender for App Serviceを有効にする必要はありません。運用環境に移行するときは、App Service のDefenderを有効にしてセキュリティに関する推奨事項を生成する必要があります。これらの推奨事項を実装して、セキュリティ体制を強化し、App Service デプロイに対する複数の脅威を検出する必要があります。
App Service には、追加料金なしで azurewebsites.net のサブドメインに Secure Sockets Layer (SSL) エンドポイントが含まれています。 HTTP 要求は既定で HTTPS エンドポイントにリダイレクトされます。運用環境のデプロイの場合、カスタムドメインは通常、App Service デプロイの前に Application Gateway または API Management と共に使用されます。
App Service の統合認証メカニズムを使用します。 Easy Auth を使用すると、ID プロバイダーを Web アプリに統合するプロセスが簡略化されます。 Web アプリの外部で認証が処理されるため、コードを大幅に変更する必要はありません。
ワークロード ID にはマネージド ID を使用します。マネージド ID を使用すると、開発者は認証資格情報を管理する必要がなくなります。基本的なアーキテクチャでは、接続文字列のパスワードを使用して、SQL Serverに対して認証を行います。管理 ID を使用して、SQL Server に対する認証を行することを検討してください。

詳細については、「 App Service でのアプリのセキュリティ保護」を参照してください。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。詳細については、「コストの最適化設計レビューチェックリスト」を参照してください。

このアーキテクチャは、Well-Architected Framework の他の柱との多くのトレードオフを通じてコストを最適化します。これらのトレードオフは、このアーキテクチャの学習と POC の目標に合わせて特別に行われます。ベースラインの高可用性ゾーン冗長 Web アプリケーションなど、運用環境に対応したアーキテクチャと比較したコスト削減は、主に次の選択肢に起因します。

自動スケールが有効になっていない 1 つの App Service インスタンス
App Service の Standard 価格レベル
カスタム TLS 証明書または静的 IP アドレスがない
Web アプリケーションファイアウォール (WAF) なし
アプリケーションのデプロイ用の専用ストレージアカウントがない
バックアップ保持ポリシーがない SQL Database の Basic プラン
Microsoft Defender for Cloud コンポーネントなし
ファイアウォールを経由するネットワークトラフィックエグレス制御なし
プライベートエンドポイントなし
Azure Monitor ログの最小限のログとログ保有期間

このアーキテクチャの推定コストを表示するには、このアーキテクチャのコンポーネントを使用する料金計算ツールの見積もりを参照してください。通常、このアーキテクチャのコストは、Azure Dev/Test サブスクリプションを使用することでさらに削減できます。これは、このような POC に最適なサブスクリプションの種類です。

オペレーショナルエクセレンス

オペレーショナルエクセレンスは、アプリケーションをデプロイし、運用環境で実行し続ける運用プロセスを対象としています。詳細については、「オペレーショナルエクセレンスのデザインレビューチェック一覧」を参照してください。

次のセクションでは、App Service アプリケーションの構成、監視、デプロイに関するガイダンスを提供します。

アプリの構成

基本的なアーキテクチャは運用環境向けではないため、構成値とシークレットを格納するために App Service 構成が使用されます。シークレットは、POC フェーズ中に App Service 構成に格納できます。実際のシークレットは使用せず、運用ワークロードに必要なシークレットガバナンスは必要ありません。

次の構成の推奨事項と考慮事項を検討してください。

まず、App Service 構成を使用して、POC デプロイに構成値と接続文字列を格納します。アプリ設定と接続文字列は、起動時にアプリに挿入される直前に暗号化および復号化されます。
運用環境に移行するときは、シークレットをKey Vaultに格納します。 Key Vaultでは、次の 2 つの方法でシークレットのガバナンスが向上します。
- シークレットをKey Vaultに外部化すると、セキュリティで保護されたシークレット管理のための 1 つの一元化された場所が提供されます。
- Key Vaultを使用すると、シークレットにアクセスするたびに含め、シークレットとのやり取りをすべてログに記録できます。
運用環境に移行する場合は、Key Vault 参照を使用して、Key Vaultと App Service の両方の構成の使用を維持できます。

Containers

基本的なアーキテクチャを使用して、サポートされているコードをWindowsまたは Linux インスタンスに直接デプロイできます。または、App Service は、コンテナー化された Web アプリケーションの実行に使用できるコンテナーホスティングプラットフォームでもあります。 App Service には、さまざまな組み込みコンテナーが用意されています。カスタムアプリまたは複数コンテナーアプリは、ランタイム環境を微調整したり、ネイティブにサポートされていないコード言語をサポートしたりするのに役立ちます。この方法では、コンテナーレジストリを導入する必要があります。

コントロールプレーン

POC フェーズでは、Kudu サービスを介してアクセスできる App Service コントロールプレーンについて理解します。このサービスは、ZIP デプロイなどの一般的なデプロイ API を提供し、生ログと環境変数を公開します。

コンテナーを使用する場合は、高度なデバッグ機能をサポートするためにコンテナーに対して Secure Shell (SSH) セッションを開く Kudu の機能を理解していることを確認してください。

診断および監視

POC フェーズでは、キャプチャに使用できるログとメトリックを理解することが重要です。 POC フェーズでの監視に関する次の推奨事項とアイデアを検討してください。

すべての項目のログソースの診断ログを有効にします。すべての診断設定の使用を構成することで、標準で提供されるログとメトリックを理解し、アプリケーションコードにおいてログ記録フレームワークを用いることで閉じる必要がある不足を特定するのに役立ちます。運用環境に移行するときは、価値を追加せず、ワークロードのログシンクにノイズとコストを追加するログソースを排除します。
Azure Log Analytics を使用するようにログ記録を構成します。 Azure Log Analyticsでは、クエリが簡単なログ記録を一元化するためのスケーラブルなプラットフォームが提供されます。
Application Insights または別のアプリケーションパフォーマンス管理 (APM) ツールを使用して、アプリケーションのパフォーマンスを監視するためのテレメトリとログを出力します。

デプロイ

次のポイントは、App Service アプリケーションをデプロイする方法に関するガイダンスを提供します。

アプリケーションのデプロイを自動化するには、「Azure Pipelines を使用した Azure Web アプリの CI/CD」のガイダンスに従います。 POC フェーズでデプロイロジックの構築を開始します。開発プロセスの早い段階で継続的インテグレーションと継続的デリバリー (CI/CD) を実装することで、運用環境に移行する際にアプリケーションを迅速かつ安全に反復処理できます。
Azure Resource Manager テンプレート (ARM テンプレート) を使用して、Azureリソースとその依存関係をデプロイします。 POC フェーズでこのプロセスを開始することが重要です。運用環境に移行すると、インフラストラクチャを自動的にデプロイする機能が必要になります。
さまざまな ARM テンプレートを使用し、Azure DevOps Services と統合します。この設定により、さまざまな環境を作成できます。たとえば、運用環境に似たシナリオやロードテスト環境を必要なときにだけレプリケートして、コストを節約できます。

詳細については、オペレーショナルエクセレンス設計原則を参照してください。

パフォーマンス効率

パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。詳細については、「パフォーマンス効率の設計レビューチェックリスト」を参照してください。

このアーキテクチャは運用環境のデプロイ用に設計されていないため、このセクションでは、このアーキテクチャで省略された重要なパフォーマンス効率機能の一部と、その他の推奨事項と考慮事項について説明します。

POC の結果は、ワークロードに適していると見積もる SKU の選択である必要があります。 App Service プランにデプロイされたコンピューティングインスタンスの数を調整することで、水平スケーリングによって需要を効率的に満たすようにワークロードを設計します。需要に合わせてコンピューティング SKU を変更する方法に依存するようにシステムを設計しないでください。

この基本アーキテクチャの App Service デプロイには、自動スケーリングは実装されていません。サービスは、需要に合わせて効率的に調整されるように動的にスケールアウトしたりスケールインしたりすることはありません。
- Standard レベルでは、自動スケール設定がサポートされ、ルールベースの自動スケールを構成できます。 POC プロセスの一環として、アプリケーションコードのリソース要件と予想される使用パターンに合わせて調整された効率的な自動スケール設定を決定します。
- 運用環境でのデプロイメントには、プラットフォームが自動的にスケールの決定を処理する自動スケーリングをサポートする Premium ティアを検討してください。
SQL Database にさらに高いサービスレベルまたはパフォーマンスレベルが必要な場合は、アプリケーションのダウンタイムなしに個々のデータベースをスケールアップするためのガイダンスに従って対処してください。

次のステップ

デプロイのチュートリアル:

製品ドキュメント:

Microsoft Learn モジュール：

ベースラインのゾーン冗長性を備えたWebアプリケーション
ディザスターリカバリーのアプローチとして複数リージョンの App Service アプリを使用する方法

フィードバック

このページはお役に立ちましたか?