みなさん、こんにちは。GS2 の丹羽です。
今日は大事件が起こりました。Twittetなどでも話題になったので皆さん知っているのではないかと思います。
こんなブログを見に来てる人ならみんな知ってると思いますが、AWSの東京リージョンには3カ所のデータセンターがあります。
そのうち1カ所のデータセンターが完全に利用できない状態になりました。
その影響で様々なゲームも影響を受けたようです。
なぜAZ障害が様々なサービスの障害につながったのか
さて、なぜ今回のようにAZがダウンするとこのような大規模な障害が発生するのでしょうか。
1. シングルAZ
サーバはどこかのデータセンターで動いていてるわけです。EC2を使ってサーバを起動するときにもどのAZに配置するかを選びます。
この時に、一つのAZに固めてサーバを配置していた。あるいは1台しかなかった。みたいなときはサーバは全滅してしまいますので、障害となります。
2. フェイルオーバー設計ミス
次に、複数のAZに配置していたけれども、フェイルオーバーがうまくいかなかった場合です。
たとえば、データベースに接続するアプリケーションがあったとして、接続しているデータベースが突然いなくなったときに、再接続する処理がちゃんと動かなかった場合などがこれにあたります。
AZの見えない未来
ここからが本題です。
私は Game Server Services というゲームの BaaS を開発しています。
GS2 は フルサーバレスアーキテクチャ で設計・実装されています。
つまり、API Gateway や AWS Lambda、DynamoDB といったフルマネージドサービスを組み合わせてサービスを作っているわけです。
そして、そのおかげで私は今日の障害が発生しても1通もアラートを受け取っていません。
障害が発生した時も、客先で打ち合わせをしていましたが、打ち合わせが終わってLINEに障害の話が届いていて問題に気が付いたくらいです。
なぜ、フルサーバレスアーキテクチャだと障害の影響を受けなかったのでしょうか。
いや、実際はAZ影響は受けます。
API Gateway はマルチAZでフェイルオーバーをしていたでしょうし、AWS Lambda もコンテナを起動するAZから障害の発生していたAZを外していたでしょう。DynamoDB もこのような障害に備えて必ず複数のAZに3個以上の複製を保持することを保証しています。
AWS がしっかりフェイルオーバーしてくれていたおかげで、私からすれば”あたかも障害がなかった”ように感じられたわけです。
オープンソースの Function as a Service を独自の仮想サーバで動かしてサーバレスだ。みたいな記事を時々見ますが、まったく的外れだということが理解いただけるのではないかと思います。
そして、今日改めて私は インフラの未来はサーバレスにある。という思いを強くしたのでした。
それでは、また。
追記
まず、この記事の趣旨は今回の障害のニュースや解説ではありません。
一般論としてAZ障害とは何かの話をしています。
そして、AWSのSLAではAZ障害は起こるものとして定義されており返金の対象ではありません。
なので、AZ障害に対する責任は利用者にあるにも関わらず、フェイルオーバーできず影響がでたのはリテラシーの問題です。
ブコメでEC2しか影響出てなかったじゃない。みたいなコメントが多いです。
それはEC2にはAZダウンは仮想サーバの強制シャットダウンに繋がるため、状況の説明責任がありますが、フルマネージドサービスは正しくフェイルオーバーしていれば説明責任はありません。
つまり、本当は影響を受けてたかもしれないし、それはわかりません。
しかし、それがフルマネージドサービスのいいところ。という記事です。
次にフェイルオーバーを正しく設計していたのに障害に繋がったという話です。
今回はALBやELBが正しくフェイルオーバーしなかったという話を聞きます。
これらはフルマネージドサービスである ALB/ELB の問題でありAWSの問題です。SLAの保障の対象でしょう。
問題が起こったことは悲劇ですが、同じ問題は二度と起きません。各自がフェイルオーバーするより確実にいい未来がフルマネージドにはあるはずです。
