こんにちは。「クロジカサーバー管理」コンサルティングチームの西原です。
どのようなサーバーであっても、障害発生自体をゼロにするということは難しいものです。どのような障害が起こりうるかを知っておき、事前に対策を考えておくことは大変重要になります。対処にかかる時間を大幅に短縮することや、障害発生のリスクを軽減することなどができるためです。障害には様々なパターンがありますが、この記事では、AWSの過去事例や対策事例について触れていきます。
AWSにおける障害発生の可能性
AWSは、セキュリティ信頼性の高いサーバーですが、障害発生の可能性はゼロではありません。もしもの時に備えて障害発生を想定した準備が必要となります。障害が発生した際には、なるべく早く情報を集めることが大切です。動作に違和感がある場合には、AWSにログインして、ダッシュボードに通知が来ていないかを確認します。また、公式障害情報サイトの「Service Health Dashboard」 にも、障害情報が掲載されます。しかし、公式サイトの掲載はリアルタイムではないため、非公式情報ではありますが、Twitterの情報収集が便利です。
起こりうる障害の種類
起こりうる障害には大きく分けると「AWS側に発生要因がある障害」「ユーザー側に発生要因がある障害」「いずれでもないもの」の3種類があります。「AWS側に発生要因がある障害」としては、主にシステム障害や人為的ミスがあります。冷却システムの障害や基盤の障害などで、サーバーが稼働できなくなるといった場合はこちらに該当します。「ユーザー側に発生要因がある障害」としては、主に人為的なミスなどがあります。「人為的なミスでないもの」には、地震や豪雨、台風、落雷などの不可抗力による障害などがあります。
過去の障害事例
実際、過去に起きたAWSの障害事例にはどのようなものがあるか紹介していきます。
東京リージョンでの障害
2019年8月におきた東京リージョンでの大規模障害です。冷却システムの障害で、主にEC2・EBSに影響がありま した。AWS側の要因による障害事例になります。東京リージョンのデータセンターの一つにおいて、冷却システムに障害が発生し、サーバーの温度が上昇したため、オーバーヒートしました。その結果サーバーの電源が停止し、他のサービスにもパフォーマンスの低下が発生しました。約3時間後に空調は回復しましたが、全面回復にはさらに時間が必要でした。
米国東部リージョンでの障害
2017年3月に起きた米国東部リージョン（us-east）での大規模障害です。人為的ミスによる障害で、S3、EC2、S3を利用するサービスなどに影響が出ました。AWS側の要因による障害事例になります。人為的な操作ミスにより、S3 APIが利用不可になったことが原因でした。
その他
天災によるAWSの障害事例に、2011年8月に欧州リージョン（eu-west）での落雷停電による障害があります。電力会社の変圧器が落雷により壊れてしまい電力の供給が止まりました。その影響でEC2、EBS、RDSに障害が発生しました。 また2016年6月にも、オーストラリアの豪雨による障害発生がありました。シドニーに大規模な停電や通信障害が発生したためEC2の一部に障害が発生しました。
障害対策
障害は、突然発生し発生自体を止めることはできません。障害は、いつか発生するという前提で障害が発生してもサービスが継続できるような設計を行うことが必要です。
リスク分散設計
サービスを中断させないためには、単独のAZ（Availability Zone）での運用ではなく、複数のAZにリソースを分散させて運用することにより、障害リスクを分散させることができます。
Auto Recovery
AWSのEC2には、標準機能として「Auto Recovery」 があります。「Auto Recovery」 は、基盤側の障害を探知して自動復旧してくれるサービスです。多少サービスが停止しても問題ないシステムであれば、この機能で対処できます。しかし、物理的にホストが壊れている状態では、自動復旧が失敗するケースもあるため、決して止められない銀行などのシステムでは不安が残ります。
バックアップ
バックアップすることによって、確実にバックアップした時点の状態に戻せるため有効な手段です。しかし、バックアップをとった時点の状態にしか戻すことができないため注意が必要です。障害が発生した時点での状態とは、異なる可能性があリます。さらに、バックアップから復旧させるには時間がかかるため、即座に復旧させることが難しい場合もあります。バックアップのみに頼るのではなく、他の手段と組み合わせることをおすすめします。
障害への補償
AWS側に要因がある障害も起こる可能性はあります。しかし、継続的なサービスの提供を行うことが前提のビジネスでは、障害の発生がビジネスの中断につながってしまいます。その場合には、AWSを通したサービスの提供ができなくなりビジネスで損害が発生することもありえます。AWSによる障害でサービス停止が発生し一定期間障害が続いた場合には、SLA（Service Level Agreement）サービスレベル合意の規定が適用されます。
SLAは、サービス開始時に合意する規定です。SLAには稼働率目標を下回った場合に、どのような補償をするかが提示されています。AWSからの返金や次回支払いからの相殺が規定されている場合もあります。しかし、障害が発生しても一律に返金対象になるわけではありません。契約者による申告やログ提出などの条件が規定されているため、条件を満たさないと返金対象にはなりません。複数サービスを利用している場合の返金条件や契約者が行うべきことなどは事前に確認しておきます。
さいごに
人為的なミスやシステム障害、災害などの不可抗力による障害などは、いつ発生するか分からないものです。しかし、リスクをできるだけ減らす設計を行うこと、障害を想定した準備をすることで、障害による影響を最小限にすることは可能です。対策は事前によく検討しておくことをおすすめします。
コーポレートサイトをクラウドでセキュアに
無料ではじめるサーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカサーバー管理の主な機能
- 導入事例
- 導入までの流れ
