Athena v3 にしたら、日付処理の仕様変更により障害が起きた話

2023.3月に書いておいたネタを今更ながら投稿します。ChatGPT狂乱祭で、すっかり投稿を忘れていました。

概要：

AWS の利用料金を Athena を使って毎月集計しています。今年の 3 月に入り、2 月分の料金集計をしたところ、なぜか 1 月分のレポートが出力されるという障害が起きました。原因を調査したところ、Athena v3 から、- interval '1' month の結果が変わっていたことが原因であることが分かりました。なお、Athena v2 から v3 へは、去年のどこかのタイミングで検証して、変更しています。

原因の詳細：

実行している SQL から、問題の箇所の抜粋を下記に示します。

select date_trunc('month', (current_timestamp AT TIME ZONE 'Asia/Tokyo')) - interval '1' month

現在の時刻 (current_timestamp AT ...) をもとに、初日を算出（date_trunc('month' ...)）、そこから一か月前の日時（- interval '1' month）を取得するという処理をしていました。Athena v2、v3 の両方とも、今月の初日を取得する SQL の結果は下記の通りです。

select date_trunc('month', (current_timestamp AT TIME ZONE 'Asia/Tokyo'))
2023-03-01 00:00:00.000 Asia/Tokyo

しかしながら、上記に - interval '1' month を加えると、Athena v2 では想定通り先月の初日が返ってくるのに対し、v3 では 1 月 29 日が返ってきます（30 日引いた？）。そのため、2 月限定のトラップで、見事に障害が発生してしまいました。

Athena v2

select  date_trunc('month', (current_timestamp AT TIME ZONE 'Asia/Tokyo') ) - interval '1' month
2023-02-01 00:00:00.000 Asia/Tokyo

Athena v3

select  date_trunc('month', (current_timestamp AT TIME ZONE 'Asia/Tokyo') ) - interval '1' month
2023-01-29 00:00:00.000 Asia/Tokyo

対策：

該当の SQL は、単純に先月の年月が取得できれば良いので、下記のように、先月の最終日を取得するように変更しました。

select date_trunc('month', (current_timestamp AT TIME ZONE 'Asia/Tokyo')) - interval '1' day

まとめ：

日付処理が含まれるコードのランタイムのバージョンアップ検証は、大変だということがわかりました。あと、重要な変更のページ https://docs.aws.amazon.com/ja_jp/athena/latest/ug/engine-versions-reference-0003.html#engine-versions-reference-0003-breaking-changes に記載しておいてほしい人生でした。