IaaS障害はどこでどうやって起きるのか？ ユーザー企業が受けるサービスダウン以外の影響とは（2/2 ページ）

日本では官民でIaaSの活用が進んでいるが、大手クラウドサービスの影響力が増した分、障害発生時の影響の大きさも目立ってきた。IaaS障害に対処するには、障害が発生する場所と原因、影響範囲を知り、冗長性確保や責任の明確化などを行うのが重要だ。

[谷井将人，ITmedia]

IaaS障害には“なすすべなし”なのか

　では、これらの被害を受けないためにはどうすればいいのか。横田氏によると別々の地域のデータセンターにサーバを分散させているケースが多いという。いわゆる冗長化という手段だ。

　IaaS障害が起きる場所はデータセンター全体、一部の部屋、一部のサーバやインスタンス、起きる原因は災害やオペレーションミスという話だった。起きる場所の最も大きいくくりがデータセンターであることからも分かるように、複数のデータセンターで同時に障害が起きるというのは考えにくい。違う場所にあるデータセンターで同時に空調設定をミスするだろうか。東京と大阪のデータセンターで同時に災害が起きる場合は、IaaSより自分の命を心配したほうがいいのではないか。

　冗長化すれば、1か所で問題が起きても、もう1か所が通常通り動いていればサービスやシステムを維持できる。データセンターを分けるとIaaSの運用コストがかさみすぎる場合は、同じデータセンター内で冗長化する方法もある。別々の部屋にあるサーバにデータを分散させておけば、大規模災害などでデータセンター全体に問題が起きない限りはほとんど問題ない。

　データセンター管理者やクラウドサービスベンダーも災害対策は取っている。ほとんどのデータセンターで停電などに備えた予備電源を用意している。さくらインターネットの場合は災害の少ない場所にデータセンターを建てるなど、立地を選ぶ時点から対策が始まっている。

　それでも災害は起きるときには起きる。18年の北海道胆振東部地震では北海道全域で大規模停電が起きた。さくらインターネットの石狩データセンターは非常用電源で電力復旧までの60時間を耐え抜いた。1つのデータセンター内で冗長化する場合は、データセンターの災害対策について事前に確認しておくのもいいだろう。

石狩データセンターの設備

　もし、IaaS障害が起きたらサービスや事業に大きな損害が起きるミッションクリティカルなシステムを運用する場合、保険に保険を重ねるなら複数のクラウドサービスを契約して冗長化するマルチクラウド環境を検討するのも一つの手だと横田氏は言う。

　もう一つ重要なのが、あらかじめ責任の所在や補償基準を確認しておくことだ。当たり前だが、クラウドサービスベンダーはIaaSの品質について責任を持っている。しかし、IaaSをユーザーが使う上で起きたすべての不具合について補償するわけではない。ユーザー側で発生した問題はユーザー側の責任になる。

　クラウドサービスベンダーが品質保証の基準として設けているのがSLA（Service Level Agreement）だ。「サーバの稼働率を99.95％以上に保つ」といった基準を定め、設定値を下回れば利用料を減額するなどの補償措置をとる。補償の適用基準もあり、これらを事前にすり合わせておくことで、障害発生時の素早い対応が可能になるのがメリットだ。

　IaaS障害に巻き込まれた場合、ユーザーがデータセンターに行って不具合を解消できるわけではなく、復旧を待つしかない場面も多い。だからこそ、あらかじめそれを理解して冗長化などの対策をすることで、IaaSの利点を余すことなく享受できるようになるのだ。