システム災害復旧のために知るべきこと

本ニュースリリースは、アンラボコリアより発表された内容を翻訳したものです。

================================================

 

  

 

 

昨年10月、データセンターで起きた火災により韓国の有名メッセンジャーアプリのサービスが停止する事故が発生した。午後３時30分から翌日の午前10時30分までの19時間の間、ユーザーはサービス利用が困難になり、すべてのサービスが正常化するまで127時間がかかった。システム復旧やユーザーへの損害賠償のため、多額の費用が投入されたと推定される。

 

サービスの復旧に時間がかかった原因は、主なデータとサービスの応用プログラムの冗長化はされていたものの、開発者の主要タスクおよび運営ツールの冗長化がされていなかったため、３万２千台ものサーバーをいちいち手動で起動しなければならなかったためであったことが確認された。

 

今回の事故を機に、該当企業はデータセンター全体に障害が発生した場合でもモニタリングと障害検知機能が円滑に作動するようにモニタリングシステムを多重化し、インフラハードウェア設備からサービスアプリケーションに至る全体システムレイヤーにおいて多重化を設計・構築していく方針であると明らかにした。

 

 

災害復旧システムの運用

 

データセンターを常に安全な状態に維持することは難しい。自然災害からインフラ障害、ヒューマンミスにより発生するデータ削除や損失、サイバー攻撃といった各種リスクからインフラを保護・復旧するための災害復旧対策を講じなければならない。

 

技術的な観点での災害復旧の核心はデータ復旧にある。災害復旧の際にはリアルタイムに変更されるデータをどのようにしてリアルタイム同期させるかがカギとなる。

 

データ同期方式には、サーバーで入出力 (I/O) 書き込みリクエストに対して原本と複製本への書き込みが完了した後に一つの I/O を完了する 「Sync 同期方式」 と、原本の保存とは別にバックグラウンドで遠隔地の複製本で同期する 「Async 非同期方式」、そして原本と複製本を区分せずにどのボリュームでも同時に読み込みと書き込みをサポートする 「Active-Active ミラーリング方式」 がある。

 

また、同期方式と非同期方式の弱点をカバーしたハイブリット複製方式もある。これは同時に３か所のデータセンターでデータを同期する方式で、近距離は同期式で冗長化し、遠距離は非同期式で運営する第３のデータセンターを置く方式だ。

 

韓国では、多くのデータセンターがメインセンターと災害復旧センターを Active-Standby の形で運営していることが問題点として指摘されている。Active-Standby は、サーバー２台をそれぞれ運営サーバーと障害発生時の代替サーバーとして使用する方式で、災害復旧センターに定期的にバックアップをするが、データの整合性などのイシューによる障害が発生した場合は復旧に時間がかかる。

普段から災害復旧センターを活用する Active-Active 構成を活用する企業は多くない。運営費用が何倍にも増えるからだ。

 

災害復旧はバックアップと異なり、単純に過去のデータを保護することではなく、停止されたサービスの再開に重点を置く。このためには運営中のサービスとほぼ変わらないリアルタイムデータを別途管理しなければならなく、サービスに問題が発生したら予備システムに切り替えてサービス運営を継続しなければならない。

 

災害復旧はどれほど迅速に、どれほど少ないデータ損失でサービスを再開できるかが重要だ。

 

 

災害復旧システムの評価指標と復旧計画

 

年中無休で稼働すべき PC で100%の稼働時間を保障することは簡単ではない。運営の側面から見ると、システムの問題だけでなく自然災害や電力損失のような物理的リスクへの備えも必要だ。 

 

可用性、すなわちオンラインサービス稼働時間の測定時に出た結果値の9の数によって予定されたサービス稼働停止時間が変わってくる。９が多いほどサービス停止時間が減少する。例えば、99%の可用性は年間の停止時間を3.65日以内、99.9%は8.77時間以内、99.99%は52.60分以内、そして99.999%は5.26分以内に抑えなければならない。

 

災害復旧計画を立てる際に決定すべき事項は、RTO と RPO だ。RTO (Recovery Time Objective) は、復旧にかかる時間の目標、すなわちサービス復旧までかかる可能性がある時間を意味する。RPO (Recovery Point Objective) は復旧時点の目標で、最後のバックアップまたはスナップショットから災害発生時点まで経過した時間を意味する。

 

最も低いレベルのバックアップおよび復元は RTO/RPO が 「時間」 基準の場合だ。サービスが何時間ほどオフライン状態になっても大丈夫な方法で、バックアップしたデータで復元を行えばいい。最も手ごろで簡単な方法だ。

 

その次は普通レベルの Active/Passive 戦略だ。RTO/RPO が 「分」 基準の場合に使用できる戦略で、リソースの Active バージョンが失敗した際に待機状態のリソースを Passive バージョンとして保有する。Active サーバーが終了すると Passive サーバーと DB に迅速に切り替える。

 

最も高いレベルの Active-Activeバージョンは RTO/RPO がほぼリアルタイムで作動する。同一サーバーの複数の複製本を並べて実行し、ロードバランサー (Load Balancer) を配置してサーバーが作動停止するとロードバランサーが落ちたサーバーを無視してリクエストを処理できるサーバーに送信して処理する。