Azure SQL Database を使用した高可用性サービスの設計Designing highly available services using Azure SQL Database

Azure SQL Database の高可用性サービスを構築してデプロイするときは、フェールオーバー グループとアクティブ geo レプリケーションを使って、局地的な機能停止や致命的な障害に対する回復力を用意します。When building and deploying highly available services on Azure SQL Database, you use failover groups and active geo-replication to provide resilience to regional outages and catastrophic failures. また、セカンダリ データベースに高速復旧できます。It also enables fast recovery to the secondary databases. この記事では一般的なアプリケーション パターンを紹介したうえで、それぞれの選択肢の利点とトレードオフについて説明します。This article focuses on common application patterns and discusses the benefits and trade-offs of each option. エラスティック プールでのアクティブ geo レプリケーションについては、エラスティック プールのディザスター リカバリー戦略に関するページを参照してください。For information about active geo-replication with Elastic Pools, see Elastic Pool disaster recovery strategies.

シナリオ 1: 最小限のダウンタイムでのビジネス継続性のための 2 つの Azure リージョンの使用Scenario 1: Using two Azure regions for business continuity with minimal downtime

このシナリオのアプリケーションには次のような特徴があります。In this scenario the applications has the following characteristics:

  • アプリケーションは 1 つの Azure リージョンでアクティブですApplication is active in one Azure region
  • すべてのデータベース セッションで、データの読み取りおよび書き込みアクセス (RW) が必要ですAll database sessions require read and write access (RW) to data
  • 待機時間とトラフィック コストを減らすため、Web 層とデータ層を併置する必要がありますWeb tier and data tier must be collocated to reduce latency and traffic cost
  • 基本的に、このようなアプリケーションに対するビジネス リスクは、データの損失よりダウンタイムの方が高くなりますFundamentally, downtime is a higher business risk for these applications than data loss

このケースでは、すべてのアプリケーション コンポーネントをまとめてフェールオーバーする必要があるとき、地域ごとの障害に対処するようにアプリケーションのデプロイ トポロジを最適化します。In this case, the application deployment topology is optimized for handling regional disasters when all application components need to failover together. 次の図にこのトポロジを示します。The diagram below shows this topology. 地理的な冗長性の場合は、アプリケーションのリソースをリージョン A とリージョン B にデプロイします。ただし、リージョン B のリソースは、リージョン A で障害が発生するまで使われません。For geographic redundancy, the application’s resources are deployed to Region A and B. However, the resources in Region B are not utilized until Region A fails. データベース接続、レプリケーション、フェールオーバーを管理するため、2 つのリージョンの間にフェールオーバー グループを構成します。A failover group is configured between the two regions to manage database connectivity, replication and failover. 両方のリージョンの Web サービスを、読み取り/書き込みリスナー <フェールオーバー グループ名>.database.windows.net を介してデータベースにアクセスするように構成します (1)。The web service in both regions is configured to access the database via the read-write listener <failover-group-name>.database.windows.net (1). 優先順位によるルーティング方法を使うように Traffic Manager を設定します (2)。Traffic manager is set up to use priority routing method (2).

注意

Azure traffic manager は、あくまで例として使用しています。Azure traffic manager is used throughout this article for illustration purposes only. 優先順位によるルーティング方法に対応していればどのような負荷分散ソリューションを使ってもかまいません。You can use any load-balancing solution that supports priority routing method.

この構成の機能停止前の状態を示したのが次の図です。The following diagram shows this configuration before an outage:

シナリオ 1.

プライマリ リージョンで障害が発生すると、SQL Database サービスがプライマリ データベースにアクセスできないことを検出し、自動フェールオーバー ポリシーのパラメーターの基づいてセカンダリ リージョンへのフェールオーバーがトリガーされます (1)。After an outage in the primary region, the SQL Database service detects that the primary database is not accessible and triggers failover to the secondary region based on the parameters of the automatic failover policy (1). アプリケーションの SLA によっては、障害の検出からフェールオーバー発生までの時間を制御する猶予期間を構成できます。Depending on your application SLA, you can configure a grace period that controls the time between the detection of the outage and the failover itself. フェールオーバー グループがデータベースのフェールオーバーをトリガーする前に、Traffic Manager がエンドポイントのフェールオーバーを開始する可能性があります。It is possible that traffic manager initiates the endpoint failover before the failover group triggers the failover of the database. その場合、Web アプリケーションはデータベースにすぐに再接続できません。In that case the web application cannot immediately reconnect to the database. ただし、データベースのフェールオーバーが完了すると、再接続は自動的に成功します。But the reconnections will automatically succeed as soon as the database failover completes. 障害が発生したリージョンは復元されてオンラインに戻り、古いプライマリは新しいセカンダリとして自動的に再接続します。When the failed region is restored and back online, the old primary automatically reconnects as a new secondary. 次の図では、フェールオーバー後の構成を示します。The diagram below illustrates the configuration after failover.

注意

フェールオーバー後にコミットされたすべてのトランザクションは、再接続の間に失われます。All transactions committed after the failover are lost during the reconnection. フェールオーバーが完了した後、リージョン B にアプリケーションは、再接続し、ユーザー要求の処理を再開できます。After the failover is completed, the application in region B is able to reconnect and restart processing the user requests. Web アプリケーションとプライマリ データベースはどちらもリージョン B に存在するようになり、併置が維持されます。Both the web application and the primary database are now in region B and remain co-located. n>

シナリオ 1.

リージョン B の機能が停止した場合は、プライマリ データベースとセカンダリ データベースの間のレプリケーション プロセスは中断されますが、両者の間のリンクは維持されます (1)。If an outage happens in region B, the replication process between the primary and the secondary database gets suspended but the link between the two remains intact (1). Traffic Manager は、リージョン B への接続が失われたことを検出し、エンドポイントの Web アプリ 2 を "低下" としてマークします (2)。Traffic managed detects that connectivity to Region B is broken and marks the endpoint web app 2 as Degraded (2). このケースではアプリケーションのパフォーマンスは影響を受けませんが、データベースは保護されていない状態になり、続けてリージョン A で障害が発生するとデータ損失が起こる高いリスクがあります。The application's performance is not impacted in this case, but the database becomes exposed and therefore at higher risk of data loss in case region A fails in succession.

注意

ディザスター リカバリーのため、アプリケーションのデプロイ先を 2 つのリージョンに限定する構成にすることをお勧めします。For disaster recovery, we recommend the configuration with application deployment limited to two regions. これは、Azure で地理的に割り当てられるリージョンがほとんどの場合 2 つだけであるからです。This is because most of the Azure geographies have only two regions. この構成では、両方のリージョンで同時発生した致命的な障害からアプリケーションは保護されません。This configuration does not protect your application from a simultaneous catastrophic failure of both regions. 万一そのような障害が発生した場合は、geo リストア操作を使って、第 3 のリージョンのデータベースを復元することができます。In an unlikely event of such a failure, you can recover your databases in a third region using geo-restore operation.

停止していた機能が復旧すると、セカンダリ データベースがプライマリ データベースと自動的に再同期されます。Once the outage is mitigated, the secondary database automatically resynchronizes with the primary. 同期の間に、プライマリ データベースのパフォーマンスが低下することがあります。During synchronization, performance of the primary can be impacted. 具体的な影響は、フェールオーバー以降に新しいプライマリが取得したデータの量に依存します。The specific impact depends on the amount of data the new primary acquired since the failover. 次の図は、セカンダリ リージョンの機能が停止した場合の例です。The following diagram illustrates an outage in the secondary region:

シナリオ 1.

この設計パターンの主な 利点 は次のとおりです。The key advantages of this design pattern are:

  • 同じ Web アプリケーションがリージョン固有の構成なしで両方のリージョンにデプロイされ、フェールオーバーを管理するための追加ロジックは必要ありません。The same web application is deployed to both regions without any region-specific configuration and doesn’t require additional logic to manage failover.
  • アプリケーションとデータベースが常に併置されるので、フェールオーバーが Web アプリケーションのパフォーマンスに影響することはありません。Application performance is not impacted by failover as the web application and the database are always co-located.

主なトレードオフは、ほとんどの期間、リージョン B のアプリケーション リソースの使用率が低いことです。The main tradeoff is that the application resources in Region B are underutilized most of the time.

シナリオ 2: データが最大限に保存されるビジネス継続性のための Azure リージョンScenario 2: Azure regions for business continuity with maximum data preservation

この設計パターンは、以下の特性を持ったアプリケーションに最適な選択肢です。This option is best suited for applications with the following characteristics:

  • 少しのデータ損失も多大なビジネス リスクを招く。Any data loss is high business risk. データベースのフェールオーバーはあくまで、機能停止が致命的な障害によるものである場合の最終手段です。The database failover can only be used as a last resort if the outage is caused by a catastrophic failure.
  • アプリケーションは操作の読み取り専用または読み取り/書き込みモードをサポートし、一定時間は「読み取り専用モード」で機能します。The application supports read-only and read-write modes of operations and can operate in "read-only mode" for a period of time.

このパターンでは、読み取り/書き込み接続がタイムアウト エラーを受け取るようになったときにアプリケーションが読み取り専用モードに切り替わります。In this pattern, the application switches to read-only mode when the read-write connections start getting time-out errors. Web アプリケーションは両方のリージョンにデプロイされ、読み取り/書き込みリスナー エンドポイントへの接続と、読み取り専用リスナー エンドポイントへの別の接続が含まれます (1)。The Web Application is deployed to both regions and include a connection to the read-write listener endpoint and different connection to the read-only listener endpoint (1). Traffic Manager プロファイルは、優先順位によるルーティングを使う必要があります。The Traffic manager profile should use priority routing. 各リージョンのアプリケーション エンドポイントで、エンドポイントの監視を有効にする必要があります (2)。End point monitoring should be enabled for the application endpoint in each region (2).

この構成の機能停止前の状態を示したのが次の図です。The following diagram illustrates this configuration before an outage:

シナリオ 2.

Traffic Manager は、リージョン A への接続障害を検出すると、ユーザーのトラフィックをリージョン B のアプリケーション インスタンスに自動的に切り替えます。このパターンでは、データ消失の猶予期間を十分に高い値 (24 時間など) に設定することが重要です。When the traffic manager detects a connectivity failure to region A, it automatically switches user traffic to the application instance in region B. With this pattern, it is important that you set the grace period with data loss to a sufficiently high value, for example 24 hours. これにより、機能の停止がその期間内に対処された場合にデータ消失を防ぐことができます。It ensures that data loss is prevented if the outage is mitigated within that time. リージョン B の Web アプリケーションがアクティブになると、読み取り/書き込み操作が失敗するようになります。When the Web application in region B is activated the read-write operations start failing. その時点で、読み取り専用モードに切り替える必要があります (1)。At that point, it should switch to the read-only mode (1). このモードでは、要求が自動的にセカンダリ データベースにルーティングされます。In this mode the requests are automatically routed to the secondary database. 停止の原因が致命的な障害である場合は、通常、猶予期間内に軽減することはできません。If the outage is caused by a catastrophic failure, most likely it cannot be mitigated within the grace period. 期限が切れると、フェールオーバー グループはフェールオーバーをトリガーします。When it expires the failover group triggers the failover. その後、読み取り/書き込みリスナーが使用できるようになり、リスナーに対する接続は失敗しなくなります (2)。After that the read-write listener becomes available and the connections to it stop failing (2). 次の図は、復旧プロセスの 2 つのステージを示したものです。The following diagram illustrates the two stages of the recovery process.

注意

プライマリ リージョンの停止していた機能が猶予期間内に対処された場合、プライマリ リージョンの接続の復旧を Traffic Manager が検出し、ユーザー トラフィックをリージョン A のアプリケーション インスタンスに戻します。そのアプリケーション インスタンスはリージョン A のプライマリ データベースを使って読み取り/書き込みモードで再開し、運用されます (前の図を参照)。If the outage in the primary region is mitigated within the grace period, traffic manager detects the restoration of connectivity in the primary region and switches user traffic back to the application instance in region A. That application instance resumes and operates in read-write mode using the primary database in region A as illustrated by the previous diagram.

シナリオ 2.

リージョン B が停止した場合、Traffic Manager はリージョン B のエンドポイント web-app-2 の障害を検出し、"低下" としてマークします (1)。If an outage happens in region B, the traffic manager detects the failure of the end point web-app-2 in region B and marks it degraded (1). その間、フェールオーバー グループは読み取り専用リスナーをリージョン A に切り替えます (2)。In the meantime, the failover group switches the read-only listener to region A (2). この停止はエンド ユーザー エクスペリエンスに影響しませんが、停止中にプライマリ データベースは危険な状態になります。This outage does not impact the end user experience but the primary database is exposed during the outage. 次の図は、セカンダリ リージョンで障害が発生した場合の例です。The following diagram illustrates a failure in the secondary region:

シナリオ 2.

機能停止が対処されると、セカンダリ データベースが即時にプライマリと同期され、読み取り専用リスナーがリージョン B のセカンダリ データベースに切り戻されます。同期対象のデータの量によっては、プライマリのパフォーマンスが同期中やや低下する場合があります。Once the outage is mitigated, the secondary database is immediately synchronized with the primary and the read-only listener is switched back to the secondary database in region B. During synchronization performance of the primary could be slightly impacted depending on the amount of data that needs to be synchronized.

この設計パターンには次のようにいくつかの 利点があります。This design pattern has several advantages:

  • 一時的な機能停止の間、データ損失を防ぐことができる。It avoids data loss during the temporary outages.
  • ダウンタイムを左右するのは、Traffic Manager が接続障害を検出するのにかかる時間のみであり、その時間は設定によって変更可能。Downtime depends only on how quickly traffic manager detects the connectivity failure, which is configurable.

トレードオフは、アプリケーションは読み取り専用モードで動作できなければならないことです。The tradeoff is that the application must be able to operate in read-only mode.

シナリオ 3: データ損失がなくダウンタイムがほぼゼロでの、異なる地理的な場所へのアプリケーションの再配置Scenario 3: Application relocation to a different geography without data loss and near zero downtime

このシナリオのアプリケーションには次のような特徴があります。In this scenario the application has the following characteristics:

  • エンド ユーザーは地理的に異なる場所からアプリケーションにアクセスしますThe end users access the application from different geographies
  • アプリケーションには、最新の更新との完全な同期に依存しない読み取り専用のワークロードが含まれますThe application includes read-only workloads that do not depend on full synchronization with the latest updates
  • データへの書き込みアクセスは、大半のユーザーと地理的に同じ場所でサポートされる必要がありますWrite access to data should be supported in the same geography for majority of the users
  • エンド ユーザーのエクスペリエンスには読み取り待機時間が重要ですRead latency is critical for the end user experience

これらの要件を満たすには、データの参照や分析などの読み取り専用操作の場合はユーザーのデバイスが地理的に同じ場所にデプロイされているアプリケーションに常に接続することを保証する必要があります。一方、OLTP 操作は、ほとんどの時間は地理的に同じ場所で処理されます。In order to meet these requirements you need to guarantee that the user device always connects to the application deployed in the same geography for the read-only operations, such as browsing data, analytics etc. Whereas, the OLTP operations are processed in the same geography most of the time. たとえば、日中の OLTP 操作は地理的に同じ場所で処理されますが、それ以外の時間は地理的に異なる場所で処理されることがあります。For example, during the day time OLTP operations are processed in the same geography, but during the off hours they could be processed in a different geography. ほとんどのエンド ユーザー アクティビティが業務時間中に発生する場合は、ほとんどのユーザーのほとんどの時間について最適なパフォーマンスを保証できます。If the end user activity mostly happens during the working hours, you can guarantee the optimal performance for most of the users most of the time. 次の図に、このトポロジを示します。The following diagram shows this topology.

アプリケーションのリソースは、多くの使用需要がある各場所にデプロイする必要があります。The application’s resources should be deployed in each geography where you have substantial usage demand. たとえば、アプリケーションが米国、欧州連合、東南アジアでよく使われる場合は、これらのすべての場所にアプリケーションをデプロイする必要があります。For example, if your application is actively used in the United States, European Union and South East Asia the application should be deployed to all of these geographies. プライマリ データベースは、ある場所の業務時間が終わったら次の場所に動的に切り替わる必要があります。The primary database should be dynamically switched from one geography to the next at the end of the working hours. この方式は、"フォロー ザ サン" と呼ばれます。This method is called “follow the sun”. OLTP ワークロードは、常に、読み取り/書き込みリスナー <フェールオーバー グループ名>.database.windows.net を介してデータベースに接続します (1)。The OLTP workload always connects to the database via the read-write listener <failover-group-name>.database.windows.net (1). 読み取り専用ワークロードは、データベース サーバー エンドポイント <サーバー名>.database.windows.net を使ってローカル データベースに直接接続します (2)。The read-only workload connects to the local database directly using the databases server endpoint <server-name>.database.windows.net (2). Traffic Manager は、パフォーマンスによるトラフィック ルーティング方法で構成されます。Traffic manager is configured with the performance routing method. この方法は、エンド ユーザーのデバイスが最も近いリージョンの Web サービスに接続されるようにします。It ensures that the end user’s device is connected to the web service in the closest region. Traffic Manager は、各 Web サービス エンドポイントのエンドポイント監視を有効にして設定する必要があります (3)。Traffic manager should be set up with end point monitoring enabled for each web service end point (3).

注意

フェールオーバー グループの構成では、フェールオーバーに使われるリージョンを定義します。The failover group configuration defines which region is used for failover. 新しいプライマリは地理的に異なる場所にあるので、フェールオーバーが発生すると、影響を受けたリージョンがオンラインに戻るまで、OLTP ワークロードと読み取り専用ワークロード両方の待機時間が長くなります。Because the new primary is in a different geography the failover results in longer latency for both OLTP and read-only workloads until the impacted region is back online.

シナリオ 3.

1 日の最後に (たとえば、ローカル時刻で午後 11 時)、アクティブなデータベースを次のリージョン (北ヨーロッパ) に切り替える必要があります。At the end of the day (for example at 11PM local time) the active databases should be switched to the next region (North Europe). このタスクは、Azure のスケジュール サービスを使って完全に自動化できます。This task can be fully automated by using Azure scheduling service. このタスクには、次の手順が含まれます。The task involves the following steps:

  • フェールオーバー グループのプライマリ サーバーを、フレンドリ フェールオーバーを使って北ヨーロッパに切り替えます (1)Switch primary server in the failover group to North Europe using friendly failover (1)
  • 米国東部と北ヨーロッパの間のフェールオーバー グループを削除しますRemove the failover group between East US and North Europe
  • 同じ名前で、ただし北ヨーロッパとアジア太平洋の間に、新しいフェールオーバー グループを作成します (2)。Create a new failover group with the same name but between North Europe and East Asia (2).
  • このフェールオーバー グループに、北ヨーロッパのプライマリとアジア太平洋のセカンダリを追加します (3)。Add the primary in North Europe and secondary in East Asia to this failover group (3).

次の図は、予定されたフェールオーバー後の新しい構成を示しています。The following diagram illustrates the new configuration after the planned failover:

シナリオ 3.

たとえば、北ヨーロッパの機能が停止すると、フェールオーバー グループによってデータベースの自動フェールオーバーが開始され、結果として、アプリケーションはスケジュールより前に次のリージョンに移動されます (1)。If an outage happens in North Europe for example, the automatic database failover is initiated by the failover group, which effectively results in moving the application to the next region ahead of schedule (1). その場合、北ヨーロッパがオンラインに戻るまで、米国東部のみがセカンダリ リージョンとして残ります。In that case the US East is the only remaining secondary region until North Europe is back online. 残っている 2 つのリージョンが、ロールを切り替えることで、3 つの場所すべての顧客にサービスを提供します。The remaining two regions serve the customers in all three geographies by switching roles. それに応じて Azure Scheduler を調整する必要があります。Azure scheduler has to be adjusted accordingly. 残っているリージョンはヨーロッパから追加のユーザー トラフィックを受け取るため、アプリケーションのパフォーマンスは、追加の待機時間だけでなく、エンド ユーザー接続数の増加によっても影響を受けます。Because the remaining regions get additional user traffic from Europe, the application's performance is impacted not only by additional latency but also by an increased number of end user connections. 北ヨーロッパの停止していた機能が復旧すると、セカンダリ データベースは現在のプライマリ データベースと直ちに同期されます。Once the outage is mitigated in North Europe, the secondary database there is immediately synchronized with the current primary. 次の図は、北ヨーロッパの機能が停止した場合の例です。The following diagram illustrates an outage in North Europe:

シナリオ 3.

注意

ヨーロッパのエンド ユーザー エクスペリエンスが長い待機時間によって低下する時間を短縮できます。You can reduce the time when the end user’s experience in Europe is degraded by the long latency. そのためには、事前にアプリケーションのコピーをデプロイし、北ヨーロッパのオフライン アプリケーション インスタンスの代わりとして、別のローカル リージョン (西ヨーロッパ) にセカンダリ データベースを作成します。To do that you should proactively deploy an application copy and create the secondary database(s) in another local region (West Europe) as a replacement of the offline application instance in North Europe. 北ヨーロッパがオンラインに戻ったときは、西ヨーロッパを使い続けるか、または西ヨーロッパのアプリケーションのコピーを削除して北ヨーロッパを使うように戻すかを決定できます。When the latter is back online you can decide whether to continue using West Europe or to remove the copy of the application there and switch back to using North Europe,

この設計の主なメリットは、次のとおりです。The key benefits of this design are:

  • 読み取り専用のアプリケーション ワークロードは、常に最も近いリージョンのデータにアクセスします。The read-only application workload accesses data in the closets region at all times.
  • 読み取り/書き込みのアプリケーション ワークロードは、各場所の最も活動的な時間帯は、最も近いリージョンのデータにアクセスします。The read-write application workload accesses data in the closest region during the period of the highest activity in each geography
  • アプリケーションは複数のリージョンにデプロイされているので、1 つのリージョンの機能が失われても、大きなダウンタイムなしに維持できます。Because the application is deployed to multiple regions, it can survive a loss of one of the regions without any significant downtime.

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

  • リージョンが停止すると、その地理的な場所は長い待機時間の影響を受けます。A regional outage results in the geography to be impacted by longer latency. 読み取り/書き込みワークロードと読み取り専用ワークロードはどちらも、異なるリージョンのアプリケーションによって提供されます。Both read-write and read-only workloads is served by the application in a different geography.
  • 読み取り専用ワークロードは、各リージョンの異なるエンドポイントに接続する必要があります。The read-only workloads must connect to a different end point in each region.

ビジネス継続性計画: クラウド障害復旧用のアプリケーション設計を選択するBusiness continuity planning: Choose an application design for cloud disaster recovery

実際のクラウド障害復旧戦略では、対象アプリケーションのニーズに合わせて、これらの設計パターンを組み合わせたり拡張したりすることができます。Your specific cloud disaster recovery strategy can combine or extend these design patterns to best meet the needs of your application. 既に述べたように、選択すべき戦略は、利用者に提供する SLA とアプリケーションのデプロイ トポロジによって異なります。As mentioned earlier, the strategy you choose is based on the SLA you want to offer to your customers and the application deployment topology. 以下の表では、意思決定の目安として、復旧ポイントの目標 (RPO) と推定復旧時間 (ERT) に基づいてそれぞれの選択肢を比較しています。To help guide your decision, the following table compares the choices based on recovery point objective (RPO) and estimated recovery time (ERT).

パターンPattern RPORPO ERTERT
アクティブ/パッシブ デプロイとデータベース併置による障害復旧Active-passive deployment for disaster recovery with co-located database access 読み取り/書き込みアクセス = 5 秒未満Read-write access < 5 sec 障害検出時間 + DNS TLLFailure detection time + DNS TTL
アクティブ/アクティブ デプロイによるアプリケーション負荷分散Active-active deployment for application load balancing 読み取り/書き込みアクセス = 5 秒未満Read-write access < 5 sec 障害検出時間 + DNS TLLFailure detection time + DNS TTL
アクティブ/パッシブ デプロイによるデータ保存Active-passive deployment for data preservation 読み取り専用アクセス < 5 秒Read-only access < 5 sec 読み取り専用アクセス = 0Read-only access = 0
読み取り/書き込みアクセス = 0Read-write access = zero 読み取り/書き込みアクセス = 障害検出時間 + データ消失の猶予期間Read-write access = Failure detection time + grace period with data loss

次のステップNext steps