クラウド移行で障害復旧は99%高速化？あるBEMSの事例から学ぶ、クラウドの驚くべき真実と見落としがちな「責任分界点」
多くの企業がシステムのクラウド移行を経営目標に掲げる中、「クラウド化」という言葉だけが先行し、その具体的な効果や注意点が見えにくくなっていないでしょうか。流行りの言葉の先にある、システムの信頼性や保守運用への具体的で、時には驚くべきインパクトとは何なのでしょうか。
本記事では、あるビルエネルギー管理システム（BEMS）のクラウド移行事例を基に、クラウドがもたらす現実を解き明かします。この事例から見えてきた4つの重要なポイントを通じて、クラウド移行の真の価値と、見落としてはならない注意点を明らかにしていきましょう。
--------------------------------------------------------------------------------
1. 衝撃：ハードウェア障害からの復旧時間が48時間から15分へ
オンプレミス環境における最大の課題の一つは、ハードウェア障害発生時の長いシステム停止時間です。この事例の顧客であるR社も、既存システムではハードウェア障害によってサービスが長時間停止することに悩まされていました。
しかし、IaaS（Infrastructure as a Service） 型のクラウド基盤サービス上に新システムを構築したことで、この状況は劇的に改善されました。以下の表は、非機能要件の一つである「可用性」に関する指標の変化を示しています。
|
非機能要件 |
指標 |
既存システム（オンプレミス） |
新システム（クラウド） |
|
可用性 |
ハードウェア障害時の平均サービス回復時間 |
48時間 |
15分 |
48時間からわずか15分へ――この99%以上もの時間短縮は、なぜ可能になったのでしょうか。理由は主に2つあります。
- 保守員の常駐による移動時間の撤廃：新システムが稼働するデータセンターには保守員が常駐しており、オンプレミス環境で発生していた「保守員の駆けつけ」という物理的な移動時間が完全にゼロになりました。
- 高度なクラウド機能の活用：新システムでは、「ライブマイグレーション」のような高度なクラウド機能が活用されています。これにより、物理サーバーに障害が発生しても、稼働中の仮想サーバーを停止させることなく別の正常な物理サーバーへ瞬時に移動させ、サービスを継続できます。
これは単なる運用改善ではありません。ビジネスにおけるリスク管理のあり方を根本から変える、戦略的な転換です。R社にとって48時間のシステム停止は、深刻な事業損失と信用の失墜に繋がりかねない重大なリスクでした。そのリスクをわずか15分という管理可能なインシデントレベルにまで低減できたことは、クラウド移行がもたらす極めて大きな価値と言えるでしょう。
しかし、こうしたハードウェアレベルでの驚異的な信頼性は、クラウドが提供する価値の半分に過ぎません。もう一つの大きな課題であった「計画停止」についてはどうでしょうか。
--------------------------------------------------------------------------------
2. 計画停止がゼロに？「アクティブ-スタンバイ」構成が実現する無停止メンテナンス
R社が抱えていたもう一つの大きな悩みは、サーバーメンテナンスに伴う計画的なサービス停止でした。既存システムでは年に4回も計画停止が必要であり、これは事業の速度を直接的に阻害し、顧客満足度を損なう要因となっていました。
クラウド移行後、この問題は「運用・保守性」の観点から完全に解消されました。メンテナンスに伴う計画停止の頻度が「ゼロ」になったのです。
これを実現したのが、「アクティブ-スタンバイ」構成です。これは、同じ機能を持つBEMSサーバーを2台用意する冗長化構成で、片方が稼働系（アクティブ）、もう一方が待機系（スタンバイ）として動作します。メンテナンス作業はまずスタンバイサーバーに対して行われ、その間もアクティブサーバーはサービスを提供し続けます。メンテナンスが完了したスタンバイサーバーをアクティブに切り替え、次にもう一方のサーバーのメンテナンスを行うことで、システム全体を停止させることなく保守作業を完了できるのです。
計画停止がゼロになるということは、サービス提供の機会損失をなくし、オペレーショナル・エクセレンス（卓越した業務遂行能力）を実現することを意味します。これもまた、クラウドがもたらす大きな変革の一つです。
ハードウェア障害と計画停止の両方を克服したことで、システムはかつてないレベルの可用性を手に入れました。しかし、この「高可用性」は口約束ではありません。クラウドの世界では、SLAという厳格な契約によってその品質が保証されるのです。
--------------------------------------------------------------------------------
3. 「月間サービス稼働率99.95%」の本当の意味：許される停止時間は月々わずか22分
クラウドサービスを契約する際に必ず目にするのが、SLA（Service Level Agreement：サービスレベル合意書）です。これは、クラウド事業者が提供するサービスの品質を保証する「約束」であり、その中でも特に重要な指標が「サービス稼働率」です。
この事例のクラウド基盤サービスでは、月間サービス稼働率として「99.95%」という目標値が設定されていました。この数字だけを見ると「ほぼ100%」と感じるかもしれませんが、具体的な時間に換算すると、その厳しさが分かります。
1ヶ月を30日間として計算してみましょう。
- 月間の総時間： 30日 × 24時間 × 60分 = 43,200分
- 許容される停止時間： 43,200分 × (100% - 99.95%) = 43,200分 × 0.05% = 21.6分
つまり、「稼働率99.95%」とは、1ヶ月の合計停止時間がわずか22分（小数点以下四捨五入）以内でなければならない、という非常に厳しい約束なのです。
さらにSLAは、目標未達の場合の「減額対応（返金ポリシー）」を定めています。例えば、月額利用料が20万円のサーバーで、実際の稼働率が99.5%まで低下した場合、約束との差（0.45%）に相当する 900円 が返金されます。ここで重要なのは金額の多寡ではありません。この仕組みが、サービス提供者のパフォーマンスに対して契約に基づいた金銭的なインセンティブを与えることで、オンプレミスの内部運用では曖昧になりがちな**「アカウンタビリティ（説明責任）」を明確化する**という点です。
SLAは、クラウドサービスの信頼性を測るための、明確で定量的な基準なのです。この契約上の保証はクラウドの大きな魅力ですが、その保証範囲を正確に理解することが極めて重要になります。
--------------------------------------------------------------------------------
4. クラウドのSLAは万能ではない：保証対象外となる「ソフトウェア障害」という落とし穴
強力な保証であるSLAですが、決して万能ではありません。特にIaaS型のクラウドサービスを利用する際には、どこまでがクラウド事業者の責任範囲で、どこからが利用者の責任範囲か、という境界線を正しく理解しておく必要があります。これは、クラウドの世界における**「責任共有モデル（Shared Responsibility Model）」**として知られる非常に重要な概念です。
クラウド事業者がSLAで保証するのは、あくまで自らが管理するインフラ部分です。具体的には、以下のようなハードウェアやネットワークインフラの障害が対象となります。
- CPUの障害
- ストレージの障害
- ネットワークインフラの障害
一方で、SLAの保証対象外となるものがあります。それが、**「ソフトウェアの障害」**です。
IaaSモデルでは、ハードウェア等のインフラは事業者が提供しますが、その上で動くゲストOS、ミドルウェア、そしてBEMSのようなアプリケーションの導入・管理は利用者の責任です。利用者が導入したOSの設定ミスや、アプリケーションのバグによってシステムが停止した場合、それは利用者の責任範囲となり、SLAによる保証は受けられません。
これは、クラウド移行における最も見落としがちな「落とし穴」の一つです。したがって、成功するクラウド戦略とは、単にシステムを移行することではありません。自社のチーム内に、ソフトウェアのライフサイクル管理や信頼性エンジニアリングといった新たな能力を育成することでもあるのです。ITチームの役割は、ハードウェアの保守から、より価値の高いアプリケーションレイヤーの安定稼働へとシフトしていきます。
--------------------------------------------------------------------------------
Conclusion
BEMSの事例が示すように、クラウド移行はハードウェア障害からの復旧時間を劇的に短縮し、計画停止をゼロにするなど、システムの信頼性と可用性を飛躍的に向上させる力を持っています。
しかしその一方で、SLAが保証するインフラの領域と、自社で責任を負うべきソフトウェアの領域を明確に区別する「責任共有モデル」の理解が不可欠です。クラウドという強力なツールを真に活用するためには、その恩恵だけでなく、新しい運用パラダイムに適応する必要があります。
最後に、一つ問いかけたいと思います。 「あなたの組織は、クラウドという強力なツールを使いこなす上で、その『新しいルール』を正しく理解し、備えることができていますか？」
