概要
sendgridのイベントデータをredashで取得するものの、全然正確な数値が取得できなかった
ちゃんと取れているイベントと、取れていないイベントがあった
調査内容
下図が改善前のフローだったので、どこにボトルネックがあるかを調べた。
ユーザーがメール受け取る（例えば）
sendgrid webhook発火でapi gateway叩く
kinesis data firehose実行
s3にデータ保存
redashがathena経由でそれを分析
調べたら、sendgridのページ上ではちゃんと、ここ1週間の全イベントを取得できているが(sendgridはイベントデータを1週間しか保持しない)、s3には全イベントデータが保存されているわけではことが分かる。
api gateway側で4xx, 5xxエラーなどは殆ど出ていなかったため、firehoseが原因ではないか？と推定。
ただ、firehoseのバッファサイズ等を変えても変わらなかったため、根本原因の特定には至らず。
対応
firehoseをlambdaに置き換えた。具体的には、以下の方針のもと実施した。
lambdaの仕事内容
受け取ったイベントデータをs3にputするだけ
リクエスト内のjson(イベントデータ)が複数であれば改行して1ファイルにまとめて保存
今後のデバッグ用に、保存するイベントデータとs3のpathはconsoleしておく
lambdaの実行時間がなるべく少なく済むように、ファイルを保存する場所は全て同じディレクトリに（1日単位で移動）
ディレクトリを細かに分割するために、最初はs3のバケットを読み込むAPIを使って、1000件越えたら次のディレクトリ掘る、としていた
しかしそれをすると、保存数が増えれば増えるほど読み込みの合計時間（≒ lambdaの実行時間）が増加する
なので全て同じ場所に入れ、仕事はputだけにした
結果、s3に全データ保存されるようになったっぽい(たぶん)。
感想
もしかするとfirehoseがs3に複数個jsonを一気に流し込むとき、改行が入らずにathenaが望む形になってなかったのが原因だったのかな？
だとするとlambdaにわざわざ変える意味があったのかは怪しい。
まあ、ひとまずよいか。
あとAWS色々触れてよかった。インフラ楽しい。