適用対象:
Azure SQL DatabaseMicrosoft Fabric SQL Database
Azure SQL データベースのビジネス継続性 とは、可用性、高可用性、ディザスター リカバリーを提供することで、中断が発生した場合でもビジネスを継続できるメカニズム、ポリシー、手順を指します。
可用性を最大化し、より高いビジネス継続性を実現するための規範的な推奨事項については、次を参照してください。
ほとんどの場合、クラウド環境で発生する可能性がある破壊的なイベントは SQL Database によって処理されて、アプリケーションとビジネス プロセスの実行が維持されます。 ただし、次のようないくつかの破壊的なイベントがあり、軽減には時間がかかる場合があります。
- ユーザーが誤ってテーブルの行を削除または更新した。
- 悪意のある攻撃者がデータの削除やデータベースの削除に成功した。
- 致命的な自然災害イベントにより、データセンターまたは可用性ゾーンまたはリージョンがダウンします。
- 構成の変更、ソフトウェアのバグ、ハードウェアの障害によって発生するまれなデータセンター、可用性ゾーン、またはリージョン全体の停止。
高可用性
Azure SQL データベースには、ソフトウェアまたはハードウェアの障害から保護する、回復性と信頼性に関する主要な保証が付属しています。 データベースのバックアップは自動化されており、破損や偶発的な削除からデータを保護します。 サービスとしてのプラットフォーム (PaaS) として、Azure SQL データベースサービスは、業界をリードする可用性 SLA が 99.99% の既製機能として可用性を提供します。
Azure クラウド環境で高可用性を実現するには、 ゾーンの冗長性を有効にします。 ゾーンの冗長性により、データベースまたはエラスティック プールは Azure 可用性ゾーン を使用して、ゾーン障害に対する回復性を確保します。
- 多くの Azure リージョンでは可用性ゾーンが提供されます。可用性ゾーンは、独立した電源、冷却、ネットワーク インフラストラクチャを持つリージョン内のデータ センターのグループで区切られます。
- 可用性ゾーンは、1つのゾーンで障害が発生した場合に、他のゾーンでリージョンのサービス、容量、および高可用性を提供するように設計されています。
ゾーンの冗長性を有効にすると、データベースまたはエラスティック プールはゾーンハードウェアとソフトウェアの障害に対する回復性を持ち、復旧はアプリケーションに対して透過的になります。 高可用性が有効になっている場合、Azure SQL データベースサービスは 99.995% の高可用性 SLA を提供できます。
障害復旧
リージョン間で可用性と冗長性を高めるために、ディザスター リカバリー機能を有効にして、致命的なリージョン障害からデータベースをすばやく復旧できます。 Azure SQL データベースのディザスタリカバリのオプションは以下の通りです。
- アクティブgeoレプリケーションでは、プライマリデータベースの任意の地域に、継続的に同期された読み取り可能なセカンダリデータベースを作成できます。
- フェールオーバー グループでは、プライマリ データベースとセカンダリ データベースの間で継続的な同期を提供するだけでなく、論理サーバー上の一部またはすべてのデータベースのレプリケーションとフェールオーバーを別のリージョンのセカンダリ論理サーバーに管理することもできます。 フェールオーバー グループは、読み取り/書き込みおよび読み取り専用のリスナー エンドポイントを提供しますメイン変更されないため、フェールオーバー後にアプリケーションの接続文字列を更新する必要はありません。
- geo リストア を使用すると、任意の Azure リージョン内の既存のサーバーに新しいデータベースを作成してプライマリ リージョンのデータベースにアクセスできない場合に、geo レプリケートされたバックアップから復元することで、リージョンの障害から復旧できます。
次の表は、Azure SQL データベースの 2 つのディザスター リカバリー オプションであるアクティブ geo レプリケーションとフェールオーバー グループを比較したものです。
| アクティブ geo レプリケーション | フェールオーバー グループ | |
|---|---|---|
| プライマリとセカンダリの間の継続的なデータ同期 | はい | はい |
| 複数のデータベースを同時にフェールオーバーする | いいえ | はい |
| フェールオーバー後、接続文字列が変更されない | いいえ | はい |
| 読み取りスケールをサポートする | はい | はい |
| 複数のレプリカ | はい | いいえ |
| プライマリと同じリージョンに存在できる | はい | いいえ |
RTO と RPO
ビジネス継続性計画を開発するときは、破壊的なイベントが発生してから、アプリケーションが完全に復旧するまでの最大許容時間について理解します。 ディザスター リカバリーに関するビジネス要件を定量化する一般的な方法は次の 2 つです。
- 目標復旧時間 (RTO): 計画外の破壊的イベントが発生した後、アプリケーションが完全に回復するために必要な時間。
- 目標復旧ポイント (RPO): 計画外の破壊的イベントから許容できるデータ損失の時間量。
次の表で、各ビジネス継続性オプションの RPO と RTO の比較を示します。
| ビジネス継続性オプション | RTO (ダウンタイム) | RPO（データ損失） |
|---|---|---|
| 高可用性 (ゾーン冗長の使用) |
通常は、30 秒未満です。 | 0 |
| ディザスター リカバリー ( カスタマー マネージド フェールオーバー ポリシー またはアクティブ geo レプリケーションでのフェールオーバー グループの使用) |
通常は、60 秒未満です。 | 0 以上 (レプリケートされていない破壊的イベントの前のデータ変更によって異なります) |
ジオ復元を使用した災害復旧 |
通常は、Azure Storage のレプリケーションに依存してかかる時間は、数分または数時間です。 | 通常、分または時間 (データベース バックアップのサイズによって異なります) |
事業継続を提供する機能
データベースの観点からは、発生する可能性のある 4 つの主要な障害シナリオがあります。 次の表に、潜在的なビジネス中断シナリオを軽減するために使用できる SQL Database のビジネス継続性機能を示します。
| ビジネス中断シナリオ | ビジネス継続性に関係する機能 |
|---|---|
| データベースノードに影響を及ぼすローカルハードウェアまたはソフトウェアの障害。 | ローカルのハードウェアとソフトウェアの障害を軽減するために、Azure 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 レプリケーションなどの継続的データ同期オプションを使用して、フェールオーバー用のセカンダリ リージョンにレプリカを作成できます。 - ジオ リストアを使用するために、バックアップストレージの冗長性をジオ冗長バックアップストレージに設定します。 |
リージョンの障害に備える
使用するビジネス継続性機能に関係なく、セカンダリ データベースを別のリージョンに準備する必要があります。 適切に準備しないと、フェイルオーバーやリカバリーの後にアプリケーションをオンラインにするのにさらに時間がかかり、トラブルシューティングも必要になる可能性が高いため、RTO が遅れる可能性があります。 チェックリストに従って、リージョンの停止に備えるための副系システムを準備します。
同じ Azure リージョン内でデータベースを復元する
自動データベース バックアップを使用すると、過去の特定の時点にデータベースを復元できます。 この方法で、人的ミスによるデータ破損から復旧できます。 ポイントインタイム リストア (PITR) を使用すると、破損イベントの前のデータの状態を表す新しいデータベースを同じサーバーに作成できます。 復旧時間については、RTO と RPOを参照してください。
特定の時点への復元でサポートされる最大バックアップ保有期間がアプリケーションで十分でない場合は、長期リテンション期間 (LTR) ポリシーを構成して拡張できます。 詳細については、「長期保存」をご覧ください。
最小のダウンタイムでアプリケーションをアップグレードする
アプリケーションのアップグレードなど、メンテナンスのために、アプリケーションをオフラインにしなければならないことがあります。 SQL Database のアクティブ geo レプリケーションを使用して、クラウド アプリケーションのローリング アップグレードを管理できます。 geo レプリケーションでは、問題が発生した場合に復旧パスを提供することもできます。
スタンバイ レプリカを使用してコストを節約する
セカンダリ レプリカがディザスター リカバリー (DR) にのみ使用され、読み取りまたは書き込みワークロードがない場合は、新しいアクティブ geo レプリケーションリレーションシップを構成するときにデータベースをスタンバイに指定することで、ライセンス コストを節約できます。
詳細については、ライセンスフリー スタンバイ レプリカに関する説明を参照してください。