ぼくがAthenaで死ぬまで

ぼくがAthenaで 死ぬまで cloudpack社内勉強会

軽い気持ちでやろうとしたこと ● Urchin（紀元前に存在が確認された古代兵器）をもうやめたい ● なにやらAWSにAthenaとかいうのがあるらしい ● よっしゃやったろ

要件 ● 朝09:00くらいには前日分のデータ閲覧したい ● 閲覧者にSQLを書かせない / 意識させない ● CloudFront / ELBのログをインタラクティブに解析したい ● テーブルはCF: 3 / ELB: 2 ● 分析の種類はCF: 6 / ELB: 5

ver.A サーバーレス 思想

ver.A構想 ● サーバーレスで余裕だろｗｗｗｗなめんなｗｗｗｗｗｗ ● Athenaｗｗｗ銀の弾丸ｋｔｋｒｗｗｗｗｗｗｗｗｗｗ ● 10daysあればenough

ver.A アーキテクチャ

ver.A アーキテクチャ データよこせ SELECT….

ver.A アーキテクチャ データよこせ SELECT…. 集計して返却

ver.A 現実

ver.A アーキテクチャ データよこせ SELECT….

ver.A アーキテクチャ データよこせ SELECT…. すげえ時間 かかる 90s <

ver.A アーキテクチャ データよこせ SELECT…. すげえ時間 かかる 90s < タイムアウト < 30s

ver.A アーキテクチャ データよこせ SELECT…. すげえ時間 かかる 90s < タイムアウト < 30s

ver.Aの反省点 ● Athenaの実行速度検証より先に組んじゃった ● API Gatewayのタイムアウトは緩和できない ● クエリをGETでぶん投げるセキュアさが残る

ver.B 中間データ 思想

ver.B 中間データ 死相

ver.B構想 ● 中間データをキャッシュ化すりゃちょろいだろｗｗｗ ● すげえクエリ数になるからLambda再帰実行したろｗｗｗｗｗ ● 10daysあればenoughｗｗｗｗｗｗｗｗｗｗ

ver.B構想 ● 中間データをキャッシュ化すりゃちょろいだろｗｗｗ ● すげえクエリ数になるからLambda再帰実行したろｗｗｗｗｗ ● 10daysあればenoughｗｗｗｗｗｗｗｗｗｗ ―その時ぼくは本気でそう思っていた―

ver.B アーキテクチャ

ver.B アーキテクチャ AM04:00に実行 されるバッチ部分 Webから中間データを 探査する部分

ver.B アーキテクチャ CF:3 / ELB: 2テーブル CF: 6 / ELB: 5クエリ 24時間分 = 672クエリ終わるまで再帰実行

ver.B アーキテクチャ CF:3 / ELB: 2テーブル CF: 6 / ELB: 5クエリ 24時間分 = 672クエリ終わるまで再帰実行 中間データとして保存

ver.B アーキテクチャ データよこせ ・いつから ・いつまで ・テーブル ・クエリタイプ

ver.B アーキテクチャ データよこせ 中間データを返却 ・いつから ・いつまで ・テーブル ・クエリタイプ

ver.B アーキテクチャ データよこせ 中間データを返却 ・いつから ・いつまで ・テーブル ・クエリタイプ 集計

ver.B 現実

ver.B アーキテクチャ データよこせ ・いつから ・いつまで ・テーブル ・クエリタイプ

ver.B アーキテクチャ データよこせ レスポンスタイムは 余裕でクリア！！ ・いつから ・いつまで ・テーブル ・クエリタイプ

ver.B アーキテクチャ データよこせ レスポンスタイムは 余裕でクリア！！ ・いつから ・いつまで ・テーブル ・クエリタイプ サイズでかすぎて死亡

ver.B アーキテクチャ データよこせ そもそも 無限ループしてた レスポンスタイムは 余裕でクリア！！ ・いつから ・いつまで ・テーブル ・クエリタイプ サイズでかすぎて死亡

ver.B アーキテクチャ データよこせ そもそも 無限ループしてた レスポンスタイムは 余裕でクリア！！ ・いつから ・いつまで ・テーブル ・クエリタイプ サイズでかすぎて死亡

ver.B 終わりの 始まり

終わりの始まり ● Athenaのトラフィックが急増してサービス制限がかかった＠15日 ○ 該当リソースを無効化 ● 東京からオレゴンへの転送量が170TB突破 == 170万円＠17日 ○ ぼくのボーナスがなくなることが確定 ○ デバッグ開始 + 該当リソース全削除 ○ サポート問い合わせ

サポートとのやりとり ● そんないくかね？ ○ 2017/03/17 16:00 - 16:18 の間のクエリについて調査 ○ 808クエリ実行（成功:178 / 失敗:630） ○ 1クエリあたり4GBほどデータスキャン ○ 該当のテーブルは東京リージョンのS3と合致 ○ 単純計算で (4GB / 18分間) * 2日分 = 134400GB つまり、ぼくの実装がバグってる

わかったこと ● テーブルの１つが東京リージョンにあった ○ 他の4テーブルは俺たちのオレゴン ● Lambdaが無限ループしてた ● エラーハンドリングできず死に続けていた ○ しかもいっちょ前にデータ転送だけは続ける

なんでこんなことが起きていたか ● ちゃんと再帰の終了条件チェックしたつもりだった ○ 一度エラーが起きると止まることなく死に続ける仕組み ● 夜間バッチを放置してるわずか３日間の出来事 ○ ちょっとデータ溜まったら整合確認しようとしていた ● そもそもユースケースにあってなかった ○ GoogleAnalyticsで異常検知 -> 原因をピンポイントで探る目的 ■ 全ログをキャッシュする必要はない ■ （ミスがなくても）ほぼ無駄にお金かかる仕組み

再発防止どうすんの？ ● ちゃんとユースケースのヒアリングをする ○ そもそも論だけどやっぱり重要 ● ちゃんとプログラムのチェックをする ○ 複数人つかっての多重チェック == 自分を信用しない ● ちゃんとリリース後のエラー発生回数などをチェックする ○ テスト実行時間を調整 ○ 複数人つかっての多重チェック == 自分を信用しない

ver.C ポーリング 思想

ver.C アーキテクチャ データよこせ ・いつから ・いつまで ・テーブル ・クエリタイプ

データくれって ver.C アーキテクチャ 言われたから このKeyでObjectつくれ よ このKeyでつくるんで！ データよこせ ・いつから ・いつまで ・テーブル ・クエリタイプ

データくれって ver.C アーキテクチャ 言われたから このKeyでObjectつくれ よ このKeyでつくるんで！ データよこせ ・いつから ・いつまで ・テーブル ・クエリタイプ はい はい

データくれって ver.C アーキテクチャ 言われたから このKeyでObjectつくれ よ このKeyでつくるんで！ データよこせ ・いつから ・いつまで ・テーブル ・クエリタイプ はい はい このKeyのデータあります か？

データくれって ver.C アーキテクチャ 言われたから このKeyでObjectつくれ よ このKeyでつくるんで！ データよこせ ・いつから ・いつまで ・テーブル ・クエリタイプ はい はい ないんごｗｗｗｗｗｗ このKeyのデータあります か？

データくれって ver.C アーキテクチャ 言われたから このKeyでObjectつくれ よ このKeyでつくるんで！ データよこせ ・いつから ・いつまで ・テーブル ・クエリタイプ はい はい ないんごｗｗｗｗｗｗ このKeyのデータあります このKeyのデータあります か？ か？

データくれって ver.C アーキテクチャ 言われたから このKeyでObjectつくれ よ このKeyでつくるんで！ データよこせ ・いつから ・いつまで ・テーブル ・クエリタイプ はい はい ないんごｗｗｗｗｗｗ できたんごｗｗｗｗ このKeyのデータあります このKeyのデータあります か？ か？

ver.C ● トリガーLambda：非同期実行のトリガー ○ ObjectKey生成 ○ 生成したObjectKeyとブラウザからのリクエストを 集計Lambdaに渡す ○ 生成したObjectKeyをブラウザに返却

ver.C ● データ集計Lambda：集計を担う ○ トリガーLambdaをバイパスしたリクエストに従い、 Athenaを用いた集計を行う ○ 集計したデータをトリガーLambdaから 受け取ったObjectKeyに従って配置

ver.C ● データ取得Lambda：S3オブジェクトの取り出し口 ○ リクエストされたObjectKeyのS3 Objectが存在すれば ■ データを返却 ■ 該当Objectの削除 ○ 存在しなければ ■ エラーを返却

ver.Cでうれしいこと ● API Gatewayの30秒縛りから解き放たれる ○ Lambdaの5分縛りに緩和される == 10倍!! ● 必要なときに必要な分だけ課金される ○ 170万いかない

ver.Cでうれしいこと ver.Aの教訓!! ● API Gatewayの30秒縛りから解き放たれる ○ Lambdaの5分縛りに緩和される == 10倍!! ● 必要なときに必要な分だけ課金される ver.Bの教訓!!

まとめ ● Athena使う際は、リージョンに気をつけよう ● Lambdaを再帰実行する際は、適切に終了するか確認しよう ● この資料つくってるときが一番つらかった