　同社が障害明けの26日に行った、エンジニアチームによる障害の振り返り会議に記者も同席した。「障害発生当初、いろいろなジョブに影響が出たため何が起きているのか分からなかった」「各サービスを管理するAWSマネジメントコンソールの動きもおかしく、問題に対応しようとしても何度もリトライしないとインスタンスが立ち上がらなかった」「AWS CLI（コマンドによる管理ツール）は比較的調子が良かった」──など、現場の生々しい声が飛び交った。

　一方、「『AWS Fargate』で運用しているサービスは自動復旧できた」という報告も上がった。Fargateはサーバなどの管理をAWS側に任せてコンテナを実行できる、いわゆる「サーバレス」のサービスだ。

AWS Fargateの仕組み（公式サイトより）

　会議では、「バッチ処理サーバをコンテナ化するのが、今後の対応策の一つだろう」という意見でまとまった。コンテナ化してFargateで運用すればAWS側が可用性を自動管理するメリットがあり、Fargateを利用しないとしても、コンテナであればサービスの立ち上げや終了が容易だからだ。

「動いているサービス」を改修することの難しさ

　VOYAGE GROUPのエンジニアの一人は、バッチ処理サーバの設計について「古いことは分かっていたが、『動いているサービス』の改修の優先度を上げるのが難しかった」と明かす。

　「新規に開発するサービスであれば、新しい技術を取り入れて設計していけるが、過去に設計してそのまま動作しているものについて緊急時を想定し再設計することに十分にリソースを割けるかというと、なかなか難しい面もある」（同）

　同社の別のエンジニアは、「そういう意味では、障害が起きて原因が詳細に報告される今回のような例は貴重。対応すべきことが明確になる」と、AWSの障害報告を評価していた。

そのサービスはどこまでリスクを許容できるのか

　各社・各エンジニアから聞いたことをまとめると、AWSに再び障害が起きた場合に、影響を最小限に抑えるための対応策としては、

3AZでのマルチAZ構成にする
コンテナ化などでサービスを落としやすく立ち上げやすい環境にする
可能ならFargateを使う（サーバレス化）
「AWS Step Functions」で処理ステップを構成しビジュアライズする（処理の見通しが容易になる）

　といった方策が考えられるという。

　聞いていて感じたのは、エンジニアの人々は「落ちない設計」より「落ちにくい・落ちても迅速に復旧できる設計」を目指しているということだ。

　ロードバランサーの障害に対応していたエンジニアA氏は、「結局はどこまでリスクを許容するかではないか。大規模災害など、東京リージョンの全てのAZが壊滅することを想定すればマルチリージョンや他社クラウドとの併用も考えられるが、自社のサービスは果たしてそこまでの継続性を必要とし、運用コストを払えるものなのか」と指摘する。

　今回の障害で、クラウドへの漠然とした不安から「オンプレミスへの回帰はどうか」という声もネット上にあった。しかし、ふたを開けてみれば5時間程度で大部分が復旧しており、オンプレミスで同様の障害があったときに同等の速度・労力で復旧できるかには疑問符が付く。

　AWSを利用する企業にとって、今回の障害は「どのようなサービス運用が適切なのか」を社内で議論する機会になりそうだ。