Azure SQL Database の地理リストア (Geo-Restore)

このポストは、9 月 13 日に投稿された Azure SQL Database Geo-Restore の翻訳です。

この記事では、Azure SQL Database のビジネス継続性および災害復旧 (BCDR) 機能を紹介するシリーズとして、地理リストア (Geo-restore) について説明します。前回の標準地理レプリケーションの記事では、それぞれのサービス レベルでどのようなビジネス継続性機能が提供されているかについて説明しました。次の表は、それを簡単にまとめたものです。

BCDR オプション	Basic レベル	Standard レベル	Premium レベル
特定時点への復元 (「うっかりミス」の復旧)	7 日間以内の任意の復元ポイント	14 日間以内の任意の復元ポイント	35 日間以内の任意の復元ポイント
地理リストア	RTO < 24 時間* RPO < 24 時間	RTO < 24 時間* RPO < 24 時間	RTO < 24 時間* RPO < 24 時間
標準地理レプリケーション	対象外	RTO < 2 時間 RPO < 30 分	RTO < 2 時間 RPO < 30 分
アクティブ地理レプリケーション	対象外	対象外	RTO < 1 時間 RPO < 5 分

地理リストアの概要

地理リストアは、地理冗長バックアップから新しいデータベースを作成してデータベースを復元する機能です。このデータベースは、任意の Azure リージョンに存在する任意のサーバーに作成できます。作成元として地理冗長バックアップを使用するため、データベースが停止してアクセスできなくなった場合でも復旧が可能です。地理リストアは、すべてのサービス レベルで追加料金なしでご利用いただくことができ、また自動的に有効化されます。

地理リストアの詳細

地理リストアでは特定時点への復元と同じテクノロジが使用されていますが、地理レプリケーションで作成された BLOB ストレージの日単位のバックアップのうち最新のものから復旧する (RA-GRS) という点が大きく異なります。このサービスでは、稼働中の各データベースの毎週の完全バックアップ、毎日の差分バックアップ、および 5 分ごとのトランザクション ログを組み合わせたバックアップ チェーンが維持されます。また、最新の完全バックアップと差分バックアップは BLOB ストレージにもコピーが作成されます。この BLOB は地理レプリケーションの対象なので、プライマリ リージョンで大規模な障害が発生しても日単位のバックアップへのアクセスは保証されます。次の図 1 は、このプロセスを示したものです。

図 1: 地理レプリケーション機能により週単位および日単位のバックアップをストレージ コンテナーにコピー

リージョン内で大規模なインシデントが発生しデータベース アプリケーションが利用できなくなっても、地理リストアを利用すると、他の任意のリージョンのサーバーに格納されている日単位のバックアップのうち最新のものからデータベースを復旧できます。日単位のバックアップのコピーは毎日 1 回実行されるため、最大で 24 時間分のデータ損失 (RPO) が発生する可能性があります。次の図 2 は、復旧プロセスを示したものです。

図 2: 最新の日単位のバックアップからデータベースを復元

地理リストアの利用方法

地理リストアは、Azure 管理ポータルで対象サーバーの [BACKUPS] タブから呼び出すことができます。このタブでは、そのサーバーに存在するすべてのデータベースで使用可能なすべてのバックアップの一覧が、各データベースで最後にバックアップが作成された日時と共に表示されます。復元に使用するバックアップを選択したら、新しいデータベースの名前と作成先のサーバーを指定します。このサーバーは、どのリージョンのものでもかまいません。入力事項の確認後、作成先のリージョンで復元要求が処理待ちの状態になります。次の図 3 ～ 6 は、この手順を示したものです。

図 3: 復元対象のデータベースが存在する "Degraded" 状態のサーバーを選択

 

図 4: 使用可能なバックアップの一覧から復元に使用するデータベースを選択

図 5: データベースの復元先の場所を指定

図 6: 復元処理中のデータベースの状態を監視

標準地理レプリケーションやアクティブ地理レプリケーションと同じく、地理リストアも REST API や PowerShell からの呼び出しにより、Azure 管理ポータルと同様に管理できます。Azure 管理ポータルは、少数のデータベースの地理リストアを突発的に実行する場合に適しています。一方、REST API や PowerShell は、複数のデータベースの復旧作業をスクリプト化する場合や、管理用のカスタマイム スクリプトやアプリケーションと統合する場合に適しています。詳細については、Azure SQL Database の REST API および PowerShell の AzureSqlDatabaseRecovery API (英語) をご覧ください。

誤って開始してしまった復元処理を中止する場合は、復元対象のマスター データベースに接続してそのデータベースを停止させます。復元処理が開始されるとすぐにそのデータベース レコードが表示されるため、復元処理の完了を待たなくてもデータベースを停止させることができます。この場合、追加料金が発生することはありません。

復旧時間に影響する要素

復旧時間は、データベースのサイズやパフォーマンス レベル、作成先のリージョンで同時実行されている復元要求の数など、複数の要素の影響を受けます。あるリージョンで長時間にわたるサービス停止が発生した場合、他のリージョンで実行される地理リストアの要求が多数発行されることがあります。このようなとき、該当するリージョンの既存のワークロードに副次的な影響が及ばないように、復元処理で使用するリソース量が必要に応じて制限されます。多数の要求が集中すると、そのリージョンのデータベースの復旧時間が増加する場合があります。

地理リストアはすべてのサービス レベルでご利用いただけますが、SQL Database の災害復旧ソリューションとしては最も基本的なもので、RPO と RTO も最長です。地理リストアの RTO は 24 時間ですが、データベース サイズが最大 2 GB の Basic レベルでは、適切な災害復旧ソリューションとしてご利用いただけるかと思います。サイズが大きい Standard レベルや Premium レベルのデータベースで、復旧時間を大幅に短縮する必要がある場合やデータ損失を抑える必要がある場合は、標準地理レプリケーションやアクティブ地理レプリケーションの利用をご検討ください。いずれの地理レプリケーションでも、継続的に複製が作成されるセカンダリに対してフェールオーバーを開始するだけでよいため、RPO および RTO は大幅に短縮されます。

災害復旧テスト

多くの場合、コンプライアンス要件として、運用環境のデータベースが障害から適切に保護されていることを示す必要があります。地理リストアは任意のタイミングで利用できるため、災害復旧テストを定期的に実施し、この復旧オプションによる災害復旧プロセスが要件を満たしていることを確認することができます。

まとめ

地理リストア、標準地理レプリケーション、アクティブ地理レプリケーションを組み合わせることで幅広い選択が可能になり、お客様のアプリケーションやビジネスのニーズに合ったビジネス継続性ソリューションを実装することができます。先に述べた料金や SLO の違いと併せて何を選択するかによって、どのようなビジネス継続性のシナリオが実現できるかが変わってきます。次の表は、その違いをまとめたものです。

シナリオ	地理リストア	標準地理レプリケーション	アクティブ地理レプリケーション
リージョン内での災害への対応	○	○	○
災害復旧テスト	○	○	○
オンラインでのアプリケーションのアップグレード	×	×	○
オンラインでのアプリケーションの再配置	×	×	○
読み込み処理の負荷分散	×	×	○

ぜひ地理リストアをお試しになり、お客様の BCDR 戦略にお役立てください。また、いつものお願いではありますが、皆様からのご意見、ご感想をお待ちしております。

Azure SQL Database のバックアップと復元の詳細については、こちらの記事をお読みください。