Azure SQL Database によるビジネス継続性の概要Overview of business continuity with Azure SQL Database

Azure SQL Database でのビジネス継続性とは、中断 (特にそのコンピューティング インフラストラクチャに対する) が発生した場合でもビジネス活動を続けることができるようにするメカニズム、ポリシー、手順を指します。Business continuity in Azure SQL Database refers to the mechanisms, policies, and procedures that enable your business to continue operating in the face of disruption, particularly to its computing infrastructure. ほとんどの場合、Azure SQL Database はクラウド環境で発生する可能性がある破壊的なイベントを処理し、アプリケーションとビジネス プロセスの実行を維持します。In the most of the cases, Azure SQL Database will handle the disruptive events that might happen in the cloud environment and keep your applications and business processes running. ただし、次のような SQL Database では自動的に対処できない破壊的なイベントがあります。However, there are some disruptive events that cannot be handled by SQL Database automatically such as:

  • ユーザーが誤ってテーブルの行を削除または更新した。User accidentally deleted or updated a row in a table.
  • 悪意のある攻撃者がデータの削除やデータベースの削除に成功した。Malicious attacker succeeded to delete data or drop a database.
  • 地震により停電が発生し、データ センターが一時的に利用不可になった。Earthquake caused a power outage and temporary disabled data-center.

この概要では、Azure SQL Database に用意されているビジネス継続性と障害復旧の機能について説明し、This overview describes the capabilities that Azure SQL Database provides for business continuity and disaster recovery. データ損失につながる、またはデータベースやアプリケーションを使用不能状態に追い込む破壊的なイベントから復旧するためのオプション、推奨事項、およびチュートリアルについて説明します。Learn about options, recommendations, and tutorials for recovering from disruptive events that could cause data loss or cause your database and application to become unavailable. ユーザーまたはアプリケーション エラーがデータ整合性に影響を及ぼすとき、Azure リージョンでシステム停止が発生したとき、あるいはアプリケーションにメンテナンスが必要なときの対処方法について説明します。Learn what to do when a user or application error affects data integrity, an Azure region has an outage, or your application requires maintenance.

ビジネス継続性を提供するときに使用できる SQL Database の機能SQL Database features that you can use to provide business continuity

データベースの観点からは、発生する可能性のある 4 つの主要な障害シナリオがあります。From a database perspective, there are four major potential disruption scenarios:

  • ディスク ドライブの障害など、データベース ノードに影響するローカルなハードウェアまたはソフトウェアの障害。Local hardware or software failures affecting the database node such as a disk-drive failure.
  • 通常はアプリケーションのバグや人的ミスによって発生するデータの破損または削除。Data corruption or deletion typically caused by an application bug or human error. このような障害はアプリケーション固有であり、通常、データベース サービスでは検出できません。Such failures are application-specific and typically cannot be detected by the database service.
  • 自然災害による可能性がある、データ センターの停止。Datacenter outage, possibly caused by a natural disaster. このシナリオでは、代替データ センターへのアプリケーションのフェールオーバーを含む何らかのレベルの geo 冗長性が必要です。This scenario requires some level of geo-redundancy with application failover to an alternate datacenter.
  • アップグレードまたはメンテナンスのエラー、インフラストラクチャの計画的なメンテナンスまたはアップグレードの間に予期しない問題が発生したときは、以前のデータベースの状態に迅速にロールバックすることが必要な場合があります。Upgrade or maintenance errors, unanticipated issues that occur during planned infrastructure maintenance or upgrades may require rapid rollback to a prior database state.

ローカルのハードウェアとソフトウェアの障害を軽減するために、SQL Database には高可用性アーキテクチャが組み込まれています。これにより、最大で 99.995% の可用性 SLA でこれらの障害からの自動復旧が保証されます。To mitigate the local hardware and software failures, SQL Database includes a high availability architecture, which guarantees automatic recovery from these failures with up to 99.995% availability SLA.

SQL Database では、データ損失からビジネスを守るために、データベースの完全バックアップ (毎週)、データベースの差分バックアップ (12 時間ごと)、およびトランザクション ログのバックアップ (5 分から 10 分ごと) が自動的に作成されます。To protect your business from data loss, SQL Database automatically creates full database backups weekly, differential database backups every 12 hours, and transaction log backups every 5 - 10 minutes . バックアップは、すべてのサービス レベルで少なくとも 7 日間 RA-GRS ストレージに保存されます。The backups are stored in RA-GRS storage for at least 7 days for all service tiers. Basic を除くすべてのサービス レベルで、ポイントインタイム リストアのために、構成可能なバックアップ保有期間 (最大 35 日間) がサポートされます。All service tiers except Basic support configurable backup retention period for point-in-time restore, up to 35 days.

また SQL Database には、予期しないさまざまなシナリオを軽減するために使用できるビジネス継続性機能がいくつか用意されています。SQL Database also provides several business continuity features, that you can use to mitigate various unplanned scenarios.

同じ Azure リージョン内でデータベースを復旧するRecover a database within the same Azure region

自動データベース バックアップを使用すると、過去の特定の時点にデータベースを復元できます。You can use automatic database backups to restore a database to a point in time in the past. この方法で、人的ミスによるデータ破損から復旧できます。This way you can recover from data corruptions caused by human errors. ポイントインタイム リストアにより、破損イベントが発生する前のデータの状態を表す新しいデータベースを同じサーバーに作成できます。The poin-in-time restore allows you to create a new database in the same server that represents the state of data prior to the corrupting event. ほとんどのデータベースで、復元操作にかかる時間は 12 時間未満です。For most databases the restore operations takes less than 12 hours. 非常に大規模なデータベースや非常にアクティブなデータベースの場合、復旧にはこれよりも長い時間がかかることがあります。It may take longer to recover a very large or very active database. 復旧時間について詳しくは、データベースの復旧時間に関するページをご覧ください。For more information about recovery time, see database recovery time.

ポイントインタイム リストア (PITR) のサポートされている最大バックアップ保有期間がアプリケーションにとって十分でない場合は、データベースの長期保有期間 (LTR) ポリシーを構成することで、保有期間を延長できます。If the maximum supported backup retention period for point-in-time restore (PITR) is not sufficient for your application, you can extend it by configuring a long-term retention (LTR) policy for the database(s). 詳細については、「Long-term backup retention」(長期バックアップ リテンション) をご覧ください。For more information, see Long-term backup retention.

geo レプリケーションとフェールオーバー グループを比較するCompare geo-replication with failover groups

自動フェールオーバー グループにより、geo レプリケーションのデプロイと使用が簡略化され、次の表に示す追加機能が追加されます。Auto-failover groups simplify the deployment and usage of geo-replication and add the additional capabilities as described in the following table:

geo レプリケーションGeo-replication フェールオーバー グループFailover groups
自動フェールオーバーAutomatic failover いいえNo はいYes
複数のデータベースを同時にフェールオーバーするFail over multiple databases simultaneously いいえNo はいYes
フェールオーバー後に接続文字列を更新するUpdate connection string after failover はいYes いいえNo
Managed Instance のサポートManaged instance supported いいえNo はいYes
プライマリと同じリージョンに存在できるCan be in same region as primary はいYes いいえNo
複数のレプリカMultiple replicas はいYes いいえNo
読み取りスケールをサポートするSupports read-scale はいYes はいYes
     

既存のサーバーにデータベースを復旧するRecover a database to the existing server

まれではありますが、Azure データ センターが停止することもあります。Although rare, an Azure data center can have an outage. 停止が発生すると、ビジネスが中断します。この中断はわずか数分で解消されることもありますが、数時間に及ぶ場合もあります。When an outage occurs, it causes a business disruption that might only last a few minutes or might last for hours.

  • オプションの 1 つは、データ センターの停止が終了し、データベースがオンラインに戻るのを待つことです。One option is to wait for your database to come back online when the data center outage is over. このオプションは、オフラインのデータベースが許容されるアプリケーションで有効です。This works for applications that can afford to have the database offline. たとえば、常時作業する必要のない開発プロジェクトや無料試用版がこれに該当します。For example, a development project or free trial you don't need to work on constantly. また、データ センターが停止したときに、復旧までの時間を予測できないため、当面はデータベースが必要ない場合にのみ使用できます。When a data center has an outage, you do not know how long the outage might last, so this option only works if you don't need your database for a while.
  • もう 1 つのオプションは、geo 冗長データベース バックアップ (geo リストア) を使用して、任意の Azure リージョン内の任意のサーバーにデータベースを復元する方法です。Another option is to restore a database on any server in any Azure region using geo-redundant database backups (geo-restore). geo リストアではソースとして geo 冗長バックアップが使用され、障害によってデータベースまたはデータセンターにアクセスできない場合でも、geo リストアを使用してデータベースを復旧できます。Geo-restore uses a geo-redundant backup as its source and can be used to recover a database even if the database or datacenter is inaccessible due to an outage.
  • 最後に、アクティブ geo レプリケーションを使用した geo セカンダリか、または 1 つまたは複数のデータベースの自動フェールオーバー グループのどちらかを構成している場合は、障害からすばやく復旧できます。Finally, you can quickly recover from an outage if you have configured either geo-secondary using active geo-replication or an auto-failover group for your database or databases. 選択するテクノロジに応じて、手動または自動フェールオーバーを使用できます。Depending on your choice of these technologies, you can use either manual or automatic failover. フェールオーバーそのものにかかる時間はほんの数秒ですが、サービスをアクティブにするために少なくとも 1 時間はかかります。While failover itself takes only a few seconds, the service will take at least 1 hour to activate it. これは、機能停止の規模に見合ったフェールオーバーを確実に行ううえで必要な時間です。This is necessary to ensure that the failover is justified by the scale of the outage. また、非同期レプリケーションの特性上、フェールオーバーによって少量のデータが失われることがあります。Also, the failover may result in small data loss due to the nature of asynchronous replication.

ビジネス継続性計画を開発するときは、破壊的なイベントが発生してから、アプリケーションが完全に復旧するまでの最大許容時間について理解する必要があります。As you develop your business continuity plan, you need to understand the maximum acceptable time before the application fully recovers after the disruptive event. アプリケーションを完全に復旧するために必要な時間は、目標復旧時間 (RTO) と呼ばれます。The time required for application to fully recover is known as Recovery time objective (RTO). さらに、予期しない破壊的なイベントからの復旧中にアプリケーションが損失を許容できる最大データ更新 (期間) 量についても理解しなければなりません。You also need to understand the maximum period of recent data updates (time interval) the application can tolerate losing when recovering from an unplanned disruptive event. 潜在的なデータ損失は、目標復旧時点 (RPO) と呼ばれます。The potential data loss is known as Recovery point objective (RPO).

復旧方法によって、提供される RPO と RTO のレベルは異なります。Different recovery methods offer different levels of RPO and RTO. 完全なアプリケーション復旧を達成するために、特定の復旧方法を選択することも、複数の方法を組み合わせて使用することもできます。You can choose a specific recovery method, or use a combination of methods to achieve full application recovery. 次の表で、各復旧オプションの RPO と RTO の比較を示します。The following table compares RPO and RTO of each recovery option. 自動フェールオーバー グループにより、geo レプリケーションのデプロイと使用が簡略化され、次の表に示す追加機能が追加されます。Auto-failover groups simplify the deployment and usage of geo-replication and adds the additional capabilities as described in the following table.

復旧方法Recovery method RTORTO RPORPO
Geo レプリケーション バックアップからの geo リストアGeo-restore from geo-replicated backups 12 時間12 h 1 時間1 h
自動フェールオーバー グループAuto-failover groups 1 時間1 h 5 秒5 s
手動のデータベース フェールオーバーManual database failover 30 秒30 s 5 秒5 s

注意

手動のデータベース フェールオーバーは、計画外モードを使用して、単一データベースをその geo レプリケートされたセカンダリにフェールオーバーすることを指します。Manual database failover refers to failover of a single database to its geo-replicated secondary using the unplanned mode. 自動フェールオーバーの RTO と RPO について詳しくは、この記事の前出の表を参照してください。See the table earlier in this article for details of the auto-failover RTO and RPO.

自動フェールオーバー グループは、アプリケーションが次のいずれかの条件を満たす場合に使用します。Use auto-failover groups if your application meets any of these criteria:

  • ミッション クリティカルである。Is mission critical.
  • サービス レベル アグリーメント (SLA) で 12 時間以上のダウンタイムが許可されていない。Has a service level agreement (SLA) that does not allow for 12 hours or more of downtime.
  • ダウンタイムによって財務責任が発生する。Downtime may result in financial liability.
  • データの変更頻度が高く、1 時間分のデータが失われることも許されない。Has a high rate of data change and 1 hour of data loss is not acceptable.
  • アクティブ geo レプリケーションの追加コストが、潜在的な財務責任と関連するビジネス損失を下回る。The additional cost of active geo-replication is lower than the potential financial liability and associated loss of business.

アプリケーションの要件に応じて、データベース バックアップとアクティブ geo レプリケーションを組み合わせて使用できます。You may choose to use a combination of database backups and active geo-replication depending upon your application requirements. これらのビジネス継続性機能を使用したスタンドアロン データベースおよびエラスティック プールの設計に関する考慮事項については、クラウド ディザスター リカバリー用のアプリケーション設計に関するページとエラスティック プールのディザスター リカバリー戦略に関するページをご覧ください。For a discussion of design considerations for stand-alone databases and for elastic pools using these business continuity features, see Design an application for cloud disaster recovery and Elastic pool disaster recovery strategies.

以下のセクションでは、データベース バックアップまたは アクティブ geo レプリケーションのいずれかを使用して復旧する手順の概要について説明します。The following sections provide an overview of the steps to recover using either database backups or active geo-replication. 要件の計画、復旧後の手順、障害をシミュレートしてディザスター リカバリー訓練を実施する方法など、詳細な手順については、障害からの SQL Database 復旧に関するページをご覧ください。For detailed steps including planning requirements, post recovery steps, and information about how to simulate an outage to perform a disaster recovery drill, see Recover a SQL Database from an outage.

障害に備えるPrepare for an outage

使用するビジネス継続性機能に関係なく、次の操作を行う必要があります。Regardless of the business continuity feature you use, you must:

  • サーバー レベルの IP ファイアウォール規則、ログイン、マスター データベース レベルのアクセス許可など、ターゲット サーバーを特定して準備します。Identify and prepare the target server, including server-level IP firewall rules, logins, and master database level permissions.
  • クライアントとクライアント アプリケーションを、新しいサーバーにリダイレクトする方法を決めますDetermine how to redirect clients and client applications to the new server
  • 監査の設定、アラートなど、他の依存関係を文書化しますDocument other dependencies, such as auditing settings and alerts

準備が不十分な状態で、フェールオーバーまたはデータベースの復旧後にアプリケーションをオンラインにすると、余計な時間がかかり、負荷がかかったときにトラブルシューティングが必要になる場合があります。良くない組み合わせです。If you do not prepare properly, bringing your applications online after a failover or a database recovery takes additional time and likely also require troubleshooting at a time of stress - a bad combination.

geo レプリケートされたセカンダリ データベースにフェールオーバーするFail over to a geo-replicated secondary database

復旧メカニズムとしてアクティブ geo レプリケーションまたは自動フェールオーバー グループを使用している場合は、自動フェールオーバー ポリシーを構成するか、または手動の計画外フェールオーバーを使用できます。If you are using active geo-replication or auto-failover groups as your recovery mechanism, you can configure an automatic failover policy or use manual unplanned failover. いったん開始すると、フェールオーバーによってセカンダリは新しいプライマリになり、新しいトランザクションを記録してクエリに応答できるようになります。失われるのは、レプリケートされなかった最小限のデータだけです。Once initiated, the failover causes the secondary to become the new primary and ready to record new transactions and respond to queries - with minimal data loss for the data not yet replicated. フェールオーバー プロセスの設計については、クラウド障害復旧用のアプリケーション設計に関するページをご覧ください。For information on designing the failover process, see Design an application for cloud disaster recovery.

注意

データ センターがオンラインに戻ると、古いプライマリは自動的に新しいプライマリに再接続し、セカンダリ データベースになります。When the data center comes back online the old primaries automatically reconnect to the new primary and become secondary databases. プライマリを元のリージョンに再配置する場合は、計画されたフェールオーバーを手動で開始することができます (フェールバック)。If you need to relocate the primary back to the original region, you can initiate a planned failover manually (failback).

geo リストアを実行するPerform a geo-restore

geo 冗長ストレージ (既定で有効) で自動バックアップを使用している場合、データベースは geo リストアを使用して復旧できます。If you are using the automated backups with geo-redundant storage (enabled by default), you can recover the database using geo-restore. 通常、復旧は 12 時間以内に実行され、最大 1 時間分のデータ損失が発生します。これは、最後のログ バックアップが実行およびレプリケートされたタイミングによって決まります。Recovery usually takes place within 12 hours - with data loss of up to one hour determined by when the last log backup was taken and replicated. 復旧処理が完了するまで、データベースは、トランザクションを記録したり、クエリに応答したりすることはできません。Until the recovery completes, the database is unable to record any transactions or respond to any queries. なお、geo リストアでは最後の使用可能な一時点までしかデータベースを復元できません。Note, geo-restore only restores the database to the last available point in time.

注意

復旧されたデータベースにアプリケーションを切り替える前に、データ センターがオンラインに戻った場合は、復旧をキャンセルすることができます。If the data center comes back online before you switch your application over to the recovered database, you can cancel the recovery.

フェールオーバー後のタスク/復旧タスクを実行するPerform post failover / recovery tasks

復旧にどちらのメカニズムを使ったとしても、ユーザーおよびアプリケーションの動作を元に戻す前に、次の追加タスクを実行する必要があります。After recovery from either recovery mechanism, you must perform the following additional tasks before your users and applications are back up and running:

  • クライアントとクライアント アプリケーションを、新しいサーバーおよび復元されたサーバーにリダイレクトするRedirect clients and client applications to the new server and restored database
  • ユーザーが接続できるように、適切なサーバー レベルの IP ファイアウォール規則が適用されていることを確認する。または、データベース レベルのファイアウォールを使用して、適切な規則を有効にする。Ensure appropriate server-level IP firewall rules are in place for users to connect or use database-level firewalls to enable appropriate rules.
  • 適切なログインとマスター データベース レベルのアクセス許可が適切に指定されていることを確認する (または 包含ユーザーを使用する)Ensure appropriate logins and master database level permissions are in place (or use contained users)
  • 必要に応じて、監査を構成するConfigure auditing, as appropriate
  • 必要に応じて、アラートを構成するConfigure alerts, as appropriate

注意

フェールオーバー グループを使用している場合で、かつ読み取り/書き込みリスナーを使用してデータベースに接続している場合、フェールオーバー後のリダイレクトは、自動的かつアプリケーションに対して透過的に実行されます。If you are using a failover group and connect to the databases using the read-write lstener, the redirection after failover will happen automatically and transparently to the application.

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

アプリケーションのアップグレードなど、計画されたメンテナンスのために、アプリケーションをオフラインにしなければならないことがあります。Sometimes an application must be taken offline because of planned maintenance such as an application upgrade. アプリケーション アップグレードの管理 に関するページでは、アクティブ geo レプリケーションを使用してクラウド アプリケーションのローリング アップグレードを有効化し、アップグレード中のダウンタイムを最小限に抑え、問題が発生した場合の復旧パスを提供する方法について説明します。Manage application upgrades describes how to use active geo-replication to enable rolling upgrades of your cloud application to minimize downtime during upgrades and provide a recovery path if something goes wrong.

次の手順Next steps

スタンドアロン データベースおよびエラスティック プール用アプリケーション設計に関する考慮事項については、クラウド ディザスター リカバリー用のアプリケーション設計に関するページと Elastic Pool のディザスター リカバリー戦略に関するページをご覧ください。For a discussion of application design considerations for stand-alone databases and for elastic pools, see Design an application for cloud disaster recovery and Elastic pool disaster recovery strategies.