そもそもSLAとは？

SLAとは、提供されるサービスのレベルにまつわる合意水準を指します。正式名称は「Service Level Agreement（サービスレベルアグリーメント）」です。

サービスなどの、形の無いものを売買する上で、そのサービスレベルの定義を明確することにより、提供者と利用者の認識に食い違いが出ないようにする役割を持ちます。

AWSで起こる可能性のある障害

どのようなシステムでも、障害が発生する可能性は少なからずあります。

AWSもその例に漏れず、起こり得る障害には、AWS側が原因で起こるもの、ユーザー側が原因で起こるもの、不可抗力で起こるものの3種類があります。

万が一の出来事に備え、正しい対策を平常時から取っておくことが重要です。そのためには、どのような種類の障害が起こり得るのか知ること、そして実際に起きた大規模な障害について理解を深める必要があります。

AWS SLAの7つの注意点

AWSのSLAについて、知っておきたい注意点が7つあります。

それは、申告しなければ返金されないこと、場合によって返金額が少なくなること、障害があったサービスのみ返金対象であること、返金方法が現金ではなくサービスクレジットの発行であること、使い方次第では返金対象にならない可能性があること、逸失利益の補填がないことです。

それでは、この7つの注意点について詳しく説明していきます。

AWS SLAの注意点1：申告しなければならない

AWS SLAの注意点の1つ目は、「AWSは障害が生じて損失が発生した場合、返金を申告する必要がある」という点です。

アマゾンにクレジットを請求し、それが受領されなければ返金されません。

請求の際には「SLAクレジットの請求」と件名欄に表記し、使用が不能となった請求対象日時と該当するAWS地域を記載します。さらに、請求対象日を裏付けるリクエストログを提示する必要があります。

AWS SLAの注意点2：場合によって返金額が少ない

AWS SLAの注意点の2つ目は、「場合によって返金額が少ない」という点です。

通常、AWSのサービスは月間の稼働率が95.0%未満ならば全額返金の対象になりますが、中には例外があります。

例えばAuroraの場合は、月間の稼働率が 99.99% で全額返金となり、RDSの場合は、月間の稼働率が 99.95% で全額返金となります。しかし、それに満たなければ数割程度のみしか保証されません。

AWS SLAの注意点3：障害があったサービスのみの返金

AWS SLAの注意点の3つ目は、「障害があったサービスのみの返金」であるという点です。

例えば AWSにて、EC2とRDSとS3を組み合わせたECサイトで、丸一日S3の動作が停止したと仮定します。

S3の停止によりサイト自体が完全に停止してしまい、利益が大幅に下がった場合でも、その全額が保証されることはありません。S3の障害であれば、S3分の返金しかされないのです。

AWS SLAの注意点4：サービスクレジットの発行

AWS SLAの注意点の4つ目は、AWS の場合「現金での返金」ではなく「サービスクレジットの発行」となっている点です。

サービスクレジットとは、翌月以降の支払いに使えるクーポンのようなものです。

例えば 、RDSのSLAの場合、「サービスクレジットは、ユーザーが将来支払うこととなるAmazon RDSの支払いに対してのみ使える」となっています。

AWS SLAの注意点5：SLAがないケースがある

AWS SLAの注意点の5つ目は、「SLAがないケースがある」という点です。

2019年の3月まで、SLAのあるAWSサービスは、わずか8個しかありませんでした。しかし、2019年3月にSLA対象のサービスが格段に増加し、9割以上のサービスへとSLAが規定されることになりました。

しかし、少数とはいえSLAの無いAWSサービスも未だにあります。サービス導入の前に、SLAの有無を確認しておくことをおすすめします。

AWS SLAの注意点6：使い方次第では返金対象にならない可能性がある

AWS SLAの注意点の6つ目は、「使い方次第では返金対象にならない可能性がある」という点です。

例えば、Amazon RDSのSLAの場合、対象は複数台のインスタンスによる構成にした場合です。よって、単一のインスタンス構成では、SLAの対象外となってしまいます。

さらに、自然災害が原因の停止など、AWSに関係の無い障害の場合も、返金されない可能性があります。

AWS SLAの注意点7：逸失利益の補填がない

AWS SLAの注意点の7つ目は、「逸失利益の補填がない」という点です。

SLAはそもそも、通信速度やサービスの定義、利用を停止する時間などの項目を決めて、そのサービスのクオリティが保証値に満たなかった場合、料金が減額されるというシステムです。

しかし、この減額の値はサービスの利用料金が上限となっている場合が多く、AWS障害による逸失利益は保証の対象外となっているのです。

AWSの障害に備えた対策方法4つ

いつ起こるか分からないAWSの障害に備え、取っておきたい対策方法が4つあります。

リスクを分散した設計で運用すること、監視体制と復旧体制をしっかり構築すること、EC2インスタンスを単一で使わないこと、SNSやサービス、サイトなどを利用してAWSの障害に関する情報を収集することです。

それでは、この4つの対策法について詳しく説明していきます。

AWSの障害に備えた対策方法1：リスクを分散した設計で運用する

AWSの障害に備えた対策方法の1つ目は、リスクを分散した設計で運用することです。

東京リージョンで生じた大規模障害の際、単独のAZで運用をされていたシステムはダウンしましたが、複数のAZで運用が行われていたシステムは停止を免れました。このように、幾つかのAZへと、リソースを分散させておくと難を免れる可能性が上がります。

したがって、あるリージョンやゾーンに障害が生じたとしても、別のゾーンに置かれたサーバーが、その後ろ盾の役割を担い、早急な復旧が可能となるような、リスクの分散された設計が重要であると言えます。

AWSの障害に備えた対策方法2：監視体制・復旧体制をしっかり構築する

AWSの障害に備えた対策方法の2つ目は、監視体制・復旧体制をしっかり構築することです。

AWSに作成した自社サービスに異常が無いか、Amazon CloudWatchを活用して監視体制を構築する必要があります。Amazon CloudWatchを利用することにより、AWS のサービス、リソース、アプリケーションを把握することが出来ます。

それと同じように、ログ、イベント、およびメトリクスという形でモニタリングのデータと運用のデータを収集して、自動化されたダッシュボードを使用することで、それらを可視化することが出来ます。

AWSの障害に備えた対策方法3：EC2インスタンスを単一で使わない

AWSの障害に備えた対策方法の3つ目は、EC2インスタンスを単一で使わないことです。

AWSのホームページによると、EC2インスタンスを単一で使った場合、SLAは90%とされています。1日単位で考えると、24時間のうち稼働が保証されるのは約21.6時間となります。つまり、残りの約2.４時間は保証をしてくれないということになります。

EC2インスタンス上で常にシステムを稼働させ続ける必要がある場合、それでは心もとないと言えるでしょう。

AWSの障害に備えた対策方法4：AWSの障害に関する情報を収集する

AWSの障害に備えた対策方法の4つ目は、AWSの障害に関する情報を収集することです。

AWS上で障害が生じた場合は、可能な限り早急に、生じている障害についての情報を収集することが必要となります。そのための方法には様々なものがあります。

1つはTwitterです。@awsstatusjpというアカウントで、東京リージョンの障害情報がツイートされます。

もう1つはダッシュボード表示です。コンソールにログインをする際、右上のアラート欄にご注目下さい。障害に関する情報が表示されている可能性があります。

AWSでこれまでに発生した障害とその原因

AWSの障害はいつ何が原因で起こるのか予測出来ません。

したがって、万が一の事態に備えて、平常時から正しい対策を取っておくことが重要であり、そのためには、実際に起きた大規模な障害について詳しく知る必要があります。

ここからは、これまで実際にAWSで起こった大規模な障害について紹介します。

東京リージョンの大規模障害

2019年8月23日、サーバーの電源が次々と停止し、EC2を始めとするサービスのパフォーマンスが劣化していくという大規模障害が生じました。

原因はAWSの東京リージョン内のデータセンターにて、冷却システム障害が発生したことです。

復旧されるまでの間、ゲームサイトやキャッシュレスサービスサイト、大手ショッピングサイトなどでもサービスが停止されるなど、深刻な影響を及ぼしました。

米国東部リージョンの大規模障害

2017年3月1日、米国東部リージョンにて、S3 APIの利用が出来なくなるという大規模な障害が発生しました。

原因はAWS側の人為的な操作ミスです。サーバの削除を行おうとした際に、コマンドの入力が適切でなかったため、想定以上のサーバが削除されてしまったのです。

これにより、AWS Lambdaを含め、米国東部リージョンにおける、S3をストレージとして利用するその他のAWSサービスにも大きな影響が生じました。

AWSのSLAはサービスによって保証条件が違うので注意しよう！

AWSサービスを始め、どんなシステムでも障害が発生する可能性はゼロではありません。起こり得る障害のパターンを理解し、それらに対応する対策を正しく立てる必要があります。

障害の対応には、単に対策を構築するだけでなく、ありとあらゆる事態を想定した復旧の予行演習を常日頃からしておくことが重要となります。

また、AWSのSLAはサービスによって保証条件が違いますので、十分注意しましょう。