もしもクラウドが止まったら【後編】

SLAがあっても「クラウド障害」には十分に備えるべき理由とは？

一般的にクラウドサービスでは障害への対策が充実しているが、サービス停止は発生する。ユーザー企業は、クラウドサービスにおけるSLAの内容や、サービス停止に陥った場合の対処法を知っておく必要がある。

公開 2024年02月29日 05時00分

更新 2024年02月29日 12時29分

著者

Brian Kirsch

[TechTarget]

印刷する連載新着通知を受け取る

　クラウドサービスの利点の一つは、自然災害や機器故障への備えが充実したインフラを利用できることだ。だがクラウドサービスのサービス停止は発生する。そうした事態を前提にして理解しておくべきなのが、サービス提供事業者とユーザー企業が交わす契約である「SLA」（サービスレベル契約）だ。このSLAを、誤解しているユーザー企業は少なくない。

SLAに違反するサービス停止時の補償は？

併せて読みたいお薦め記事

連載：もしもクラウドが止まったら

前編：いまさら聞けない「クラウドのSLA」　小数点の“大き過ぎる”違いとは？

システムに必要なレジリエンス

　仮にクラウドサービスが停止した場合、その影響は企業によって異なる。メールが1日利用できない場合、重要な問題にならない企業もあれば、事業を立ち直せないほどのダメージを受ける企業もある。

　サービスがSLAの水準を下回る時間停止した場合、サービス料金の一部はクレジットとして返金される可能性がある。この返金の割合をサービスクレジットと呼ぶ。

　例えば、あるサービスの利用料が1時間当たり20ドルで、8時間停止して50％が補償される場合は、80ドル戻ってくる計算になる。サービスクレジットは利用するサービスによって異なるので、SLAを確認しておくことが大事だ。

　注意すべきことは、事業の損失がどの程度であれ、発生したサービス停止による損失は補償されないということだ。補償されるのはサービス利用料だけであり、仮にサービス停止中に100万ドルの売り上げを失っても80ドルしか受け取れない。売り上げの一部を補償してもらえると思い込んでいる企業は珍しくない。

クラウドサービスの停止の影響を最小限に抑えるためには？

　サービス停止の影響を最小限に抑える方法として、アプリケーションや必要な機能を、2つの異なるクラウドサービスにデプロイ（実行環境に配置）する「マルチクラウドデプロイメント」という手法がある。他にも、1つのアプリケーションを分割して2つのクラウドサービスにデプロイする方法もあるが、冗長性が十分に確保できるとは言えない。

　冗長性を確保するには、両方のクラウドに同一のアプリケーションをデプロイすることが望ましいが、コストがかる。そのためマルチクラウドデプロイメントを採用する企業はまれだ。

　信頼できるバックアップの取得は、データを保護するために不可欠だが、サービス停止自体を防ぐことはできない。残念なことに、アプリケーションを動かすデータセンターがユーザー企業保有のものでない場合、ユーザー企業はその運営に関与できない。そのためデータセンターのサービス停止に関して、ユーザー企業がコントロールできることはほとんどない。クラウドサービスが停止しても、他の人と同じように列に並んで復旧を待たなければならない。

　大事なのは、リスクを認識しておくことだ。クラウドサービスの停止は発生する。常に100％安全ということはあり得ない。クラウドサービスで重大なシステム停止が発生する可能性はあるが、リスクを認識していれば、それに対処するための計画や復旧手順を準備できる。非効率的な手作業が必要になることもあるが、対処はできるはずだ。