Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ぼくがAthenaで死ぬまで

20,245 views

Published on

はじめてのくらうど死

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

ぼくがAthenaで死ぬまで

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

×