IT・技術研修ならCTC教育サービス

サイト内検索 企業情報 サイトマップ

研修コース検索

コラム

クラウド時代のサーバー運用入門

CTC 教育サービス

 [IT研修]注目キーワード   Python  UiPath(RPA)  最新技術動向  Microsoft Azure  Docker  Kubernetes 

第9回　クラウド時代の障害対応術 (8) DR環境構築してますか？ (濱田康貴) 2018年8月

DR環境の必要性

みなさんこんにちは。去る2018年6月18日、大阪府北部を震源とする地震におきまして、被災された皆様にお見舞い申し上げます。本稿執筆時点で余震は減少しているものの、身の安全を第一にお過ごしいただければ幸いです。
さて、業務システムの構築に携わっている方々にはDR環境について検討されたことがある方もいらっしゃるかと思います。DR(Disaster Recovery)とは日本語に訳すると惨事復旧、つまり、あるサービスを実行する基盤が天災などにより被災しても、あらかじめ構築したDR環境へ切り替えることにより、事業継続性 (BCP) を担保するという目的があります。

DR環境とサーバー冗長化とはどう違うのか

DR環境もサーバー冗長化も、事業継続性 (BCP) 担保という大きな目的は一緒ですが、以下のような違いがあります。

表1 DR環境とサーバー冗長化の違い

  DR環境 サーバー冗長化
目的 データセンター、リージョン単位での災害対策 サーバー単位の冗長化 (同一Availability Zoneまたは異なるAvailability Zone)を行うことによるダウンタイムゼロ化または最小化
運用系から待機系に切り替わるまでの時間 比較的長い傾向 (※1) Active/Active または数秒単位でのActive/Standby切替 (※2)
運用系 待機系切替の判断基準 上長承認が必要なことが多い 通常運用としてほぼ自動化されることが多い

※1
システム全体のデータを遠隔地へ差分転送しなければならず、また、最後の差分転送から被災時点までのデータ欠損状況によってはサービス再開に時間がかかるケースもある

※2
Active/Active構成の場合、理論上ダウンタイムはゼロとなるが、Active/Standby構成の場合、運用系と待機系の切替でダウンタイムが発生するケースが多い

通常のサーバー冗長化も地理的に離れた拠点間で行う場合もありますが、頻繁にファイルやデータベースの更新を行う場合、回線遅延による系間でのデータ同期ズレが発生することもあるため、高速回線による接続性が担保されているかどうかを考慮に入れて設計することをおすすめします。

冗長化レベルの考え方

DR環境構築の大切さは、技術に明るくない方にもその重要性は理解していただけると思います。しかし、何がなんでも地理的に冗長化するとなると、当然に必要な予算や運用負荷が増えてしまいます。そこで、起こりうるリスクと目標復旧時間を起点に冗長化のレベルを考えるのがベストです。例えると

表2 冗長化レベルの考え方

リスク 目標復旧時間 冗長化方式
サーバー障害または高負荷によるアクセス不可 数秒～1分以内、または障害を体感しない程度
  • ロードバランサ配下の配置
  • Active/Active構成
人為事故などによるデータ欠損、誤りデータ投入 数分～数時間以内
  • 定時バックアップ取得
  • バックアップデータやバイナリログ等からの復旧

※厳密にはサーバー冗長化ではないが、データの冗長性という観点

データセンター単位での災害罹災 数10分～数時間以内
  • DR環境構築

いかがでしょうか。ここに取り上げた例はほんの一部でしかありません。クライアントへ提供するサービスの重要性に鑑み、適切な冗長化レベルを設計するとよいでしょう。また、本稿では取り上げませんが、サーバー冗長化だけではなく、オフィスが災害に被災した場合の回線冗長化、電源冗長化についても検討するとよいでしょう。

DR環境を設計するにあたって

DR環境設計は基本的に、運用系と同じ基盤をもう1セット別拠点に構築することになりますので、それ自体は新たな技術を持ち込むわけではなく、クラウドであれば仮想サーバーのイメージをコピーするなどで短期間に構築するケースも多いでしょう。これだけを取り上げると簡単そうに見えますが、DR環境の設計は、運用設計にこそ重要なポイントが隠れています。
DR環境構築にあたり、

  • 以下、DRで達成したい品質の目標を決め計画をたて運用設計を行う
    • 目標復旧地点(RPO)の観点
    • 目標復旧時間(RTO)の観点
  • 運用手順書を作成する
  • 運用訓練を行う
    • 作業所要時間がRTOに収まるかどうかの計測を行う
    • 運用手順書の評価を行う
      • RPOを満足できる品質で作業できるかどうかの評価
      • 作業者のスキルや気付きに依存せず同じ品質を担保できるかどうかの評価
    • 運用訓練後のフィードバック
  • DR発動後の事業継続性 (BCP) 評価
    • DR発動前後で業務フローに変更がないか、または少ないに越したことはないが、業務フローに変更がある場合は、それを明確にし、業務マニュアルへ落とし込む
    • DR発動により実施できない業務フロー(地域に依存するなど)がある場合は、業務マニュアルへ落とし込む以外に、影響を受ける部署や顧客への周知を行う

最低限これらの運用設計を行う必要があります。表1でも少し触れましたが、ファイルやデータベースの状態を持つ基盤であれば、運用系と待機系との間でのデータ同期間隔を把握し、フェイルオーバーするにあたって、最後のバックアップまたはデータ同期から被災時点までのデータ差分同期について考慮が必要です。そして、フェイルバック時には同様に逆方向のデータ同期を行う必要があることにも理解が必要です。

また、災害発生時に「さあこれから被災した拠点のバックアップデータをDR環境へリストアしよう」と思ったところで、回線が寸断されていたり、飛行機や新幹線が不通になっているためにリムーバブルメディアを持ち出すこともできなかったりすると、せっかくのDR基盤も宝の持ち腐れになってしまいます。回線容量などが許す限り、高い頻度で運用系と待機系の間でデータを同期しておくことで、RTOの短縮を図ることができます。

DR環境こそクラウドを検討するメリット

普段から起動しないDR環境であれば、常に電気代や回線使用料、ハウジング使用料が必ずかかるオンプレミス環境ではなく、バックアップデータの同期を行うときだけクラウド(IaaS)の仮想サーバーを起動することでコストを下げることも可能です。データの持ち方がシンプルで、仮想サーバー構築の所要時間が短いのであれば、データのバックアップだけオブジェクトストレージへ常にバックアップする、という方法もあります。

いかがでしたでしょうか。DR環境構築と一言で言っても、思った以上に考えることがあると思われた方もいらっしゃるかと思います。本稿を機に運用プロセス改善、品質向上、事業継続性 (BCP) 向上に繋げていただけると幸いです。

 


 

前回のコラム
「第8回　クラウド時代の障害対応術 (7) シェルコマンドのパイプライン、リダイレクトとプロセス置換に慣れよう」 次回のコラム
「第10回　クラウド時代の障害対応術 (9) ログは口ほどに物を言う」

CTC教育サービス 関連コース

 [IT研修]注目キーワード   Python  UiPath(RPA)  最新技術動向  Microsoft Azure  Docker  Kubernetes 

「クラウド時代のサーバー運用入門」コラム一覧へ

コラム一覧へ