Azure SQL Database によるビジネス継続性の概要

この概要では、Azure SQL Database に用意されているビジネス継続性と障害復旧の機能について説明し、 データ損失につながる、またはデータベースやアプリケーションを使用不能状態に追い込む破壊的なイベントから復旧するためのオプション、推奨事項、およびチュートリアルについて説明します。 ユーザーまたはアプリケーション エラーがデータ整合性に影響を及ぼすとき、Azure リージョンでシステム停止が発生したとき、あるいはアプリケーションにメンテナンスが必要なときの対処方法について説明します。

ビジネス継続性を提供するときに使用できる SQL Database の機能

SQL Database には、自動バックアップ、オプションのデータベース レプリケーションなど、ビジネス継続性の機能がいくつか用意されており、 推定復旧時間 (ERT) と、最近のトランザクションに対する潜在的なデータ損失の特徴が、それぞれ異なります。 オプションについて理解したら、その中から適切なものを選択できます。これらのオプションは、ほとんどの場合、さまざまなシナリオに対して組み合わせて使用できます。 ビジネス継続性計画を開発するときは、破壊的なイベントが発生してから、アプリケーションが完全に復旧するまでの最大許容時間について理解する必要があります。これが目標復旧時間 (RTO) です。 さらに、破壊的なイベントの発生後、復旧中にアプリケーションが損失を許容できる最大データ更新 (期間) 量についても理解しなければなりません。これは目標復旧時点 (RPO) です。

次のテーブルは、3 つの一般的なシナリオについて ERT と RPO を比較しています。

機能 Basic レベル Standard レベル Premium レベル
バックアップからのポイントインタイム リストア 7 日間以内のあらゆる復元ポイント 35 日間以内のあらゆる復元ポイント 35 日間以内のあらゆる復元ポイント
Geo レプリケーション バックアップからの geo リストア ERT < 12 時間、RPO < 1 時間 ERT < 12 時間、RPO < 1 時間 ERT < 12 時間、RPO < 1 時間
Azure Backup コンテナーからの復元 ERT < 12 時間、RPO < 1 週間 ERT < 12 時間、RPO < 1 週間 ERT < 12 時間、RPO < 1 週間
アクティブ geo レプリケーション ERT < 30 秒、RPO < 5 秒 ERT < 30 秒、RPO < 5 秒 ERT < 30 秒、RPO < 5 秒

データベース バックアップを使用してデータベースを復旧する

SQL Database は、データ損失からビジネスを守るために、データベースの完全バックアップ (毎週)、データベースの差分バックアップ (1 時間ごと)、およびトランザクション ログのバックアップ (5 ~ 10 分ごと) を組み合わせて自動的に実行します。 これらのバックアップは、Standard および Premium サービス レベルの場合は 35 日間、Basic サービス レベルでは 7 日間、geo 冗長ストレージに格納されます。 詳細については、サービス レベルに関する記事をご覧ください。 サービス階層のリテンション期間がビジネス要件を満たしていない場合、リテンション期間を長くするには、サービス階層を変更します。 データベースの完全バックアップと差分バックアップは、データ センターの停止に対する保護のためにペアのデータ センターにもレプリケートされます。 詳細については、データベースの自動バックアップに関するページをご覧ください。

組み込みのリテンション期間がアプリケーションにとって十分でない場合は、データベースの長期的なリテンション期間ポリシーを構成することでリテンション期間を拡張できます。 詳細については、長期間のリテンションに関するページを参照してください。

これらのデータベースの自動バックアップを使用して、さまざまな中断イベントから、データ センター内または別のデータ センターにデータベースを回復することができます。 データベースの自動バックアップでの復旧時間は、同じリージョン内で同時に復旧するデータベースの合計数、データベースのサイズ、トランザクション ログのサイズ、ネットワーク帯域幅など、複数の要因によって異なりますが、 通常は 12 時間もかかりません。 他のデータ リージョンに復旧する場合は、geo 冗長ストレージで 1 時間ごとにデータベースの差分バックアップが実行されるため、潜在的なデータ損失が 1 時間分の量を超えることはありません。

重要

自動バックアップを使って復旧するには、SQL Server の共同作業者ロールのメンバーまたはサブスクリプション所有者である必要があります。「RBAC: 組み込みのロール」をご覧ください。 復旧には、Azure ポータル、PowerShell、または REST API を使用できます。 Transact-SQL は使用できません。

次のようなアプリケーションについては、ビジネス継続性と復旧メカニズムとして自動バックアップを使用します。

  • ミッション クリティカルではない。
  • 拘束力のある SLA がない。24 時間以上のダウンタイムで財務責任が課せられることがない。
  • データ変更率 (1 時間あたりのトランザクション数など) が低く、最大 1 時間分の変更に対するデータ損失を許容できる。
  • コスト重視である。

迅速に復旧する必要がある場合は、後述する アクティブ geo レプリケーションを使用してください。 35 日より前の期間のデータを回復する能力が必要な場合は、長期のバックアップ リテンション期間を使用します。

アクティブ geo レプリケーションと自動フェールオーバー グループ (プレビュー段階) を使用して、復旧時間を短縮し、復旧に伴うデータ損失を抑える

ビジネス中断が発生した場合、データベース バックアップを使用してデータベースを復旧するほか、アクティブ geo レプリケーションを使用して、最大 4 つの読み取り可能なセカンダリ データベースが任意のリージョンに作成されるように、データベースを構成することもできます。 このセカンダリ データベースは、非同期レプリケーション メカニズムを使用して、プライマリ データベースと同期し続けます。 この機能は、データ センター停止が発生した場合、またはアプリケーションのアップグレード中のビジネス中断を防ぐために使用されます。 また、アクティブ geo レプリケーションを使用して、地理的に分散したユーザーの読み取り専用クエリのパフォーマンスを高めることもできます。

自動的かつ透過的なフェールオーバーを有効にするには、SQL Database の自動フェールオーバー グループ機能 (プレビュー段階) を使用して、geo レプリケートされたデータベースをグループにまとめる必要があります。

プライマリ データベースが予期せずオフラインになった場合、またはメンテナンスのためにプライマリ データベースをオフラインにする必要がある場合は、セカンダリ データベースをすばやくプライマリに昇格し ("フェールオーバー" とも呼ばれます)、プライマリに昇格したデータベースに接続されるようにアプリケーションを構成できます。 アプリケーションがフェールオーバー グループ リスナーを使用してデータベースに接続している場合は、SQL 接続文字列構成をフェールオーバーの後で変更する必要がありません。 計画フェールオーバーの場合、データ損失は発生しません。 計画外フェールオーバーについては、非同期レプリケーションの性質上、最近のトランザクションのデータが多少失われます。 自動フェールオーバー グループ (プレビュー段階) を使用すると、フェールオーバー ポリシーをカスタマイズしてデータ損失の可能性を最小限に抑えることができます。 フェールオーバー後は、後でフェールバックできます。このフェールバックは、計画に従って、またはデータ センターがオンラインに戻ったときに行います。 いずれにしても、ユーザーのダウンタイムはわずかで、再接続が必要です。

重要

アクティブ geo レプリケーションと自動フェールオーバー グループ (プレビュー段階) を使用するには、サブスクリプション所有者であるか、SQL Server の管理アクセス許可を持っている必要があります。 Azure ポータル、PowerShell、または REST API で構成およびフェールオーバーを行う場合は、Azure サブスクリプションのアクセス許可を使用できます。Transact-SQL で行う場合は、SQL Server のアクセス許可を使用できます。

アクティブ geo レプリケーションと自動フェールオーバー グループ (プレビュー段階) は、アプリケーションが次のいずれかの条件を満たす場合に使用します。

  • ミッション クリティカルである。
  • サービス レベル アグリーメント (SLA) で 24 時間以上のダウンタイムが許可されていない。
  • ダウンタイムによって財務責任が発生する。
  • データ変更率が高く、1 時間分のデータの損失が許容されない。
  • アクティブ geo レプリケーションの追加コストが、潜在的な財務責任と関連するビジネス損失を下回る。

>

ユーザーまたはアプリケーション エラーの発生後にデータベースを復旧する

ミスをしない人など存在しません。 一部のデータ、重要なテーブル、そしてデータベース全体さえも、うっかり削除してしまう場合があります。 アプリケーションの欠陥で、正しいデータが不良データによって誤って上書きされることもあります。

ここでは、このような場合の復旧オプションを紹介します。

ポイントインタイム リストアを実行する

自動バックアップを使用すると、データベースのコピーを、データベース リテンション期間内の既知の適切な時点まで遡って復旧できます。 データベースを復元したら、元のデータベースを復元したデータベースに置き換えるか、復元したデータから必要なデータを元のデータベースにコピーできます。 データベースでアクティブ geo レプリケーションが使用されている場合は、復元されたコピーから元のデータベースに必要なデータをコピーすることをお勧めします。 元のデータベースを復元したデータベースに置き換える場合は、アクティブ geo レプリケーションを再構成して再同期する必要があります (大きなデータベースの場合はかなり時間がかかることがあります)。 これにより、データベースは利用可能な最新のポイント イン タイムまでリストアされますが、geo セカンダリの任意のポイント イン タイムへのリストアは現在サポートされていません。

詳細情報、および Azure ポータルまたは PowerShell を使用してデータベースを特定の時点に復元する詳細な手順については、「 ポイントインタイム リストア」をご覧ください。 Transact-SQL を使用して回復することはできません。

削除されたデータベースの復元

データベースだけが削除され、論理サーバーが削除されていない場合は、削除されたデータベースを、そのデータベースが削除された時点に戻すことができます。 この場合、データベースが削除された論理 SQL サーバーに、データベース バックアップが復元されます。 このデータベースの復元は元の名前を使用して実行することも、復元したデータベースに新しいに名前を付けることもできます。

詳細情報、および削除されたデータベースを Azure ポータルまたは PowerShell を使用して復元する詳細な手順については、 削除されたデータベースの復元に関するページをご覧ください。 Transact-SQL を使用して復元することはできません。

重要

論理サーバーが削除された場合、削除されたデータベースは回復できません。

Azure Backup コンテナーからの復元

自動化されたバックアップの現在のリテンション期間外にデータの損失が発生したが、データベースに長期保存が構成されている場合は、Azure Backup コンテナーの毎週のバックアップから、新しいデータベースにデータを復元できます。 この時点で、元のデータベースを復元したデータベースに置き換えるか、復元したデータベースから必要なデータを元のデータベースにコピーできます。 アプリケーションのメジャー アップグレードの前の古いバージョンのデータベースを取得し、監査担当者からの要求または法律上の要請に対応する必要がある場合は、Azure Backup コンテナーに保存されている完全バックアップを使用してデータベースを作成することができます。 詳細については、「長期保存」をご覧ください。

Azure リージョン データ センターが停止した場合にデータベースを別のリージョンで回復する

まれではありますが、Azure データ センターが停止することもあります。 停止が発生すると、ビジネスが中断します。この中断はわずか数分で解消されることもありますが、数時間に及ぶ場合もあります。

  • オプションの 1 つは、データ センターの停止が終了し、データベースがオンラインに戻るのを待つことです。 このオプションは、オフラインのデータベースが許容されるアプリケーションで有効です。 たとえば、常時作業する必要のない開発プロジェクトや無料試用版がこれに該当します。 また、データ センターが停止したときに、復旧までの時間を予測できないため、当面はデータベースが必要ない場合にのみ使用できます。
  • もう 1 つは、アクティブ geo レプリケーションを使用して別のデータ リージョンにフェールオーバーするか、geo 冗長データベース バックアップ (geo リストア) を使用してデータベースを復旧するオプションです。 フェールオーバーの所要時間はわずか数秒ですが、バックアップからデータベースが復旧する場合は数時間かかります。

アクションを実行するタイミング、復旧にかかる時間、および発生するデータ損失の量は、ビジネス継続性機能をアプリケーションでどのように使用するかによって異なります。 実際は、アプリケーションの要件に応じて、データベース バックアップとアクティブ geo レプリケーションを組み合わせて使用できます。 ビジネス継続性機能を使用したスタンドアロン データベースおよびエラスティック プール用アプリケーション設計に関する考慮事項については、クラウド ディザスター リカバリー用のアプリケーション設計) に関するページとエラスティック プールのディザスター リカバリー戦略に関するページをご覧ください。

以下のセクションでは、データベース バックアップまたは アクティブ geo レプリケーションのいずれかを使用して復旧する手順の概要について説明します。 要件の計画、復旧後の手順、障害をシミュレートして障害復旧訓練を実施する方法など、詳細な手順については、障害からの SQL Database 復旧に関するページをご覧ください。

障害に備える

使用するビジネス継続性機能に関係なく、次の操作を行う必要があります。

  • サーバー レベルのファイアウォール規則、ログイン、マスター データベース レベルのアクセス許可など、ターゲット サーバーを特定して準備します。
  • クライアントとクライアント アプリケーションを、新しいサーバーにリダイレクトする方法を決めます
  • 監査の設定、アラートなど、他の依存関係を文書化します

準備が不十分な状態で、フェールオーバーまたはデータベースの復旧後にアプリケーションをオンラインにすると、余計な時間がかかり、負荷がかかったときにトラブルシューティングが必要になる場合があります。良くない組み合わせです。

geo レプリケートされたセカンダリ データベースにフェールオーバーする

アクティブ geo レプリケーションと自動フェールオーバー グループ (プレビュー段階) を復旧メカニズムとして使用している場合は、自動フェールオーバー ポリシーを構成するか手動フェールオーバーを使用できます。 いったん開始すると、フェールオーバーによってセカンダリは新しいプライマリになり、新しいトランザクションを記録してクエリに応答できるようになります。失われるのは、レプリケートされなかった最小限のデータだけです。 フェールオーバー プロセスの設計については、クラウド障害復旧用のアプリケーション設計に関するページをご覧ください。

注意

データ センターがオンラインに戻ると、古いプライマリは自動的に新しいプライマリに再接続し、セカンダリ データベースになります。 プライマリを元のリージョンに再配置する場合は、計画されたフェールオーバーを手動で開始することができます (フェールバック)。

geo リストアを実行する

Geo 冗長ストレージ レプリケーションによる自動バックアップを復旧メカニズムとして使用している場合は、geo リストアを使用してデータベース復旧を開始します。 ほとんどの場合、12 時間以内に復旧が実行され、最大 1 時間分のデータ損失が発生します。これは 1 時間ごとの差分バックアップによって、最後のバックアップが実行およびレプリケートされたタイミングによって決まります。 復旧処理が完了するまで、データベースは、トランザクションを記録したり、クエリに応答したりすることはできません。 これにより、データベースは利用可能な最新のポイント イン タイムまでリストアされますが、geo セカンダリの任意のポイント イン タイムへのリストアは現在サポートされていません。

注意

復旧されたデータベースにアプリケーションを切り替える前に、データ センターがオンラインに戻った場合は、復旧をキャンセルすることができます。

フェールオーバー後のタスク/復旧タスクを実行する

復旧にどちらのメカニズムを使ったとしても、ユーザーおよびアプリケーションの動作を元に戻す前に、次の追加タスクを実行する必要があります。

  • クライアントとクライアント アプリケーションを、新しいサーバーおよび復元されたサーバーにリダイレクトする
  • ユーザーが接続できるように、適切なサーバー レベルのファイアウォール規則が適用されていることを確認する (または データベース レベルのファイアウォールを使用する)
  • 適切なログインとマスター データベース レベルのアクセス許可が適切に指定されていることを確認する (または 包含ユーザーを使用する)
  • 必要に応じて、監査を構成する
  • 必要に応じて、アラートを構成する

最小のダウンタイムでアプリケーションをアップグレードする

アプリケーションのアップグレードなど、計画されたメンテナンスのために、アプリケーションをオフラインにしなければならないことがあります。 アプリケーション アップグレードの管理 に関するページでは、アクティブ geo レプリケーションを使用してクラウド アプリケーションのローリング アップグレードを有効化し、アップグレード中のダウンタイムを最小限に抑え、問題が発生した場合の復旧パスを提供する方法について説明します。

次のステップ

スタンドアロン データベースおよびエラスティック プール用アプリケーション設計に関する考慮事項については、クラウド障害復旧用のアプリケーション設計に関するページとエラスティック プール障害復旧戦略に関するページをご覧ください。