クラウド障害を見逃せば「SLA」の補償は受けられない？

　大規模なクラウドサービスの障害が国内外で相次いで発生している。AWS（Amazon Web Services）は2019年8月に東京リージョンで障害が発生し、AWS上で稼働する多くのサービスが一時停止した。同じくAWS関連で、2021年9月にはネットワーク障害が起こり、全日本空輸（ANA）の多くの飛行機に遅延が発生した。そのほか2019年11月にはマイクロソフトのOffice 365で障害が発生し、メールの送受信ができないなど、多くのビジネスマンを巻き込んだ。

　クラウドサービス提供会社のSLA（サービス品質保証）ではサービスの稼働率を示しているが、稼働率を下回った場合は保証を受けることができる。ただし、稼働率として計算する時間（年単位、月単位など）や受けられる保証は提供会社や提供サービス、利用者側の構成によっても異なる。


　たとえばAWSのケースとして、システム障害などに備えて、仮想マシンを複数のAZ（アベイラビリティゾーン、リージョン内の独立した区画）に構築する冗長構成（マルチAZ構成）の場合を見てみる。この場合では、月あたり99.99%の稼働率を保証しているが、コストの関係から1つのAZ内のみで構築していた場合は月あたり90%にまで、稼働率の保証は下がってしまう。

　補償内容で言えば、マルチAZ構成は利用料のうち10%の返金、1つのAZ内のみで構築した場合は100%の返金となる。マルチAZ構成で100%の返金となるのは稼働率が月あたり95%を下回った時である。1カ月（30日間）であれば36時間以上クラウドサービスが停止していないと100%の補償を受けられない。

　また、補償を受けるためにはサービスが停止していた証跡を付けた上でAWSサポートセンターに申請する必要がある。

　なお、SLAおよびその補償内容、手続き方法は変更されることがある。本稿で取り上げるやAWSやGCP、Azureのクラウドサービスを利用する際は、各社の公式サイトから最新のSLAを確認すべきだろう。

「クラウド」「オンプレ」を利用するメリットを比較

　ここまでであれば、クラウドサービスが信用できないものに思えてくる。しかし、それでもなおクラウドサービスは高い可用性があると筆者は考える。

　そもそもシステムを準備するのはオンプレミスでも可能だ。オンプレミスであればクラウドサービス提供会社の影響を受けず自由に構築でき、場合によってはクラウドサービスよりも高い可用性（稼働率）を実現することができる。

　しかし、AWS・GCP・Azureよりも高い可用性（稼働率）を実現するにはコストと手間が膨大にかかる。24時間365日でシステムが正常に動いているかを監視し、何か問題が起きればすぐに対処する必要もある。地震や津波といった災害が発生した場合を考えると複数の場所にシステムを作っておく必要がある。

　また、自前でデータセンターを持つ場合はシステムだけではなく、温度管理や空調、電源などにも気を配る必要がある。エンジニアの確保が難しくなっている昨今、それだけの体制を構築するのは難しい。

　すべてを自前で準備するのは現実的ではないが、どの範囲を外部に委託するのかを検討する際に、クラウドサービスは有力な選択肢の一つとなるだろう。システムを構成する要素ごとに、メリット／デメリット、費用対効果を考慮に入れた上で、クラウドサービスを選択することが必要である。

　とは言えクラウドサービスも停止することがある。利用者としてはそうしたリスクがあることも意識しながら、クラウド障害に備えなくてはならない。ここからはクラウド障害に備えて行うべき対策について解説していく。

【次ページ】クラウド障害に備えるべき「技術・体制・プロセス」の対策