Recommended
More Related Content
What's hot
What's hot (20)
More from Shinichi Takahashi
More from Shinichi Takahashi (18)
Recently uploaded
Recently uploaded (9)
ぼくがAthenaで死ぬまで
- 3. 要件 ● 朝09:00くらいには前日分のデータ閲覧したい ● 閲覧者にSQLを書かせない / 意識させない ● CloudFront / ELBのログをインタラクティブに解析したい ● テーブルはCF: 3 / ELB: 2 ● 分析の種類はCF: 6 / ELB: 5
- 5. ver.A構想 ● サーバーレスで余裕だろｗｗｗｗなめんなｗｗｗｗｗｗ ● Athenaｗｗｗ銀の弾丸ｋｔｋｒｗｗｗｗｗｗｗｗｗｗ ● 10daysあればenough
- 9. ver.A 現実
- 12. ver.A アーキテクチャ すげえ時間 かかる 90s < タイムアウト < 30s データよこせ SELECT….
- 13. ver.A アーキテクチャ すげえ時間 かかる 90s < タイムアウト < 30s データよこせ SELECT….
- 14. ver.Aの反省点 ● Athenaの実行速度検証より先に組んじゃった ● API Gatewayのタイムアウトは緩和できない ● クエリをGETでぶん投げるセキュアさが残る
- 15. ver.B 中間データ 思想
- 16. ver.B 中間データ 死相
- 17. ver.B構想 ● 中間データをキャッシュ化すりゃちょろいだろｗｗｗ ● すげえクエリ数になるからLambda再帰実行したろｗｗｗｗｗ ● 10daysあればenoughｗｗｗｗｗｗｗｗｗｗ
- 18. ver.B構想 ● 中間データをキャッシュ化すりゃちょろいだろｗｗｗ ● すげえクエリ数になるからLambda再帰実行したろｗｗｗｗｗ ● 10daysあればenoughｗｗｗｗｗｗｗｗｗｗ ―その時ぼくは本気でそう思っていた―
- 19. ver.B アーキテクチャ
- 21. ver.B アーキテクチャ CF:3 / ELB: 2テーブル CF: 6 / ELB: 5クエリ 24時間分 = 672クエリ終わるまで再帰実行
- 22. ver.B アーキテクチャ CF:3 / ELB: 2テーブル CF: 6 / ELB: 5クエリ 24時間分 = 672クエリ終わるまで再帰実行 中間データとして保存
- 26. ver.B 現実
- 32. ver.B 終わりの 始まり
- 33. 終わりの始まり ● Athenaのトラフィックが急増してサービス制限がかかった＠15日 ○ 該当リソースを無効化 ● 東京からオレゴンへの転送量が170TB突破 == 170万円＠17日 ○ ぼくのボーナスがなくなることが確定 ○ デバッグ開始 + 該当リソース全削除 ○ サポート問い合わせ
- 34. サポートとのやりとり ● そんないくかね？ ○ 2017/03/17 16:00 - 16:18 の間のクエリについて調査 ○ 808クエリ実行（成功:178 / 失敗:630） ○ 1クエリあたり4GBほどデータスキャン ○ 該当のテーブルは東京リージョンのS3と合致 ○ 単純計算で (4GB / 18分間) * 2日分 = 134400GB つまり、ぼくの実装がバグってる
- 35. わかったこと ● テーブルの１つが東京リージョンにあった ○ 他の4テーブルは俺たちのオレゴン ● Lambdaが無限ループしてた ● エラーハンドリングできず死に続けていた ○ しかもいっちょ前にデータ転送だけは続ける
- 36. なんでこんなことが起きていたか ● ちゃんと再帰の終了条件チェックしたつもりだった ○ 一度エラーが起きると止まることなく死に続ける仕組み ● 夜間バッチを放置してるわずか３日間の出来事 ○ ちょっとデータ溜まったら整合確認しようとしていた ● そもそもユースケースにあってなかった ○ GoogleAnalyticsで異常検知 -> 原因をピンポイントで探る目的 ■ 全ログをキャッシュする必要はない ■ （ミスがなくても）ほぼ無駄にお金かかる仕組み
- 37. 再発防止どうすんの？ ● ちゃんとユースケースのヒアリングをする ○ そもそも論だけどやっぱり重要 ● ちゃんとプログラムのチェックをする ○ 複数人つかっての多重チェック == 自分を信用しない ● ちゃんとリリース後のエラー発生回数などをチェックする ○ テスト実行時間を調整 ○ 複数人つかっての多重チェック == 自分を信用しない
- 38. ver.C ポーリング 思想
- 41. ver.C アーキテクチャ データよこせ ・いつから ・いつまで ・テーブル ・クエリタイプ データくれって 言われたから このKeyでObjectつくれ よ このKeyでつくるんで！ はい はい
- 46. ver.C ● トリガーLambda：非同期実行のトリガー ○ ObjectKey生成 ○ 生成したObjectKeyとブラウザからのリクエストを 集計Lambdaに渡す ○ 生成したObjectKeyをブラウザに返却
- 47. ver.C ● データ集計Lambda：集計を担う ○ トリガーLambdaをバイパスしたリクエストに従い、 Athenaを用いた集計を行う ○ 集計したデータをトリガーLambdaから 受け取ったObjectKeyに従って配置
- 48. ver.C ● データ取得Lambda：S3オブジェクトの取り出し口 ○ リクエストされたObjectKeyのS3 Objectが存在すれば ■ データを返却 ■ 該当Objectの削除 ○ 存在しなければ ■ エラーを返却
- 49. ● API Gatewayの30秒縛りから解き放たれる ○ Lambdaの5分縛りに緩和される == 10倍!! ● 必要なときに必要な分だけ課金される ○ 170万いかない ver.Cでうれしいこと
- 50. ● API Gatewayの30秒縛りから解き放たれる ○ Lambdaの5分縛りに緩和される == 10倍!! ● 必要なときに必要な分だけ課金される ver.Cでうれしいこと ver.Aの教訓!! ver.Bの教訓!!
- 51. ● Athena使う際は、リージョンに気をつけよう ● Lambdaを再帰実行する際は、適切に終了するか確認しよう ● この資料つくってるときが一番つらかった まとめ