Azure SQL Database を使用した高可用性サービスの設計

Azure SQL Database の高可用性サービスを構築してデプロイするときは、フェールオーバー グループとアクティブ geo レプリケーションを使用して、局地的な障害と致命的な機能停止に対する回復力を用意することで、セカンダリ データベースに高速復旧できます。 この記事では、一般的なアプリケーション パターンを紹介したうえで、アプリケーションのデプロイ要件、目標とするサービス レベル アグリーメント、トラフィック待機時間、コストの面から、各オプションの利点とトレードオフについて説明します。 エラスティック プールでのアクティブ geo レプリケーションについては、エラスティック プールのディザスター リカバリー戦略に関するページを参照してください。

設計パターン 1: アクティブ/パッシブ デプロイとデータベースの併置によるクラウド障害復旧

この設計パターンは、以下の特性を持ったアプリケーションに最適な選択肢です。

  • アクティブ インスタンスが単一の Azure リージョンに存在する。
  • データへの読み取り/書き込み (RW) アクセスに強く依存する。
  • Web アプリケーションとデータベースを異なるリージョンに置いて接続することが、待機時間とトラフィック コストの面から許されない。

すべてのアプリケーション コンポーネントに障害の影響が波及し、ひとつのまとまりとしてフェールオーバーする必要があるとき、このケースでは地域ごとの障害に対処するようにアプリケーションのデプロイ トポロジを最適化します。 地理的な冗長性を確保するために、アプリケーション ロジックとデータベースの両方が別のリージョンにレプリケートされますが、正常な状況下ではアプリケーション ワークロードの処理にそれらが使用されることはありません。 セカンダリ リージョンにおけるアプリケーションの構成には、セカンダリ データベースへの SQL 接続文字列を使用する必要があります。 フェールオーバーによるルーティング方法を使用するように Traffic Manager を設定します。

注意

Azure traffic manager は、あくまで例として使用しています。 フェールオーバーによるルーティング方法に対応していればどのような負荷分散ソリューションを使用してもかまいません。

この構成の機能停止前の状態を示したのが次の図です。

SQL Database の geo レプリケーションの構成。 クラウド ディザスター リカバリー 。

プライマリ リージョンで障害が発生すると、SQL Database サービスがプライマリ データベースにアクセスできないことを検出し、自動フェールオーバー ポリシーのパラメーターの基づいてセカンダリ データベースへのフェールオーバーがトリガーされます。 アプリケーションの SLA によって、障害の検出からフェールオーバー発生までの猶予期間を構成できます。 猶予期間を構成すると、機能停止が致命的でそのリージョンの可用性が簡単には復元できない場合に、データ消失のリスクを減らすことができます。 フェールオーバー グループがデータベースのフェールオーバーをトリガーする前に、エンドポイントのフェールオーバーが Traffic Manager により開始された場合、Web アプリケーションはデータベースに再接続できなくなります。 データベースのフェールオーバーが完了すると、アプリケーションによる再接続の試行は自動的に成功します。

注意

アプリケーションとデータベースの完全に調整されたフェールオーバーを実現するには、独自の監視方法を考案して、Web アプリケーション エンドポイントとデータベースの手動フェールオーバーを使用します。

アプリケーションのエンドポイントとデータベースの両方のフェールオーバーが完了すると、プライマリ データベースはリージョン B に移るため、アプリケーションはユーザー要求の処理をリージョン B で再開し、データベースと併置されます。このシナリオを次の図に示します。 すべての図において実線はアクティブな接続を、点線は中断状態の接続を、通行止めの標識はアクション トリガーを示しています。

geo レプリケーション: セカンダリ データベースへのフェールオーバー。 App data backup.

セカンダリ リージョンの機能が停止した場合、プライマリ データベースとセカンダリ データベース間のレプリケーション リンクが中断状態となりますが、プライマリ データベースに影響は出ていないためフェールオーバーはトリガーされません。 このケースではアプリケーションの可用性は変更されませんが、レプリケーションされていない状態で運用されることから、両方のリージョンに相次いで障害が発生した場合、リスクは増大します。

注意

ディザスター リカバリーについては、アプリケーションのデプロイ先を 2 つのリージョンに限定する構成にすることをお勧めします。 これは、Azure で地理的に割り当てられるリージョンがほとんどの場合 2 つだけであるからです。 この構成では、両方のリージョンで同時発生した致命的な障害からアプリケーションは保護されません。 万一そのような障害が発生した場合は、geo リストア操作を使って、第 3 のリージョンのデータベースを復元することができます。

停止していた機能が復旧すると、セカンダリ データベースがプライマリ データベースと自動的に再同期されます。 同期対象のデータの量によっては、プライマリのパフォーマンスが同期中やや低下する場合があります。 次の図は、セカンダリ リージョンの機能が停止した場合の例です。

プライマリと同期されたセカンダリ データベース。 クラウド ディザスター リカバリー 。

この設計パターンの主な 利点 は次のとおりです。

  • 同じ Web アプリケーションが、リージョン固有の設定やフェールオーバーに対応するための追加のロジックなしに、両方のリージョンにデプロイされる。
  • アプリケーションとデータベースが常に併置されるので、フェールオーバーが Web アプリケーションのパフォーマンスに影響することはない。

一方、セカンダリ リージョンの冗長アプリケーション インスタンスが障害復旧にしか使用されないことが最大の トレードオフ となります。

設計パターン 2: アクティブ/アクティブ デプロイによるアプリケーション負荷分散

このクラウド障害復旧は、以下の特性を持ったアプリケーションに最適な選択肢です。

  • データベースの書き込みに比べて読み取りの割合が大きい。
  • データベースの書き込み待機時間よりも読み取り待機時間がエンドユーザーのエクスペリエンスにより大きな影響を及ぼす。
  • 読み取り専用ロジックと読み取り/書き込みロジックを異なる接続文字列を使って分離できる。
  • 読み取り専用ロジックが、データが直近の更新と完全に同期されていることを前提としない。

開発するアプリケーションがこれらの特性を満たしている場合、リージョンの異なる複数のアプリケーション インスタンスにエンド ユーザーの接続を負荷分散することによって、エンド ユーザーの全体的なエクスペリエンスを実質的に高めることができます。 DR のペアとして 2 つのリージョンを選択する必要があり、フェールオーバー グループはこれらのリージョンにデータベースが必要です。 そのためには、アクティブなアプリケーション インスタンスをすべてのリージョンに割り当てたうえで、読み取り/書き込み (RW) ロジックをフェールオーバー グループの読み取り/書き込みリスナー エンドポイントに接続する必要があります。 これにより、プライマリ データベースが障害の影響を受けた場合、フェールオーバーが自動的に開始されることが保証されます。 Web アプリケーションの読み取り専用ロジック (RO) は、そのリージョン内のデータベースに直接接続する必要があります。 Traffic Manager は、パフォーマンスによるルーティングを使用するように設定し、エンド ポイントの監視を各アプリケーション インスタンスに対して有効にします。

パターン 1 と同様の監視アプリケーションをデプロイすることを検討してください。 ただし、パターン 1 とは異なり、この監視アプリケーションでエンド ポイントのフェールオーバーをトリガーする必要はありません。

注意

このパターンでは複数のセカンダリ データベースを使用していますが、フェールオーバーに使用し、フェールオーバー グループの一部を担う必要があるのはリージョン B のセカンダリだけです。

ユーザーの地理的位置に最も近接するアプリケーション インスタンスにユーザーからの接続を誘導するために、Traffic Manager は、パフォーマンスによるルーティングを使用するように設定します。 この構成の機能停止前の状態を示したのが次の図です。

障害なし: 最も近いアプリケーションへのパフォーマンスによるルーティング。 geo レプリケーション。

リージョン A でデータベース障害が検出されると、フェールオーバー グループがリージョン A のプライマリ データベースからリージョン B のセカンダリへのフェールオーバーを自動的に開始します。また、Web アプリケーションの読み取り/書き込み接続が影響を受けないように、リージョン B への読み取り/書き込みリスナー エンドポイントを自動的に更新します。 Traffic Manager は、オフラインとなったエンド ポイントをルーティング テーブルから除外しますが、残っているオンライン インスタンスには、エンド ユーザーのトラフィックをルーティングし続けます。 読み取り専用 SQL 接続文字列は常に同じリージョン内のデータベースを指しているので、影響を受けません。

次の図は、フェールオーバー後の新しい構成を示しています。

フェールオーバー後の構成。 クラウド ディザスター リカバリー 。

いずれかのセカンダリ リージョンの機能が停止した場合、Traffic Manager は、そのリージョンのオフライン エンド ポイントをルーティング テーブルから自動的に削除します。 そのリージョンのセカンダリ データベースへのレプリケーション チャネルが中断状態となります。 残っているリージョンへのユーザー トラフィックが増えるという点で、機能が停止している間はアプリケーションのパフォーマンスに影響が生じます。 停止していた機能が復旧すると、影響のあったリージョンのセカンダリ データベースがプライマリ データベースと直ちに同期されます。 同期対象のデータの量によっては、プライマリのパフォーマンスが同期中やや低下する場合があります。 次の図は、リージョン B の機能が停止した場合の例です。

Outage in secondary region. クラウドの障害復旧 - geo レプリケーション。

この設計パターンの主な 利点 は、アプリケーション ワークロードを複数のセカンダリにスケールして最適なエンド ユーザー パフォーマンスを実現できることです。 このオプションの トレードオフ は次のとおりです。

  • アプリケーション インスタンスとデータベースの間の読み取り/書き込み接続に関して待機時間とコストのばらつきが生じる
  • 機能が停止している間、アプリケーションのパフォーマンスが影響を受ける
注意

同様のアプローチで、レポート ジョブ、ビジネス インテリジェンス ツール、バックアップなど特定のワークロードの負荷を軽減することができます。 通常これらのワークロードはデータベースのリソースを著しく消費するため、予測されるワークロードに見合ったパフォーマンス レベルのセカンダリ データベース 1 つ指定することをお勧めします。

設計パターン 3: アクティブ/パッシブ デプロイによるデータ保存

この設計パターンは、以下の特性を持ったアプリケーションに最適な選択肢です。

  • 少しのデータ損失も多大なビジネス リスクを招く。 データベースのフェールオーバーはあくまで、機能停止が致命的である場合の最終手段。
  • アプリケーションは操作の読み取り専用または読み取り/書き込みモードをサポートし、一定時間は「読み取り専用モード」で機能します。

このパターンでは、読み取り/書き込み接続がタイムアウト エラーを受け取るようになったときにアプリケーションが読み取り専用モードに切り替わります。 Web アプリケーションは両方のリージョンにデプロイされ、読み取り/書き込みリスナー エンドポイントへの接続と、読み取り専用リスナー エンドポイントへの別の接続が含まれます。 Traffic Manager は、フェールオーバーによるルーティングを使用するように設定し、エンドポイントの監視を各リージョンのアプリケーション エンドポイントに対して有効にします。

この構成の機能停止前の状態を示したのが次の図です。

フェールオーバー前のアクティブ/パッシブ デプロイ。 クラウド ディザスター リカバリー 。

Traffic Manager がリージョン A への接続障害を検出すると、ユーザーのトラフィックをリージョン B のアプリケーション インスタンスに自動的に切り替わります。このパターンでは、データ消失の猶予期間を十分に高い値 (24 時間など) に設定することが重要です。 これにより、機能の停止がその期間内に対処された場合にデータ消失を防ぐことができます。 リージョン B の Web アプリケーションがアクティブになると、読み取り/書き込み操作が失敗するようになります。 その時点で、読み取り専用モードに切り替える必要があります。 このモードでは、要求が自動的にセカンダリ データベースにルーティングされます。 致命的なエラーが発生し、猶予期間内に機能の停止が対処されないと、フェールオーバー グループがフェールオーバーをトリガーします。 その後、読み取り/書き込みリスナーが使用できるようになり、リスナーに対する呼び出しが失敗しないようになります。 これを示したのが次の図です。

Outage: Application in read-only mode. クラウド ディザスター リカバリー 。

プライマリ リージョンの停止していた機能が猶予期間内に対処された場合、プライマリ リージョンの接続の復旧を Traffic Manager が検出し、ユーザー トラフィックをリージョン A のアプリケーション インスタンスに戻します。そのアプリケーション インスタンスはリージョン A のプライマリ データベースを使用して読み取り/書き込みモードで再開し、運用されます。

リージョン B の機能が停止すると、リージョン B のアプリケーション エンドポイントのエラーを Traffic Manager が検出し、フェールオーバー グループが読み取り専用リスナーをリージョン A に切り替えます。この機能停止はエンド ユーザーのエクスペリエンスに影響しませんが、機能停止時にプライマリ データベースが公開されます。 これを示したのが次の図です。

Outage: Secondary database. クラウド ディザスター リカバリー 。

機能停止が対処されると、セカンダリ データベースが即時にプライマリと同期され、読み取り専用リスナーがリージョン B のセカンダリ データベースに切り戻されます。同期対象のデータの量によっては、プライマリのパフォーマンスが同期中やや低下する場合があります。

この設計パターンには次のようにいくつかの 利点があります。

  • 一時的な機能停止の間、データ損失を防ぐことができる。
  • ダウンタイムを左右するのは、Traffic Manager が接続障害を検出するのにかかる時間のみであり、その時間は設定によって変更可能。

トレードオフは次のとおりです。

  • アプリケーションが読み取り専用モードで動作できなければならない。
注意

万一リージョンのサービス機能が完全に停止した場合は、データベースのフェールオーバーを手動で起動し、データの損失を受け入れます。 セカンダリ リージョンのアプリケーションが、データベースへの読み取り/書き込みアクセスが可能な状態で動作します。

ビジネス継続性計画: クラウド障害復旧用のアプリケーション設計を選択する

実際のクラウド障害復旧戦略では、対象アプリケーションのニーズに合わせて、これらの設計パターンを組み合わせたり拡張したりすることができます。 既に述べたように、選択すべき戦略は、利用者に提供する SLA とアプリケーションのデプロイ トポロジによって異なります。 以下の表では、意思決定の目安として推定データ損失つまり、回復ポイントの目標 (RPO) と推定復旧時間 (ERT) に基づいてそれぞれの選択肢を比較しています。

パターン RPO ERT
アクティブ/パッシブ デプロイとデータベース併置による障害復旧 読み取り/書き込みアクセス = 5 秒未満 障害検出時間 + DNS TLL
アクティブ/アクティブ デプロイによるアプリケーション負荷分散 読み取り/書き込みアクセス = 5 秒未満 障害検出時間 + DNS TLL
アクティブ/パッシブ デプロイによるデータ保存 読み取り専用アクセス < 5 秒 読み取り専用アクセス = 0
読み取り/書き込みアクセス = 0 読み取り/書き込みアクセス = 障害検出時間 + データ消失の猶予期間

次のステップ