このシナリオの例は、高可用性とディザスター リカバリーを実現できるようにビルドされた、回復性がある多層アプリケーションをデプロイする必要があるあらゆる業界に適用されます。 このシナリオでは、アプリケーションは 3 つのレイヤーで構成されます。
- Web 層:ユーザー インターフェイスを含む最上位レイヤー。 このレイヤーでは、ユーザーの操作が解析され、処理するためにアクションが次のレイヤーに渡されます。
- ビジネス層:ユーザーの操作が処理され、次のステップに関して論理的な意思決定が行われます。 このレイヤーは、Web 層とデータ層に接続されます。
- データ層:アプリケーション データが格納されます。 通常は、データベース、オブジェクト ストレージ、またはファイル ストレージが使用されます。
一般的なシナリオとして、Windows または Linux で実行されているミッションクリティカルなアプリケーションが挙げられます。 SAP や SharePoint など、市販のアプリケーションのほか、カスタム基幹業務アプリケーションも該当します。
考えられるユース ケース
その他の関連するユース ケース:
- SAP や SharePoint などの、回復性の高いアプリケーションのデプロイ
- 基幹業務アプリケーション用の事業継続とディザスター リカバリー計画の策定
- ディザスター リカバリーの構成、およびコンプライアンスを目的とした関連する訓練の実施
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
- ゾーンがサポートされているリージョン内で、2 つの可用性ゾーンにまたがる各階層に VM を分散します。 他のリージョンでは、1 つの可用性セット内の各階層に VM をデプロイします。
- データベース層は、AlwaysOn 可用性グループを使用するように構成できます。 この SQL Server 構成では、可用性グループ内の 1 つのプライマリ読み取り/書き込みレプリカが最大 8 個のセカンダリ読み取り専用レプリカと一緒に構成されます。 プライマリ レプリカで問題が発生した場合、可用性グループはプライマリ読み取り/書き込みアクティビティをセカンダリ レプリカのいずれかにフェールオーバーし、アプリケーションを引き続き使用できるようにします。 詳細については、SQL Server 用の Always On 可用性グループの概要に関するページをご覧ください。
- ディザスター リカバリーのシナリオでは、ディザスター リカバリーに使用されるターゲット リージョンへの SQL Always On 非同期ネイティブ レプリケーションを構成できます。 データ変更率が、Azure Site Recovery でサポートされている制限内の場合は、ターゲット リージョンへの Azure Site Recovery レプリケーションを構成することもできます。
- ユーザーは、Traffic Manager エンドポイントを使用して、フロントエンド ASP.NET Web 層にアクセスします。
- Traffic Manager により、トラフィックが、プライマリ ソース リージョンのプライマリ パブリック IP エンドポイントにリダイレクトされます。
- パブリック IP により、Web 層の VM インスタンスのいずれかへの呼び出しが、パブリック ロード バランサーを介してリダイレクトされます。 Web 層の VM インスタンスがすべて、1 つのサブネットに含まれています。
- Web 層の VM から、各呼び出しが、処理のために内部ロード バランサーを介して、ビジネス層の VM インスタンスのいずれかにルーティングされます。 ビジネス層の VM がすべて、別のサブネットに含まれています。
- 操作はビジネス層で処理され、ASP.NET アプリケーションは、Azure の内部ロード バランサーを介して、バックエンド層の Microsoft SQL Server クラスターに接続されます。 これらのバックエンド SQL Server インスタンスは、別のサブネットに含まれています。
- Traffic Manager のセカンダリ エンドポイントは、ディザスター リカバリーに使用されるターゲット リージョンでパブリック IP として構成されます。
- プライマリ リージョンで中断が発生した場合は、Azure Site Recovery のフェールオーバーを呼び出します。これにより、アプリケーションは、ターゲット リージョンでアクティブになります。
- Traffic Manager のエンドポイントにより、クライアント トラフィックは、ターゲット リージョンのパブリック IP に自動的にリダイレクトされます。
Components
- 可用性セットを使うことで、Azure にデプロイする VM は、クラスター内で切り離された複数のハードウェア ノードに確実に分散されます。 Azure 内でハードウェアまたはソフトウェアの障害が発生した場合、影響を受けるのは VM のサブセットのみで、ソリューション全体は引き続き利用および運用可能です。
- 可用性ゾーンは、データセンターの障害からアプリケーションとデータを保護します。 可用性ゾーンは、Azure リージョン内の切り離された物理的な場所です。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。
- Azure Site Recovery を使用すると、ビジネス継続性とディザスター リカバリーのニーズのために VM を別の Azure リージョンにレプリケートできます。 コンプライアンスのニーズを満たしていることを確認するために、定期的なディザスター リカバリー訓練を実施できます。 ソース リージョンで障害が発生した場合、アプリケーションを回復できるように、選択したリージョンに指定した設定で VM がレプリケートされます。
- Azure Traffic Manager は、トラフィックをグローバル Azure リージョンにまたがるサービスに最適に分散させながら、高可用性と応答性を提供する DNS ベースのトラフィック ロード バランサーです。
- Azure Load Balancer は、定義された規則と正常性プローブに従って受信トラフィックを分散させます。 ロード バランサーは、低遅延と高スループットを実現し、あらゆる TCP アプリケーションと UDP アプリケーションの数百万ものフローにスケールアップします。 このシナリオでは、パブリック ロード バランサーを使って、着信クライアント トラフィックが Web 層に分散されます。 このシナリオでは、内部ロード バランサーを使って、ビジネス層からバックエンド SQL Server クラスターにトラフィックが分散されます。
代替
- このインフラストラクチャにはオペレーティング システムに依存している要素がないため、Windows は、他のオペレーティング システムで置き換えることができます。
- バックエンド データ ストアの代わりに、Linux 用 SQL Server を使用できます。
- データベースは、使用可能な任意の標準データベース アプリケーションで置き換えることができます。
シナリオの詳細
このシナリオでは、ASP.NET と Microsoft SQL Server を使用する多層アプリケーションを示します。 可用性ゾーンがサポートされる Azure リージョンで、ご自身の仮想マシン (VM) を、可用性ゾーンにまたがる 1 つのソース リージョンにデプロイし、その VM をディザスター リカバリーに使用されるターゲット リージョンにレプリケートできます。 可用性ゾーンがサポートされていない Azure リージョンでは、可用性セット内にあるご自身の VM をデプロイし、それらの VM をターゲット リージョンにレプリケートできます。
リージョン間でトラフィックをルーティングするには、グローバル ロード バランサーが必要です。 次の 2 つの主な Azure サービスがあります。
- Azure Front Door
- Azure Traffic Manager
ロード バランサーを選択する際は、ご自身の要件と、2 つのサービスの機能セットを考慮してください。 どのくらいの速度でフェールオーバーを実行しますか。 TLS 管理のオーバーヘッドに対応できますか。 組織にコストの制約はありますか。
Front Door は、SSL オフロード、パスベースのルーティング、高速フェールオーバー、キャッシュなどのレイヤー 7 機能を提供して、アプリケーションのパフォーマンスと可用性をさらに向上させます。 Azure ネットワークへのインフラストラクチャのオンボーディングが早くなるため、パケットの移動が速くなる場合があります。
Front Door によって新しいホップが追加されるため、セキュリティ操作が追加されています。 アーキテクチャが規制要件に準拠している場合は、追加のトラフィック TLS 終端ポイントに関する制限が存在することがあります。 Front Door によって選択された TLS 暗号スイートは、組織のセキュリティ レベルを満たしている必要があります。 また、Front Door では、バックエンド サービスにおいて Microsoft が使用する証明書が使用されることを想定しています。
もう 1 つの注意点はコストです。 このアーキテクチャでは、追加コストに見合った (フェールオーバーだけではない) 広範な機能セットを利用する必要があります。
Traffic Manager は、DNS ベースの負荷分散サービスです。 DNS レベルでのみ、分散とフェールオーバーが実行されます。 そのため、DNS キャッシュに関連した、また DNS TTL を遵守しないシステムに関連した一般的な課題が理由で、Front Door ほど高速なフェールオーバーはできません。
必要に応じて、両方のロード バランサーを組み合わせることができます。 たとえば、DNS ベースのフェールオーバーが必要であるものの、そのトラフィック管理されたインフラストラクチャの前に POP エクスペリエンスを追加する必要があるとします。
このアーキテクチャでは、Traffic Manager を使用しています。軽量であるためです。 フェールオーバーのタイミングは、十分にわかりやすいはずです。
考慮事項
スケーラビリティ
ご自身のスケーリング要件に基づいて、各階層で VM を追加または削除できます。 このシナリオではロード バランサーが使用されているため、アプリケーションのアップタイムに影響を与えずに、VM を階層に追加できます。
スケーラビリティに関する他のトピックについては、Azure アーキテクチャ センターの「パフォーマンス効率のチェックリスト」を参照してください。
Security
フロントエンド アプリケーション層へのすべての仮想ネットワーク トラフィックが、ネットワーク セキュリティ グループによって保護されます。 フロントエンド アプリケーション層 VM インスタンスのみがバックエンド データベース層にアクセスできるように、規則によってトラフィックのフローが制限されます。 ビジネス層またはデータベース層からのアウトバウンド インターネット トラフィックは許可されません。 攻撃フットプリントを減らすために、ダイレクト リモート管理ポートは開かれていません。 詳細については、Azure ネットワーク セキュリティ グループに関するページをご覧ください。
セキュリティで保護されたシナリオの設計に関する一般的なガイダンスについては、「Azure のセキュリティのドキュメント」を参照してください。
価格
Azure Site Recovery を使用して Azure VM のディザスター リカバリーを構成すると、次の料金が継続的に発生します。
- VM あたりの Azure Site Recovery ライセンス コスト。
- データ変更をソース VM ディスクから別の Azure リージョンにレプリケートするためのネットワーク エグレス コスト。 Azure Site Recovery では組み込みの圧縮機能によって、データ転送要件が約 50% 削減されます。
- 復旧サイトでのストレージ コスト。 これは、通常、ソース リージョンのストレージ コストに、復旧ポイントをスナップショットとして維持するための追加ストレージのコストを足したものです。
Microsoft は、6 つの仮想マシンを使用して 3 層アプリケーションのディザスター リカバリーを構成するためのサンプル コスト計算ツールを提供しています。 すべてのサービスがコスト計算ツールで事前構成されています。 特定のユース ケースの場合、価格がどのように異なるかを確認するには、該当する変数を変更して、コストを見積もります。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- スジェイ・タラシラ | 主要製品リード
次の手順
関連リソース
その他の高可用性とディザスター リカバリーの参照アーキテクチャについては、以下を参照してください。