システム障害対策の勘所〜復旧時間とコストのトレードオフ〜

システム障害対策の勘所 ~復旧時間とコストのトレードオフ~

システム担当者なら必ず一度は悩むシステム障害への対応方法。システム障害が起きた場合に、システムにはどの程度の影響が出るでしょうか?障害時のシステムへの影響は、どんな障害が起きたか、そしてどのようなシステム構成をとっているかで大きく変わります。今回は、特に機器障害に的を絞り、システム構成とシステム障害時の復旧時間(システムダウン対策)について考察します。また、合わせて各構成をとった場合のコストについても考えます。
(2011年12月 掲載開始)

復旧時間とコストのトレードオフ

システム障害が起きるとどうなるか? ~シングル構成~

はじめに、一番シンプルな構成であるシングル構成時に、主にハードウェア故障などにより、システムダウンした場合を考えます。

シングル構成では、機器が1つずつで構成されます。この場合ある機器が故障で壊れるとどうなるでしょう?基本的には、壊れた機器の変わりに新しい機器を用意し、1からすべての設定をしなければならなくなります。壊れたものがサーバであれば、一般的に障害復旧には次の作業が必要になります。

シングル構成 (=ネットワーク)機器・サーバがそれぞれ1つずつ)

障害復旧の流れ(シングル構成)

0)代替サーバの調達
1)サーバの物理的な設置
2)OSインストール
3)OSの設定
4)アプリケーションのインストール
5)アプリケーションの設定
6)確認作業

障害復旧の流れ(シングル構成)

一度経験済みの作業とはいえ、これら一連の作業を再度行えば、障害復旧時間は少なく見積もっても、丸一日。長ければ数日かかるでしょう。社内のあるシステムが1週間システムダウンすることを想像してみれば、その損害の大きさがイメージできるのではないかと思います。
なお、これは代替サーバがすぐ調達できた場合で、調達に時間がかかるような場合は、その分だけ障害復旧時間が長くなります。また、次に説明するバックアップを取得していない場合は、これまで蓄積したデータが消失してしまう場合も考えられます。

次善の策 ~バックアップの取得~

先ほどは、機器が故障した場合におけるシステムへの影響の大きさを見てきました。システムが、まる1週間停止するというのは、大半のシステムにおいて、許容できない数値になるでしょう。
そこで障害復旧時間を短縮するため、まず考えられるのが「バックアップの取得」です。サーバやネットワーク機器をセットアップしたあと、設定情報やデータをバックアップとして取得します。この場合、障害時の復旧対応は、時間のかかる設定作業の時間をスキップできますので、バックアップがない場合に比べてシステムダウン時間の大幅な短縮が可能です。

バックアップの取得

障害復旧の流れ(シングル構成+バックアップ)

0)代替サーバの調達
1)サーバの物理的な設置
2)OSインストール
3)バックアップのリストア
4)確認作業

障害復旧の流れ(シングル構成+バックアップ)

このようにバックアップを取得することにより、障害復旧時間が短縮できます。しかし、ここで考慮する必要があるのは、OSやアプリケーションの「設定」はいらなくなりますが、「物理的に機器を交換する」「初期設定をする」「バックアップを戻す」等の作業は必ず発生するということです。これらの対応には、1時間から数時間、長ければ丸1日程度の時間がかかります。

バックアップの難所

バックアップを取得することは、システム障害時の障害復旧時間を短縮するための第一歩です。比較的少ない投資で、大きな効果が期待できるバックアップですが、以下のような注意点があります。

1.データ消失のリスク

バックアップというのは、通常リアルタイムではなく、「ある時点」のデータをバックアップします。よって、変更の少ないネットワーク機器などでは問題になることは少ないですが、データの更新が頻繁にあるサーバが故障した場合などでは、バックアップを取得した時点(たとえば、前日夜間)から障害時までのデータが失われてしまう場合があります。

2.機器交換にかかる時間と労力(人力作業)

バックアップ/リストア方式で運用する場合で問題となるのは、特に物理的な交換作業が発生するため、「必ず人手を介す必要がある」ということです。人手がいない夜間や休日に障害が発生した場合は、作業者の移動時間などその分だけ復旧が遅れることになります。また、この状況をカバーするため、深夜に現場に駆けつけて復旧対応に追われている情報システム部門の方も多いでしょう。

3.バックアップ/リストアの難しさとコスト

ネットワーク機器の情報をバックアップしリストアをする場合は、作業内容は簡単で、かつそのための追加コストもかからない場合がほとんどです。しかし、サーバ機器のバックアップとリストアとなると、難易度が上がる場合が多いです。
まずは、バックアップ方式。一般的には、バックアップのための特別なソフトウェア(バックアップ用サーバとバックアップソフトウェア)が必要となります。これらの追加の購入費用、構築や運用の労力がかかってきます。
また、特に問題となるのは、データ量が多いサーバデータのバックアップ。近年、データ量の増大により、1回のバックアップ取得にかかる時間が増えており、これまでの一般的なバックアップ手法などでは、バックアップが間に合わないような事態も発生しています(例えば、1TBのデータのバックアップが夜間だけでは終了しない等)。

コストが許せば最善の策 ~システムの冗長化~

最長丸1日程度のシステムダウンが許されないようなシステムの場合は、バックアップの取得より上位の対策をとる必要があります。この場合は、「システムの冗長構成」をとることが必要となります。

システムの冗長構成をとった場合は、機器障害時に利用中の機器から予備系の機器に切り替わるための時間がシステム停止時間となります。冗長化の方式や障害対象にもよりますが、一般的に、予備系への切り替えは自動的に行われます。よって、「日単位、時間単位」から「分単位、秒単位」にダウンタイムを圧縮することが可能です。条件によっては、システムダウンタイムがゼロとなる場合もあります。

冗長構成(=ネットワーク機器・サーバがそれぞれ複数台)

システム冗長化の難所

システムの冗長化は、対障害性を高めダウンタイムを短縮するための最善策です。しかし、すべてのシステムが冗長構成で構築されているわけではありません。理想的でありながら、冗長構成がとられない理由はなんでしょうか?
ここで、ポイントは、以下の3つです。

1.冗長化するべきポイントはいくつもある

システムには、インターネット回線、サーバ、ファイアウォール、それを結ぶスイッチ、ストレージなど多くの構成要素があります。一口に、「冗長化」といっても、システム障害対策として冗長化を検討すべきポイントは、いくつもあります。

ストレージの冗長化 冗長化検討する際に考慮すべき主な項目

たとえば、一般的な、「サーバの冗長化」。しかし、サーバを冗長化しただけでは、サーバ以外のシングルポイントでダウンするかもしれません。

しかし、後に述べるようにすべてを冗長化するのは、高額かつ大変な労力がかかりますので、相当重要でコストをかけらえるシステムでないと、すべてのポイントを冗長化しているシステムは稀でしょう(例えば、金融機関の基幹システム等)。よって、冗長化するとしても、影響が大きい部分だけ(たとえばサーバだけ)の冗長化になってしまっているのが、多くのシステムの実態でしょう。

シングルストレージ

2.冗長化は難しい

先のように、システム障害対策として冗長化を検討すべき対象はさまざまです。冗長する対象にもよりますが、冗長化の構成を行うには、高いスキルと多くの労力が必要となります。単に機器を2つ用意すれば即冗長化となるわけではありません。A、B2つの機器が動いて、AがダウンしたらBに切り替わる。それには、特別なプロトコル、特別な設定、特別なソフトウェアが必要になってきます。
たとえば、サーバならVMware HA 、ルータのVRRP、スイッチのスパニングツリーやスタック構成、ストレージの仮想化機能などがあります。これらに対応した機器やソフトウェアを用意し、設定・運用する必要があります。

切替プロトコル

3.冗長化すると高額

一般に、冗長構成は高額です。同じ機器を買えば単純計算で2倍の金額が必要となります。加えて、冗長化に特別な設定や追加ソフトウェアがいると、金額は2倍以上になる場合もあります。また、仮想化ソフトウェアの冗長化機能(HA)を利用するには、通常ストレージが必要になりますが、このストレージの導入が高額になる場合が多くなります。

すべてのポイントで 冗長化した場合の構成 (=すべての機器・回線 が複数個ずつ)

まとめ

このように、システム障害対策には、いろいろな方法があります。それぞれ障害復旧時間、そして構築のコスト/労力が大きく異なります。自社のシステムの内容、重要度などを考慮し、最適なシステム構成を選択する必要があるでしょう。また、障害復旧時間の予測値は、構成ごとに大きく異なり最初の設計・構築時にほとんど決まってしまいます。よって、構築前に障害対応の内容や復旧予想時間まで含めてあらかじめ検討しておくことが重要となります。

  シングル構成 バックアップ
/リストア
冗長構成
障害復旧時間 1日~数日 数時間~1日 数秒~数分
コスト
労力/難易度 易しい アプリケーションのリストアが難しい場合がある 冗長化プロトコルが難

この記事を読んだ方にオススメのコラム

クラウド選びの勘所〜稼働率とSLAを読み解く〜
クラウドサービスの可用性・安定性指標として使われている「稼働率」や「SLA」。このコラムではクラウド選定の際に知っておきたい稼働率・SLAのポイントを紹介します。

社内システムクラウド化の意外な課題
近年、これまでクラウドサービスの利用が進んでいなかった一般企業の情報システム用途などにも、クラウドは浸透してきています。このコラムでは社内システムをクラウドへ移行する上でのメリットとその際の課題を解説します。

コラム 一覧
ITインフラに関する、トレンド情報やお客様が抱えている課題などを、ビットアイル・エクイニクス独自の視点で解説する、各種コラムを掲載中です。