AWS大規模障害とインフラ設計について

2019年8月23日（金）AWSの大規模障害が発生し、大手サイトやクラウドサービスなど、多くのサイトが影響をうけました。
Twitterが一番情報が早く、「これうちだけかな？」と思ったときの情報源としては最適だと思います。今回もとても役に立ちました。

情報の中で「マルチAZにしてないサービスが浮き彫りになったね！」という意見がいくつもありましたが、すこし気になりました。影響を受けたユニクロ・楽天・PayPayなど、大手のサイト・サービスがシングルAZ構成で動いているとは思えないですよね。
いろいろ考えても推測で終わってしまうので、このあたりの情報が公開されるといいな。と思います。

さて、喉元すぎればなんとやらという格言もあるとおり、終わると忘れてしまうので、いい機会なのでSLAについて整理してみます。システムのSLAではなくインフラのSLAについて。

前提として、受託開発でクライアントのサービスを保守・運用サポートしているイーツー・インフォの場合を記載しています。

可用性とコスト・対応範囲

どれくらいのSLAを提案するか

厳密にSLAを定めることは少ないですが、おおよそ営業時間内SLA99%くらいで設計することが多いです。その場合、月間のサーバ停止時間が6～8時間くらい許容される（はず）。

どのような提案をするか

シングルリージョンで設計しています。
バックアップからの復旧＆とりあえず最低構成での再構築が１日で完了し、業務影響が許容できる範囲のサービスであれば、シングルAZでもOKとしています。
うちの規模くらいだとマルチAZにしてもサーバ利用料が数万円増で終わる場合がほとんどなので、できればコストを許容してほしいと思っています。専用サーバとかだったら月数十万かかっていたわけだし。
それなりの規模（ミドル以上のエンジニアが１日で復旧できないレベル）で、それなりの事業影響があるシステムであれば、コストを割いてALB,ELB,RDSすべてマルチAZ構成にすることでリスクを低減します。
リージョン自体が死んだ場合はもう仕方ないよねっていうことになりそう。
日頃からシステム構築管理・運用部分をきちんとやっておくことで、リージョン自体が運用不可能になった場合の保険になります。
インフラ構築のコード化、プログラムデプロイ、初期化処理の自動化（DBマイグレーションとか）ができる構成にしておきます。
バックアップの取得・監視をします。
NAT Gateway, Internet Gateway, メール送信など、関連するサービスはマネージドサービスを利用することでSPOFにならないように設計します。
SLAの対象を24時間にしない。夜中1:00とかにサービス停止すると終了なので、営業時間内ですよっていうのを契約で縛ります。
営業時間外はクライアント側も誰もいないということが多いので、許容されることがほとんどです。
障害が発生しても気づかないと終わるので、監視をきちんとやります。

つまり真面目にやると

たいへん

課題

よく考えたら、システム＋インフラでひとつなので、両者を合わせて99%にしたい場合はちょっといま検討が足りていない気がします。

SLAの対象を99.99%にする場合を考える

SLAを99.99%にする場合の停止許容時間は40分くらい。考えることが爆発的に増えるので、考えるのをやめます。でも業務でやりたい・・・。

まとめ

システム、インフラの信頼性を高めやすい世の中になっているので、日頃からアンテナを張り巡らせておくことは大切だと思います。
想像力大切
AWS停止時にサービスがとまるのはしょうがない！っていう姿勢になるために、予めリスク予測しておく必要がありそうです。
障害発生時にファクトに基づかない推測したり、情報を参照したりするのはとても危険 AWSを始めとするクラウドサービスのおかげで、サービスの安定稼働と素早い復旧がしやすい環境になっていると思います。