今日(2021年6月8日)、Fastlyで大規模な障害が起きていた。

これによってGitHubなど有名なサービスがたくさん影響を受けており、私の開発作業にも影響が出ていた。私自身が利用しているサービスへの影響範囲を見るためにDowndetectorを確認してみた。するとそこに、ECサイトのアマゾン・ドット・コムの障害も報告されていた。

実際にamazon.co.jpを開いてみると、Webページにアクセスはできるものの画像やCSSが欠けたと思われるデザインの崩れた無残なページが表示された。なるほど、確かにアマゾン・ドット・コムで障害が起きていると言える状態だった。

(※本稿では、同じAmazonでもクラウドサービスを「AWS」、ECサイトを「アマゾン・ドット・コム」と表記する)

アマゾン・ドット・コムはもちろん、同社のクラウドサービスであるAWSをバリバリに使っている。私はアマゾン・ドット・コムはAWSの提供するCDNであるCloudFrontを使っているはずで、Fastlyは使っていないと思い込んでいたので、実際どうなのか調べてみた。

調査

エラーを返しているのはアマゾン・ドット・コムのアセットファイル配信元images-fe.ssl-images-amazon.comというドメインだった。このドメインに対してdigを打つと、CNAMEでmedia.amazon.map.fastly.netというFastlyのドメインが引けた。

しかし何度かdigを見てみると、後にCNAMEレコードはc.media-amazon.comというamazonの物と思われるドメインに切り替わった。(手元には19:08:48 JSTのdig結果のメモが残っていたので、遅くともこの時刻には切り替わっている)

その他、akamaiのドメインに変わったタイミングもあった(メモを取り忘れた)。これらの結果を見て、もしかしたらAWSの提供するDNS Route 53の機能DNS フェイルオーバーかもしれないと思った。(あくまで推測)

推測

アマゾン・ドット・コムは静的ファイルをFastly・Amazon(AWS CloudFrontか?)・Akamaiの3重冗長構成になるようデプロイしていて、どれかが落ちた時にもDNS フェイルオーバーで復旧できる構成になっているのではないか、と考えた。

DNS フェイルオーバーは、AWS Route 53以外のクラウドやCDN内のDNSサービスではなかなか見かけない機能。おそらく多くのケースでフェイルオーバーはDNSの責務ではないと考えられているからではないかと思う。けど、複数のCDNサービスに静的ファイルをデプロイして冗長構成にしたい場合には、CDNの前段に立つDNSにフェイルオーバー機能が必要になると思う。確かに、今回のようなCDNの障害への対策になる機能だった。

また、私自身Web開発者を何年もやっていてCDNやクラウドサービスの障害の経験は少なくないが、実際の障害発生時にあまりこういう他社のフェイルオーバーを目撃できる事は少ない。ちょっと良いものを見た気分でいた。

本当にDNSフェイルオーバーしたのか

...ただ、実際にアマゾン・ドット・コムはFastlyの障害発生時にキレイに切り替わって完全復旧することはなく、アセットファイル配信元のCNAMEレコードはしばらくの間FastlyとAmazon・Akamaiを行ったり来たりしていた。理由は分からない。これはDNS フェイルオーバーを使ったのではなく、アマゾン・ドット・コムの中の人が人力で復旧作業の試行錯誤とかをしていたのかもしれないし、DNS フェイルオーバーの設定がおかしかったのかもしれない。

実際に検証するには障害発生時のアマゾン・ドット・コムの挙動とAWS Route53のDNSフェイルオーバーの挙動とを突き合わせる必要があるけど、大手CDNの障害なんてそうそう起こるものでもないし、そもそも私はDNSフェイルオーバーを使ったことは無いのでよく知らない。

結局アマゾン・ドット・コムが本当にDNSフェイルオーバーしたのかは分からない。ただ、こういったCDNレベルの障害に対して使える策としてDNSフェイルオーバーという機能がAWS Route53にはあるのは事実で、AWSの強みのひとつと言えると思う。

なお余談だが、このブログはCloudflareを介して提供しているため、特にFastlyの障害の影響は受けなかった。

画像の出典