.NET 向け信頼性の高い Web アプリパターン

Azure App Service

Azure Front Door

Azure Cache for Redis

.NET

この記事では、信頼性の高い Web アプリパターンの実装に関するガイダンスを提供します。このパターンでは、クラウド移行のために Web アプリを変更 (リプラットフォーム) する方法について説明します。 Well-Architected フレームワークの原則に沿った規範的なアーキテクチャ、コード、構成のガイダンスを提供します。

.NET 向け信頼性の高い Web アプリパターンを使用する理由

信頼性の高い Web アプリパターンは、クラウドへの移行時に Web アプリを変更する方法 (リプラットフォーム) を定義する一連の原則と実装手法です。クラウドで成功するために行う必要がある最小限のコード更新に焦点を当てています。次のガイダンスでは、参照実装を例として使用し、架空の会社 Relecloud のリプラットフォームの流れに従って、移行に関するビジネスコンテキストを説明します。 Relecloud では、.NET 向け信頼性の高い Web アプリパターンを実装する以前は、ASP.NET フレームワークを使用するモノリシックなオンプレミスのチケット販売 Web アプリがありました。

ヒント

GitHub logo 信頼性の高い Web アプリパターンの参照実装 (サンプル) が用意されています。これは、Relecloud という架空の会社での、信頼性の高い Web アプリの実装の最終状態を表します。この記事で説明する、コード、アーキテクチャ、構成に対するすべての更新プログラムを取り入れた実稼働グレードの Web アプリです。この参照実装をデプロイして使用し、信頼性の高い Web アプリパターンの実装について案内します。

信頼性の高い Web アプリパターンの実装方法

この記事には、信頼性の高い Web アプリパターンを実装するための、アーキテクチャ、コード、構成のガイダンスが含まれます。以下のリンクを使用して、必要な特定のガイダンスに移動します。

ビジネスコンテキスト: このガイダンスをビジネスコンテキストに合わせて調整し、リプラットフォームに関する意志決定を促進する短期目標と長期目標を定義する方法を学習します。
アーキテクチャのガイダンス: 適切なクラウドサービスを選択し、ビジネス要件を満たすアーキテクチャを設計する方法について説明します。
コードのガイダンス: クラウドでの Web アプリの信頼性とパフォーマンス効率を向上させる、再試行、サーキットブレーカー、キャッシュアサイドの 3 つの設計パターンを実装します
構成のガイダンス: 認証と承認、マネージド ID、適正サイズの環境、コードとしてのインフラストラクチャ、監視を構成します。

ビジネスコンテキスト

Web アプリのリプラットフォームの最初の手順は、ビジネス目標を定義することです。サービスレベル目標やコスト最適化の目標、Web アプリケーションの将来の目標など、短期目標を設定する必要があります。これらの目標は、クラウドサービスの選択と、クラウド内の Web アプリケーションのアーキテクチャに影響します。 99.9% のアップタイムなど、Web アプリのターゲット SLO を定義します。 Web アプリの可用性に影響を与えるすべてのサービスについて、複合 SLA を計算します。

たとえば、Relecloud では売上予測は好調であり、チケット販売 Web アプリの需要の増加が予想されます。この需要を満たすために、Web アプリケーションの目標を定義しました。

低コストで価値の高いコード変更を適用
99.9% のサービスレベル目標 (SLO) にリーチ
DevOps プラクティスを採用
コスト最適化環境を作成
信頼性とセキュリティを改善

Relecloud のオンプレミスインフラストラクチャは、これらの目標を達成するためのコスト効率の高いソリューションではありませんでした。そこで、Web アプリケーションを Azure に移行することが、即時および将来の目標を達成するための最もコスト効率の高い方法であると判断しました。

アーキテクチャのガイダンス

信頼性の高い Web アプリパターンには、いくつかの重要なアーキテクチャ要素があります。エンドポイント解決を管理するための DNS、悪意のある HTTP トラフィックをブロックする Web アプリケーションファイアウォール、受信ユーザー要求を保護してルーティングするためのロードバランサーが必要です。アプリケーションプラットフォームは、Web アプリコードをホストし、仮想ネットワーク内のプライベートエンドポイントを介してすべてのバックエンドサービスに対する呼び出しを実行します。アプリケーションパフォーマンス監視ツールは、Web アプリの状態を把握するためのメトリックとログをキャプチャします。

図 1. 信頼性の高い Web アプリパターンの重要なアーキテクチャ要素。

アーキテクチャの設計

目標復旧時間 (RTO) や目標復旧時点 (RPO) などの復旧メトリックをサポートするようにインフラストラクチャを設計します。 RTO は可用性に影響し、SLO をサポートする必要があります。目標復旧ポイント (RPO) を決定し、RPO を満たすようにデータ冗長性を構成します。

インフラストラクチャの信頼性を選択します。 可用性のニーズを満たすために必要な可用性ゾーンとリージョンの数を決定します。複合 SLA が SLO を満たすまで、可用性ゾーンとリージョンを追加します。信頼性の高い Web アプリパターンは、アクティブ/アクティブ構成またはアクティブ/パッシブ構成で複数のリージョンをサポートします。たとえば、参照実装では、アクティブ/パッシブ構成を使用して 99.9% の SLO を満たしています。

マルチリージョンの Web アプリの場合は、ビジネスニーズに応じてアクティブ/アクティブ構成またはアクティブ/パッシブ構成をサポートするように、2 つ目のリージョンにトラフィックをルーティングするようにロードバランサーを構成します。 2 つのリージョンでは同じサービスが必要ですが、一方のリージョンにはリージョンを接続するハブ仮想ネットワークを配置する点が異なります。ハブアンドスポークネットワークトポロジを導入して、ネットワークファイアウォールなどのリソースを一元化および共有します。仮想マシンがある場合は、ハブ仮想ネットワークに Bastion ホストを追加して仮想マシンを安全に管理します (図 2 を参照)。

図 2. 2 つ目のリージョンを設定し、ハブアンドスポークトポロジを採用した信頼性の高い Web アプリパターン。
ネットワークトポロジを選択します。 Web とネットワークの要件に適したネットワークトポロジを選択します。複数の仮想ネットワークを使用する場合は、ハブアンドスポークネットワークトポロジを使用します。これにより、オンプレミスと仮想ネットワークに対するハイブリッド接続オプションを使用した、コスト、管理、セキュリティの利点がもたらされます。

適切な Azure サービスを選択する

Web アプリをクラウドに移行する場合は、ビジネス要件を満たし、オンプレミス Web アプリの現在の機能に合わせた Azure サービスを選択する必要があります。この配置により、リプラットフォーム工数を最小限に抑えることができます。たとえば、同じデータベースエンジンを維持し、既存のミドルウェアとフレームワークをサポートできるサービスを使用します。次のセクションでは、Web アプリに適した Azure サービスを選択するためのガイダンスを提供します。

たとえば、クラウドに移行する以前は、Relecloud のチケット販売 Web アプリはオンプレミスのモノリシックな ASP.NET アプリでした。 2 つの仮想マシン上で実行され、Microsoft SQL Server データベースがありました。 Web アプリは、スケーラビリティと機能のデプロイに関する一般的な課題に苦しんでいます。この出発点、ビジネス目標、SLO がサービスの選択を推進しました。

アプリケーションプラットフォーム: Azure App Service をアプリケーションプラットフォームとして使用します。 Relecloud では、次の理由からアプリケーションプラットフォームとして Azure App Service を選択しました。
- 高いサービスレベルアグリーメント (SLA): 運用環境の SLO 99.9% を満たす高い SLA を備えています。
- 管理オーバーヘッドの削減: これは、スケーリング、正常性チェック、負荷分散を処理するフルマネージドソリューションです。
- .NET サポート: アプリケーションが書き込まれる .NET のバージョンをサポートします。
- コンテナー化機能: Web アプリはコンテナー化せずにクラウドに集約できますが、アプリケーションプラットフォームにより、Azure サービスを変更しないコンテナー化もサポートされています。
- オートスケール: Web アプリは、ユーザーのトラフィックと設定に基づいて、自動的にスケールイン/アウトできます。プラットフォームでは、さまざまなホスティング要件に対応するために、スケールアップまたはスケールダウンもサポートされています。
ID 管理: ID およびアクセス管理ソリューションとして Microsoft Entra ID を使用します。 Relecloud では、次の理由で Microsoft Entra ID を選択しました。
- 認証と承認: アプリケーションは、コールセンターの従業員を認証および承認する必要があります。
- 拡張性: より大規模なシナリオをサポートするように拡張されます。
- ユーザー ID 制御:コールセンターの従業員は、既存のエンタープライズ ID を使用できます。
- 承認プロトコルのサポート: マネージド ID に対して OAuth 2.0 をサポートします。
データベース: 同じデータベースエンジンを維持できるサービスを使用します。データストアのデシジョンツリーを使用します。 Relecloud の Web アプリでは、オンプレミスの SQL Server を使用していました。そのため、既存のデータベーススキーマ、ストアドプロシージャ、関数を使用したいと考えていました。 Azure ではいくつかの SQL 製品を利用できますが、Relecloud では次の理由から Azure SQL Database を選択しました。
- 信頼性: 汎用層は、高い SLA と複数リージョンの冗長性が提供します。高いユーザー負荷をサポートできます。
- 管理オーバーヘッドの削減: マネージド SQL データベースインスタンスを提供します。
- 移行サポート: オンプレミス SQL Server からのデータベース移行をサポートします。
- オンプレミス構成との整合性: 既存のストアドプロシージャ、関数、およびビューをサポートします。
- 回復力: バックアップとポイントインタイムリストアをサポートします。
- 専門知識と最小限のやり直し: SQL Database は社内の専門知識を活用し、導入に必要な作業は最小限です。
アプリケーションパフォーマンスの監視: Application Insights を使用して、アプリケーションのテレメトリを分析します。 Relecloud では、次の理由で Application Insights を使用することを選択しました。
- Azure Monitor との統合: Azure Monitor との最適に統合します。
- 異常検出: パフォーマンスの異常を自動的に検出します。
- トラブルシューティング: 実行中のアプリの問題を診断するのに役立ちます。
- 監視: ユーザーがアプリをどのように使用しているかに関する情報を収集し、カスタムイベントを簡単に追跡できるようにします。
- 可視性のギャップ: オンプレミスソリューションには、アプリケーションパフォーマンス監視ソリューションがありませんでした。 Application Insights は、アプリプラットフォームとコードとの簡単な統合を提供します。
キャッシュ: Web アプリアーキテクチャにキャッシュを追加するかどうかを選択します。 Azure Cache for Redis は、Azure のプライマリキャッシュソリューションです。これは、Redis ソフトウェアに基づくマネージドインメモリデータストアです。 Relecloud の Web アプリの負荷は、コンサートや会場の詳細の表示に大きく偏っており、次の理由から Azure Cache for Redis が追加されました。
- 管理オーバーヘッドの削減: フルマネージドサービスです。
- スピードとボリューム: 一般的にアクセスされ、変化が遅いデータでは、データスループットが高く、読み取りの待機時間が短くなります。
- 多様なサポート: Web アプリのすべてのインスタンスが使用する統合キャッシュの場所です。
- 外部データストア: VM ローカルキャッシュを実行したオンプレミスのアプリケーションサーバー。このセットアップでは、頻度の高いデータがオフロードされず、データを無効にできませんでした。
- 非スティッキー・セッション: セッション・ステートを外部化すると、非スティッキー・セッションがサポートされます。
ロードバランサー: PaaS ソリューションを使用する Web アプリケーションでは、Web アプリのアーキテクチャと要件に基づいて、Azure Front Door、Azure Application Gateway、またはその両方を使用する必要があります。ロードバランサーのデシジョンツリーを使用して、適切なロードバランサーを選択します。 Relecloud では、複数のリージョン間でトラフィックをルーティングできるレイヤー 7 ロードバランサーが必要でした。 Relecloud は、SLO を 99.9 満たすためにマルチリージョンの Web アプリを必要としていました。 Relecloud は、次の理由から Azure Front Door を選択しました。
- グローバル負荷分散: 複数のリージョン間でトラフィックをルーティングできるレイヤー 7 ロードバランサーです。
- Web application firewall: Azure Web Application Firewall とネイティブに統合されます。
- ルーティングの柔軟性: アプリケーションチームは、アプリケーションの将来の変更に対応するために必要なイングレスを構成できます。
- トラフィックの高速化: エニーキャストを使用して、最も近い Azure のポイントオブプレゼンスにリーチし、Web アプリへの最速ルートを見つけます。
- Custom Domain: 柔軟なドメイン検証で Custom Domain 名をサポートします。
- 正常性プローブ: アプリには、インテリジェントな正常性プローブの監視が必要です。 Azure Front Door は、プローブからの応答を使用して、クライアント要求をルーティングするための最適な配信元を決定します。
- 監視サポート: Front Door とセキュリティパターンの両方に対応するオールインワンダッシュボードがある組み込みレポートをサポートします。 Azure Monitor と統合するアラートを構成できます。アプリケーションが各要求と失敗した正常性プローブをログに記録できるようにします。
- DDoS Protection:第 3 から 4 層の DDoS Protection が組み込まれています。
- コンテンツ配信ネットワーク: Relecloud がコンテンツ配信ネットワークを使用するために位置づけます。コンテンツ配信ネットワークは、サイトアクセラレーションを提供します。
Web アプリケーションファイアウォール: Azure Web Application Firewall を使用して、Web での一般的な悪用や脆弱性からの一元的な保護を提供します。 Relecloud では、次の理由から、Azure Web Application Firewall を使用しました。
- グローバル保護: パフォーマンスを犠牲にすることなく、グローバルな Web アプリ保護を向上させます。
- ボットネット保護: チームは、ボットネットに関連するセキュリティ上の懸念事項に対応するために、設定を監視、構成できます。
- オンプレミスとのパリティ: オンプレミスソリューションは、IT 部門が管理する Web アプリケーションファイアウォールの内側で実行されていました。
- 使いやすさ: Web Application Firewall は Azure Front Door と統合されています。
ストレージの構成: アプリ構成ストレージを Web アプリに追加するかどうかを選択します。 Azure App Configuration は、アプリケーション設定と機能フラグを一元管理するためのサービスです。 App Configuration のベストプラクティスを確認して、このサービスがアプリに適しているかどうかを判断します。 Relecloud では、ファイルベース構成を、アプリケーションプラットフォームおよびコードと統合されている一元的な構成ストアで置き換えたいと考えていました。次の理由から、App Configuration をアーキテクチャに追加しました。
- 柔軟性: 機能フラグをサポートします。機能フラグを使用すると、ユーザーはアプリを再デプロイすることなく、運用環境で早期プレビュー機能をオプトインおよびオプトアウトできます。
- Git パイプラインのサポート: 構成データの信頼できるソースは、Git リポジトリである必要があります。パイプラインで、一元的な構成ストアのデータを更新する必要があります。
- マネージド ID のサポート: マネージド ID をサポートして、構成ストアへの接続を簡素化し、セキュリティで保護しやすくします。
シークレットマネージャー: Azure での管理にシークレットを使用している場合は、Azure Key Vault を使用します。 ConfigurationBuilder オブジェクトを使用して、.NET アプリに Key Vault を組み込むことができます。 Relecloud のオンプレミスの Web アプリではシークレットをコード構成ファイルに格納していましたが、RBAC と監査制御をサポートする場所にシークレットを格納する方がセキュリティ対策として適しています。マネージド ID は Azure リソースに接続するための推奨ソリューションですが、Relecloud には管理に必要なアプリケーションシークレットがありました。 Relecloud は、次の理由で Key Vault を使用しました。
- 暗号化: 保存時と転送中の暗号化をサポートします。
- マネージド ID のサポート:アプリケーションサービスは、マネージド ID を使用してシークレットストアにアクセスできます。
- 監視とログに記録: 監査アクセスを簡単にし、格納されているシークレットが変更されたときにアラートを生成します。
- 統合: Azure 構成ストア (App Configuration) およびWeb ホスティングプラットフォーム (App Service) とのネイティブ統合が提供されます。
ストレージソリューション: Azure のストレージオプションを確認し、要件に基づいて適切なストレージソリューションを選択します。 Relecloud のオンプレミスの Web アプリでは各 Web サーバーにディスクストレージをマウントしていましたが、チームは外部データストレージソリューションを使用したいと考えていました。 Relecloud は、次の理由で Azure Blob Storage を選択しました。
- セキュアなアクセス: Web アプリは、パブリックインターネットに公開されているストレージに匿名アクセスでアクセスするためのエンドポイントを排除できます。
- 暗号化: 保存時と転送中のデータを暗号化します。
- 回復性: ゾーン冗長ストレージ (ZRS) をサポートします。ゾーン冗長ストレージでは、プライマリリージョン内の 3 つの Azure 可用性ゾーンにまたがって、データが同期的にレプリケートされます。各可用性ゾーンは、独立した電源、冷却装置、ネットワークがある別個の物理的な場所にあります。この構成は、チケット画像の損失に対する回復性を高めます。
エンドポイントセキュリティ: Azure Private Link を使用して、仮想ネットワーク内のプライベートエンドポイント経由でサービスとしてのプラットフォームソリューションにアクセスします。仮想ネットワークとサービスとの間のトラフィックは、Microsoft バックボーンネットワークをまたがります。 Relecloud は、次の理由で Private Link を選択しました。
- 強化されたセキュリティ通信: アプリケーションが Azure プラットフォーム上のサービスにプライベートにアクセスでき、データストアのネットワークフットプリントが削減されるため、データ漏えいからの保護に役立ちます。
- 最小工数: プライベートエンドポイントは、Web アプリが使用する Web アプリプラットフォームとデータベースプラットフォームをサポートします。どちらのプラットフォームも、変更が最小限になるように既存のオンプレミス構成をミラーリングします。
ネットワークセキュリティ: Azure Firewall を使用して、ネットワークレベルで受信トラフィックと送信トラフィックを制御します。 Azure Bastion を使用して、RDP/SSH ポートを公開することなく、仮想マシンに安全に接続します。 Relecloud では、ハブアンドスポークネットワークトポロジを採用し、共有ネットワークセキュリティサービスをハブに配置したいと考えていました。 Azure Firewall では、スポークからのすべての送信トラフィックを検査することでセキュリティとネットワークセキュリティを強化しました。 DevOps サブネット内のジャンプホストから安全にデプロイするために、Relecloud には、Azure Bastion が必要でした。

コードのガイダンス

Web アプリをクラウドに正常に移行するには、再試行パターン、サーキットブレーカーパターン、キャッシュアサイド設計パターンを使用して Web アプリコードを更新する必要があります。

図 3。設計パターンのロール。

各設計パターンは、Well-Architected フレームワークの 1 つ以上の柱に沿ったワークロード設計の利点を提供します。実装する必要があるパターンの概要を以下に示します。

再試行パターン: 再試行パターンは、断続的に失敗する可能性のある操作を再試行することによって、一時的なエラーを処理します。このパターンは、他の Azure サービスに対するすべての送信呼び出しに実装します。
サーキットブレーカーパターン: サーキットブレーカーパターンは、一時的ではない操作をアプリケーションが再試行するのを防ぎます。このパターンは、他の Azure サービスに対するすべての送信呼び出しに実装します。
キャッシュアサイドパターン: キャッシュアサイドパターンは、データストアよりも頻繁に、キャッシュに対する追加とキャッシュからの取得を実行します。このパターンは、データベースに対する要求に実装します。

設計パターン	信頼性 (RE)	パフォーマンス効率 (PE)	WAF の原則のサポート
再試行パターン	✔		RE:07
サーキットブレーカーパターン	✔	✔	RE:03 RE:07 PE:07 PE:11
キャッシュアサイドパターン	✔	✔	RE:05 PE:08 PE:12

再試行パターンを実装する

一時的なサービスの中断に対処するために、再試行パターンをアプリケーションコードに追加します。これらの中断は、一時的な障害と呼ばれます。一時的な障害は、通常は数秒以内に解決されます。再試行パターンを使用すると、失敗した要求を再送信できます。また、要求の遅延と、障害と認めるまでの試行回数を構成することもできます。

組み込みの再試行メカニズムを使用する ほとんどの Azure サービスで早急に実装を進める必要がある、組み込みの再試行メカニズムを使用します。たとえば、参照実装では、Entity Framework Core の接続の回復性を使用して、Azure SQL Database に対する要求に再試行パターンを適用します (次のコードを参照してください)。
```
services.AddDbContextPool<ConcertDataContext>(options => options.UseSqlServer(sqlDatabaseConnectionString,
    sqlServerOptionsAction: sqlOptions =>
    {
        sqlOptions.EnableRetryOnFailure(
        maxRetryCount: 5,
        maxRetryDelay: TimeSpan.FromSeconds(3),
        errorNumbersToAdd: null);
    }));
```

再試行プログラミングライブラリを使用します。 HTTP 通信の場合は、Polly や Microsoft.Extensions.Http.Resilience などの標準の回復性ライブラリを統合します。これらのライブラリは、外部 Web サービスとの通信を管理するために不可欠な包括的な再試行メカニズムを提供します。たとえば、参照実装では、IConcertSearchService オブジェクトを呼び出すオブジェクトがコードによって構築されるたびに、Polly を使用して再試行パターンを適用します (次のコードを参照してください)。

private void AddConcertSearchService(IServiceCollection services)
{
    var baseUri = Configuration["App:RelecloudApi:BaseUri"];
    if (string.IsNullOrWhiteSpace(baseUri))
    {
        services.AddScoped<IConcertSearchService, MockConcertSearchService>();
    }
    else
    {
        services.AddHttpClient<IConcertSearchService, RelecloudApiConcertSearchService>(httpClient =>
        {
            httpClient.BaseAddress = new Uri(baseUri);
            httpClient.DefaultRequestHeaders.Add(HeaderNames.Accept, "application/json");
            httpClient.DefaultRequestHeaders.Add(HeaderNames.UserAgent, "Relecloud.Web");
        })
        .AddPolicyHandler(GetRetryPolicy())
        .AddPolicyHandler(GetCircuitBreakerPolicy());
    }
}

private static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy()
{
    var delay = Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromMilliseconds(500), retryCount: 3);
    return HttpPolicyExtensions
      .HandleTransientHttpError()
      .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
      .WaitAndRetryAsync(delay);
}

サーキットブレーカーパターンを実装する

サーキットブレーカーパターンを使用して、一時的な障害ではないサービスの中断を処理します。サーキットブレーカーパターンは、アプリケーションが応答しないサービスに継続的にアクセスすることを防ぎます。これにより、アプリケーションが解放され、CPU サイクルの無駄が回避されるため、アプリケーションはエンドユーザーに対するパフォーマンスの整合性を維持します。

たとえば、参照実装では、API に対するすべての要求にサーキットブレーカーパターンが適用されます。これは、HandleTransientHttpError ロジックを使用して、安全に再試行できる HTTP 要求を検出しますが、指定された期間にわたるエラーの総数が制限されます (次のコードを参照してください)。

private static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy()
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));
}

キャッシュアサイドパターンを実装する

キャッシュアサイドパターンを Web アプリに追加して、メモリ内データ管理を改善します。このパターンにより、データ要求を処理し、キャッシュと永続的ストレージ (データベースなど) の間の整合性を確保する責任がアプリケーションに割り当てられます。これにより、応答時間が短縮され、スループットが向上し、さらなるスケーリングの必要性が軽減されます。また、プライマリデータストアの負荷が軽減され、信頼性とコスト最適化が向上します。キャッシュアサイドパターンを実装するには、次の推奨事項に従います。

キャッシュを使用するようにアプリケーションを構成します。 実稼働アプリでは、分散 Redis Cache を使用する必要があります。これは、データベースクエリを減らすことでパフォーマンスが向上し、非スティッキーセッションが実現するため、ロードバランサーがトラフィックを均等に分散できるようになります。たとえば、参照実装では、分散 Redis Cache を使用しています。 AddAzureCacheForRedis メソッドは、Azure Cache for Redis を使用するようにアプリケーションを構成します (次のコードを参照してください)。
```
private void AddAzureCacheForRedis(IServiceCollection services)
{
    if (!string.IsNullOrWhiteSpace(Configuration["App:RedisCache:ConnectionString"]))
    {
        services.AddStackExchangeRedisCache(options =>
        {
            options.Configuration = Configuration["App:RedisCache:ConnectionString"];
        });
    }
    else
    {
        services.AddDistributedMemoryCache();
    }
}
```

必要性の高いデータをキャッシュします。 必要性の高いデータにキャッシュアサイドパターンを適用して、その有効性を高めます。 Azure Monitor を使用して、データベースの CPU、メモリ、ストレージを追跡します。これらのメトリックは、キャッシュアサイドパターンを適用した後に、より小さいデータベース SKU を使用できるかどうかを判断するのに役立ちます。たとえば、参照実装では、Upcoming Concerts ページで使用される、必要性の高いデータがキャッシュされます。 GetUpcomingConcertsAsync メソッドは、SQL Database から Redis Cache にデータをプルし、キャッシュに最新のコンサートデータを入力します (次のコードを参照してください)。

public async Task<ICollection<Concert>> GetUpcomingConcertsAsync(int count)
{
    IList<Concert>? concerts;
    var concertsJson = await this.cache.GetStringAsync(CacheKeys.UpcomingConcerts);
    if (concertsJson != null)
    {
        // There is cached data. Deserialize the JSON data.
        concerts = JsonSerializer.Deserialize<IList<Concert>>(concertsJson);
    }
    else
    {
        // There's nothing in the cache. Retrieve data 
        // from the repository and cache it for one hour.
        concerts = await this.database.Concerts.AsNoTracking()
            .Where(c => c.StartTime > DateTimeOffset.UtcNow && c.IsVisible)
            .OrderBy(c => c.StartTime)
            .Take(count)
            .ToListAsync();
        concertsJson = JsonSerializer.Serialize(concerts);
        var cacheOptions = new DistributedCacheEntryOptions {
            AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1)
        };
        await this.cache.SetStringAsync(CacheKeys.UpcomingConcerts, concertsJson, cacheOptions);
    }
    return concerts ?? new List<Concert>();
}

キャッシュデータを最新の状態に保ちます。 最新のデータベース変更と同期するように、定期的なキャッシュ更新をスケジュールします。データボラティリティとユーザーのニーズに基づいて最適なリフレッシュレートを決定します。この方法により、アプリケーションはキャッシュアサイドパターンを使用して、迅速なアクセスと最新の情報の両方を提供できます。たとえば、参照実装では、1 時間だけデータをキャッシュし、データが変更されたときに CreateConcertAsync メソッドを使用してキャッシュキーをクリアします (次のコードを参照してください)。
```
public async Task<CreateResult> CreateConcertAsync(Concert newConcert)
{
    database.Add(newConcert);
    await this.database.SaveChangesAsync();
    this.cache.Remove(CacheKeys.UpcomingConcerts);
    return CreateResult.SuccessResult(newConcert.Id);
}
```
データの一貫性を確保します。 データベース書き込み操作の直後にキャッシュを更新するメカニズムを実装します。イベント駆動の更新または専用のデータ管理クラスを使用して、キャッシュの一貫性を確保します。キャッシュとデータベースの変更を一貫して同期することは、キャッシュアサイドパターンの主要な部分です。たとえば、参照実装では、UpdateConcertAsync メソッドを使用して、キャッシュ内のデータの整合性を維持します (次のコードを参照してください)。
```
public async Task<UpdateResult> UpdateConcertAsync(Concert existingConcert), 
{
   database.Update(existingConcert);
   await database.SaveChangesAsync();
   this.cache.Remove(CacheKeys.UpcomingConcerts);
   return UpdateResult.SuccessResult();
}
```

構成ガイダンス

以降のセクションでは、構成の更新の実装に関するガイダンスを提供します。各セクションは、Well-Architected フレームワークの 1 つ以上の柱と一致します。

構成	信頼性 (RE)	セキュリティ (SE)	コスト最適化 (CO)	オペレーショナルエクセレンス (OE)	パフォーマンス効率 (PE)	WAF の原則のサポート
ユーザーの認証と承認を構成する		✔		✔		SE:05 OE:10
マネージド ID を実装する		✔		✔		SE:05 OE:10
適切なサイズの環境			✔			CO:05 CO:06
自動スケーリングを実装する	✔		✔		✔	RE:06 CO:12 PE:05
リソースのデプロイの自動化				✔		OE:05
監視を実装する			✔	✔	✔	OE:07 PE:04

認証と承認を構成する

Web アプリケーションを Azure に移行する場合は、ユーザーの認証と承認のメカニズムを構成します。次の推奨事項に従ってください。

ID プラットフォームを使用します。 Microsoft ID プラットフォームを使用して、Web アプリ認証を設定します。このプラットフォームでは、シングルテナントアプリケーションとマルチテナントアプリケーションの両方がサポートされており、ユーザーは自分の Microsoft ID またはソーシャルアカウントでサインインできます。
アプリの登録を作成します。 Microsoft Entra ID では、プライマリテナントにアプリケーションを登録する必要があります。アプリケーションを登録することで、Web アプリへのアクセス権を取得するユーザーがプライマリテナントに ID を確保できます。
プラットフォームの機能を使用します。 ユーザー認証とデータアクセスにプラットフォームの機能を使用することで、カスタムの認証コードの必要性を最小限に抑えます。たとえば、App Services では組み込みの認証がサポートされているため、Web アプリで最小限のコードを記述するか、まったくコードを記述せずに、ユーザーのサインインとデータへのアクセスを実現できます。
アプリケーションで承認を強制します。 ロールベースのアクセス制御 (RBAC) を使用して、アプリケーションのロールに最小限の特権を割り当てます。重複を回避し、明確にするために、さまざまなユーザーアクションに対して特定のロールを定義します。ユーザーを適切なロールにマップし、必要なリソースとアクションにのみアクセスできるようにします。

ストレージに対しては一時的なアクセスを優先します。 一時的なアクセス許可を使用して、共有アクセス署名 (SAS) などの不正アクセスや違反から保護します。ユーザー委任 SAS を使用して、一時的なアクセスを許可するときのセキュリティを最大化します。これは、Microsoft Entra ID の資格情報を使用し、永続的なストレージアカウントキーを必要としない唯一の SAS です。
Azure で承認を強制します。 Azure RBAC を使用して、ユーザー ID に最小限の特権を割り当てます。 Azure RBAC は、Azure のリソース ID がアクセスできる対象、それらのリソースに対して実行できる操作、アクセスできる領域を決定します。
永続的で高度なアクセス許可は避けます。 Microsoft Entra Privileged Identity Management を使用して、特権操作の Just-In-Time アクセスを許可します。たとえば、開発者は多くの場合、データベースの作成/削除、テーブルスキーマの変更、ユーザーのアクセス許可の変更を行うために、管理者レベルのアクセス権を必要とします。 Just-In-Time アクセス権を使用して、特権タスクを実行するための一時的なアクセス許可をユーザー ID に付与しします。

マネージド ID を実装する

マネージド ID をサポートするすべての Azure サービスにマネージド ID を使用します。マネージド ID を使用すると、Azure リソース (ワークロード ID) は、資格情報を管理することなく、他の Azure サービスに対して認証し、やり取りすることができます。ハイブリッドシステムとレガシシステムでは、移行を簡略化するためにオンプレミスの認証ソリューションを維持できますが、できるだけ早くマネージド ID に移行する必要があります。マネージド ID を実装するには、次の推奨事項に従います。

適切な種類のマネージドIDを選択します。同じアクセス許可のセットを必要とする複数の Azure リソースがある場合は、ユーザー割り当てのマネージド ID を優先します。各リソースに対してシステム割り当てのマネージド ID を作成し、すべてのリソースに同じアクセス許可を割り当てるよりも、この設定のほうが効率的です。そうでない場合は、システム割り当てのマネージド ID を使用します。
最小特権を構成します。 Azure RBAC を使用して、データベースでの CRUD アクションやシークレットへのアクセスなど、操作に不可欠なアクセス許可のみを付与します。ワークロード ID のアクセス許可は永続的であるため、ワークロード ID にジャスト・イン・タイムまたは短期のアクセス許可を提供することはできません。 Azure RBAC が特定のシナリオに対応していない場合は、Azure サービスレベルのアクセスポリシーで Azure RBAC を補完します。
残りのシークレットを保護します。 残りのシークレットを Azure Key Vault に格納します。各 HTTP 要求中ではなく、アプリケーションの起動時に Key Vault からシークレットを読み込みます。 HTTP 要求内での高頻度のアクセスにより、Key Vault のトランザクション制限を超える可能性があります。アプリケーション構成を Azure App Configuration に格納します。

たとえば、参照実装では、SQL データベース接続文字列の Authentication 引数を使用しているため、App Service はマネージド ID: Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default を使用して SQL データベースに接続できます。 DefaultAzureCredential を使用することで、Web API がマネージド ID を使用して Key Vault に接続できるようにします (次のコードを参照してください)。

    builder.Configuration.AddAzureAppConfiguration(options =>
    {
         options
            .Connect(new Uri(builder.Configuration["Api:AppConfig:Uri"]), new DefaultAzureCredential())
            .ConfigureKeyVault(kv =>
            {
                // Some of the values coming from Azure App Configuration
                // are stored in Key Vault. Use the managed identity
                // of this host for the authentication.
                kv.SetCredential(new DefaultAzureCredential());
            });
    });

適切なサイズの環境

Azure サービスのパフォーマンスレベル (SKU) を使用して、過剰にならないように各環境のニーズを満たします。環境のサイズを適切に設定するには、次の推奨事項に従います。

コストを見積もる。 Azure 料金計算ツールを使用して、各環境のコストを見積もります。
実稼働環境のコストを最適化します。 運用環境には、運用に必要なサービスレベルアグリーメント (SLA)、機能、スケールを満たす SKU が必要です。リソースの使用状況を継続的に監視し、実際のパフォーマンスニーズに合わせて SKU を調整します。
実稼働前の環境のコストを最適化します。 実稼働前の環境では、低コストのリソースを使用し、不要なサービスを無効にして、Azure Dev/Test 料金設定などの割引を適用する必要があります。実稼働前の環境が実稼働環境と十分に同等であることを確認し、リスクが発生しないようにします。このバランスにより、不要なコストを発生させずにテストを効果的に維持できます。
コードとしてのインフラストラクチャ (IaC) を使用して SKU を定義します。 IaC を実装することで、環境に基づいて適切な SKU を動的に選択してデプロイします。このアプローチにより、一貫性が向上し、管理が簡略化されます。

たとえば、参照実装では、Bicep パラメーターを使用して、よりコストの高いレベル (SKU) を実稼働環境にデプロイします。

    var redisCacheSkuName = isProd ? 'Standard' : 'Basic'
    var redisCacheFamilyName = isProd ? 'C' : 'C'
    var redisCacheCapacity = isProd ? 1 : 0

自動スケーリングを実装する

オートスケールにより、Web アプリの回復力と応答性が維持され、動的なワークロードを効率的に処理できます。オートスケールを実装するには、次の推奨事項に従います。

スケールアウトを自動化します。Azure オートスケールを使用して、実稼働環境での水平スケーリングを自動化します。アプリケーションがさまざまな負荷を処理できるように、主要なパフォーマンスメトリックに基づいてスケールアウトするようにオートスケールルールを構成します。
スケーリングトリガーを調整します。 アプリケーションのスケーリング要件に慣れていない場合は、最初のスケーリングトリガーとして CPU 使用率から始めます。スケーリングトリガーを調整して、RAM、ネットワークスループット、ディスク I/O などの他のメトリックを含めます。目標は、Web アプリケーションの動作を合わせることで、パフォーマンスを向上させることです。
スケールアウトバッファーを指定します。 最大容量に達する前にトリガーするように、スケーリングのしきい値を設定します。たとえば、100% に達するまで待機するのではなく、CPU 使用率 85% で実行するようにスケーリングを構成します。このプロアクティブなアプローチは、パフォーマンスを維持し、潜在的なボトルネックを回避するのに役立ちます。

リソースのデプロイの自動化

自動化を使用して、すべての環境に Azure のリソースとコードをデプロイおよび更新します。次の推奨事項に従ってください。

コードとしてのインフラストラクチャを使用します。 継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを通じて、コードとしてのインフラストラクチャをデプロイします。 Azure では、すべての Azure リソース用に Bicep、ARM (JSON)、Terraform のテンプレートがあらかじめ用意されています。
継続的インテグレーション/継続的デプロイ (CI/CD) パイプラインを使用します。 CI/CD パイプラインを使用して、ソース管理からさまざまな環境 (テスト、ステージング、運用など) にコードをデプロイします。 GitHub プロジェクト用の Azure DevOps または GitHub Actions を使用している場合は、Azure パイプラインを利用します。
単体テストの統合。 App Services にデプロイする前に、パイプライン内のすべての単体テストの実行と受け渡しに優先順位を付けます。 SonarQube などのコード品質およびカバレッジツールを組み込んで、包括的なテストカバレッジを実現します。
モックフレームワークを導入します。 外部エンドポイントを含むテストでは、モックフレームワークを利用します。これらのフレームワークを使用すると、シミュレートされたエンドポイントを作成できます。これにより、実際の外部エンドポイントを構成し、環境間でテスト条件を統一する必要がなくなります。
セキュリティスキャンを実行します。 静的アプリケーションセキュリティテスト (SAST) を使用して、ソースコードのセキュリティ上の欠陥とコーディングエラーを見つけます。さらに、ソフトウェア構成分析 (SCA) を実行して、サードパーティのライブラリとコンポーネントのセキュリティリスクを調べます。これらの分析用のツールは、GitHub と Azure DevOps の両方に簡単に統合できます。

監視を実装する

アプリケーションとプラットフォームの監視を実装して、Web アプリのオペレーショナルエクセレンスとパフォーマンス効率を向上させます。監視を実装するには、次の推奨事項に従います。

アプリケーションテレメトリを収集します。 Azure Application Insights で自動インストルメンテーションを使用して、コードを変更することなく、要求スループット、平均要求期間、エラー、依存関係の監視などのアプリケーションテレメトリを収集します。

参照実装では、NuGet パッケージ Microsoft.ApplicationInsights.AspNetCore からの AddApplicationInsightsTelemetry を使用して、テレメトリの収集を有効にします (次のコードを参照してください)。
```
public void ConfigureServices(IServiceCollection services)
{
   ...
   services.AddApplicationInsightsTelemetry(Configuration["App:Api:ApplicationInsights:ConnectionString"]);
   ...
}
```
カスタムアプリケーションメトリックを作成します。 カスタムアプリケーションテレメトリには、コードベースのインストルメンテーションを使用します。コードに Application Insights SDK を追加し、Application Insights API を使用します。

参照実装では、カートのアクティビティに関連するイベントに関するテレメトリが収集されます。 this.telemetryClient.TrackEvent は、カートに追加されたチケットをカウントします。ここではイベント名 (AddToCart) が指定され、concertId と count を持つディクショナリが指定されます (次のコードを参照)。
```
this.telemetryClient.TrackEvent("AddToCart", new Dictionary<string, string> {
    { "ConcertId", concertId.ToString() },
    { "Count", count.ToString() }
});
```
プラットフォームを監視します。 サポートされているすべてのサービスの診断を有効にし、関連付けのためにアプリケーションログと同じ宛先に診断を送信します。 Azure サービスはプラットフォームログを自動的に作成しますが、診断を有効にした場合にのみ保存されます。診断をサポートするサービスごとに、診断設定を有効にします。

参照実装をデプロイする

参照実装では、最初の導入フェーズで必要な変更に重点を置きながら、オンプレミスの ASP.NET アプリケーションから Azure への移行のシミュレーションを通じて開発者を案内します。この例では、架空の会社である Relecloud のコンサートチケット販売アプリケーションを使用し、オンプレミスの Web アプリケーションを通じてチケットを販売しています。 Relecloud では、Web アプリケーションに次の目標を設定しています。

低コストで価値の高いコード変更を実装する
99.9% のサービスレベル目標 (SLO) を達成する
DevOps プラクティスを採用
コスト最適化環境を作成
信頼性とセキュリティを向上させる

Relecloud では、オンプレミスインフラストラクチャは、これらの目標を達成するコスト効率の高いソリューションではないと判断しました。そして、CAMS Web アプリケーションを Azure に移行することが、直近および将来の目標を達成するための最もコスト効率の高い方法であると決定しました。次のアーキテクチャは、Relecloud の信頼性の高い Web アプリパターンの実装の最終状態を表しています。

図 3. 参照実装のアーキテクチャ。このアーキテクチャの Visio ファイルをダウンロードします。

参照の実装

次の方法で共有

.NET 向け信頼性の高い Web アプリパターン

.NET 向け信頼性の高い Web アプリパターンを使用する理由

信頼性の高い Web アプリパターンの実装方法

ビジネスコンテキスト

アーキテクチャのガイダンス

アーキテクチャの設計

適切な Azure サービスを選択する

コードのガイダンス

再試行パターンを実装する

サーキットブレーカーパターンを実装する

キャッシュアサイドパターンを実装する

構成ガイダンス

認証と承認を構成する

マネージド ID を実装する

適切なサイズの環境

自動スケーリングを実装する

リソースのデプロイの自動化

監視を実装する

参照実装をデプロイする

フィードバック

その他のリソース

次の方法で共有

.NET 向け信頼性の高い Web アプリ パターン

.NET 向け信頼性の高い Web アプリ パターンを使用する理由

信頼性の高い Web アプリ パターンの実装方法

ビジネス コンテキスト

アーキテクチャのガイダンス

アーキテクチャの設計

適切な Azure サービスを選択する

コードのガイダンス

再試行パターンを実装する

サーキット ブレーカー パターンを実装する

キャッシュアサイド パターンを実装する

構成ガイダンス

認証と承認を構成する

マネージド ID を実装する

適切なサイズの環境

自動スケーリングを実装する

リソースのデプロイの自動化

監視を実装する

参照実装をデプロイする

フィードバック

その他のリソース

.NET 向け信頼性の高い Web アプリパターン

.NET 向け信頼性の高い Web アプリパターンを使用する理由

信頼性の高い Web アプリパターンの実装方法

ビジネスコンテキスト

サーキットブレーカーパターンを実装する

キャッシュアサイドパターンを実装する