アプリからログをいい具合に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はテーブル毎に1日に Insert する Job を作れる制限が決まっており、それが1,000件になっています。 それを超えてしまい、どうしようもなくなった!という状態でした。
仕方ないのでログを結合する
幸い、どのログが入ったのか入っていないのか、BigQueryのJobのIDがなんなのかというのはLambdaからDynamoDBに記録していたので、たどることができます。
なので、うまい具合にretryもしつつ、S3にたまったログを結合して(且つ、timestampなど特定のカラムをnormalizeして)BigQueryにいれるスクリプトを書きました。書きましたとも!
うまくいった
ということで、上記の対応でうまく対処できました。こうやって日々Locariのログを捌いています。
BigQueryはデータの投入もとても早いので(Steraming Insertの場合もすぐクエリーをうてます)かなりリアルタイムに近いデータにアクセスができるのは利点かなと思っています。もちろんBIのBackendとしても十分な速度とコストパフォーマンスがあると思います。
ちなみに汎用化すれば、BigQueryの普及に寄与できそうな Lambda(ES2015) を公開できそうなのですが、もうしばらく時間がかかりそうです...!
このスクリプトのメンテを中心とする基盤のメンテナンスやBigQueryに向けて一緒にクエリーを叩いてくれるような方を探しています! よかったらご応募ください!