プロに教わるAzure設計運用のベストプラクティス 第1回

仮想マシン単体のSLAから、高可用性、災害復旧（DR）構成やバックアップの要点まで

Azureで実現する高可用性の“勘どころ”と構築のポイント

災害復旧：Azure間でのAzure Site Recovery（ASR）

　次に、災害復旧の構成をとる手法としてAzureで広く採用されている「Azure Site Recovery（ASR）」を紹介しよう。

　ASRは、メインサイト（メインリージョン）に配置された仮想マシンのディスクイメージを、定期的にDRサイト（ペアリージョン）にコピーするテクノロジーだ。メインサイトで災害が発生した際に、DRサイト側でこのイメージから仮想マシンを起動し、フェールオーバーしてビジネスを継続できる。さらにメインサイトの復旧時には、DRサイトで変更された内容を書き戻してメインサイトを起動する（フェールバック）といった一連の災害復旧機能を提供している。

　このASRはさまざまな用途で利用できる。下の図にあるように、オンプレミスをメインサイトにしたクラウドDRサイトの構築（中央）、あるいはオンプレミス環境からのクラウド移行（右）にも活用が可能だ。

Azure Site Recovery（ASR）の活用シナリオ

　もっとも、基本的な使い方はAzureリージョン間でのDRサイト構築（左）であり、これを「Azure間（Azure to Azure）のASR」などと呼ぶ。日本国内のリージョンを使ってDRシステムを構成する例を挙げながら、もう少し詳しく説明していこう。

Azure間（Azure to Azure）のASR

　メインサイトを東日本リージョンで運用する場合、ASRによって、東日本リージョンで構築した仮想マシン（VMイメージ）のコピーがDRサイトの西日本リージョンに作成される。東日本リージョンのVMイメージを西日本リージョンにレプリケーションしておき、フェールオーバーの段階で仮想マシンを起動する。つまり平常時は、西日本リージョン側では仮想マシンを起動していないので、そのぶんコストが抑えられるのが特徴だ。

　もうひとつの特徴的な機能として「テストフェールオーバー」がある。災害発生などに備えてDRの訓練をしたいが、メインサイトの本番環境を止めてテストするわけにはいかない、という課題に応えるものだ。

　その仕組みはシンプルで、前述した東日本／西日本リージョンの構成ならば、東日本リージョンの本番環境は起動したまま、西日本リージョンのDRサイトも立ち上げるというものだ。問題なく起動することが確認できたら、西日本リージョンの変更内容を破棄してシャットダウンし、ふたたび東日本リージョンからのレプリケーションを待ち受ける状態に戻す。

　またASRの「復旧計画」機能を使えば、フェールオーバー時の仮想マシンの起動順序や設定変更作業（データベースの状態チェックなど）をカスタマイズして制御することができるのも便利なポイントだ。

　ちなみに、ASRを使ってDR用のペアリージョンを構成する場合、ASRサービスだけ別のリージョンを選択できる。同じリージョンでASRが稼働していると、大規模障害などでASR自身も機能しなくなる可能性があるからだ。東日本リージョン／西日本リージョンの場合、ASRをそのほかのアジア域内（同じジオクラスター）にあるリージョンに配置できる。

　最後に、ASRのRPO（目標復旧時点）、RTO（目標復旧時間）について触れておく。まずRPOは技術仕様上、「約30秒」が最短となる。最短30秒ごとに仮想マシンイメージのスナップショットが作成され、DRサイトにコピーされるイメージだ。また、SLAで定められたRTOは「2時間」。つまり災害や障害の発生後、2時間後までにはDRサイトで仮想マシンが立ち上げられることが保証されている。

「Azure Backup」によるバックアップと復元

　災害復旧においてはバックアップも重要である。Azureで提供されているPaaS型のバックアップソリューション「Azure Backup」についても理解しておこう。

　Azure Backupは、Azureのさまざまなバックアップ機能を包含する“ブランド名”だと思ってほしい。実際には仮想マシンイメージだけでなく、SQL ServerやSAP HANAなどさまざまなバックアップが実行できるからだ。それぞれで提供される機能や使っているテクノロジーも異なる。

Azure Backupの概要

　マイクロソフトでは、特にメインのサービスをわかりやすく「Azure VM Backup」と呼ぶことがある。これは先ほどのASRと同じく、仮想マシンイメージをコピー（バックアップ）するサービスだ。具体的には、Azureまたはオンプレミスにある仮想マシンやファイルを、Azureのクラウドストレージにバックアップできる。バックアップ先のインフラ構築や管理が不要のためコスト削減ができ、物理的な設置スペースの制約がないことなどの利点がある。

Azure Backupは、オンプレミスの仮想マシンイメージやファイルもバックアップできる

　Azure VM Backupがバックアップしたデータは、Azureのストレージ（Recovery Servicesコンテナー）に保存される。このとき、バックアップデータの可用性を高めるために、Azureストレージの冗長オプションである「LRS（ローカル冗長ストレージ）」や「GRS（ジオ冗長ストレージ）」を選択できる。LRSは同一リージョン内で冗長化、GRSはペアリージョン間で冗長化するオプションだ。したがって、災害復旧を考えたバックアップデータの冗長化にはGRSオプションが使えるということになる。

　念のために書いておくと、GRSではプライマリリージョン（ここでは東日本リージョン）全体に障害が発生した場合にのみ、マイクロソフトによるフェールオーバー処理が実行されてセカンダリリージョン（同 西日本リージョン）に切り替わる。平常時はセカンダリリージョンのデータにアクセスすることができず、フェールオーバー処理もユーザー自身ではできない（マイクロソフトによる処理を待つことになる）点には注意していただきたい。

　バックアップからの仮想マシンの復元（リストア）方法についても少し触れておこう。Azure VM Backupでは、いくつかの復元方法が用意されている。

Azure Backupにおける復元（リストア）の目的と方法

　最もよく利用されるのは、バックアップした仮想マシンを丸ごと復元する「上書き更新」だろう。既存の仮想マシンに上書きして過去の状態に戻すだけでなく、新たに用意した仮想マシンをリストア先にすることもできる。

　それ以外にも、バックアップからディスクを復元して、手作業で仮想マシンを新規作成することもできる。もっとも、上書き更新のほうが手軽なのでこの方法を利用することはまれだろう。復元したディスクを既存の仮想マシンにアタッチして、必要なファイルだけを抜き出すといったことは可能だ。

　復元の話が出たついでに紹介しておくが、今年2月にGA（一般提供開始）となった新しい機能として「Cross Region Restore（CRR）」がある。前述したGRSの派生機能として覚えておくとよいが、CRRは仮想マシンのバックアップとDRレプリケーションをひとまとめに提供してくれるうえ、GRSとは異なりユーザー自身が任意のタイミングでリストアできる。ただし本稿執筆時点では、セカンダリリージョンに保存されたバックアップデータからのセルフサービスリストアに限定されている点は注意してほしい。

システム規模に合わせた高可用性と災害復旧の考え方

　第2章の最後に、実際にAzureで高可用性と災害復旧をどう構築していくのかを、基幹系システムのような大規模システムの構築例に基づいて解説していく。ここではSAPシステムをAzureで構築する例を取り上げる。

Azure上にSAPシステムを展開する場合の一般的な高可用性／災害復旧構成

　SAPシステムのように、アプリケーションサーバー（APサーバー）層とデータベースサーバー（DBサーバー）層で構成されるシステムの場合、まず同一リージョン内で高可用性構成をとり、さらにリージョン間で災害復旧構成をとるというのが標準的なアーキテクチャだ。

　図を見るとわかるが、大規模システムと言っても特殊な部分はなく、ここまで説明してきたASRやAzure Backupなどから必要なサービスを組み合わせて利用している。まずはこの点を理解することが重要だろう。

　ポイントは、DBサーバー以外は災害復旧構成にASRを使っている点だ。業務データが蓄積されていないサーバーは、ASRで仮想マシンイメージをコピーしておくだけで十分に災害復旧対策となる。また、災害対策サイト（セカンダリリージョン）側の仮想マシンは、平常時はシャットダウンしておけばよい。

　ただしDBサーバーは例外となる。ASRは仮想マシンイメージのレプリケーションを行うだけでDBデータの整合性までは保証せず、またRPOも最短5分と（DBに適用するには）長い。一般に基幹系システムの場合は、より高度な要件が求められるので、ASR以外のデータバックアップ方法を検討する必要がある。

　ここでは、たとえばSQL Serverの「Always On」機能、SAP HANAの「システムレプリケーション」機能など、DBが備えるネイティブ機能の利用が推奨される。ただし、こうしたレプリケーションを行うためには、プライマリ／セカンダリリージョンの双方でDBサーバーを立ち上げておく必要があり、それ相応のコストもかかる。

　そこまで高い要件を必要としないDBサーバーの場合は、Azure Backupを使ってデータベースファイルを遠隔コピーしておけば、リーズナブルなコストでDR構成が組める。ただし、Azure Backupのスケジュールバックアップは「1日1回」なので、RPOは最短でも1日になってしまう。このように、DBサーバーではRPO要件に基づいて災害復旧構成を考えてほしい。