回復性の高いアプリケーション サービスを構築する
組織から、コストと複雑さを最低限に抑えつつ、復旧要件を満たすことを求められています。
このユニットでは、geo 冗長性と可用性クラスターが回復性のあるアプリケーションを構築するのにどのように役立つかについて学習します。 アプリケーションのフェールオーバーとフェールバックに何が関係しているかを学習します。 このユニットを終了すると、監視および通知戦略を実装する理由とその方法を理解できるようになります。
アプリケーションの geo 冗長性を追加する
アプリケーションをホストしているインフラストラクチャの状態に関わらず、アプリケーションの実行を維持できる必要があります。 自然災害やその他の問題により、地域全体に電力が供給されなくなることや、インターネットにアクセスできなくなることがあります。 これらの問題に適切に対応し、アプリケーションの実行を維持するには、geo 冗長性を確保する必要があります。 ただし、geo 冗長を適切に実装しないと、コストがかかる可能性があります。
Azure を使用して、オンプレミスのアプリケーションを geo 冗長にすることができます。 Azure でアプリケーション用に冗長なインフラストラクチャを実行することの利点は、ユーザーに (関連するコストを含め) 物理的な場所を維持してセキュリティで保護する責任がなくなることです。
Azure では、地球の反対側にあるリージョンを使用してアプリケーションに冗長性を追加できます。メンテナンスをする必要はありません。 メンテナンスが自動的に行われると、geo 冗長性をより簡単かつコスト効率よく実現できます。
VPN サイト間接続を使用することで、Azure 内の別のリージョンにあるインフラストラクチャのレプリカを実行している仮想ネットワークに、オンプレミス ネットワークを拡張できます。 オンプレミス ネットワークの正常性を監視するのに、Azure Traffic Manager が役立つ場合があります。 オンプレミスの場所で何らかの問題が発生した場合は、異なるリージョンにある Azure のレプリカ インフラストラクチャを使用することができます。
同様に、Azure 内で実行されているアプリケーションの geo 冗長性を設定することもできます。 たとえば、アプリケーションが仮想ネットワーク内の Azure 仮想マシンのグループで実行されている場合、geo 冗長性を確保するために別のリージョンで同じ設定をレプリケートできます。
仮想ネットワーク ピアリングを使用して、1 つとして扱われる 2 つの異なる仮想ネットワークを接続します。 これら 2 つのネットワークのトラフィックは、パブリック インターネットやゲートウェイを通過しません。 リソースは、同じネットワーク内にあるかのように、他のリソースに直接接続できます。
この場合、Traffic Manager は、各エンドポイントの正常性を監視することで、両方のリージョンを確認します。 プライマリ リージョンで何らかの問題が発生した場合は、Traffic Manager によって要求がセカンダリ リージョンにルーティングされます。
高可用性クラスターを追加する
高可用性クラスターは、確実に最小限のダウンタイムでワークロードの可用性を維持し、実行するのに役立ちます。 高可用性クラスターは、これらのいずれかの種類のアーキテクチャで使用できます。
アクティブ/アクティブ アーキテクチャ: 2 つの同一の Azure 仮想マシンなど、複数のノード間で要求を分け、負荷を分散します。 これらの Azure 仮想マシンをまとめて実行し、要求を共有することができます。 また、さまざまなルーティング方法に基づいて、これらのノードに要求を配布することもできます。
下の図は、アクティブ/アクティブ クラスターのおおまかな例です。
アクティブ/パッシブ アーキテクチャ: アクティブで使われている 1 つのノードと、パッシブで使われていないもう 1 つのノードで、Azure 仮想マシンを実行します。 パッシブ ノードは、アクティブ ノードで障害が発生した場合にのみ使用します。
アクティブ/アクティブのシナリオでは、ノードが同時に実行されています。 このシナリオでは、マシンの仕様がアクティブ/パッシブ クラスター内のマシンと同じである場合、日常的に実行コストが高くなります。
アクティブ/パッシブ クラスターは、アクティブ/アクティブ クラスターよりもコスト効率が高くなることがあります。 パッシブ ノードではユーザー要求をアクティブに処理していないため、ソフトウェア ライセンスのコストが低くなり、リソース コストが低くなる可能性があります。 しかし、アクティブ/パッシブ クラスターではアクティブ ノードのみを実行するため、アクティブ/アクティブ クラスターのように、変動する需要に柔軟に対応することはできません。
Azure 可用性セットなどのリソースは、複数のノードで高可用性を実現するのに役立ちます。 ハードウェア障害やネットワークの停止など、1 台のコンピューターに影響が発生した場合は、別のコンピューターを使用して実行を続けることができます。
また、Azure Virtual Machine Scale Sets を使ってアクティブ/アクティブ クラスターを作成し、要求に直接対応してスケールアップとスケールダウンを行うマシンを実行することもできます。 また、Azure Load Balancer の高可用性ポートのルールを使うと、コンピューターのアクティブ/アクティブまたはアクティブ/パッシブ クラスターを使用するのに役立つ場合があります。
アプリケーションのフェール オーバーとフェール バックを行う
組織は、オンプレミスで実行されているアプリケーションのインフラストラクチャを所有しています。 組織が確実にコンプライアンス要件を満たし、ビジネス継続性の目標を達成できるように支援する必要があります。 Azure Site Recovery と Traffic Manager を一緒に使用することで、Azure にフェール オーバーしてからフェール バックし、アプリケーションを実行し続けることができます。
障害が発生した場合は、Azure で作成されたインフラストラクチャにクライアント トラフィックをスムーズにリダイレクトできます。 Traffic Manager を使用してプロファイルを作成し、優先順位によるルーティング方法を設定します。 その後、2 つのエンドポイント (オンプレミス環境用に 1 つ、Azure に設定する環境用に 1 つ) を作成します。
通常はオンプレミスの環境を実行し、もう一方の Azure の環境はフェールオーバー先専用とするため、次のように 2 つの優先度を設定できます。
- オンプレミス環境に優先度 1
- Azure の環境に優先度 2
Traffic Manager は、これらの優先順位によって、2 つの環境間でトラフィックをどのようにルーティングするかを判断します。 Traffic Manager は、エンドポイントが正常でないことが通知されるまで、オンプレミス環境へのルーティング トラフィックを保持します。 その場合、Traffic Manager は 2 つ目の Azure の環境にトラフィックをルーティングします。
Azure Site Recovery では、フェールオーバーがトリガーされた場合にのみ、Azure で仮想マシンの実行が開始されます。 障害が発生した場合は、Azure Site Recovery を使用して、オンプレミス環境から Azure 環境に対してフェールオーバーを開始できます。
Traffic Manager を使用すると、エンドポイントを監視するプローブの頻度を設定できます。 通常のプローブの場合は 30 秒、より高速なプローブの場合はこれより短い 10 秒間隔でエンドポイントの正常性を監視するよう Traffic Manager を構成しました。
フェールオーバーが完了した後、クライアントは Azure の新しいエンドポイントに透過的に誘導されます。 フェールオーバーの原因となった問題に対処したら、Azure Site Recovery を使用して、またオンプレミス環境にフェールバックできます。 Traffic Manager は、オンプレミスのエンドポイントの正常性を調査し続けます。 Traffic Manager は、エンドポイントが正常な状態であることを識別すると、トラフィックをオンプレミスの環境に送り返します。
