発端
お客様のサイトダウン通知を確認
お客様のサイトダウンの通知を確認しました。
1分ほどで復旧しているため緊急性は低いものの念の為調査を行うことにしました。
ダウン調査開始
各種リソースの CPU 使用率とアクセスの微増が見られました。
nginx のログ、php のログ、RDS のメンテナンス時刻などを調べました。
特に問題が見つけられないため、CloudFront のアクセスログを調べることにしました。
Athena による調査
CloudFront のアクセスログを調査するために Athena のテーブルを作成。
複数のクエリを実行し特定の uri へのアクセス集中がないことなどから、リソース不足が原因と考え様子見ということになりました。
発覚
翌日、上長が該当のアカウントの「AWS Data Transfer APN1-USE1-AWS-Out-Bytes」のコストが跳ね上がっていることに気がつき調査を開始。
確認したところ、ap-northeast-1 にある CloudFront のログが保存されている S3 バケットに対して、us-east-1 の Athena でテーブルを作成しクエリを実行したため、ap-northeast-1 → us-east-1 間で大量のデータ転送( 14,333.018 GB )が発生していることを発見。
原因は CloudFront のログ検索であるとわかりました。
原因
原因は Athena でクエリを実行するリージョンを間違えたことでした。
CloudFront のログは ap-northeast-1 の S3 バケットにありましたが、私は Athena テーブルを us-east-1 で作成していました。
そのため、700GB ほどあるログのリージョン間での転送が発生してしまい、コストが跳ね上がってしまいました。
教訓
CloudFront のログ検索を Athena で行う際は、「ログが保存してあるリージョン」と「Athena でクエリを実行するリージョン」が同じであることを絶対に確認するようにしましょう。
CloudFront のログはとても容量が大きいので、間違えると今回のような大量の転送料を取られることになります。