編集

Share via

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

Azure App Service
Azure Key Vault
Azure Monitor
Azure SQL データベース

このアーキテクチャは、基本的 Web アプリケーションの基本コンポーネントを示しています。 このアーキテクチャを使用して Web アプリケーションを構築し、ニーズに合わせてアプリケーションをカスタマイズできます。

アーキテクチャ

Azure の基本的な Web アプリケーションのリファレンス アーキテクチャを示す図。

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

コンポーネント

  • Azure App Service は、クラウド アプリケーションを作成およびデプロイするためのフル マネージドのプラットフォームです。 これにより、Web アプリが実行する一連のコンピューティング リソースを定義し、Web アプリをデプロイし、デプロイ スロットを構成できます。
  • デプロイ スロットを使用すると、デプロイをステージし、運用環境のデプロイとスワップできます。 このようにして、運用環境に直接デプロイするのを回避します。 特定の推奨事項については、後述の「リリース エンジニアリングとデプロイ」のセクションを参照してください。
  • IP アドレス: App Service アプリには、パブリック IP アドレスとドメイン名があります。 ドメイン名は azurewebsites.net のサブドメインです (contoso.azurewebsites.net など)。
  • Azure DNS は、DNS ドメインのホスティング サービスであり、Microsoft Azure インフラストラクチャを使用した名前解決を提供します。 Azure でドメインをホストすることで、その他の Azure サービスと同じ資格情報、API、ツール、課金情報を使用して DNS レコードを管理できます。 カスタム ドメイン名 (contoso.com など) を使用するには、カスタム ドメイン名を IP アドレスにマップする DNS レコードを作成します。 詳細については、「 Azure App Service のカスタム ドメイン名の構成」を参照してください。
  • Azure SQL Database は、クラウドのサービスとしてのリレーショナル データベースです。 SQL Database は、そのコード ベースを Microsoft SQL Server データベース エンジンと共有しています。 アプリケーションの要件に応じて、Azure Database for MySQL または Azure Database for PostgreSQL を使用することもできます。 これらの代替手段は、オープン ソースの MySQL Server および Postgres データベース エンジンに基づく、フル マネージドのデータベース サービスです。
  • Microsoft Entra ID は、組織向けに開発されたクラウド アプリに従業員がアクセスできるようにするクラウドベースの ID およびアクセス管理サービスです。
  • Azure Monitor は、環境全体でログとメトリックを収集、分析、操作するためのソリューションです。
  • Azure Key Vault では、シークレット管理、キー管理、証明書管理がサポートされています。 データベース接続文字列などのアプリケーション シークレットを保存できます。

推奨事項

実際の要件は、コードで説明および指定されているアーキテクチャとは異なる場合があります。 コードは実稼働構成でデプロイされます。 推奨事項を使用して、ニーズに合わせてデプロイをカスタマイズします。

App Service プラン

App Service プランの価格レベルは異なります。 各価格レベルで、コア数とメモリが異なる複数の "インスタンス サイズ" がサポートされます。 デプロイ後に価格レベルを変更するには、左側のナビゲーションで [スケールアップ (App Service プラン)] を選びます。 以下に、App Service の推奨事項をいくつか示します。

  • Basic、Standard、Premium の各価格レベルで運用ワークロードを実行します。 これら 3 つのレベルでは、アプリは専用の仮想マシン インスタンスで実行され、スケールアウトできるリソースが割り当てられています。
  • 自動スケーリングと TLS/SSL が必要な場合は、Standard と Premier の各レベルを使用します。
  • テストと開発用に別の App Service プランを作成します。 コスト効率を高めるためのテストと開発には、Free と Shared (プレビュー) の各レベルを使用します。 ただし、運用環境のワークロードには Free と Shared のレベルを使用しないでください。 共有リソースはスケールアウトできません。
  • デプロイのテストなどの使用していないプランは、必ず削除してください。 App Service プランは、1 秒単位で課金されます。 アプリが停止されても、App Service プランのインスタンスは課金の対象となります。 App Service プランと課金の詳細については、以下を参照してください。

以下の ARM テンプレートは、Standard 価格レベルにデプロイされます。

SQL Database

  • Azure SQL Database を使用して、管理オーバーヘッドを削減します。 Azure SQL Database は、データベースのコレクションの中央管理ポイントとして機能する論理コンストラクトです。 この論理構造により、管理オーバーヘッドが軽減されます。 グループ内の各データベースは、特定のサービス レベルでデプロイされます。 各グループ内で、データベースはリソースを共有できません。 サーバーのコンピューティング コストは発生しませんが、データベースごとにレベルを指定する必要があります。 そのため、専用リソースによりパフォーマンスは向上する可能性がありますが、コストが高くなる場合があります。
  • キャパシティ プランニングを実行し、要件に合うレベルとパフォーマンス レベルを選択してください。 SQL Database は、Basic、Standard、および Premium サービス レベルをサポートしており、各レベルに、データベース トランザクション ユニット (DTU) で測定された複数のパフォーマンス レベルが存在します。

リージョン

  • ネットワークの待機時間を最小限に抑えるために、App Service プランと SQL Database を同じリージョンに作成します。 一般的には、ユーザーに最も近いリージョンを選択してください。
  • リソース グループにもリージョンがあります。 デプロイ メタデータを保存する場所を指定します。 デプロイ時の可用性を向上させるには、リソース グループとそのリソースを同じリージョンに配置します。
  • コストを見積もるには、料金計算ツールを使用します。
  • 詳細については、「Microsoft Azure Well-Architected Framework」のコストのセクションを参照してください。

考慮事項

これらの考慮事項では、Azure Well-Architected フレームワークの重要な要素を実装します。 柱は、ワークロードの品質を向上させる一連の指針です。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

パフォーマンス効率

Azure App Service の主な利点は、負荷に応じてアプリケーションをスケーリングできることです。 アプリケーションのスケーリングを計画する場合の考慮事項を次に示します。

App Service アプリのスケーリング

App Service アプリをスケーリングする方法は 2 つあります。

  • "スケールアップ" とは、インスタンスのサイズを変更することです。 インスタンス サイズにより、各 VM インスタンスのメモリ、コア数、およびストレージが決まります。 手動でスケールアップするには、インスタンス サイズまたはプラン レベルを変更します。
  • "スケールアウト" とは、負荷の増加に対応するためにインスタンスを追加することです。 価格レベルごとに、インスタンスの最大数が設定されています。 スケールアウトを行うには、インスタンス数を手動で変更するか、スケジュールやパフォーマンス メトリックに基づいて Azure で自動的にインスタンスが追加または削除されるように自動スケーリングを構成します。 各スケール操作は迅速に、通常は数秒以内で行われます。

自動スケーリングを有効にするには、インスタンスの最小数と最大数を定義する自動スケーリング "プロファイル" を作成します。 スケール イベントをトリガーするスケジュール ベースのプロファイルを設定できます。 たとえば、平日と週末で別個のプロファイルを作成できます。 プロファイルには、どのタイミングでインスタンスを追加または削除するかを指定するルールを含めることができます。 たとえば、CPU 使用率が 5 分にわたって 70% を超えた場合に、インスタンスを 2 つ追加します。

Web アプリのスケーリングに関する推奨事項:

  • スケールアップとスケールダウンを可能な限り制限します。 アプリケーションの再起動をトリガーできます。 代わりに、スケールアウトします。通常の負荷でパフォーマンスの要件を満たすレベルとサイズを選択したうえで、インスタンスをスケールアウトして、トラフィック量の変化に対処します。
  • 自動スケールを有効にします。 アプリケーションに予測可能な通常のワークロードがある場合は、プロファイルを作成することで、事前にインスタンス数のスケジュールを設定します。 ワークロードを予測できない場合は、ルール ベースの自動スケーリングを使用して負荷の変化に対応します。 両方のアプローチを組み合わせることができます。
  • 自動スケーリング ルールには CPU 使用率を使用します。 一般的に、CPU 使用率は自動スケールのルールのメトリックとして適切です。 ただし、アプリケーションのロード テストを行い、潜在的なボトルネックを特定したうえで、そのデータに基づいて自動スケールのルールを設定する必要があります。
  • インスタンスを追加する場合はクールダウン期間を短くし、インスタンスを削除する場合はクールダウン期間を長くします。 自動スケーリング ルールには "クールダウン" 期間が含まれます。 "クールダウン" 期間は、スケール アクションの完了後、新しいスケール アクションが開始されるまでの待機時間です。 クールダウン期間により、スケーリングが再度行われる前に、システムを安定させることができます。 たとえば、インスタンスを追加するときは 5 分に、インスタンスを削除するときは 60 分に設定します。 負荷の高い場所に新しいインスタンスを追加して余分なトラフィックを処理し、段階的にスケールバックすることをお勧めします。

SQL データベースのスケーリング

SQL Database により高いサービス レベルまたはパフォーマンス レベルが必要な場合は、アプリケーションのダウンタイムなしで個々のデータベースをスケールアップします。

詳細については、「Azure SQL Database で単一データベースのリソースをスケーリングする」を参照してください。

[信頼性]

この資料の作成時点では、App Service のサービス レベル アグリーメント (SLA) は 99.95% です。 App Service の SLA は、1 つのインスタンスおよび複数のインスタンスの両方に適用されます。 SQL Database の SLA は、Basic、Standard、Premium の各レベルで 99.99% です。

バックアップ

SQL Database には、データの損失を復元するためのポイント イン タイム リストアと geo リストアが用意されています。 こうした機能はすべてのレベルで使用でき、自動的に有効になっています。 バックアップをスケジュールまたは管理する必要はありません。

  • ポイントインタイム リストアを使用します。 人為的ミスから復旧するには、データベースを以前の特定の時点に戻します。
  • geo リストアを使用します。 サービス停止から復旧するには、データベースを geo 冗長バックアップから復元します。
  • App Service のバックアップと復元の使用を検討してください。 バックアップと復元は、アプリケーション ファイルの機能です。 ただし、バックアップ ファイルには、接続文字列などのアプリ設定がプレーン テキストで含まれています。
  • App Service のバックアップ機能を使用して SQL データベースをバックアップしないでください。 これを行うと、データベースが SQL BACPAC ファイルにエクスポートされ、DTU が消費されます。 代わりに、上で説明した SQL Database のポイントインタイム リストアを使用します。 詳細については、SQL Database を使用したクラウド ビジネス継続性とデータベース ディザスター リカバリーに関するページを参照してください。

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

運用、開発、およびテスト環境それぞれに対して個別のリソース グループを作成してください。 環境を分離すると、デプロイの管理、テスト デプロイの削除、アクセス権の割り当てが容易になります。

リソースをリソース グループに割り当てるときは、以下の機能を検討してください。

  • ライフサイクル。 一般的に、同じライフサイクルのリソースは、同じリソース グループに追加します。
  • アクセス。 Azure ロールベースのアクセス制御 (RBAC) を使用して、アクセス ポリシーをグループ内のリソースに適用できます。
  • 課金。 リソース グループのロールアップ コストを表示できます。

詳細については、「Azure Resource Manager の概要」を参照してください。

アプリの構成

  • 構成設定をアプリ設定として格納します。 Resource Manager テンプレート内で、または PowerShell を使用して、アプリ設定を定義します。 実行時、アプリケーションはアプリ設定を環境変数として使用できます。
  • パスワード、アクセス キー、または接続文字列を、ソース管理にチェックインしないでください。 代わりに、シークレットをパラメーターとして、デプロイ スクリプトに渡します。スクリプトは、こうした値をアプリ設定として格納します。
  • デプロイ スロットをスワップすると、アプリ設定は既定でスワップされます。 運用環境とステージングで異なる設定が必要な場合は、スワップされないスロット固有のアプリ設定を作成できます。

診断および監視

  • アプリケーションのログ記録や Web サーバーのログ記録を含む、診断のログ記録を有効にします。 Azure Log Analytics を使用するようにログ記録を構成します。 ログ記録に関する詳細なガイダンスについては、監視と診断のガイダンスに関するページをご覧ください。
  • New Relic、Application Insights などのサービスを使用して、負荷がかかった状態のアプリケーションのパフォーマンスと動作を監視してください。 Application Insights のデータ速度の制限に気を付けてください。
  • Azure DevOps や Azure DevOps Server などのツールを使用して、ロード テストを行います。 クラウド アプリケーションのパフォーマンス分析の概要については、「パフォーマンス分析の手引き」を参照してください。

DevOps

  • ARM テンプレートを使用して、Azure リソースとその依存関係をデプロイします。 付属の ARM テンプレートにより、1 つの Web アプリケーションがデプロイされます。 すべてのリソースは、同じ基本ワークロードで分離されます。 この分離により、ワークロードの固有のリソースをチームに簡単に関連付けることができます。 チームは、これらのリソースのすべての側面を個別に管理できます。 この分離により、DevOps チームは、継続的インテグレーションと継続的デリバリー (CI/CD) を実行できます。
  • さまざまな ARM テンプレートを使用し、Azure DevOps サービスと統合します。 このセットアップを使用すると、数分で異なる環境を作成できます。 たとえば、運用環境に似たシナリオやロード テスト環境を必要なときにだけレプリケートして、コストを節約できます。
  • Web アプリケーションの複数のインスタンスをプロビジョニングします。 Web アプリが 1 つのインスタンスに依存して単一障害点を作成する可能性を回避したいと考えています。 複数のインスタンスによって回復性とスケーラビリティが向上します。

詳細については、Azure Well-Architected Framework の DevOps に関するセクションを参照してください。

リリース エンジニアリングとデプロイ

  • Azure Resource Manager テンプレートを使用して Azure リソースをプロビジョニングします。 テンプレートにより、PowerShell または Azure CLI を使用したデプロイが自動化しやすくなります。
  • アプリケーションのデプロイ (コード、バイナリ、コンテンツ ファイル)。 ローカル Git リポジトリからのデプロイ、Visual Studio の使用、クラウド ベースのソース管理からの継続的デプロイなど、複数のオプションがあります。 「 Azure App Service へのアプリのデプロイ」を参照してください。

App Service アプリには、production という名前のデプロイ スロットが必ず 1 つ含まれます。 運用スロットは、ライブ運用サイトを表します。 更新プログラムをデプロイするステージング スロットを作成することをお勧めします。 ステージング スロットを使用する利点は次のとおりです。

  • デプロイが成功していることを確認してから、それを運用環境にスワップできます。
  • ステージング スロットにデプロイすることで、運用環境にスワップする前に、すべてのインスタンスを確実にウォームアップできます。 ウォームアップとコールドスタートに時間がかかるアプリケーションは多数あります。
  • 3 番目のスロットを作成して、前回正常起動時のデプロイを保持します。 ステージングと運用をスワップしたら、これまでの運用環境のデプロイ (現在ステージング スロットにある) を、前回正常起動時デプロイ用のスロットに移動します。 このようにして、後で問題を見つけた場合に、前回正常起動時のバージョンにすばやく戻ることができます。

運用環境およびステージング環境のデプロイ用スロットのスワップ

  • 前のバージョンに戻す場合は、データベース スキーマのすべての変更に下位互換性があることを確認します。
  • 同じ App Service プラン内のすべてのアプリが同じ VM インスタンスを共有するため、運用環境のデプロイのスロットをテスト用に使用しないでください。 たとえば、ロード テストは実稼働の運用サイトの機能を低下させる可能性があります。 代わりに、運用とテスト用に別々の App Service プランを作成します。 テスト デプロイを別のプランに入れて、運用バージョンから切り離してください。

セキュリティ

このセクションでは、この記事で説明している Azure サービスに固有のセキュリティの考慮事項について説明します。 これはセキュリティ上のベスト プラクティスを網羅した一覧ではありません。 その他のセキュリティの考慮事項については、Azure App Service でのアプリのセキュリティ保護に関するページを参照してください。

SQL Database 監査

監査により、規定遵守を維持したり、ビジネス上の懸念やセキュリティ違反の疑いを示す差異や異常に対する分析情報を得たりすることが容易になります。 「SQL Database 監査の使用」を参照してください。

デプロイ スロット

デプロイ スロットごとにパブリック IP アドレスがあります。 開発および DevOps チームのメンバーのみがこうしたエンドポイントにアクセスできるように、Microsoft Entra ログインを使用して、非運用スロットをセキュリティで保護します。

ログ記録

ユーザーのパスワードなど、不正アクセスにつながる情報はログに記録しないようにします。 このような詳細情報は、データを格納する前に除外してください。

SSL

App Service アプリには、追加コストなしで、azurewebsites.net のサブドメインに SSL エンドポイントが含まれています。 SSL エンドポイントには、*.azurewebsites.net ドメインのワイルドカード証明書が含まれます。 カスタム ドメイン名を使用する場合は、カスタム ドメインに合致する証明書を指定する必要があります。 最も簡単な方法は、Azure Portal から直接に証明書を購入することです。 他の証明機関から証明書をインポートすることもできます。 詳細については、「Azure App Service の SSL 証明書を購入して構成する」を参照してください。

ARM テンプレートのデプロイでは、HTTPS は既定では有効になっていません。 セキュリティのベスト プラクティスとして、アプリは HTTP 要求をリダイレクトすることで HTTPS を強制する必要があります。 HTTPS をアプリケーション内で実装するか、Azure App Service でのアプリの HTTPS の有効化に関するページの説明に従って、URL 書き換え規則を使用できます。

認証

Microsoft Entra ID、Facebook、Google、Twitter などの ID プロバイダー (IDP) を使用して認証することをお勧めします。 認証フローには OAuth 2 または OpenID Connect (OIDC) を使用してください。 Microsoft Entra ID には、ユーザーとグループの管理、アプリケーション ロールの作成、オンプレミス ID の統合、およびバックエンド サービス (Microsoft 365 や Skype for Business など) の使用に関する機能が用意されています。

ユーザーのログインおよび資格情報をアプリケーションで直接管理するのは避けてください。 これにより潜在的な攻撃面が作成されます。 少なくとも、メール確認、パスワード復元、および多要素認証が必要です。また、パスワードの強度を検証し、パスワード ハッシュを安全に格納する必要があります。 大規模な ID プロバイダーはこれをすべて処理し、セキュリティ プラクティスを常に監視し、強化しています。

App Service 認証を使用して、OAuth または OIDC 認証フローを実装することを検討してください。 App Service 認証の利点は次のとおりです。

  • 構成が簡単。
  • シンプルな認証シナリオではコードが不要。
  • ユーザーに代わって、OAuth アクセス トークンを使用してリソースを消費できるよう、委任承認をサポート。
  • 組み込みのトークン キャッシュを提供。

App Service 認証の制限は次のとおりです。

  • カスタマイズのオプションに制限がある。
  • ログイン セッションごとに、委任承認が 1 つのバックエンド リソースに制限される。
  • 複数の IDP を使用する場合、ホーム領域検出のための組み込みメカニズムがない。
  • マルチテナント シナリオでは、アプリケーションがトークン発行者を検証するロジックを実装する必要がある。

このシナリオのデプロイ

このアーキテクチャには、Azure App Service プランと空のアプリケーションが含まれます。 Azure SQL Database、Azure Key Vault を使用してデータベース接続文字列を保存し、Azure Monitor を使用してログ、監視、アラートを生成します。

デプロイ用のリソース グループを作成するには、次のコマンドを使用します。 埋め込みシェルを使用するには、[試す] ボタンを選びます。

az group create --name basic-web-app --location eastus

次のコマンドを実行して、Web アプリケーションとサポート インフラストラクチャをデプロイします。 プロンプトが表示されたら、ユーザー名とパスワードを入力します。 これらの値は、Azure SQL Database インスタンスにアクセスするために使用されます。

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

詳細および他のデプロイ オプションについては、このソリューションのデプロイに使用される ARM テンプレートを参照してください。

基本的な Web アプリケーションの ARM テンプレート

次のステップ

アプリケーションのトラブルシューティングのヒント:

製品ドキュメント:

Microsoft Learn モジュール：