こんにちは。ＳＣＳＫの池田です。
日々お客様と接するなかで、「クラウドに移行したら、可用性は考えなくても良いのでは」と考える経営者や情報システム担当者が少なからずいらっしゃいます。確かに、AWSやAzure、Google Cloudなどの主要クラウド事業者は99.9%以上の稼働率を謳い、堅牢なインフラを提供しています。しかし、この認識には重大な誤解があります。クラウド事業者が保証するのは「インフラ」の可用性であり、アプリケーションやミドルウェア、データの整合性までは責任を負いません。本記事では、クラウド環境における可用性の盲点と、LifeKeeperをはじめとするHAクラスタ製品がいかにしてリスクを極小化するかを解説します。
クラウド事業者の「可用性保証」とは何か
クラウド事業者のサービスレベルアグリーメント（SLA）をよく読むと、保証の範囲が明確に区切られていることに気づきます。一般的に、クラウド事業者が保証するのは以下のレイヤに限られます。
- 物理サーバー・ストレージ・ネットワークの稼働
- ハイパーバイザーによる仮想化基盤の安定動作
- データセンター全体の電源・冷却・物理セキュリティ
これは、言い換えると「電力会社が『停電しない』と保証する」のと同じです。電力会社は電力は供給し続けますが、その電力をもとに動いている工場の機械が壊れないことや、製品が不良品にならないことまでは保証しません。クラウドも同様に、仮想マシンは動き続けますが、その上で動作するOS、ミドルウェア、アプリケーションの停止やデータの不整合までは責任を負わないのです。
実際、クラウド環境でのシステム停止の多くは、インフラ層ではなく上位レイヤで発生しています。OSのパニック、データベースの障害、ミドルウェアの設定ミス、アプリケーションのメモリリークなど、これらはクラウド事業者のSLA対象外であり、利用企業が自ら対策を講じる必要があります。
オンプレとクラウドで変わらない「本質的なリスク」
オンプレミス時代のシステム停止要因を振り返ってみましょう。ハードウェア故障は確かに存在しましたが、実際の停止の多くはソフトウェア起因でした。OSの不具合、アプリケーションのバグ、人為的な設定ミス、メンテナンス中の事故など、これらはクラウドに移行しても消えません。
むしろ、クラウド環境では新たなリスクも増えています。物理機器が見えないことによるシステム構成把握の困難さ、マルチリージョン構成の複雑さ、API連携の増加による障害伝播のリスクなど、管理すべき対象が増えているのです。
「インフラは任せられる」という安心感が、かえって可用性対策の甘さを生み出しています。オンプレミス時代は自社でサーバーを抱えていたため、停止の恐怖が身に染みて対策を講じていました。しかしクラウド移行後は「何かあってもクラウド会社が直してくれるだろう」と、つい油断してしまうのです。
OSより上位レイヤ——ここが可用性の境界線
クラウド事業者の責任範囲と企業の責任範囲の境界は、OSのレイヤにあります。仮想マシンの起動自体は保証されますが、その中で動作するOSのクラッシュ、データベースの障害、Webサーバーの停止など、これらは全て利用企業の対応領域です。
例えば、AWSでEC2インスタンスが突然応答しなくなる事態を想定してください。AWSのダッシュボードでは「インスタンスは実行中」と表示されていても、OS内でカーネルパニックが発生し、サービスは完全に停止している。こうした事態は決して珍しくありません。
この時、AWSは何もしてくれません。インスタンスは「稼働」しているのですから、SLAは履行されているのです。復旧作業は全て利用企業の責任となり、停止時間はそのまま事業損失に直結します。
データベースの障害も同様です。クラウド環境であっても、持ち込みライセンス（BYOL）方式で独自に構築・運用している場合、その責任はオンプレミス時代と何ら変わりません。クラウド事業者は仮想マシンの稼働を保証するだけです。データベースの要件に合わせたOS・ネットワークの設計、インストール、設定、チューニング、障害対応は全て利用企業の責任です。
具体的には、以下の事象は全て自社での対応が必要です。
・論理的な不整合：アプリケーションバグによる不正データの登録、外部キー制約違反、トランザクションログの破損
・パフォーマンス障害：長時間実行クエリによるテーブルロック、コネクションプールの枯渇、インデックス欠損による遅延、メモリ不足
・レプリケーション遅延・分岐：マスターとスタンバイ間の同期遅延、ネットワーク分離時のスプリットブレイン、フェイルオーバー後のデータ欠落
バックアップの設定も自社の責任です。自動化の有無、保持期間、暗号化、別 region へのコピーなど、これらを自社で設計・運用しなければなりません。リストアの実行判断、データ整合性の確認、RTO（目標復旧時間）/RPO（目標復旧時点）の設計も、全て利用企業が行う必要があります。
「クラウドに載せたから任せられる」という認識は完全に誤りです。むしろ、オンプレミス時代のインフラ担当者が抱えていた知見が分散し、クラウドの複雑性が加わることで、可用性リスクは増大していると言えます。
LifeKeeperが実現する「クラウドを超えた可用性」
このような課題に対し、SCSKが推奨するのがサイオステクノロジー社の「LifeKeeper」を用いたHAクラスター構成です。LifeKeeperは数十年の歴史を持ち、世界中で90,000ユーザーライセンスの導入実績を誇る高可用性ソフトウェアです。
LifeKeeperの最大の特長は、OSより上位レイヤのミドルウェア、アプリケーション、さらにはデータの整合性までを統合的に監視・保護できる点です。単なるサーバーの死活監視に留まらず、サービスプロセスの状態、アプリケーションの応答性、SQLクエリーの発行可否までを多角的にチェックします。
クラウド環境での具体的な機能として、以下が挙げられます。
- クラウドネイティブなフェイルオーバー：同一リージョン内のAvailability Zoneを跨いだ冗長構成、リージョン間のディザスタリカバリを自動化
- データのリアルタイム保護：ストレージレプリケーションによるRPO（目標復旧時点）の最小化、スプリットブレイン防止機能
このため、単一の仮想マシンやデータベースインスタンスの障害が即座に検出され、待機系への自動切り替えが実行されます。利用者にとっては一瞬の接続切断で済み、ビジネスへの影響を極小化できます。
「クラウドだから不要」は危険な幻想
クラウド移行における可用性対策の見直しは、コスト削減の観点からも重要です。
なぜならLifeKeeperは、オンプレミスで培った可用性設計のノウハウを、そのままAWSやAzureに展開することができます。
これにより同じLifeKeeperの操作感で可用性を担保でき、学習コストや運用リスクを抑えられます。
最も重要なのは「安心感」です。インフラの可用性はクラウドに任せ、自社はアプリケーションの価値創造に集中する。この理想を実現するためには、OSより上位のレイヤを自ら保護する仕組みが欠かせません。LifeKeeperは、その境界を明確にし、企業が責任を持つべき部分を確実に守るための基盤となります。
まとめ
今回は、クラウド移行における可用性の誤解と、LifeKeeperをはじめとするHAクラスター製品の価値について解説しました。クラウド事業者はインフラの可用性を保証しますが、OSより上位のミドルウェア、アプリケーション、データの整合性までは企業自身の責任です。「クラウドに移行したから安心」という考えは、予期せぬ停止リスクを招く危険な幻想です。オンプレミス時代以上に、クラウド環境では包括的な可用性設計が求められます。システム停止リスクに不安があり、事業継続性を本気で考えたい場合は、ぜひSCSKにご相談ください。
詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで
