2020年9月26日CloudFront障害中のアクセスログを調査してみた

2020年9月26日(土)、日本時間の18時前後に発生していたCloudFront障害について、CloudFrontのアクセスログを調査してみました。

#Amazon CloudFront

#AWS

suzuki.ryo

2020.09.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWSチームのすずきです。

2020年9月26日(土)、日本時間 PM 5:55 から PM 6:45 の間、日本のCloudFrontのエッジロケーションで断続的にエラーが発生していた件について、 CloudFrontのアクセスログを元に調査する機会がありましたので、紹介させて頂きます。

弊社ポータルのお知らせ

日本時間2020年9月27日(日) 5:47:45 CloudFront お知らせ日本のエッジロケーションでエラーが上昇しておりました。| Elevated Errors from one of our edge... https://t.co/5qSz7x59vV

— AWS障害情報(全リージョン) (@awsstatusjp_all) September 26, 2020

Athena(抽出)

国内に存在するエッジロケーションと推測されるアクセスログを Athenaで抽出しました。

CREATE table cf_20200926 AS
SELECT
    date || ' ' || substr(time,1,5) || ':00' as datetime,
    x_edge_location,
    substr(x_edge_location,1,5) as x_edge_location_s,
    split_part(c_ip,'.',1) || '.' || split_part(c_ip,'.',2) || '.' || split_part(c_ip,'.',3) || '.0' as ip_s
FROM
    cloudfront_logs
WHERE
    cs_status = '200'
    and x_edge_location like 'NRT%'
    and dt in(
        '2020-09-26-08',
        '2020-09-26-09',
        '2020-09-26-10'
    )

「x_edge_location」に示された3文字の空港コードと数値でエッジロケーションの識別が可能です(2020年9月現在)。今回、成田の空港コード(NRT)と一致するログを日本国内のものとして扱いました。

ウェブディストリビューションの標準ログファイル形式

集計簡略化の為、x_edge_locationと接続元IP情報は末尾を切り捨て処理しました。
CloudFrontのアクセスログは、Lambda と Firehose で集約、ETL処理済みのデータを利用しました。

CloudFrontがS3に出力したTSV形式のアクセスログを処理する事も可能です。

QuickSight(可視化)

データセット

データセットは Athena、CTASクエリで生成したテーブルを指定しました。

日付カラムについて、元データの文字列を日付型として利用するため、書式指定 (yyyy-MM-dd HH:mm:ss) を行いました。

解析結果

エッジロケーション別リクエスト数

分単位のエッジロケーション毎のリクエスト数を求めました。

Visual Type 「Stacked area line chart」
X Axis 「datetime (MINUTE)」
Color 「x_edge_location_s」

特定のエッジロケーション(NRT12)のリクエスト数について、日本時間の18時台に減少していた事が確認できました。

特定エッジロケーション(NRT12)のリクエスト数

「NRT12」のみ抽出するフィルタを追加しました。

当環境では18時04分から18時51分の間にかけて「NRT12」の処理数が減少していたことが確認できました。

特定エッジロケーション(NRT12)に接続実績のあったIPアドレス

「Top and bottom filter」フィルターを利用して、9/28の17~19時台に NRT12 に多くアクセスしていた IPアドレス(第4オクテットは省略)を求めました。

IPアドレスから確認できるISPと位置情報から、東京近辺のISPが上位を占めていることが確認できました。

utrace

utrace

今回アクセスログを解析した CloudFront については、東京近辺、ネットワーク的にも「NRT12」に近いISPの利用者が影響を受けていた可能性が高いことが推測できました。

まとめ

今回のエッジロケーション障害、クライアントからのリクエストはCloudFrontに到達する事なくタイムアウトしており、CloudFrontのアクセスログとしては記録されないものでしたが、大凡の影響範囲などについては把握することができました。

特定エッジロケーションに問題があったと推測される時間帯、CloudFront全体のリクエスト数としては大きな減少が認められなかった事から、クライアント側で行われるラウンドロビンが効果的に機能していたケースもあったと推測されます。

CloudFront DNS名の名前解決サンプル

$ host d1vppnlr8nl79s.cloudfront.net
d1vppnlr8nl79s.cloudfront.net has address 143.204.82.49
d1vppnlr8nl79s.cloudfront.net has address 143.204.82.27
d1vppnlr8nl79s.cloudfront.net has address 143.204.82.121
d1vppnlr8nl79s.cloudfront.net has address 143.204.82.91

今回のエッジロケーション障害についてはAWS側の復旧を待つのが最善だったと思われます。

ただ、より大規模なCloudFrontの障害を想定した Route53 ヘルスチェックなどを利用したフェイルオーバの実現性や、 CloudFrontのリアルタイムログを活用した早期異常検出の可能性についても、この機会に再検討してみたいと思います。