このページの本文へ

相次ぐAzure障害、サービス可用性を高めるHAとDRを解説

障害、サービス停止を回避するAzureのDR構成を知ろう

2017年04月03日 08時00分更新

文● 羽野三千世/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

Azure Storageのフェールオーバー

NEO:Azure Storageには、「GRS(地理冗長ストレージ)」、「RA-GRS(読み取りアクセス地理冗長ストレージ)」などいくつかの冗長化オプションがあります。

GRSでは、プライマリリージョンで3つのレプリカを持ちます。さらにペアになるセカンダリリージョン(東日本リージョンに対しては西日本リージョン、またはその逆)に非同期でレプリケーションを行い、セカンダリリージョンでも3つのレプリカを持ちます。リージョン内のレプリカへの書き込みは同期的に行われます。

リージョン間レプリケーションは非同期なので、プライマリリージョンでの更新がセカンダリリージョンにレプリケーションされるまでに遅延があります。GRSでは、15分未満の遅延を目標にしています。

GRSでは、通常時はセカンダリリージョンのストレージアカウントは読み書き不可です。Azureでは、特定のAzureリージョンのAzure Storageで大規模な障害が発生し、復旧に長時間かかると予想される場合に限り、マイクロソフトが、GRS(および後述のRA-GRS)が構成されたストレージアカウントのフェールオーバーを行います。フェールオーバーが行われた後は、セカンダリリージョン上のストレージアカウントが読み書き可能になります。

ただし、数時間程度のAzure Storage障害では、マイクロソフトはストレージアカウントのフェールオーバーを行いません。今回、東日本リージョン、西日本リージョンで発生した一連の障害でもフェールオーバーは行っていません。ユーザーが自分でフェールオーバーを実行できる機能を実装する計画がありますが、提供時期は未定です。

一方、より上位のオプションRA-GRSは、これまで説明したGRSの機能に加えて、通常時にセカンダリリージョンのストレージアカウントに読み取り専用でアクセスできます。

GRSの場合、プライマリリージョンでのAzure Storage障害や災害がおこっても、(マイクロソフトがフェールオーバーを行わない限りは)セカンダリリージョンでできることはありません。RA-GRSの場合、システムを読み取り専用にデグレードして、セカンダリリージョンでサービスを継続することができます。

また、セカンダリリージョンでRA-GRSのストレージアカウントのデータを、セカンダリリージョンに別途作成したストレージアカウントへコピーすることで、デグレードせずにサービスを提供することもできるでしょう。この場合、障害発生後にデータをコピーするのか、通常時に定常的に更新データをコピーするようにするか、データ量や更新頻度などをもとに検討する必要があります。

ASCII羽野:Azure Storageのフェールオーバーはめったに行われないのですね。マイクロソフトの公式サイト「Azure Storageの停止が発生した場合の対処方法」では、最初の選択肢として「復旧を待つ」が推奨されています。Azureストレージサービスの障害では、基本的には復旧またはフェールオーバーを待ち、数時間のサービス停止が許容されないシステムではセカンダリリージョンでサービス継続が可能な「RA-GRS」を選択しておくとよさそうです。

Azure SQL Databaseでは「アクティブ地理レプリケーション」でDR構成に

NEO:Azure SQL DatabaseのDRでは、「アクティブ地理レプリケーション」という機能を活用できます。

前述のように、Azure SQL Databaseの論理データベースは、特定のリージョン内に配置された1つのプライマリデータベースと3つ以上のセカンダリデータベースから構成されています。

アクティブ地理レプリケーションを使うと、プライマリの論理データベースが動作しているAzureリージョンとは別のリージョンに、最大4つのセカンダリ論理データベースを作成できます(同じリージョン内に作成も可能)。

Azure Storageと異なり、Azure SQL Databaseのアクティブ地理レプリケーションでは、新たなプライマリ論理データベースの指定(フェールオーバー)は、ユーザー自身がAzureポータル、PowerShell、REST APIなどを使って行うことができます。プライマリを死活監視し、障害や災害を検知したらデータベースのフェールオーバーを行う処理をユーザーが自分で実装することで、DRを実現できます。

アクティブ地理レプリケーションのレプリケーションは非同期で、5秒未満の遅延があります。そのため、フェールオーバーの際はプライマリで障害/災害が発生した直後5秒の更新が失われる可能性があります。

ASCII羽野:Azure SQL Databaseには、もともとアクティブ地理レプリケーションというDRのメニューが用意されているのですね。最後に、Azure App ServiceのDRについて教えてください。

カテゴリートップへ

本記事はアフィリエイトプログラムによる収益を得ている場合があります

アクセスランキング

  1. 1位

    ITトピック

    情シス人材不足でも「採用予定なし」中小企業の意見/“従業員発のSNS炎上”6割の企業が懸念/「SNS疲れ」利用を減らす効果的方法、ほか

  2. 2位

    ビジネス・開発

    「Gemini Enterprise」に大規模導入の波 ― SOMPO・NTTデータ・Skyが描く“エージェント企業”への進化

  3. 3位

    ITトピック

    北米での成長率がすごすぎる NinjaOneとはいったい何者だ?

  4. 4位

    Team Leaders

    Power AutomateでSharePointリストにある申請データ一覧をメール送信する方法

  5. 5位

    sponsored

    無線APにデザインは不要ですか? ブラックスケルトンモデルは今どきのオフィスにめちゃなじむんです

  6. 6位

    YouTube

    ぶっちゃけ、あのSaaSってどう!? 情シスがガチ格付け! 本当に使えるツールを決める最強SaaSティア決定戦!!

  7. 7位

    ビジネス・開発

    脱・巨大プルリクエスト GitHub公式の「スタック型プルリクエスト」が登場

  8. 8位

    TECH

    プロテクティブDNSでDNSをセキュリティ基盤へ 福岡大学でも「運用課題なし」の実績

  9. 9位

    デジタル

    異常検知からロボット走行、車両制御まで —— 現場を遠隔化・自動化するSORACOM活用のIoTソリューション

  10. 10位

    ビジネス・開発

    情シスは「フィジカルAI」にどう向き合うべきか 実用化に不可欠な“現場×AI×経営”の橋渡し役に

集計期間:
2026年08月04日~2026年08月10日
  • 角川アスキー総合研究所