アプリからログをいい具合にBigQueryに突っ込む険しい道
千葉です。基盤と雑用をしています。
弊社のログの解析はBigQueryに丸投げなのですが、それ以外はAWSさんにおんぶにだっこなので、いわゆる
- Kinesis Firehoseからかんたんに Redshift にはいります！！
- Mobile Analyticsからボタンひとつで Redshift にはいります！！
というのを敢えて使わずに茨の道を歩まねばなりません。辛いです。 また、BigQueryのStreaming Insertで100%安心です＼(^o^)／ となれば良いのですが、前に障害のメールもありましたし、デバッグもしにくいという理由からこちらも避けて通っています。
ということで弊社の構成です。
- アプリはMobile AnalyticsのSDKを使ってログをいい具合に転送する
- Mobile AnalyticsのS3連携（Kinesis Firehoseのよう）で定期的にS3に書き出す
- Lambda が S3 Put Event を拾って DynamoDB に記録しつつ BigQuery に突っ込むjobをつくる
最近は俄然Kinesisファミリーが流行していますが、Mobile Analyticsも同じようなことができます。 また Cookpadさんのpureeのようなものがアプリではやはり必要なので、AWSさんの開発力に乗ってしまえるのも利点です。
ところが、いきなりの障害
上記の運用でしばらくうまくいっていたのですが、急にログがBigQueryにはいらなくなりました／(^o^)＼ よくよく見ると Put のイベントの数がいきなり増えています。
BigQueryはテーブル毎に１日に Insert する Job を作れる制限が決まっており、それが1,000件になっています。 それを超えてしまい、どうしようもなくなった！という状態でした。
仕方ないのでログを結合する
幸い、どのログが入ったのか入っていないのか、BigQueryのJobのIDがなんなのかというのはLambdaからDynamoDBに記録していたので、たどることができます。
なので、うまい具合にretryもしつつ、S3にたまったログを結合して（且つ、timestampなど特定のカラムをnormalizeして）BigQueryにいれるスクリプトを書きました。書きましたとも！
うまくいった
ということで、上記の対応でうまく対処できました。こうやって日々Locariのログを捌いています。
BigQueryはデータの投入もとても早いので（Steraming Insertの場合もすぐクエリーをうてます）かなりリアルタイムに近いデータにアクセスができるのは利点かなと思っています。もちろんBIのBackendとしても十分な速度とコストパフォーマンスがあると思います。
ちなみに汎用化すれば、BigQueryの普及に寄与できそうな Lambda(ES2015) を公開できそうなのですが、もうしばらく時間がかかりそうです...！
このスクリプトのメンテを中心とする基盤のメンテナンスやBigQueryに向けて一緒にクエリーを叩いてくれるような方を探しています！ よかったらご応募ください！
