こんにちは。やましーです。
突然ですがクラウドサービスはダウンしてその間サービスをまったく使うことができなくなることがあります。
例えば2019年8月23日にはAmazonのAWS、2019年5月3日にはMicrosoftのAzureで大規模な障害が起きています。
- え？クラウドって落ちるの？
- 原因は？
- 対策ってどうすればいいの？
- その間の保証は？
こういった疑問を持たれたと思います。
また、一度障害が起きると、社会的な影響の大きさから世間でもニュースになったりもします。
私の場合ですと構築したシステムのお客様からは「うちのシステムは大丈夫なのか？」など問い合わせを受けることがあります。
ということで、今日はクラウドでシステムやサービスを構築するときに考慮しておかなければならない「クラウドサービスの大規障害についてその原因と対策」を解説したいと思います。
クラウドサービスダウン対策
いきなり結論です。どのような対策を打てばいいのでしょうか。
クラウドサービスはダウンするもの。これを受け入れ、その上でいかに停止しないサービスを構築かがカギとなってきます。
ポイントは３つです。
- 複数のリージョンや可用性ゾーンで分散するように構築する。
- リージョンの概念がないサービスへの対策を行う。
- 復旧手順を確立しておく。
このポイントがなぜ有効なのか、過去の事例を紹介しつつ説明したいと思います。
AWSの障害の影響と原因
2019年8月23日にAmazonのクラウドサービスであるAWSが障害に見舞われました。
AWSの障害の影響
これにより最大約10時間に渡って、AWS上で構築したシステムやサービスが利用できないなどの影響がありました。
そのサービスの中にはネット通販サイトやQRコード決済でおなじみの「PayPay」が利用できないなど大きな影響がありました。
例えば一日１０万円売り上げるネット通販サイトであれば１０時間の停止で約４万円の損失です。
しかしそれ以上にクレーム対応であったり、影響調査や原因調査、復旧対応など様々なことに時間がとられてしまい、最悪の場合、顧客離れにもつながってしまいます。
AWSの障害の原因
Amazonの発表によると原因は
東京リージョン（東京地域）にあるデータセンターには無数のコンピューターがあります。そのコンピューターを冷却するための空調がうまく動作せず、室内の温度が高くなりすぎ、コンピューターがダウンしてしまったとのことでした。
Azureの障害の影響と原因
2019年5月3日にはMicrosoftのクラウドサービスであるAzureでは世界的に大規模な障害に見舞われました。
Azureの障害の影響
Azureへアクセスが出来なかったり、Office 365のSharePointや、Microsoft Teamsへのアクセスが不安定になったりといった影響がありました。
日本ではゴールデンウィークの早朝（ 午前4時43分から午前7時35分 ）ということで被害の影響はあまり大きくなかったようです。
もしこれが平日の昼間であればその影響の大きさは計り知れないですね。
Azureの障害の原因
米Microsoftの発表（原文はすでに見ることができませんが）によると原因は
Office 365にアクセスするためにはURLからIPアドレスに変換しなくてはなりません。このIPアドレスへの変換はDNSサーバーが行っています。
今回は MicrosoftがこのDNSサーバーへ設定をする際、４台のうち１台が誤っていたことにより正しくIPアドレスが取得できず、Office 365やAzureへアクセスができない問題へと発展してしまいました。
クラウドサービスがダウンしたときの対策
いずれも原因となっている問題に対してクラウドを使う我々は対処することができません。
ここまで聞くと、 だったら、クラウドサービス事業はどこまで保証してくれるのか ？そうはいってもサービスが止まると困る。そう考えてしまいますよね。
では、クラウドサービス事業者はどこまで保証してくれるのでしょうか。
クラウド事業者の保証それがSLA
AmazonやMicrosoftといったクラウド事業者と契約をする際にSLA（サービスレベルアグリーメント）と呼ばれる取り決めを行います。（取り決めといっても一方的にですが）
これはクラウドサービス事業者がこのレベルまで品質を保証しますよといった取り決めです。
例えばAWSでは種々の条件はありますが仮想サーバーSLAは99.99％としています。
これはどういう意味かというと、一か月の間に5分間以上サーバーが落ちてしまった場合は月間使用料の10%を返金するというものです。
月間の使用料が１０万円のサーバーであれば１万円の返金ということですね。
注意しなければならないのは、構築したサービスが稼働できなくて発生した損害については特に補償は無いということです。あくまで支払った金額のうちいくらかが返金されるだけなのです。
クラウドはダウンするものということを前提に
結局クラウドサービスはダウンするものということを設計段階で考慮して、可能な限りあなたが提供するサービスやシステムを停止させないように構築するということです。
設計するポイントとしては３つあります。
- 複数のリージョンや可用性ゾーンで分散するように構築する。
- リージョンの概念がないサービスへの対策を行う。
- 復旧手順を確立しておく。
複数のリージョンや可用性ゾーンで分散するように構築する
AWSやAzureでは東日本リージョンと西日本リージョンとして地域を分けて、片方がダウンしてももう片方に影響がないようにサービスが提供されています。
また、同じリージョンの中でも複数のデータセンターがありそれぞれが別々の可用性（availability)ゾーンとして独立して、１つの可用性ゾーンが不能に陥ったとしても別の可用性ゾーンに影響が出ないようにサービスが提供されています。
あなたがサービスやシステムを構築する場合、１つのリージョンだけに構築するのではなく、複数のリージョンに分散して構築したり、１つのリージョンであっても違う可用性ゾーンにシステムを構築することで、障害に強くなります。
これによりAWSの空調設備による障害を回避することができます。
もちろん、分散するとコストに跳ね返ってきますが、単純に２リージョンに構築したからと言って２倍になるわけではありません。
コンピューター１０台を１リージョンに構築するのを５台ずつ２リージョンに構築するとコンピューターの台数自体は変わらないためコストが高くなるわけではありません。
クラウドサービスではデータセンターの外に通信が外に出る場合にその通信量に応じて料金がかかります。
また、リージョンが違うということは距離が離れるということなので、数ミリ秒の通信遅延が発生するのでそういった点をしっかりと考慮する必要があります。
リージョンの概念がないサービスへの対策を行う
Azureの大規模障害の事例について、DNSなどリージョンの概念がないサービスの障害について対策を打つ必要があります。
この例では複数のDNSサーバーを採用するよう検討したり、マルチクラウドを採用し、そもそも別のクラウドサービスも併用して使うなど検討すると良いです。
復旧手順を確立しておく
基本的には復旧はクラウドサービス事業者側で迅速に行われますが、いつ復旧するかわかりません。
そこで、自分の手で別のリージョンや、可用性ゾーンで作りなおすというのもの１つの手です。
そのために日々バックアップを取り、そのバックアップを別の場所で展開してサービスを再開しても問題ないかなどを検証し復旧手順を確立しておくと良いです。
まとめ
クラウドサービスが一部不能に陥った場合でもあなたが構築したサービスを継続させるための対策を紹介しました。
もちろん、対策を講じるとコストに跳ね返ってくるので、提供するサービスが停止したことによるリスクをどう捉えるかが大切になってきます。
年に１度あるかないかのリスクに備えてコスト増を許すのか、それともリスクを許容して、サービス停止を許すかは事前に合意を取っておくべき事項になります。
しっかり対策を提案して、周りから一目を置かれる存在になりましょう！
以上、最後までお読みいただきありがとうございました。
やましーでした。
