次の方法で共有

Azure SQL Database によるビジネス継続性の概要

  • [アーティクル]

適用対象: Azure SQL Database

この記事では、Azure SQL データベースの事業継続とディザスター リカバリー機能の概要について説明し、データの損失やインスタンスとアプリケーションが使用できなくなる可能性がある破壊的イベントからの復旧に関するオプションと推奨事項について説明します。 ユーザーまたはアプリケーション エラーがデータ整合性に影響を及ぼすとき、Azure Availability Zones またはリージョンでシステム停止が発生したとき、あるいはアプリケーションにメンテナンスが必要なときの対処方法について説明します。

概要

Azure SQL データベースのビジネス継続性 とは、可用性、高可用性、ディザスター リカバリーを提供することで、中断が発生した場合でもビジネスを継続できるメカニズム、ポリシー、手順を指します。

ほとんどの場合、クラウド環境で発生する可能性がある破壊的なイベントは SQL Database によって処理されて、アプリケーションとビジネス プロセスの実行が維持されます。 ただし、次のようないくつかの破壊的なイベントがあり、軽減には時間がかかる場合があります。

  • ユーザーが誤ってテーブルの行を削除または更新した。
  • 悪意のある攻撃者がデータの削除やデータベースの削除に成功した。
  • 致命的な自然災害イベントにより、データセンターまたは可用性ゾーンまたはリージョンがダウンします。
  • 構成の変更、ソフトウェアのバグ、またはハードウェア コンポーネントの障害によって発生する、まれなデータセンター、可用性ゾーン、またはリージョン全体の停止。

可用性

Azure SQL データベースには、ソフトウェアまたはハードウェアの障害から保護する、回復性と信頼性に関する主要な保証が付属しています。 データベースのバックアップは自動化されており、破損や偶発的な削除からデータを保護します。 サービスとしてのプラットフォーム (PaaS) として、Azure SQL データベースサービスは、業界をリードする可用性 SLA が 99.99% の既製機能として可用性を提供します。

高可用性

Azure クラウド環境で高可用性を実現するには、ゾーン冗長性を有効にして、データベースまたはエラスティック プールで可用性ゾーンを使用して、データベースまたはエラスティック プールがゾーン障害に対する回復性を確保します。 多くの Azure リージョンでは可用性ゾーンが提供されます。可用性ゾーンは、独立した電源、冷却、ネットワーク インフラストラクチャを持つリージョン内のデータ センターのグループで区切られます。 可用性ゾーンは、1 つのゾーンで障害が発生した場合に、リージョンのサービス、容量、および高可用性を再メインゾーンで提供するように設計されています。 ゾーンの冗長性を有効にすると、データベースまたはエラスティック プールはゾーンハードウェアとソフトウェアの障害に対する回復性を持ち、復旧はアプリケーションに対して透過的になります。 高可用性が有効になっている場合、Azure SQL データベースサービスは 99.995% の高可用性 SLA を提供できます。

障害復旧

リージョン間で可用性と冗長性を高めるために、ディザスター リカバリー機能を有効にして、致命的なリージョン障害からデータベースをすばやく復旧できます。 Azure SQL データベースのディザスタリカバリのオプションは以下の通りです。

  • アクティブgeoレプリケーションでは、プライマリデータベースの任意の地域に、継続的に同期された読み取り可能なセカンダリデータベースを作成できます。
  • フェールオーバー グループでは、プライマリ データベースとセカンダリ データベースの間で継続的な同期を提供するだけでなく、論理サーバー上の一部またはすべてのデータベースのレプリケーションとフェールオーバーを別のリージョンのセカンダリ論理サーバーに管理することもできます。 フェールオーバー グループは、読み取り/書き込みおよび読み取り専用のリスナー エンドポイントを提供しますメイン変更されないため、フェールオーバー後にアプリケーションの接続文字列を更新する必要はありません。
  • geo リストア を使用すると、任意の Azure リージョン内の既存のサーバーに新しいデータベースを作成してプライマリ リージョンのデータベースにアクセスできない場合に、geo レプリケートされたバックアップから復元することで、リージョンの障害から復旧できます。

次の表は、Azure SQL データベースの 2 つのディザスター リカバリー オプションであるアクティブ geo レプリケーションとフェールオーバー グループを比較したものです。

アクティブ geo レプリケーション フェールオーバー グループ
プライマリとセカンダリの間の継続的なデータ同期 はい はい
複数のデータベースを同時にフェールオーバーする いいえ はい
フェールオーバー後メイン接続文字列が変更されない いいえ はい
読み取りスケールをサポートする はい はい
複数のレプリカ はい いいえ
プライマリと同じリージョンに存在できる はい いいえ

事業継続を提供する機能

データベースの観点からは、発生する可能性のある 4 つの主要な障害シナリオがあります。 次の表に、潜在的なビジネス中断シナリオを軽減するために使用できる SQL Database のビジネス継続性機能を示します。

ビジネス中断シナリオ ビジネス継続性に関係する機能
データベースノードに影響を及ぼすローカルハードウェアまたはソフトウェアの障害。 ローカルのハードウェアとソフトウェアの障害を軽減するために、SQL Database には可用性アーキテクチャが組み込まれています。これにより、最大で 99.99% の可用性 SLA でこれらの障害からの自動復旧が保証されます。
通常はアプリケーションのバグや人的ミスによって発生するデータの破損または削除。 このような障害はアプリケーション固有であり、通常、データベース サービスでは検出できません。 SQL Database では、データ損失からビジネスを守るために、データベースの完全バックアップ (毎週)、データベースの差分バックアップ (12 時間または 24 時間ごと)、トランザクション ログのバックアップ (5 分から 10 分ごと) が自動的に作成されます。 どのサービス レベルでも、既定でバックアップは geo 冗長ストレージに 7 日間格納されます。 Basic を除くすべてのサービス レベルで、ポイントインタイム リストア(PITR) のために、構成可能なバックアップ保有期間 (最大 35 日間) がサポートされます。 サーバーが削除されていない場合、または長期保存 (LTR) を設定している場合は、削除したデータベースを削除した時点に復元できます。
まれなデータセンターまたは可用性ゾーンの停止。自然災害イベント、構成の変更、ソフトウェアのバグ、ハードウェア コンポーネントの障害が原因である可能性があります。 データセンターまたは可用性ゾーン レベルの停止を軽減するには、データベースまたはエラスティック プールのゾーン冗長性を有効にして、Azure Availability Zones を使用し、Azure リージョン内の複数の物理ゾーン間で冗長性を提供します。 ゾーン冗長性を有効にすると、最大 99.995% の高可用性 SLA で、データベースまたはエラスティック プールがゾーン障害に対する回復性を確保できます。
致命的な自然災害イベントによって引き起こされる可能性のある、すべての可用性ゾーンとそのデータセンターに影響を与えるまれ なリージョンの停止 。 リージョン全体の障害を軽減するには、次のいずれかのオプション
を使用してディザスター リカバリーを有効にします。 フェールオーバー グループ (推奨)やアクティブ geo レプリケーションなどの継続的データ同期オプションを使用して、フェールオーバー用のセカンダリ リージョンにレプリカを作成できます。
- geo リストアを使用するために、バックアップストレージの冗長性をジオ冗長バックアップストレージに設定します。

RTO と RPO

ビジネス継続性計画を開発するときは、破壊的なイベントが発生してから、アプリケーションが完全に復旧するまでの最大許容時間について理解します。 アプリケーションを完全に復旧するために必要な時間は、目標復旧時間 (RTO) と呼ばれます。 また、予期しない破壊的なイベントからの復旧中にアプリケーションが損失を許容できる最大データ更新 (期間) 量についても理解しなければなりません。 潜在的なデータ損失は、目標復旧時点 (RPO) と呼ばれます。

次の表で、各ビジネス継続性オプションの RPO と RTO の比較を示します。

ビジネス継続性オプション RTO: ダウンタイム RPO: データ損失なし
高可用性
(ゾーン冗長の使用)		 通常は、30 秒未満です。 0
ディザスター リカバリー
(顧客管理 フェールオーバー ポリシー でのフェールオーバー グループの使用またはアクティブ geo レプリケーション)		 通常は、60 秒未満です。 0
以上 (レプリケートされていない破壊的イベントの前のデータ変更によって異なります)

geo 復元を使用したディザスター リカバリー		 通常、分または時間 通常、分または時間

ビジネス継続性チェックリスト

可用性を最大化し、より高いビジネス継続性を実現するための規範的な推奨事項については、次を参照してください。

リージョンの停止に備える

使用するビジネス継続性機能に関係なく、セカンダリ データベースを別のリージョンに準備する必要があります。 適切に準備しないと、フェイルオーバーやリカバリーの後にアプリケーションをオンラインにするのにさらに時間がかかり、トラブルシューティングも必要になる可能性が高いため、RTO が遅れる可能性があります。 チェックリストに従って、リージョンの停止に備え、セカンダリを準備します。

同じ Azure リージョン内でデータベースを復元する

自動データベース バックアップを使用すると、過去の特定の時点にデータベースを復元できます。 この方法で、人的ミスによるデータ破損から復旧できます。 ポイントインタイム リストア(PITR)により、破損イベントが発生する前のデータの状態を表す新しいデータベースを同じサーバーに作成できます。 ほとんどのデータベースで、復元操作にかかる時間は 12 時間未満です。 非常に大規模なデータベースや非常にアクティブなデータベースの場合、復旧にはこれよりも長い時間がかかることがあります。 詳しくは、「データベース復旧」をご覧ください。

ポイントインタイム リストア のサポートされている最大バックアップ保持期間がアプリケーションに十分でない場合は、データベースの長期保有期間 (LTR) ポリシーを構成することで、保持期間を延長できます。 詳細については、「Long-term backup retention」(長期バックアップ リテンション) をご覧ください。

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

アプリケーションのアップグレードなど、メンテナンスのために、アプリケーションをオフラインにしなければならないことがあります。 アプリケーション アップグレードの管理 に関するページでは、アクティブ geo レプリケーションを使用してクラウド アプリケーションのローリング アップグレードを有効化し、アップグレード中のダウンタイムを最小限に抑え、問題が発生した場合の復旧パスを提供する方法について説明します。

スタンバイ レプリカを使用してコストを節約する

セカンダリ レプリカがディザスター リカバリー (DR) にのみ使用され、読み取りまたは書き込みワークロードがない場合は、新しいアクティブ geo レプリケーションリレーションシップを構成するときにデータベースをスタンバイに指定することで、ライセンス コストを節約できます。

詳細については、ライセンスフリー スタンバイ レプリカに関する説明を参照してください。

次のステップ

アプリケーション設計に関する考慮事項については、クラウド ディザスター リカバリー用のアプリケーション設計に関するページと、エラスティック プールのディザスター リカバリー戦略に関するページをご覧ください。

「Azure SQL Database のディザスター リカバリー ガイダンス」と「Azure SQL Database の高可用性とディザスター リカバリーのチェックリスト」をご覧ください。