Azure SQL Database の標準地理レプリケーション

このポストは、9 月 3 日に投稿した Azure SQL Database Standard Geo-Replication の翻訳です。

今回の記事では、ビジネス継続性のシナリオを取り上げ、新しくリリースされた Azure SQL Database の標準地理レプリケーション機能について説明します。標準地理レプリケーション機能では、プライマリ データベースでコミットされたトランザクションを、事前に指定された Azure リージョンのセカンダリ データベースに非同期で複製するようにデータベースを構成できます。詳細の説明に入る前に、まずはプレビュー版として利用可能なビジネス継続性機能全般について簡単にまとめ、さらに 2014 年 4 月に発表した新しいサービス レベルに沿って説明します。各サービス レベルの詳細については、こちらの記事をご覧ください。

ビジネス継続性モデル

以前のアクティブ地理レプリケーションの記事では、筆者の Tobias Ternstrom がビジネス継続性の課題について説明しました。今回の記事の内容をより深くご理解いただくために、あらかじめ把握しておいていただきたいことをここで簡単にご紹介します。

• 災害復旧 (DR): アプリケーションの通常のビジネス機能を復元する処理。
• 特定時点への復元: 過去の (バックアップ保持期間内の) 特定の時点の状態にデータベースを復元する機能。人為的なミスやプログラムのエラーにより発生したデータ破損から復旧する際に使用します。
• 目標復旧時間 (RTO): 障害発生後アプリケーションの機能が完全に復旧するまでの最長のダウンタイム。
• 目標復旧時点 (RPO): 障害発生後アプリケーションの機能が完全に復旧するまでに失われる可能性のある、最新のデータ変更内容の最大量 (期間)。

次の表は、各サービス レベルで提供されているビジネス継続性機能をまとめたものです。

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

ビジネス継続性/災害復旧 (BCDR) モデルで重要な点は、アプリケーションのパフォーマンス特性に応じて、ニーズに合ったビジネス継続性ソリューションを選択することです。アプリケーションが処理するデータ量が少なく更新頻度も低い場合は、Basic レベルのパフォーマンスが適しており、地理リストア機能でも十分にニーズに対応した災害復旧能力が得られます。アプリケーションのデータ処理量が多い場合は Standard レベル以上の高いパフォーマンスとより高度な RPO が必要なため、災害復旧ソリューションには標準地理レプリケーションが推奨されます。アクティブ地理レプリケーションは、RPO が小さい最も高度な復旧機能が求められる、更新データ量が非常に多いアプリケーションが想定されています。このように、SQL Database の BCDR モデルは、Basic から Premium へとレベルが上がるに従ってビジネス継続性機能の堅牢性がより高くなります。また、読み込み処理中心のデータ処理の場合は高レベルの RPO はそれほど必要ではないため、上位のサービス レベルでも下位サービス レベルで提供されている BCDR 機能をご利用いただけるようになっています。

標準地理レプリケーションとアクティブ地理レプリケーションの相違点

ここからは、ユーザー エクスペリエンスの詳細、およびアクティブ地理レプリケーションとの相違点について説明します。

標準地理レプリケーションはアクティブ地理レプリケーションと同じテクノロジを基礎として構築されていますが、書き込み頻度が低いアプリケーションに最適化されています。この機能は主に、(a) 更新頻度が低く、災害復旧について高度な SLA を必要としないアプリケーションを対象とすること、(b) そのようなアプリケーションはシンプルな復旧ワークフローで十分であり、フェールオーバーを実行するかどうかの判断に複雑な監視ロジックを必要としないこと、また、(c) そのようなアプリケーションは一般的にコストの制限が厳しい、という条件を考慮して設計されました。上記のような条件に対応するため、下記のように簡略化を行っています。

1. セカンダリ データベースは、マイクロソフトが定義した「DR ペア」となる Azure リージョンに作成されます。DR ペアのリストはこちらのページ (英語) でご確認いただけます。

2. セカンダリ データベースはマスター データベースから閲覧可能ですが、フェールオーバー処理が完了するまで直接接続することはできません (オフライン セカンダリ)。

3. セカンダリ データベースは、読み取りアクセス不能のとき (オフラインのとき) には割引料金が適用されます。

4. フェールオーバー機能は、プライマリ データベースをホストしているデータ センターが長時間停止した場合に有効になります。この機能は、インシデントが発生してから 1 時間が経過すると有効になり、ポータルでは該当するサーバーの状態が “degraded” と表示されます。

5. 障害発生時、アプリケーションまたはお客様がフェールオーバーを開始せず、プライマリ データベースの場所がインシデント発生後 24 時間以内に復旧しなかった場合、標準地理レプリケーションが適用されているすべてのデータベースが自動的にセカンダリ データベースの場所にフェールオーバーされます。

次の図 1 は、標準地理レプリケーションの一般的な構成を示したものです。

図 1: DR ペアのリージョンにデータベースのオフライン セカンダリを設定可能

この図に示すように、標準地理レプリケーションの目的は、あるリージョン内の Azure SQL Database で大規模な障害が発生した場合にデータベースを復旧することです。この目的であれば、より強力なアクティブ地理レプリケーション機能の一部を使用するだけでも達成できます。ただ、アクティブ地理レプリケーションで対応可能なシナリオの中には、標準地理レプリケーションでは対応できないシナリオがあります。次の表に、両機能の相違点をまとめました。

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

Premium のデータベースでアクティブ地理レプリケーションではなく標準地理レプリケーションを使用するケース

Premium レベルのデータベースの保護には、標準地理レプリケーションとアクティブ地理レプリケーションの両方、またはいずれかを使用できます。しかし、より強力なアクティブ地理レプリケーションではなく標準地理レプリケーションを使用するケースとは、どのような状況なのでしょうか。標準地理レプリケーションは簡単で低コストの災害復旧ソリューションとして設計されており、特に更新頻度が低いアプリケーションに適しています。Premium のデータベースで主に大規模な読み込み処理中心のワークロードが実行されている場合、標準地理レプリケーションが適していることもあります。標準地理レプリケーションでは、セカンダリ データベースの場所を指定すること、セカンダリ データベース (最大 4 つ) に読み取りアクセスすること、そしてフェールオーバーのタイミングと場所を完全に管理することができません。ただし、その代わりに監視機能とフェールオーバーのワークフローの管理をマイクロソフトが行うため、お客様はこれらを簡略化できます。1 つの Premium データベースでいずれかの機能のみを選択する必要はなく、災害復旧ソリューションとして標準地理レプリケーションでオフラインのセカンダリを作成し、さらに読み込み処理の負荷が高い場合に備えて負荷分散を行うために読み込み可能なセカンダリを 1 つまたは複数作成することも可能です。

データベースのフェールオーバー

標準地理レプリケーションは、データ層で障害が発生した場合を想定した災害復旧ソリューションです。プライマリをホストしているリージョンで Azure SQL Database のサービスが停止した場合にのみ、お客様はペアのリージョンのセカンダリへのフェールオーバーを開始できます。標準地理レプリケーションでは、アプリケーション層のサービス停止によるデータベースの手動フェールオーバーはサポートされていません。アクティブ地理レプリケーションでは、こうした場合に必要となる、フェールオーバーを実行するタイミングと場所を制御できます。

あるリージョンで長時間にわたるサービス停止が発生した場合、マイクロソフトが標準地理レプリケーションの対象になっているすべてのデータベースに対してフェールオーバーを有効にします。このサービスでは、フェールオーバーが必要かどうかをインシデント発生後 1 時間以内に決定することを目標としています。いったんサービスが有効になると、セカンダリ データベースとの地理レプリケーションの関係が解消され、実際にフェールオーバーが開始されます。この手法によって、フェールオーバーのロジックが簡略化されます。アプリケーションは、ただフェールオーバーが有効になるフラグを待機してフェールオーバーを実行するか、またはデータ センターが復旧するまで待機するだけです。アプリケーションを高可用性環境に最適化する必要があり、1 時間分のデータ損失を許容できる場合は、フェールオーバーが有効になってすぐにフェールオーバーを実施します。データ損失に対するアプリケーションの耐性が低い場合は、SQL Database サービスの復旧を待つという選択肢もあります。その場合はデータ損失は発生しません。ただし、プライマリのデータ センター (およびデータベース) が 24 時間以内に復旧しなかった場合、サービスによって自動的にフェールオーバーが開始されます。この場合、アプリケーションでデータ損失および 24 時間のダウンタイムが発生します。お客様がデータベースをフェールオーバーするか、自動的に実行されるのを待機するかにかかわらず、すべての場合において、アプリケーションがフェールオーバー先のデータベースに接続できるように再構成する必要があります。

フェールオーバーが完了したら、新しいプライマリも保護する必要があります。このサービスでは、フェールオーバーを有効化するプロセスの一部として、DR ペアの構成を更新して代替先のリージョンを設定します。これにより、地理レプリケーションが開始され、新しいプライマリが保護されます。新しいセカンダリのシード処理にはしばらく時間がかかるため (所要時間はデータベースのサイズによって異なります)、保護されていない状況でアプリケーションを操作するリスクを許容してでもシード期間中に可用性を復元するかを決定する必要があります。最も安全性の高い方法は、フェールオーバー先のデータベースが新しいセカンダリで保護されるまで待機した後にアプリケーションを有効化することです。シード処理が終了した後の DR 構成は、図 2 のようになります。

図 2: フェールオーバー後は、更新された DR ペアを使用してアプリケーションが新しいセカンダリ データベースを作成

災害復旧テスト

データベースのフェールオーバーはデータを扱う処理であり、中断を伴うので、定期的にフェールオーバーのワークフローのテストを実施してアプリケーションの対応状況を確認する必要があります。このプロセスは災害復旧テストと呼ばれます。技術の実践としてよい機会ですが、それだけではなく、コンプライアンス認定の一環としても業界内の多くのセキュリティ標準で必須のプロセスとなっています。通常の状態ではオフラインのセカンダリからのフェールオーバーは有効化されていませんが、プライマリ データベースの地理レプリケーションを停止すると、災害復旧のワークフロー全体のテストを実施できます。停止時点でプライマリがアクティブな場合、プライマリでコミット済みでありながらまだセカンダリに複製されていないトランザクションは失われます。停止後はセカンダリに完全にアクセスできるようになり、アプリケーションは新しいプライマリとして使用できるようになります。データを損失する可能性があることと、テスト中はプライマリが保護されないことを考慮すると、運用環境のデータベースで災害復旧テストを実施することは推奨されません。その代わりに、同一リージョン内にテスト用のデータベース コピーを作成し、そのコピーのオフライン セカンダリを作成して、それらのデータベースをテスト環境としてアプリケーションのフェールオーバーのワークフローを確認することをお勧めします。

管理ツール

標準地理レプリケーションでは、アクティブ地理レプリケーションで使用可能な REST API の一部を使用することができます。標準地理レプリケーションの管理は、この API を使用するか、PowerShell コマンドレットを使用するか、または Azure 管理ポータルを使用して行います。この機能はまだプレビュー段階なので、まず Azure SQL Database の新しいサービス レベルのプレビューにサインアップする必要があります。標準地理レプリケーションを有効化する最も簡単な方法は、図 3 に示すように、Azure 管理ポータルで [GEO-REPLICATION] タブを使用する方法です。

図 3: Azure 管理ポータルで地理レプリケーションのオフライン セカンダリを作成し、状態を監視

地理レプリケーションはいつでも無効化できます。それには 2 つの方法があり、1 つはプライマリ データベースの地理レプリケーションを終了すること、もう 1 つはセカンダリ データベースをダウンさせることです。前者は、誤って操作が開始されたときに中止する場合に便利です。セカンダリ データベースのシード処理が完了する前に無効化された場合は、セカンダリ データベースには課金されません。シード処理完了後に無効化された場合は、セカンダリとして使用されたデータベースを個別に削除する必要があり、また該当するデータベースの使用料金が日割で課金されます。後者の場合、1 つの手順を実行するだけで自動的に地理レプリケーションが終了し、セカンダリ データベースも終了して課金対象から除外されます。

まとめ

標準地理レプリケーションは、更新頻度が比較的低いアプリケーションを対象とした強力な災害復旧ソリューションとしてお使いいただけます。アクティブ地理レプリケーションほどの柔軟性はありませんが、マイクロソフトでは幅広い分野のアプリケーションのニーズに対応していると考えています。この機能について、皆様のご意見をお待ちしております。新しいサービス レベルのプレビューにサインアップし、標準地理レプリケーションをお試しのうえ、お気軽にご意見をお寄せください。また、さらに詳細な内容についてはこちらの記事 (英語) をご覧ください。