SQL Database のアクティブ地理レプリケーションの詳細
このポストは、7 月 12 日に投稿した Spotlight on SQL Database Active Geo-Replication の翻訳です。
この記事は、ビジネス継続性と災害復旧について取り上げたシリーズ記事の第 1 弾です。初回であるこの記事では、ビジネス継続性の一般的なシナリオについて説明し、さらに SQL Database の Premium サービス レベルでご利用いただけるアクティブ地理レプリケーションの詳細についてご紹介します。アクティブ地理レプリケーションについてさらに詳しい情報を知りたい方は、情報量が豊富な Channel 9 のビデオ (英語) をご覧ください。Sasha Nosov と Scott Klein が、そのしくみや実際のビジネス シナリオへの応用について説明しています。
ビジネス継続性とは
ビジネス継続性とは、サービス中断が発生したとき (特にコンピューティング インフラストラクチャが原因の場合) に業務の運用を継続するためのしくみやポリシー、手順などのことを指します。
データベースという視点から見ると、サービス中断には主に次の 4 つの原因が考えられます。
- ローカルのハードウェアまたはソフトウェアの障害 : ディスク ドライブの障害などによりデータベース ノードが影響を受ける場合です。
- データの損失や消去 : 通常はアプリケーションの不具合や人為的なミスにより発生します。このような障害は本質的にはアプリケーション固有のものであり、インフラストラクチャでルールに従って自動的に検出したり軽減策をとることはできません。
- データセンターのサービス停止 : 自然災害などによって発生します。この場合、代替データセンターへのアプリケーションのフェールオーバーを伴う何らかの地理レプリケーションが必要です。
- アップグレードやメンテナンスでのエラー : 計画していたアップグレードやメンテナンスの際にアプリケーションやデータベースで予期しない問題が発生したときには、データベースを以前の状態に迅速にロールバックすることが必要な場合があります。
Azure SQL Database がビジネス継続性を確保するしくみ
Azure SQL Database は、堅牢な高可用性データベース サービスとして基礎から構築されたもので、常にデータベースのレプリカを 3 つ以上保持し、応答の前に少なくとも 2 つのレプリカに対して更新をコミットするシステムを使用しています。この高可用性システムにより、上記のシナリオのうち 1 つめのローカルのハードウェアおよびソフトウェアの障害は解決されます。
現在プレビューとして提供している新しいサービス レベルの Basic、Standard、Premium では、以下に示す他の 3 つの問題を解決する機能を提供し、次世代のビジネス継続性を実現しています。
データの損失や消去 : Basic、Standard、Premium の各レベルのデータベースでは、データベースを以前の状態に復元するセルフサービス型のポイントインタイム リストア機能がサポートされています。これにより、アプリケーションのエラーや人為的ミスによるデータの損失や消去からの保護が可能です。完全バックアップは毎週、差分バックアップは毎日、トランザクション ログのバックアップは 5 分ごとに実施されます。データベースのバックアップの保持期間は、Basic では 7 日間、Standard では 14 日間、Premium では 35 日間です。この機能では、最近削除されたものも含め、データベースを保持期間内の任意の時点に復元できます。
データセンターのサービス停止 : Basic、Standard、Premium の各サービス レベルでは、データベースに対して、他のリージョンに存在する他のデータセンターで復旧する必要のある長期的なデータセンターのサービス停止に対する保護が実施されます。地理冗長ソリューションには次の 3 種類があります。
- 地理リストア (Geo-restore) *: Basic、Standard、Premium の各サービス レベルで、最後に実施された日単位のバックアップの地理冗長コピーを使用できます。[*近日中にプレビューをリリース予定]
- 標準の地理レプリケーション*: Standard および Premium データベースでは、ローカルの高可用性システムを拡張して、対となるリージョンでセカンダリ レプリカを作成し、保守を行います。このセカンダリはオフラインで、データセンターで障害が発生しない限りアクセスできません。障害が発生した場合はオンラインになり、アプリケーションがフェールオーバーに使用できるようになります。[*近日中にプレビューをリリース予定]
- アクティブ地理レプリケーション: Premium データベースで提供するサービスで、データ損失のリスクを最小限に抑えると共に復旧時間も最短となる、最も高品質なソリューションです。これは標準の地理レプリケーションを拡張したもので、地理レプリケートされたセカンダリが最大で 4 つオンラインの状態で保持され、これらは常時使用できます。また、負荷分散を実行したり、レプリケートされたデータに世界中のどこからでも短いレイテンシでアクセスすることができます。アクティブ地理レプリケーションは、現在プレビューをご利用いただけます。
アップグレードやメンテナンスでのエラー : アクティブ地理レプリケーションを使用した場合に作成されるデータベースのコピーは常にレプリケーションが実施され、データベースやアプリケーションの更新やメンテナンスが行われる前の状態にすぐに固定できます。処理中または処理完了後に何らかのエラーが検出された場合は、このコピーにすばやく手軽にフォールバックできます。
各サービス レベルで使用可能なソリューションは異なりますが、データベースのサービス レベルは簡単にアップグレードやダウングレードができます。このため、たとえば、重要なアップグレードを行う前に Standard から Premium にアップグレードして、アクティブ地理レプリケーションを使用することもできます。アップグレード作業が完了した後は、データベースを元のレベルにダウングレードしてコストを抑えられます。
アクティブ地理レプリケーションの詳細
ここでは、アクティブ地理レプリケーションがどのような場面でビジネス継続性に有効かについて、そのしくみや活用方法を詳しく見ていきます。
図 1: Premium データベースでは、同一リージョンまたは異なるリージョンで最大 4 つの読み取り可能なセカンダリ レプリカが保持されます。
アクティブ地理レプリケーションのリレーションシップは、Azure 管理ポータル、PowerShell、REST API のそれぞれで作成および管理できます。ポータルでは、プライマリとセカンダリのそれぞれからレプリケーションのリレーションシップを管理できます。プライマリからは、各セカンダリのレプリケーションのステータスを監視できます。
図 2: Azure 管理ポータルでは最大で 4 つの地理レプリケーションのセカンダリを作成し、その状態を監視できます。
最大で 4 つの読み取り可能なセカンダリを、プライマリと同じ名前で、異なる場所に存在するサーバーに作成できます。セカンダリが最初に作成されるときには、その時点のプライマリの状態のままシードされます。いったん各セカンダリが最新の状態になると、その後はプライマリのコピーとして継続的に保守されます。他のすべてのデータベースと同様に、セカンダリ データベースは、通常の高可用性システムを使用してローカルで保護されています。
ローカルの高可用性レプリケーション モデルとは異なり、プライマリからセカンダリへの地理レプリケーションは非同期で行われます。プライマリに適用されたトランザクションはセカンダリにコピーされて適用されますが、この処理を待機する間にプライマリがブロックされることはありません。変更はバッファーに保存されるため、一時的な接続障害が発生したり、離れた場所にコピーするためにレイテンシが長い場合でも、レプリケーション システムは対応可能です。
セカンダリへのトランザクションの適用がプライマリのボトルネックにならないようにするには、セカンダリのパフォーマンスがプライマリと同等か、またはそれ以上である必要があります。
セカンダリは読み取り可能なので、独立した読み取り専用のワークロードをサポートしています。この機能により、複雑なクエリのワークロードの負荷を複数のデータベースに分散したり、アプリケーションがデータにアクセスしたときのレイテンシを世界中どこでも低く抑えることができます。
図 3: データセンターのサービス停止によりプライマリが影響を受けた場合、レプリケーションのリレーションシップが終了し、アプリケーションがセカンダリにフェールオーバーされます。
レプリケーションのリレーションシップは手動で管理されるため、任意の時点でリレーションシップを終了できます。プライマリから終了する場合は、即座に終了して保留中のトランザクションを破棄するか、または保留中のトランザクションをすべて適用した後に終了するかを選択できます。
データセンターのサービスが停止してプライマリに影響がある場合も、フェールオーバーは手動で行います。このため、フェールオーバーを実行するかどうか、およびどのタイミングで実行するかは管理者が決定できます。プライマリ データベースは使用できないため、この場合はセカンダリ データベースからリレーションシップを終了します。セカンダリからのリレーションシップの終了は常に即座に行われるため、プライマリが使用不能になった時点でまだコピーされていなかったトランザクションは失われます。データが失われる量は、プライマリで障害が発生した時点でどれほど活発にトランザクションが行われていたか、およびその接続でトランザクションのバッファー処理がどの程度行われていたかによります。レプリケーションのリレーションシップを終了するかどうかは、データ損失によって見込まれる損害とアプリケーションをバックアップすることによるメリットを考慮して決定します。
いったんセカンダリ データベースへのリレーションシップを終了すると、このデータベースは通常の読み書き可能なデータベースになります。この時点で、データベースに対するフル アクセスを所有するアプリケーションをフェールオーバーできます。各セカンダリはプライマリと同じ名前を持ちますが、個別のデータベースであり、異なるサーバーに存在するため、アプリケーションでは更新された接続文字列を再構成する必要があります。
フェールオーバー処理の管理が終了した後に、プライマリとして新しい本番用のデータベースに交換した以外は以前と同じ構成の地理レプリケーションのリレーションシップを再構築することがあります。この場合、使用しているアプリケーションとビジネス継続性のポリシーの要件となっている地理冗長性と負荷分散を必ず確保します。
図 4: セカンダリへの元のリレーションシップを終了した後は、新たに地理レプリケーションのリレーションシップを作成して、新しいプライマリを保護すると共に負荷分散の各要件をサポートする必要があります。
アクティブ地理レプリケーションは、さまざまなアプリケーションのアーキテクチャのパターンと統合可能です。この場合、どのレイヤーとコンポーネントが最もリスクが高く、どのコンポーネントが地理的に分散されるかがそれぞれのパターンで異なります。詳細についてはこちらの記事を参照してください。
まとめ
アクティブ地理レプリケーションは、強力な地理レプリケーション機能でデータセンターのサービス停止からデータベースを保護するだけではなく、他のビジネス継続性のシナリオにも有効です。アクティブ地理レプリケーションは、現在 Premium データベースでプレビューをご利用いただけます。
SQL Database のビジネス継続性の詳細については、アクティブ地理レプリケーションの記事をお読みいただくか、アクティブ地理レプリケーションでビジネスを保護する方法について説明している Sasha Nosov と Scott Klein の Channel 9 ビデオ (英語) をご覧ください。
アクティブ地理レプリケーション、およびこの機能によって可能となるビジネス継続性機能をご利用いただくには、新しいサービス レベルのプレビュー機能にサインアップしていただく必要があります。ぜひこの機能をお試しいただき、ご意見をお聞かせください。