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

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

シナリオ 1: 最小限のダウンタイムでのビジネス継続性のための 2 つの Azure リージョンの使用

このシナリオのアプリケーションには次のような特徴があります。

  • アプリケーションは 1 つの Azure リージョンでアクティブです
  • すべてのデータベース セッションで、データの読み取りおよび書き込みアクセス (RW) が必要です
  • 待機時間とトラフィック コストを減らすため、Web 層とデータ層を併置する必要があります
  • 基本的に、このようなアプリケーションに対するビジネス リスクは、データの損失よりダウンタイムの方が高くなります

このケースでは、すべてのアプリケーション コンポーネントをまとめてフェールオーバーする必要があるとき、地域ごとの障害に対処するようにアプリケーションのデプロイ トポロジを最適化します。 次の図にこのトポロジを示します。 地理的な冗長性の場合は、アプリケーションのリソースをリージョン A とリージョン B にデプロイします。ただし、リージョン B のリソースは、リージョン A で障害が発生するまで使われません。 データベース接続、レプリケーション、フェールオーバーを管理するため、2 つのリージョンの間にフェールオーバー グループを構成します。 両方のリージョンの Web サービスを、読み取り/書き込みリスナー <フェールオーバー グループ名>.database.windows.net を介してデータベースにアクセスするように構成します (1)。 優先順位によるルーティング方法を使うように Traffic Manager を設定します (2)。

注意

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

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

シナリオ 1. 機能停止の前の構成。

プライマリ リージョンで障害が発生すると、SQL Database サービスがプライマリ データベースにアクセスできないことを検出し、自動フェールオーバー ポリシーのパラメーターの基づいてセカンダリ リージョンへのフェールオーバーがトリガーされます (1)。 アプリケーションの SLA によっては、障害の検出からフェールオーバー発生までの時間を制御する猶予期間を構成できます。 フェールオーバー グループがデータベースのフェールオーバーをトリガーする前に、Traffic Manager がエンドポイントのフェールオーバーを開始する可能性があります。 その場合、Web アプリケーションはデータベースにすぐに再接続できません。 ただし、データベースのフェールオーバーが完了すると、再接続は自動的に成功します。 障害が発生したリージョンは復元されてオンラインに戻り、古いプライマリは新しいセカンダリとして自動的に再接続します。 次の図では、フェールオーバー後の構成を示します。

注意

フェールオーバー後にコミットされたすべてのトランザクションは、再接続の間に失われます。 フェールオーバーが完了した後、リージョン B にアプリケーションは、再接続し、ユーザー要求の処理を再開できます。 Web アプリケーションとプライマリ データベースはどちらもリージョン B に存在するようになり、併置が維持されます。 n>

シナリオ 1. フェールオーバー後の構成

リージョン B の機能が停止した場合は、プライマリ データベースとセカンダリ データベースの間のレプリケーション プロセスは中断されますが、両者の間のリンクは維持されます (1)。 Traffic Manager は、リージョン B への接続が失われたことを検出し、エンドポイントの Web アプリ 2 を "低下" としてマークします (2)。 このケースではアプリケーションのパフォーマンスは影響を受けませんが、データベースは保護されていない状態になり、続けてリージョン A で障害が発生するとデータ損失が起こる高いリスクがあります。

注意

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

停止していた機能が復旧すると、セカンダリ データベースがプライマリ データベースと自動的に再同期されます。 同期の間に、プライマリ データベースのパフォーマンスが低下することがあります。 具体的な影響は、フェールオーバー以降に新しいプライマリが取得したデータの量に依存します。 次の図は、セカンダリ リージョンの機能が停止した場合の例です。

シナリオ 1. セカンダリ リージョンでの機能停止の後の構成。

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

  • 同じ Web アプリケーションがリージョン固有の構成なしで両方のリージョンにデプロイされ、フェールオーバーを管理するための追加ロジックは必要ありません。
  • アプリケーションとデータベースが常に併置されるので、フェールオーバーが Web アプリケーションのパフォーマンスに影響することはありません。

主なトレードオフは、ほとんどの期間、リージョン B のアプリケーション リソースの使用率が低いことです。

シナリオ 2: データが最大限に保存されるビジネス継続性のための Azure リージョン

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

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

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

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

シナリオ 2. 機能停止の前の構成。

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

注意

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

シナリオ 2. ディザスター リカバリーのステージ。

リージョン B が停止した場合、Traffic Manager はリージョン B のエンドポイント web-app-2 の障害を検出し、"低下" としてマークします (1)。 その間、フェールオーバー グループは読み取り専用リスナーをリージョン A に切り替えます (2)。 この停止はエンド ユーザー エクスペリエンスに影響しませんが、停止中にプライマリ データベースは危険な状態になります。 次の図は、セカンダリ リージョンで障害が発生した場合の例です。

シナリオ 2. セカンダリ リージョンの停止。

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

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

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

トレードオフは、アプリケーションは読み取り専用モードで動作できなければならないことです。

シナリオ 3: データ損失がなくダウンタイムがほぼゼロでの、異なる地理的な場所へのアプリケーションの再配置

このシナリオのアプリケーションには次のような特徴があります。

  • エンド ユーザーは地理的に異なる場所からアプリケーションにアクセスします
  • アプリケーションには、最新の更新との完全な同期に依存しない読み取り専用のワークロードが含まれます
  • データへの書き込みアクセスは、大半のユーザーと地理的に同じ場所でサポートされる必要があります
  • エンド ユーザーのエクスペリエンスには読み取り待機時間が重要です

これらの要件を満たすには、データの参照や分析などの読み取り専用操作の場合はユーザーのデバイスが地理的に同じ場所にデプロイされているアプリケーションに常に接続することを保証する必要があります。一方、OLTP 操作は、ほとんどの時間は地理的に同じ場所で処理されます。 たとえば、日中の OLTP 操作は地理的に同じ場所で処理されますが、それ以外の時間は地理的に異なる場所で処理されることがあります。 ほとんどのエンド ユーザー アクティビティが業務時間中に発生する場合は、ほとんどのユーザーのほとんどの時間について最適なパフォーマンスを保証できます。 次の図に、このトポロジを示します。

アプリケーションのリソースは、多くの使用需要がある各場所にデプロイする必要があります。 たとえば、アプリケーションが米国、欧州連合、東南アジアでよく使われる場合は、これらのすべての場所にアプリケーションをデプロイする必要があります。 プライマリ データベースは、ある場所の業務時間が終わったら次の場所に動的に切り替わる必要があります。 この方式は、"フォロー ザ サン" と呼ばれます。 OLTP ワークロードは、常に、読み取り/書き込みリスナー <フェールオーバー グループ名>.database.windows.net を介してデータベースに接続します (1)。 読み取り専用ワークロードは、データベース サーバー エンドポイント <サーバー名>.database.windows.net を使ってローカル データベースに直接接続します (2)。 Traffic Manager は、パフォーマンスによるトラフィック ルーティング方法で構成されます。 この方法は、エンド ユーザーのデバイスが最も近いリージョンの Web サービスに接続されるようにします。 Traffic Manager は、各 Web サービス エンドポイントのエンドポイント監視を有効にして設定する必要があります (3)。

注意

フェールオーバー グループの構成では、フェールオーバーに使われるリージョンを定義します。 新しいプライマリは地理的に異なる場所にあるので、フェールオーバーが発生すると、影響を受けたリージョンがオンラインに戻るまで、OLTP ワークロードと読み取り専用ワークロード両方の待機時間が長くなります。

シナリオ 3. プライマリが米国東部の構成。

1 日の最後に (たとえば、ローカル時刻で午後 11 時)、アクティブなデータベースを次のリージョン (北ヨーロッパ) に切り替える必要があります。 このタスクは、Azure のスケジュール サービスを使って完全に自動化できます。 このタスクには、次の手順が含まれます。

  • フェールオーバー グループのプライマリ サーバーを、フレンドリ フェールオーバーを使って北ヨーロッパに切り替えます (1)
  • 米国東部と北ヨーロッパの間のフェールオーバー グループを削除します
  • 同じ名前で、ただし北ヨーロッパとアジア太平洋の間に、新しいフェールオーバー グループを作成します (2)。
  • このフェールオーバー グループに、北ヨーロッパのプライマリとアジア太平洋のセカンダリを追加します (3)。

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

シナリオ 3. 北ヨーロッパへのプライマリの切り替え。

たとえば、北ヨーロッパの機能が停止すると、フェールオーバー グループによってデータベースの自動フェールオーバーが開始され、結果として、アプリケーションはスケジュールより前に次のリージョンに移動されます (1)。 その場合、北ヨーロッパがオンラインに戻るまで、米国東部のみがセカンダリ リージョンとして残ります。 残っている 2 つのリージョンが、ロールを切り替えることで、3 つの場所すべての顧客にサービスを提供します。 それに応じて Azure Scheduler を調整する必要があります。 残っているリージョンはヨーロッパから追加のユーザー トラフィックを受け取るため、アプリケーションのパフォーマンスは、追加の待機時間だけでなく、エンド ユーザー接続数の増加によっても影響を受けます。 北ヨーロッパの停止していた機能が復旧すると、セカンダリ データベースは現在のプライマリ データベースと直ちに同期されます。 次の図は、北ヨーロッパの機能が停止した場合の例です。

シナリオ 3. 北ヨーロッパの停止。

注意

ヨーロッパのエンド ユーザー エクスペリエンスが長い待機時間によって低下する時間を短縮できます。 そのためには、事前にアプリケーションのコピーをデプロイし、北ヨーロッパのオフライン アプリケーション インスタンスの代わりとして、別のローカル リージョン (西ヨーロッパ) にセカンダリ データベースを作成します。 北ヨーロッパがオンラインに戻ったときは、西ヨーロッパを使い続けるか、または西ヨーロッパのアプリケーションのコピーを削除して北ヨーロッパを使うように戻すかを決定できます。

この設計の主なメリットは、次のとおりです。

  • 読み取り専用のアプリケーション ワークロードは、常に最も近いリージョンのデータにアクセスします。
  • 読み取り/書き込みのアプリケーション ワークロードは、各場所の最も活動的な時間帯は、最も近いリージョンのデータにアクセスします。
  • アプリケーションは複数のリージョンにデプロイされているので、1 つのリージョンの機能が失われても、大きなダウンタイムなしに維持できます。

ただし、いくつかのトレードオフがあります。:

  • リージョンが停止すると、その地理的な場所は長い待機時間の影響を受けます。 読み取り/書き込みワークロードと読み取り専用ワークロードはどちらも、異なるリージョンのアプリケーションによって提供されます。
  • 読み取り専用ワークロードは、各リージョンの異なるエンドポイントに接続する必要があります。

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

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

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

次のステップ