コアアプリケーションのビジネス継続性を維持

ベストプラクティスガイド
コアアプリケーションの
ビジネス継続性を維持
データセンターの停止を回避するための
ベストプラクティス
P2
ベストプラクティスガイド
車で市場に向かっている場面を思い浮かべてください。あなたは視界に入った何かに、ほんの一
瞬気を取られます。その瞬間に前を走行していた車が急停止し、あなたはその車に追突してしま
います。このような事故は、それ自体でも十分なショックですが、保険に加入していない、ある
いは損害を補償できるだけのお金がないと、事態はより一層深刻化します。
個人としての私たちは、事故、盗難、またはその他の損害から自身を守るための保険の必要性に
ついて、再考することはめったにありません。企業の場合も同様で、多くの企業がときには年間
数百万ドルもの資金を、リスクの評価や軽減に費やしています。多くの業種において IT 組織は、
不正アクセスや漏洩からデータを守るためには「金に糸目は付けない」方針を採っています。し
かしながら、データを処理するアプリケーションの可用性、あるいはシステムやデータセンター
の障害に伴う損失の防止に関しては、今日求められる「常時稼働」に適さない、旧来の考え方か
ら脱却できていない組織が少なくありません。こうした組織では、許容されるレベルのビジネス
継続性の確保に必要なリソースへの投資に、消極的な傾向が見受けられます。
IDC社は、多くの業種にわたるダウ
ンタイムの平均コストを 1 時間あた
り約170万ドルと見積もっており、1
時間あたり1,000万ドル近くに達す
るケースもあると指摘しています。
ダウンタイムインシデントの平均時
間は 90 分で、ときには 24 時間以上
継続することもあります3。
脅威は現実
具体的に考えてみましょう。顧客向けシステムがダウンした場合は、どの程度の収益の損失が予
想されますか。処理中の顧客トランザクションが失われた場合は、ビジネスあるいは顧客にどの
ような影響が生じますか。電子メールシステムやユニファイドコミュニケーション / コラボレー
ションシステムが停止した場合は、生産性の側面からビジネスにどのような損失が生じますか。
あるいはデータセンターで火災が発生した、電源が失われた、または地震による被害が発生した
ことで、センターが事実上オフラインになった場合は、どのような影響が懸念されますか。
こうした事態は一般に考えられているよりも頻繁に発生しています。大企業の 95% が過去 24 か
月間に、予定外のデータセンターの停止（単一のシステムではなくデータセンター全体の停止）
を 1 回以上経験しています。平均的な金融サービス企業は、過去 24 か月間に完全なデータセンター
の停止を 1.8 回経験しています。医療機関における平均値は、過去 24 か月間で 3 回です 1。
IDC 社は、多くの業種にわたるダウンタイムの平均コストを 1 時間あたり約 170 万ドルと見積もっ
ており、
1 時間あたり 1,000 万ドル近くに達するケースも存在すると指摘しています 2。インシデン
トの平均時間は 90 分で、ときには 24 時間以上継続することもあります。ダウンタイムに伴う
真のコストには、収益の損失に加えて、評判の低下、顧客からの信頼やロイヤルティの喪失、競
争力の低下、さらには法規制への違反といった問題も含まれます。ソーシャルメディアが強い影
響力を持つ今日、障害発生のニュースは口コミですぐに拡散され、ダメージの回復には数年を要
することもあります。
復旧目標
アプリケーションサービスが停止した場合に許容される復旧時間、すなわち復旧時間目標 (RTO)
は、アプリケーションによって異なり、5 秒の場合もあれば、5 分、あるいは 5 日の場合も考え
られます。一般的にダウンタイムのコストは、アプリケーションの RTO を設定するうえで重要
な要素になります。アプリケーションによっては、RTO がゼロに設定される場合もあり、これ
は顧客やエンドユーザーに障害の発生を認識されてはならないことを意味します。
アプリケーションサービスが停止した場合に許容される最大データ損失量、すなわち復旧ポイン
ト目標 (RPO) は、データの性質、および企業にとってのデータの価値（法的責任を問われる可
能性も含めた、損失の大きさ）、あるいはその両方に基づき設定されます。
一般的に RPO は、対象となるトランザクションの平均的価値に基づき決定されがちです。この
アプローチは一見合理的に思われますが、少し掘り下げて考えると、常に有効とは限らないこと
がわかります。一例として、金融機関の場合であれば、電子資金移動 (EFT) の平均額が 1,000
ドルであったとしても、最高額は数百万ドルの可能性があります。
1
『幸運を祈るよりも、避けられない障害に
備えたビジネス継続性計画を策定』、Gravic,
Inc.、2015 年 ( 一次資料 : Ponemon Institute)
『x86 上 の 高 価 値 ビ ジ ネ ス ア プ リ ケ ー
ション : 真のフォールトトレラントシステ
ムの必要性』、Peter Rutten、IDC 社、2015
年5月
2、3
P3
ベストプラクティスガイド
RTO: システム障害からの復旧に許容
される最大時間
RPO: システム障害が発生した場合に
許容される最大データ損失量
どのトランザクションが失敗するかを予見することはできないため、障害に伴う真の潜在的コス
トは、失われる可能性がある最も価値の高いデータと考える必要があります（たとえば、最高額
の EFT トランザクション、最大の販売注文、最大の商取引、データ損失に伴う最大の法的責任、
最大規模のアカウントなど）。RPO の設定は、このような最大値を基準にしなければなりません。
ビジネスの継続性
ビジネスの継続性に関して、通常まず思い浮かぶのが、トランザクション、収益、生産性の喪失
といった問題です。こうしたビジネス上の問題により、多くの組織が、戦略上の緊急課題として
ビジネスの継続性を重視し始めています。システム障害や大災害については、発生するかもしれ
ない問題ではなく、いずれ必ず発生する問題と捉えたうえで、発生した場合の 影響を考えるこ
とが大切です。ビジネスの継続性とは、どのような事態が発生しようとも、事業活動を持続でき
るようにすることを意味します。
実務的な側面から捉えると、ビジネスの継続性を維持するためには、コアアプリケーションおよ
びそのデータの維持や提供に必要なすべてのシステムについて、許容される RTO および RPO を
検証（および再検証）することが必要です（ベストプラクティスとして 1 ∼ 2 年ごとの見直しが
推奨されます）。許容される RTO および RPO の決定は、場合によってはごくシンプルです。た
とえば医療記録システムは常に利用可能でなければならず、データの損失は一切許されません。
これらのデータは患者の生命にかかわるものであり、障害が発生した場合は、問題の発生をユー
ザーに気付かれることなく、即座に復旧できなければなりません。
一方、許容される RTO と RPO の決定が、それほど簡単でないケースも存在します。たとえば、
運用しているオンラインストア、VoIP フォン、顧客関係管理 (CRM) システムなどの価値を評価
する場合は、それらのシステムがダウンした場合にどのような事態が発生するか、システムはミッ
ションクリティカルまたはビジネスクリティカルか、システムがダウンした場合にも大半の業務
を継続できるか、失われたデータの復旧にどれくらいの時間をかけることが許容されるか、顧客
がシステムにアクセスできない場合にどのような影響が生じるか、といった点を検証しなければ
なりません。このような検証を行うと、考えていたよりも重要性が高いことが判明するシステム
が少なくありません。そうしたシステムについては、現行のものよりも厳しい RTO と RPO を
設定し、ビジネス継続性のためのサポートを強化する必要があります。さらに検証作業を進めた
結果、それらのアプリケーションやサービスがミッションクリティカルであり、ダウンした場合
にはビジネスに深刻な影響が生じることが判明するケースも考えられます。また現時点ではミッ
ションクリティカルでないシステムも、今後ミッションクリティカルになる可能性があることも
忘れないようにしてください。
P4
ベストプラクティスガイド
「クリティカル」とは何かを明確化
HPE では、ビジネスの効率的な遂行に不可欠なアプリケーションおよびデータを「ビジネスク
リティカル」、非常に重要性が高く、その停止が深刻な事態を招くアプリケーションおよびデー
タを「ミッションクリティカル」と定義しています。この基準に照らして、ご自身の組織において、
ミッションクリティカルなシステムが使用不能に陥った場合、あるいはミッションクリティカル
なトランザクションデータが失われた場合を考えてみてください。顧客に対してどのような影響
が生じますか。収益にはどのような影響が生じますか。データの喪失が法律やコンプライアンス
の問題に発展する恐れはありますか。
ビジネス継続性のためのサポートは、ミッションクリティカルなレベルからビジネスベーシック
なレベルに至るまで、あらゆるアプリケーションおよびデータを包括的にカバーしていなければ
なりません。この観点からのアプリケーションやシステムの重要性は、顧客のニーズや収益性に
基づき評価する必要があります。非常に高い可用性が求められる（ゼロまたはほぼゼロの RTO
が必要な）アプリケーション、あるいは損失が許されない（ゼロまたは、ほぼゼロの RPO が必
要な）データは、ミッションクリティカルと見なされます。
ダウンすることが許されない、
また
は誰にも気付かれない瞬時の復旧
が必要なアプリケーションは、
ミッシ
ョンクリティカルなアプリケーション
です。
コアアプリケーションとサービスの例を、以下に示します。
• 金融サービス : 支払処理、不正防止、高頻度取引
• 通信 : モバイルネットワーク管理、マシンツーマシン、リアルタイム顧客サービス
• 小売 : POS、e- コマース、オンライン取引、注文処理
• 製造 : 継続的な生産管理プロセスおよびマルチチャネル配送
• 医療 : リアルタイムの患者 / 検査データ、医療提供者情報の検索
• 交通 : 予約、発券、スケジュール管理
一般的に、常時稼働が原則となっている今日、相互接続された複雑な顧客向けワークロードのダ
ウンタイムは許されません。
P5
ベストプラクティスガイド
ビジネス継続性のための各種アプローチ
真のビジネス継続性を実現するためには、局所的な災害（データセンターの火災など）および地
域的な災害（地域の送電網の故障など）の両方を乗り切るために、一定水準の地理的な分散（隔
たり）が欠かせません。地理的に分散されたビジネス継続性インフラストラクチャを構築する手
法として、それぞれ RTO/RPO プロファイルが異なる、3 つの基本的なアプローチが存在します。
• 非同期アクティブ / パッシブ : これは昔ながらのディザスタリカバリ (DR) シナリオで、すべてのト
ランザクションがアクティブなシステム上で実行され、データはパッシブなバックアップノードに非
同期で複製されます。障害が発生した場合は、バックアップノード上でアプリケーションを起動す
るための時間を要し、RTO の値は大きくなりがちです。また、これらのアプリケーションを再起動
するためのフェイルオーバー手順は、テストや実行が複雑で、失敗するリスクも高くなります。
• 非同期アクティブ / ほぼアクティブ : Sizzling-Hot-Takeover (SZT) または Sizzling-Hot-Standby
とも呼ばれるこのアプローチは、複製を使用するアクティブ / パッシブアーキテクチャーに似てい
ますが、バックアップノード上でアプリケーションデータベースのローカルコピーが読み書き可能な
状態で常にオープンされており、即座にトランザクション処理を開始できる点が大きく異なります。
このアプローチは、すべてのユーザートランザクションがプライマリノードに送られることを除いて、
基本的にはアクティブ / アクティブアーキテクチャーです。そのためフェイルオーバーが発生した場
合に、旧来の DR 手法に比べて成功する確率が高く、より優れた再現性の高い RTO を実現でき
ます。
• 非同期アクティブ / アクティブ : ディザスタトレラントなアーキテクチャー内では、本稼働処理は複
数のノードに分散され、各ノード上では（双方向データ複製により同期される）データベースコピー
が実行されています。1 つのノードで障害が発生した場合、そのトラフィックは別のアクティブノー
ドへと自動的にルーティングされます。存続しているノードに接続されているユーザーが、障害の
発生に気付くことはありません。すべてのノードが常に動作していることがわかっているため、フェ
イルオーバーは、テストや実践が容易なシンプルなプロセスになります。
P6
ベストプラクティスガイド
ミッションクリティカルなアプリケーションの場合は、ディザスタトレラントなマルチノード
アーキテクチャーが最良の選択肢となり、最高の RTO と RPO を実現できます。言うまでもなく、
ビジネス継続性ソリューションの構築には、ソフトウェアベースのトランザクションデータ複製
から、ハードウェアベースのクラスタリングや RAID まで、さまざまなテクノロジーを活用でき
ますが、各テクノロジーが提供可能な RTO/RPO 機能には、それぞれ限界があります。
もう 1 つの考慮すべき事項が、データベース設計およびアプリケーションアーキテクチャーで重
要な ACID（Atomicity（不可分性）、Consistency（一貫性）、Isolation（独立性）、Durability（耐
久性））コンセプトの 1 つである、不可分性の問題です。不可分性とは、トランザクション処理
のための「オールオアナッシング」ルールを定義するもので、ある一時点で開始されたトランザ
クションが完了するまでの間に何らかの問題が発生した場合は、そのトランザクションがあたか
も実行されなかったかのように、開始時点まで完全に巻き戻すことを意味します。ビジネス継続
性アプローチを設計する場合、とりわけミッションクリティカルなアプリケーションについては、
この機構を組み込むことが必要です。
総所有コスト (TCO) の観点から捉
えた場合、旧来のアクティブ/パッ
シブ型DRアーキテクチャーのTCO
は、
ダウンタイムコストによって押し
上げられます。
TCOについては、一般的に次の法
則が成り立ちます。
• 可用性を高めるほど、複雑性と実
装コストが増大する
• 可用性を高めるほど、ダウンタイ
ムコストは減少する
すなわち実装コストが増大するほ
ど、全体的なTCOは、それよりは
るかに速いペースで減少していき
ます 4。別の言い方をすれば、 1 回
の障害で発生するコスト分の金額
で、フォールトトレランスを大幅
に強化することが可能です。
4
『幸運を祈るよりも、避けられない障害に備
えたビジネス継続性計画を策定』、
Gravic, Inc.、2015 年
（一次資料 : Ponemon Institute）
総所有コスト (TCO)
顧客に許容される範囲を超えるアプリケーションの停止を引き起こす、何らかの障害、事案、ま
たは災害が予見される場合は、ビジネスの喪失や評判の低下を回避するために、ディザスタトレ
ラントなアーキテクチャーを構築する必要があります。今日のソーシャルメディアの時代には、
顧客の不平不満は口コミですぐに拡散されます。ダウンタイムに関して厳格なコンプライアンス
要件が存在する企業の場合は、ディザスタトレラントなアーキテクチャーを構築することで、政
府から科せられる罰金や報告書などの負担も軽減できます。一例として、システムがダウンして
完全復旧までに 3 時間を要した場合、先に引用した IDC 調査による平均ダウンタイムコストをあ
てはめると、企業の損失額が 500 万ドルを超える恐れがあります。同じ障害が発生したとしても、
適切なビジネス継続性環境を構築していたために、わずか数秒で復旧できた場合、あるいはアプ
リケーションへの影響を回避できた場合には、損失額ははるかに小さくなります。
P7
ベストプラクティスガイド
ビジネスの継続性を支えるソリューション
HPE サービス
ヒューレット・パッカード エンタープライズでは、ビジネスクリティカルなデータセンターを
必要とするお客様が、災害に強いアーキテクチャーを構築できるように、豊富なスキルと経験を
有するプロフェッショナルによる、包括的なアドバイス、設計、導入、管理サービスを提供して
います。
HPE Integrity NonStop X
HPE Integrity NonStop X システムは、常時稼働を求められる業界向けに設計された製品で、最
高レベルの可用性、システムワイドなセキュリティ、優れた拡張性、およびクラス最小レベルの
TCO を特徴とします。IDC 社が定める高可用性レベルで最高の AL4 は、複数のハードウェア / ソ
フトウェアコンポーネントを組み合わせることで、代替リソースへのほぼ瞬時のフェイルオー
バーを実現し、中断なしにビジネスを継続できるレベルと規定されています 5。HPE Integrity
NonStop X を HPE NonStop Shadowbase ソフトウェアと組み合わせると、地理的に異なる複数
の場所にわたって AL4 のフォールトトレランスを実現し、卓越した可用性により計画的または
計画外のダウンタイムをゼロにすることで、アプリケーションの停止が発生する可能性をほぼ完
全に排除できます。可用性、拡張性、およびデータ整合性に優れたミッションクリティカルなコン
ピューティング環境を構築するために、HPE NonStop X の導入をご検討ください。
HPE XP ストレージ
HPE XP7 ストレージは、ハイブリッドフラッシュストレージとして設計されており、データの
継続的な可用性、拡張性、およびパフォーマンスを必要とするミッションクリティカルなアプリ
ケーションに最適です。アレイベースの仮想化テクノロジーは、マルチサイトおよびマルチアレ
イの仮想化、複製、および管理を可能にすることで、可用性の向上、災害の回避、およびストレー
ジサイロの排除によるリソース使用率の改善に貢献します。HPE XP7 ストレージは、HPE が提
供する最も可用性の高い SAN アレイで、優れた復旧、リモート複製、および DR 機能を提供す
る多数のソフトウェアソリューションが搭載されています。
5
『全世界および米国の高可用性サーバー 2014
∼ 2018 年 の 予 測 と 分 析 』、IDC 社、Doc
#250565
ベストプラクティスガイド
まとめ
ミッションクリティカルなシステムに影響を与える重大な事案は、「発生するかもしれない」問
題ではなく、
「いずれ必ず発生する」問題と捉えたうえで、発生した場合の影響を考えることが
大切です。持続的なディザスタトレランスを念頭に置いて設計されたビジネス継続性ソリュー
ションは、最善の復旧時間目標および復旧ポイント目標を、ビジネスにとって適正な TCO で実
現し、被害を最小限に抑制することを可能にします 6。
詳細情報
hpe.com/jp/nonstop（日本語）
hpe.com/jp/ja/storage/enterprise-xp（日本語）
hpe.com/info/dcm（英語）
『x86 上の高価値ビジネスアプリケーション :
真のフォールトトレラントシステムの必要
性』、Peter Rutten、IDC 社、2015 年 5 月
6
メールニュース配信登録
© Copyright 2016 Hewlett Packard Enterprise Development LP. 本書の内容は、将来予告なく変更されることが
あります。
ヒューレット・パッカード エンタープライズ製品およびサービスに対する保証については、当該製品および
サービスの保証規定書に記載されています。本書のいかなる内容も、新たな保証を追加するものではありません。本
書の内容につきましては万全を期しておりますが、本書中の技術的あるいは校正上の誤り、省略に対しては責任を
負いかねますのでご了承ください。
4AA6-5326JPN、2016年5月