High Availability の導入についての考察 - Arcserve ·...

WHITEPAPER

High Availability の導入についての考察

システムの稼動停止時間を最小化するための対策とは

今日、情報技術（IT）は企業に多大な価値を与えていますが、一方で、きわめて脆弱でもあることを意味してい

ます。市場がよりグローバルになると、従業員がどこかの地域で常に働いていますし、ビジネスは常に稼動状態

にあります。アプリケーションの可用性が維持できないと、直ちに売上げや生産性、ブランドの価値の低下や規

制の問題にも発展する恐れがあります。極端なシステムの停止はビジネスの存続にとって脅威となるのです。

では企業はどのようにこういった実在する脅威に取り組めばよいのでしょうか。実際は、大抵の企業は上手く対

応できていないのが現状です。

事業の継続性 - 予定外のシステム停止を見越したビジネスシステムの復旧計画、準備、実施 – は、時とし

て IT の問題であると考えられがちです。そして多くの企業では IT 部門に解決策を提供してもらおうと丸投げ

しています。これでは、指針がきちんと示された戦略を持たないさまざまな解決策を導入してしまうことにつな

がります。この用語が意味する通り、事業の継続性はビジネスの問題であり、解決するためにはビジネス側から

の取り組みが必要になるのです。

既存の事業継続性計画がこういった問題にさらされているかを知る方法は以下の通りです：

・ 計画に大幅な手動による操作や処理が介在する必要がある場合

・ 計画が基幹システムに対して数秒以上のデータ損失を許容するような場合

・ 計画が基幹システムのアクセスを数分で元に戻せない場合

・ 計画が 30 年も昔のバックアップ/リカバリの技術を元にしている場合

バックアップ/リカバリは、30 年にわたって IT システムの保護にとって頼りになる手法であったわけですが、

今よりもシンプルであった時代に開発された技術です。テープ、またはディスクへのデータのバックアップ、ま

たはスナップショットの実行 – 現代的なバックアップと同等のもの – は、ある時点のアプリケーションデー

タのイメージを作成します。ある時点のコピーからのリストアは、データを一番最近のバックアップより直近の

ものに戻すことはできません。そのコピーが 15 分前からであろうと 2 日前であろうと、バックアップからのリ

カバリは、データ損失の影響に直面せざるを得ないということを意味しています。システムによっては許容範囲

かもしれません。しかし、多くの最も重要なビジネスアプリケーションにとって、データの損失は壊滅的な問題

になってしまいます。

バックアップ/リカバリの手法は、比較的単純なコンピューティングプロセスを元に開発されています。それは、

誰もシステムを使っていない時間帯に定期的にスケジュールされてバックアップを行うという処理です。日々の

業務で活用している常に稼動状態にあるアプリケーションでは、継続的なシステムの可用性を保証し、バックア

ップ可能な時間帯に依存せず、データ損失の脅威を最小限にする技術が要求されています。

最新のハイ･アベイラビリティ(HA)の技術は、アプリケーションとデータの変更を遠隔地のサイトに継続的に転

送し続けます。地震、停電、ソフトウェアのインストールの不具合などの災害や障害が発生すると、遠隔地の最

新のシステムに自動的に瞬時にフェールオーバーします。したがって、HA はシステムの停止とデータの損失を

最小限にできる最適なソリューションなのです。

WHITEPAPER

手軽に導入できるハイ･アベイラビリティ

システムの停止やデータ損失に対応できるようにシステムの可用性を保証する必要がある場合、HA は最適なソ

リューションですが、長年にわたって HA の技術は、中小中堅企業にとって、複雑で高価すぎると考えられてき

ました。社会通念として、豊富な予算や IT リソースを持つ大企業だけが HA のソリューションを導入できると

考えられていたのです。こういったことが最近までまことしやかに思われていました。

HA は一般的に、遠隔地にある IT システムをデータセンターにあるアプリケーションと同期させ続けるための

レプリケーションとハートビート技術の組み合わせを使って実現しています。かつては、2 ヶ所の物理的なサイ

ト間の高帯域な専用ネットワークと特定のアプリケーションと OS でサーバ、ストレージ、ネットワーク機器を

冗長化させることで実現していました。この冗長化のコストが、中小中堅企業にとって手の届かないものだった

のです。

今日、低コストで高帯域なネットワークが普及し、ビジネス上でも必要不可欠になっています。加えて、多種多

様なサービスプロバイダによって、要望に応じて、低コストで仮想サーバを簡単に導入できるようになりました。

こういったインフラが促進することで、HA 技術を多くの企業がさらに低価格で導入できるようになったのです。

HA のインフラコストの劇的な低下は、多くの企業の事業継続性計画にとって転換期を向かえさせる結果となり

ました。協調性が無く、時として重複したバックアップソリューションがデータセンターにも導入されています

が、事業継続性の解決策としてバックアップ/リカバリを採用していたなら、おそらくこれらのサイロ化したソ

リューションは、メンテナンスを困難にしたり、生産性を低下させるだけでなく、惨事復旧を困難なものにして

いることにお気づきだと思います。最新の HA は、データ保護のコストを削減し、惨事復旧を簡素化しながら、

データの損失やシステムの停止を最小限にするように、事業の継続性に対する普遍的なアプローチを提供してい

ます。

図１- サイロ化されたバックアップソリューションの導入による複雑さに隠されたリスク

HA は、企業のビジネスにとって最適かもしれませんが、業務システムの詳細な分析無しに復旧の要件を決定す

ると、どのアプリケーションにメリットがあるかが分からなくなってしまいます。確実なことは、HA の導入を

制限していたコストやインフラの制約が無くなったことで他の問題に対処できるようになるということです。

WHITEPAPER

業務継続性の 10 の落とし穴

惨事復旧をどのように正しく実施するかについてはいろいろ取り沙汰されていますが、間違った方法で実施して

しまう時に待ち受けている落とし穴について見ていきましょう。ここでは、惨事復旧や業務継続性計画に関する

10 の落とし穴を詳細に述べます。

ビジネスについてであって、テクノロジーの問題ではない！

惨事復旧、ハイアベイラビリティ、バックアップ/リカバリ、業務継続性の目的はみな同じです：どんな状況に

あってもビジネスを常に稼動状態にしておくこと。企業では頻繁に会話をテクノロジー主導で行うことがありま

す。忘れられがちですが絶対に覚えておく必要があることは、惨事復旧はビジネスの要件を満たすことであって、

ビジネスの要件主導で行われるべきであるということです。惨事復旧をどのように実施するかを計画していく前

に、なぜか、ということを考える必要があります。ビジネスのリーダーと話をして優先度について理解しましょ

う。それは、誰かにとっては e メールであり、他の誰かにとっては受注システム、または Microsoft SharePoint

であったりします。重要なのは、ビジネス側のユーザに聞かなければ最も重要なシステムが何であるかは決めら

れないということです。企業のニーズを理解することは、惨事復旧のテクノロジーを何にするかを左右する優先

度を決めることにつながります。

一大事か、そうではないか

惨事復旧を考える時、台風や洪水、テロ攻撃などは思い浮かべると思いますが、不十分なロールバックの手続き

の検討や重要なネットワーク機器のハードウェアエラーによるソフトウェアのアップグレードの失敗といった

ことはあまり思い浮かべないかもしれません。しかし、最悪な状況の計画と日常的な些細なエラーはどちらも普

通に起こり得ることです。惨事復旧の計画は、普通のことから一大事なことまですべての起こり得ることを考慮

に入れる必要があります。

システム停止による損害を知らずにどうやって予算を割り当てるのか?

システムの停止とデータ損失がビジネスにとってどれほどの財務的なリスクになるかを見極める前に、惨事復旧

計画の予算を割り振ってしまう場合が多くあります。基幹システムの停止で被る損害が実際いくら位になるかを

定量化すること無くして、こういった損害を防ぐためにいくら費やせばいいのかを決めるのは困難なことです。

惨事復旧への取り組みは、ビジネスの要件に合致していなければなりません。これは、予算を割り当てる前にシ

ステム停止の財務面でのコストを評価するということです。そのコストを算出する際には法令順守の点も忘れな

いでください。法的な義務が満たされていない場合にしばしば罰金が科せられる場合があるからです。

リスクの評価について

起こる事象を惨事として分類するかどうかは、企業や部門ごとに変わってきます。いくつかの出来事 – 例え

ば地震など – は、まさしく企業が発生に備えて自ら保護すべき一大事です。一般的なその他の事象 - ネッ

トワーク機器のエラーなどの – が大きな財務上の影響を与える場合もあります。惨事復旧を考える時、必ず

問うべきことがあります：何から保護しようとしているのか? 当たり前のことを見逃してはいけません。小さな

問題から起こる小さな損失が急速に大きな問題に発展する場合もあるからです。

WHITEPAPER

計画はあるか?

惨事復旧計画がバックアップテープの上にポストイットで貼られているようなら、それは困った問題です。です

が実際には驚くべき数の企業が惨事復旧計画をきちんと立案していません。全てのアプリケーション、ハードウ

ェア、設備、サービスプロバイダ、社員、そしてその優先度の詳細が記載された正式な文書を作成しておく必要

があります。そして、すべての利害関係者から文書化の賛同を得ておくことも必要です。計画は、すべての機能

領域を含んでいて、惨事の前後と惨事の間に起こることに関する明確なガイダンスを示していなければなりませ

ん。

計画はあるが、テストをしていない

惨事復旧計画を維持し続けることは、それがきちんと動作する場合にのみ有効です。計画が動作することを確実

にする方法は、それをテストすることです。惨事の状態をシュミレーションしてテストすることが不可欠ですが、

それもまた困難なことです。惨事復旧のテストを実施するのは、予算も時間もかかりますし、日々の業務からリ

ソースを割かなければなりません。しかし、アプリケーションのレベルで復旧がきちんとテストされない限り、

実際の惨事の際に困難に遭遇することになります。惨事復旧計画の無停止テスト環境が構築できるようなデータ

保護ソリューションを探すようにしてください。

だれが、何を担当するのか?

実際の惨事の際は、混沌として混乱した状態になるでしょう。もし主なスタッフが惨事復旧の際に何を担当する

のか分かっていなければ、問題が長引いてしまいます。惨事復旧計画は関係者の全ての役割と責務についてきち

んと提示されている必要があります。もちろんその主なスタッフが稼動できない時はどうするのかも含めておく

必要があります。復旧計画のテストにはそれらの人々も含めておくことが重要です。

復旧時点は何？復旧時間は誰?

ビジネスの各領域がシステムの停止やデータの損失に対してどのように影響を受けるかを知ることも非常に重

要です。この情報は惨事復旧のテクノロジーを選択する際に役に立つだけでなく、惨事復旧計画の基礎にもなり

ますし、各業務アプリケーションの復旧の際の失敗がもたらす結果も知らしめてくれます。システムの停止やデ

ータ損失のアプリケーションの許容範囲を示すために 2 つの指標が使われています：目標復旧時点（RPO）と目

標復旧時間（RTO）です。両指標とも時間を単位として測定されます。RPO は惨事が起きた時間から後ろに戻

すことで、RTO は前に延ばすことです。

RPO はデータ損失の尺度になります。より大きな RPO は、ビジネスにとって問題になる前にアプリケーション

が許容できるデータ損失も大きくなるということです。そこまでのデータの復旧に成功できる地点と考えること

ができます。逆に、その地点から惨事が起きた地点までの全てのデータはなくなってしまうということになりま

す。

RTO は継続中のビジネスに対するアプリケーションの重要度の尺度になります。より小さい RTO は、企業が損

失を被る前により迅速にアプリケーションをオンラインの状態に戻す必要があるということです。

WHITEPAPER

図 2 - アプリケーションとデータソースがどのくらい頻繁にバックアップ（目標復旧時点 - RPO）されるべきかとどれくら

い迅速に復旧（目標復旧時間 – RTO）する必要があるかを知ることは、事業継続性計画にとって非常に重要な構成要素です。

各アプリケーションの RPO と RTO が分からないと、惨事復旧の際にはどうすれば良いか皆目見当がつかない

ことになります。つまり、惨事後の復旧を確実にするための全てのことが当て推量になってしまうということで

す。RPO と RTO は惨事の際に提供できるサービスのレベルを定義することに繋がるのです。

継続的なデータ保護（CDP）のようなテクノロジーは、それらの目的に合致していることを確実にする意味で非

常に重要です。

考えているより復旧には時間がかかる

多くの企業にとって惨事復旧はデータセンターにバックアップテープを任せた時点で終わりと考えているかも

しれませんが、キーとなる業務システムの復旧にどのくらいかかるか、惨事発生後にどれくらいのビジネスデー

タが損失するかを知ることは不可欠です。現場から離れた場所にあるバックアップのコピーにアクセスできたと

しても、直ちにアプリケーションが復旧できることを保証するものではありません。データを読める機器にアク

セスできるでしょうか? データをリストアしてビジネス側のユーザを満足させられるほど迅速にアプリケーシ

ョンシステムを再構築できるでしょうか? クラウドサービスプロバイダからデータを復旧できる帯域幅を確保

しているでしょうか? アプリケーションの復旧にどれくらいの時間がかかるのか、そのシステム停止のビジネ

スに対する影響はどれくらいかを知ることで、別のテクノロジーを選択する必要があるかもしれません。

元に戻す

障害サイトへのフェールオーバー後にフェールバックして元に戻すことは、時として惨事復旧計画では見落とさ

れがちな要素です。なぜかは簡単です。惨事を考える時、もっぱら保護している資産にのみ注力してしまい、惨

事が過ぎ去った後のそれらの資産はどうなるかはほとんど考えないからです。

本番システムにフェールバックする機能は、あらゆる点でフェールオーバーの機能と同じく重要です。慎重に計

画しない限り、バックアップデータセンターは同じ機能、または本番サイトとしての性能を出すことは不可能で

す。

フェールバックの計画が無ければ、最初のフェールオーバーを成功できるかも知れませんが、業務を数週間並行

するうちに不十分に設定されたバックアップサイトによってビジネスの損失が増えていくことに気づくことに

なるでしょう。

WHITEPAPER

リスクを理解する

e メールは例外として、ビジネスユーザからのインプット無しに、ビジネスに対してどのアプリケーションが最

大のシステム停止のリスクとなるかを知ることはほぼ不可能ですが、RPO と RTO はこのリスクを測定する指標

となります。さらに、惨事復旧の際にどのアプリケーションの優先度が高いかをも示すことになります。

RPO と RTO は少しずつ変化しながら作用していきます。センターでの停止といった事象のタイムラインを考え

てみましょう。RPO は、停止の事象の背後にあってアプリケーションが許容できるデータ損失量を表していま

す。その地点が停止の事象からさらに後退すると、データ損失量の増加に伴って企業への潜在的なコストも増加

します。

RTO は、停止の事象の RPO に対するタイムラインの反対側にあります。 RTO はビジネス上の損失が増え始め

る前に許容することができるアプリケーション停止の量を表しています。言い換えれば、停止後、どれくらい迅

速にアプリケーションを再起動して稼動させる必要があるかと言うことを意味しています。

システム中の情報が他の情報源から再作成されている場合、災害時に一部のデータが失われるのは頭痛の種にな

りますが、それほど大きな問題でないかもしれません。例えば、買掛金システムの中で請求書が無くなったとし

ても、ベンダーに支払い依頼を再度送信してもらうことで再作成が可能です。しかし、データを容易に再生成で

きない場合 - 例えば、オンラインでの注文など - は、直接的に売上げや利用者の生産性、企業の評判やブラン

ド、さらには法令順守にも影響を及ぼす可能性があります。

同様に、基幹システムではないもの - 例えば、業務分析アプリケーションの月次レポートなど - は、例えば、

販売時点情報管理（POS）アプリケーションのような日々の業務に関わるシステムと同じようにシステム停止に

よる直接的な影響は受けません。RTO はアプリケーションの停止によるビジネスへの影響を測定しますので、

どのアプリケーションにどの惨事復旧ツールを適用すればよいかを決定する手助けになります。

RPO と RTO の指標と、定期的な惨事復旧の実際のテストからの結果の差異は、アプリケーションの可用性にギ

ャップがあるかどうかを表します。可用性にギャップがあるからと言って、常に業務継続性に対するアプローチ

が間違っているということではありません。企業は異なるベンダーの、一部重複したり全く同じで複雑な復旧方

法の惨事復旧テクノロジーを使っている場合もあるからです。テストによって問題や既存の業務継続性テクノロ

ジーの矛盾点を洗いだすことができ、RTO を改善可能な単一のアプローチ、または単一のソリューションベン

ダーに統一すべき領域を浮き彫りにできるのです。

WHITEPAPER

優れた HA とはどんなものか?

よく知られている優れたハイ･アベイラビリティとはどんなものでしょうか：アプリケーションの停止とデータ

損失が無いものです。しかし、それは中小中堅企業にとって現実的なものでしょうか?

HA テクノロジーは、もはや業務継続性に対してかつてそうだったような、複雑で難解なアプローチではなくな

りました。大企業が、長年にわたって基幹のビジネスシステムを保護するためハイ･アベイラビリティの手法を

使い続けてきましたので、テクノロジーはテストを重ねて来たことで惨事を回避する標準的なツールとして今や

広く受け入れられています。それは、シンプルで、何度でも繰り返し可能で、測定可能な自動ツールです。継続

的なデータ保護（CDP）やレプリケーション、自動フェールオーバーとフェールバック可能なようなテクノロジ

ーは非常に重要です。

HA 製品の成熟によって、中小中堅企業が気軽に導入できる価格帯が実現しました。HA 製品とインフラコスト

の低価格化 - ブロードバンドやサーバの仮想化、複数のサービスプロバイダ - が劇的に利便性を向上させると

ともに、HA をすべての規模の企業にとって非常に現実的な業務継続性の選択肢にしたのです。

システムの停止とデータ損失は、IT に頼っているビジネスにとって避けがたいことです。こういったリスクを

正しいテクノロジーで相殺することは、ソフトウェアの開発と導入･展開のサイクルのかなり早い段階から考慮

すべき点です。それぞれのアプリケーションに要求される保護のレベルを理解することは、適正なリソースを割

り振ることにも繋がります。ビジネスユーザが本番環境でアプリケーションを利用する時までに、そのアプリケ

ーションの RPO と RTO が明確に決められていて、障害や災害時に確実に復旧できるように最適な業務継続性

ソリューションが実装されていなければなりません。

システム停止とデータ損失が起こらないようにと要求することのできない業務継続性のアプローチは、ハイ･ア

ベイラビリティではありません。惨事復旧の改善を保証する多種多様なソリューションが利用可能だと思います

が、皆様の企業が晒されているリスクや脅威を排除できるわけではありません。なぜなら、それらは HA ではな

いからです。

図 3 - 統合的な業務継続性ソリューション

WHITEPAPER

Copyright ©2015 Arcserve(USA), LLC. All rights reserved.

本資料で参照するその他すべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に属します。本資料に掲載の情報や成果は、さまざまな環

境において導入されたソフトウェア製品と当該顧客の事例に基づいています。本資料で提示されるソフトウェア製品の性能は、環境の如何に関わらず将来

に渡って保証されるものではありません。本書は情報提供のみを目的としており、Arcserve は本情報の正確性または完全性に対して一切の責任を負いま

せん。

Arcserve® Unified Data Protection について

Arcserve は、20 年以上にわたって世界中の企業に対してシステムの停止を無くす保護ソリューションを提供

し続けてきました。Arcserve® Unified Data Protection (UDP)は、一瞬も止めることが許されないビジネス

継続性の要件に確実に応えることができるデータ保護・HA ソリューションです。中央で集中管理可能な

Arcserve® UDP は、統合バックアップ、スナップショット、レプリケーション、そして重複排除機能を標準搭

載しており、仮想環境や物理環境、オンプレミスからクラウドにも幅広く対応しています。Arcserve® UDP

Assured RecoveryTM は、包括的でリアルタイムな無停止テスト機能を提供します。Arcserve® の詳細につい

ては、www.arcserve.com/jp をご覧ください。