この記事では、信頼性の高い Web アプリ パターンを適用する方法について説明します。 信頼性の高い Web アプリ パターンは、クラウドへの移行時に Web アプリを変更する方法 (再プラットフォーム) を定義する一連の原則と実装手法です。 クラウドで成功するために行う必要がある最小限のコード更新に焦点を当てています。
このガイダンスの適用を容易にするために、デプロイできる信頼性の高い Web アプリ パターンの参照実装があります。
リファレンス実装のアーキテクチャ。このアーキテクチャの Visio ファイルをダウンロードします。
次のガイダンスでは、全体の例としてリファレンス実装を使用します。 信頼性の高い Web アプリ パターンの実装を計画するには、次の手順を実行します。
ビジネス目標を定義する
クラウド コンピューティングへの移行の最初の手順は、ビジネス目標を明確にすることです。 信頼性の高い Web アプリ パターンでは、Web アプリケーションの即時目標と将来目標の両方を設定することの重要性が強調されています。 これらの目標は、クラウド サービスの選択と、クラウド内の Web アプリケーションのアーキテクチャに影響します。
例: 架空の会社 Relecloud は、オンプレミスの Web アプリケーションを通じてチケットを販売しています。 Relecloud は売上予測が肯定的であり、チケット発行 Web アプリの需要の増加を予測しています。 この需要を満たすために、Web アプリケーションの目標を定義しました。
- 低コストで価値の高いコード変更を適用
- 99.9% のサービス レベル目標 (SLO) にリーチ
- DevOps プラクティスを採用
- コスト最適化環境を作成
- 信頼性とセキュリティを改善
Relecloud のオンプレミス インフラストラクチャは、これらの目標を達成するためのコスト効率の高いソリューションではありませんでした。 そこで、Web アプリケーションを Azure に移行することが、即時および将来の目標を達成するための最もコスト効率の高い方法であると判断しました。
適切なマネージド サービスを選択する
Web アプリをクラウドに移行する場合は、ビジネス要件を満たし、オンプレミス Web アプリの現在の機能に合わせた Azure サービスを選択する必要があります。 この配置により、リプラットフォーム工数を最小限に抑えることができます。 たとえば、同じデータベース エンジンを維持し、既存のミドルウェアとフレームワークをサポートできるサービスを使用します。 次のセクションでは、Web アプリに適した Azure サービスを選択するためのガイダンスを提供します。
例: クラウドに移行する前、Relecloud のチケット発行 Web アプリはオンプレミスのモノリシックな ASP.NET アプリでした。 2 つの仮想マシン上で実行され、Microsoft SQL Server データベースがありました。 Web アプリは、スケーラビリティと機能のデプロイに関する一般的な課題に苦しんでいます。 この出発点、ビジネス目標、SLO がサービスの選択を推進しました。
アプリケーション プラットフォーム
Web アプリに最適なアプリケーション ホスティング プラットフォームを選択します。 Azure には、さまざまな Web アプリの要件を満たすさまざまなコンピューティング オプションがあります。 絞り込みオプションに関するヘルプについては、Azure コンピューティング デシジョン ツリーを参照してください。
例: Relecloud は、次の理由からアプリケーション プラットフォームとして Azure App Service を選択しました。
高いサービス レベル アグリーメント (SLA): 運用環境の SLO 99.9% を満たす高い SLA を備えています。
管理オーバーヘッドの削減: これは、スケーリング、正常性チェック、負荷分散を処理するフル マネージド ソリューションです。
.NET サポート: アプリケーションが書き込まれる .NET のバージョンをサポートします。
コンテナ化機能: Web アプリはコンテナ化せずにクラウドに集約できますが、アプリケーション プラットフォームは Azure サービスを変更せずにコンテナ化もサポートします。
オートスケール:Web アプリは、ユーザーのトラフィックと設定に基づいて、自動的にスケールアップ/ダウン/イン/アウトできます。
ID 管理
Web アプリに最適な ID 管理ソリューションを選択します。 詳細については、「ID 管理ソリューションの比較」と「認証方法」を参照してください。
例: Relecloud は、次の理由で Microsoft Entra ID を選択しました。
認証と承認: アプリケーションは、コール センターの従業員を認証および承認する必要があります。
拡張性: より大規模なシナリオをサポートするように拡張されます。
ユーザー ID 制御:コール センターの従業員は、既存のエンタープライズ ID を使用できます。
承認プロトコルのサポート: マネージド ID に対して OAuth 2.0 をサポートします。
データベース
Web アプリに最適なデータベースを選択します。 オプションの絞り込みについては、Azure データ ストアのデシジョン ツリーを参照してください。
例: Web アプリはオンプレミスの SQL Server を使用していて、Relecloud は既存のデータベース スキーマ、ストアド プロシージャ、関数を使用することを考えています。 Azure ではいくつかの SQL 製品を利用できますが、Relecloud では次の理由から Azure SQL Database を選択しました。
信頼性: 汎用層は、高い SLA と複数リージョンの冗長性が提供します。 高いユーザー負荷をサポートできます。
管理オーバーヘッドの削減: マネージド SQL データベース インスタンスを提供します。
移行サポート: オンプレミス SQL Server からのデータベース移行をサポートします。
オンプレミス構成との整合性: 既存のストアド プロシージャ、関数、およびビューをサポートします。
回復力: バックアップとポイントインタイム リストアをサポートします。
専門知識と最小限のやり直し: SQL Database は社内の専門知識を活用し、導入に必要な作業は最小限です。
アプリケーション パフォーマンス監視
Web アプリのアプリケーション パフォーマンス監視を選択します。 Application Insights は、Azure ネイティブ アプリケーション パフォーマンス管理 (APM) ソリューションです。 これは、Azure の監視ソリューションである Azure Monitor の機能です。
例: Relecloud は、次の理由で Application Insights を使用することを選択しました。
Azure Monitor との統合: Azure Monitor との最適に統合します。
異常検出: パフォーマンスの異常を自動的に検出します。
トラブルシューティング: 実行中のアプリの問題を診断するのに役立ちます。
監視: ユーザーがアプリをどのように使用しているかに関する情報を収集し、カスタム イベントを簡単に追跡できるようにします。
可視性のギャップ: オンプレミス ソリューションには、アプリケーション パフォーマンス監視ソリューションがありませんでした。 Application Insights は、アプリ プラットフォームとコードとの簡単な統合を提供します。
キャッシュ
Web アプリ アーキテクチャにキャッシュを追加するかどうかを選択します。 Azure Cache for Redis は、Azure のプライマリ キャッシュ ソリューションです。 これは、Redis ソフトウェアに基づくマネージド インメモリ データ ストアです。
例: Relecloud の Web アプリの負荷は、コンサートや会場の詳細の表示に大きく偏っています。 次の理由により、Azure Cache for Redis が追加されました。
管理オーバーヘッドの削減: フル マネージド サービスです。
スピードとボリューム: 一般的にアクセスされ、変化が遅いデータでは、データ スループットが高く、読み取りの待機時間が短くなります。
多様なサポート: Web アプリのすべてのインスタンスが使用する統合キャッシュの場所です。
外部データ ストア: VM ローカル キャッシュを実行したオンプレミスのアプリケーション サーバー。 このセットアップでは、頻度の高いデータがオフロードされず、データを無効にできませんでした。
非スティッキー・セッション: セッション・ステートを外部化すると、非スティッキー・セッションがサポートされます。
Load Balancer
Web アプリに最適なロード バランサーを選択します。 Azure にはいくつかのロード バランサーがあります。 オプションの絞り込みに関するヘルプについては、「アプリに最適なロード バランサーを選択する」を参照してください。
例: 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 アプリケーション ファイアウォール
Web アプリを Web 攻撃から保護する Web アプリケーション ファイアウォールを選択します。 Azure Web Application Firewall (WAF) は、Azure の Web Application Firewall で、一般的な Web 悪用や脆弱性から一元的に保護します。
例: Relecloud は、Web 攻撃から Web アプリを保護する必要がありました。 次の理由から、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 アプリは、コード構成ファイルに保管されていましたが、シークレットを外部化するセキュリティ手法の方がより優れています。 マネージド ID は Azure リソースに接続するための推奨ソリューションですが、Relecloud には管理に必要なアプリケーション シークレットがありました。 Relecloud は、次の理由で Key Vault を使用しました。
暗号化: 保存時と転送中の暗号化をサポートします。
マネージド ID:アプリケーション サービスは、マネージド ID を使用してシークレット ストアにアクセスできます。
監視とログに記録: 監査アクセスを簡単にし、格納されているシークレットが変更されたときにアラートを生成します。
統合: Azure 構成ストア (App Configuration) およびWeb ホスティング プラットフォーム (App Service) とのネイティブ統合が提供されます。
ストレージ ソリューション
Web アプリに最適なストレージ ソリューションを選択します。 詳細については、「ストレージ オプションを確認する」を参照してください
例: オンプレミス Web アプリでは、各 Web サーバーにディスク ストレージがマウントされていますが、チームは外部データ ストレージ ソリューションを使用することを考えていました。 Relecloud は、次の理由で Azure Blob Storage を選択しました。
セキュアなアクセス: Web アプリは、パブリック インターネットに公開されているストレージに匿名アクセスでアクセスするためのエンドポイントを排除できます。
暗号化: 保存時と転送中のデータを暗号化します。
回復性: ゾーン冗長ストレージ (ZRS) をサポートします。 ゾーン冗長ストレージでは、プライマリ リージョン内の 3 つの Azure 可用性ゾーンにまたがって、データが同期的にレプリケートされます。 各可用性ゾーンは、独立した電源、冷却装置、ネットワークがある別個の物理的な場所にあります。 この構成は、チケット画像の損失に対する回復性を高めます。
エンドポイントのセキュリティ
Azure サービスへのプライベート アクセスのみを有効にすることを選択します。 Azure プライベート リンクは、仮想ネットワーク内のプライベート エンドポイント経由で Platform-as-a-Service ソリューションへのアクセスを提供します。 仮想ネットワークとサービスとの間のトラフィックは、Microsoft バックボーン ネットワークをまたがります。
例: Relecloud は、次の理由でプライベート リンクを使用しています。
強化されたセキュリティ通信: アプリケーションが Azure プラットフォーム上のサービスにプライベートにアクセスでき、データ ストアのネットワーク フットプリントが削減されるため、データ漏えいからの保護に役立ちます。
最小工数: プライベート エンドポイントは、Web アプリが使用する Web アプリ プラットフォームとデータベース プラットフォームをサポートします。 どちらのプラットフォームも、変更が最小限になるように既存のオンプレミス構成をミラーリングします。
ネットワークのセキュリティ
仮想ネットワークにネットワーク セキュリティ サービスを追加するかどうかを選択します。 Azure Firewall は、ネットワーク トラフィックを検査するステートフルなネットワーク ファイアウォールです。 Azure Bastion を使用すると、RDP/SSH ポートを公開することなく、仮想マシンに安全に接続できます。
例: Relecloud はハブ アンド スポーク ネットワーク トポロジを採用し、共有ネットワーク セキュリティ サービスをハブに配置したいと考えていました。 Azure Firewall では、スポークからのすべての送信トラフィックを検査することでセキュリティとネットワーク セキュリティを強化しました。 DevOps サブネット内のジャンプ ホストから安全にデプロイするために、Relecloud には、Azure Bastion が必要でした。
適切なアーキテクチャを選択する
Web アプリで使用可能な方法を定義し、最適なクラウド サービスを選択したら、Web アプリに最適なアーキテクチャを決定する必要があります。 アーキテクチャは、ビジネス要件、技術要件、および SLO をサポートする必要があります。
アーキテクチャの冗長性を選択する
ビジネス目標によって、Web アプリが必要とするインフラストラクチャとデータの冗長性のレベルが決まります。 Web アプリ SLO は、冗長性の要件を理解するための適切なベースラインを提供します。 可用性のクリティカル パスに対するすべての依存関係を複合 SLA で計算します。 依存関係には、Azure サービスとMicrosoft 以外のソリューションを含める必要があります。
依存関係ごとに可用性の見積もりを割り当てます。 サービス レベル アグリーメント (SLA) は適切な開始点を提供しますが、SLA はコード、デプロイ戦略、アーキテクチャ接続の決定を考慮していません。
例: Relecloud は、可用性のクリティカル パスでサービスを識別しました。 可用性の見積もりに Azure SLA を使用しました。 複合 SLA の計算に基づいて、Relecloud は SLO を 99.9% 満たすためにマルチリージョン アーキテクチャを必要としていました。
ネットワーク トポロジを選択する
Web とネットワークの要件に適したネットワーク トポロジを選択します。 ハブ アンド スポーク ネットワーク トポロジは、Azure の標準的な構成です。 コスト、管理、セキュリティの面での利点があります。 また、オンプレミス ネットワークへのハイブリッド接続オプションもサポートしています。
例: Relecloud は、コストと管理のオーバーヘッドを削減してマルチリージョン デプロイのセキュリティを強化するために、ハブ アンド スポーク ネットワーク トポロジを選択しました。
データの冗長性を選択する
Azure のリージョンと Availability Zones に分散することで、データの信頼性を確保します。地理的な分離が大きいほど、信頼性が高くなります。
目標復旧時点 (RPO) を設定します。 RPO は、障害発生時の許容される最大データ損失を定義し、データがレプリケーションを必要とする頻度を示します。 たとえば、1 時間の RPO は、最近のデータ損失を最大 1 時間分受け入れることを意味します。
データ レプリケーションを実装します。 データ レプリケーションをアーキテクチャと RPO に合わせます。 Azure では、通常、Availability Zones 内での同期レプリケーションがサポートされます。 複数のゾーンを利用して信頼性を簡単に向上させます。 アクティブ/パッシブ セットアップの複数リージョン Web アプリの場合は、Web アプリの RPO ごとにパッシブ リージョンにデータをレプリケートし、レプリケーションの頻度が RPO を超えるのを確認します。 アクティブ/アクティブ構成では、リージョン間で凖リアルタイムのデータ同期が必要であり、コードの調整が必要になる場合があります。
フェールオーバー プランを作成します。 ダウンタイムまたは機能の損失によって決定される、障害に対する対応戦略の概要を説明するフェールオーバー (障害復旧) 計画を立てます。 許容可能な最大ダウンタイムの目標復旧時間 (RTO) を指定します。 フェールオーバー プロセスが RTO よりも高速であることを確認します。 一貫性と制御のために自動または手動のフェールオーバー メカニズムを決定し、通常の運用プロセスへの戻りについて詳しく説明します。 フェールオーバー計画をテストして、有効性を確認します。
次のステップ
この記事では、信頼性の高い Web アプリ パターンの実装を計画する方法について説明しました。 次の手順では、信頼性の高い Web アプリ パターンの実装手法を適用します。