adjust サーバーサイドイベントトラッキングを活用する

はじめに

こんにちは。Gunosy Tech Lab Data Reliability & MLOps Group の阿部といいます。この記事は Gunosy Advent Calendar 2019 14日目の記事です。昨日の記事は竹中さんのノリで使っていたGoLandをちゃんと使う - Gunosy Tech Blog でした。

弊社では adjust を利用してイベントトラッキングを行い、プロモーション効果計測などに活用しています。今回の記事では adjust のサーバーサイドイベントトラッキングという機能を紹介し、adjust にイベントを送信するまでの仕組みをお伝えします。

はじめに
adjust サーバーサイドイベントトラッキングとは
やりたいこと
システム構成
運用
まとめ

adjust サーバーサイドイベントトラッキングとは

サーバーサイドイベントトラッキングを利用するとクライアントではなくサーバーサイドから adjust にイベントを送信することができます( 参考リンク )。

クライアントに実装が不要なため、たとえばSQLで特定の条件でデバイスIDを抽出し送信するといったことが可能になります。

やりたいこと

adjustにイベントを送信する仕組みを構築するにあたり、以下のようなことを考えました。

計測したいイベントが増えたときに、できるだけ早く対応したい
イベントの重複排除を柔軟に設定できるようにしたい

しかしながらいくつか仕様上の制約があり、若干頭を抱えてしまいました。

複数イベント同時に送信できない

イベント毎にadjustのエンドポイントを叩く必要があります。たとえば数万件とかあったりすると面倒です。

送信間隔は0.01秒以上時間を空ける必要がある

異なるイベントを異なるバッチで走らせていると不意に 0.01秒の制約を破ってしまうかもしれません。

イベントの重複排除をする場合はデバイスIDでのみ可能 ( 参考リンク )

例えば MAU など、月次などの単位で重複排除したい場合等々あると思います。その場合どうすればいいでしょうか。一ヶ月ごとに処理をしてもいいかもしれませんが、できればイベントが発生した時点で送ってしまいたいですね。(その上、イベントは28日以内に送らないといけないという制約もあります)

イベントトークン毎に時系列でソートされている必要がある （例：3日に発生したイベントトークンXのイベントが、7日に発生した同じトークンのイベントの後に送られてくる場合、3日に発生したイベントは拒否される。）

一度送ったら修正できないので注意が必要

システム構成

以上のような要件と制約をもとにシステムの構成を考えます。おおまかに以下のような流れになります。

Digdag + Embulk で Athena を利用して特定条件のイベントを抽出
それをDynamoDBに書き込む
イベントの追加/変更を DynamoDB ストリームに流す
Lambda でイベントを adjust に送信する

重複排除

DynamoDBを使って重複排除を行っています。重複が有無は同一のプライマリキーが存在するかどうかで判定することができます。時系列ソートに関しても、厳密ではないですがワークフローを時系列で走らせれば、想定する用途では問題無い程度にはなります。

Digdag (+Embulk) から Athena にクエリを発行し、トラッキングしたい条件に合致するデバイスIDを取得し、DynamoDBに書き込みます。

ワークフローの詳細こちらです。

speakerdeck.com

プライマリキーは {app_token}|{event_token}|{gps_adid}|{idfa}|{idfv} のようにします。 DynamoDBのアトリビュートは app_token 等のプライマリキーを構成する要素の他、タイムスタンプやTTL用のものも用意しています。 TTLはだいたいのケースではイベント送信期限の28日間を設定すれば良いと思います。

複数同時送信の防止と送信間隔の調整

0.01秒間隔を空けるという制約は、一つのストリーム (DynamoDB Streams) を一つのバッチ (Lambda) で処理することで実現しています。

DynamoDB の設定で DynamoDB ストリームを有効化し、StreamViewType は NEW_IMAGE に設定します ( Change data capture for DynamoDB Streams - Amazon DynamoDB )。こうしておくと重複したイベントが来ても DynamoDB ストリームには流れなくなり、重複排除が可能です。プライマリキーに、例えば日付などの追加の情報を付与し、重複排除の条件を変えることもできます。 Lambda のイベントソースマッピングで DynamoDB を指定します。 ParallelizationFactor を 1 (default) にしておくと、同時に複数のバッチが走らないように制限できます。イベント数が多いとタイムアウトの恐れがあるので Lambda の Timeout は長く、バッチサイズは小さめしておくと良いです。同時に Firehose を使う等して、処理したイベントのログをS3に置いておくと安心です。

実装

Lambda はPythonで動かしており、実装はこんな感じです。

エラー処理は500の内でも無視して良いもの、だめなものなどを発生ベースで洗練させていっています（リトライで直る可能性があればリトライする等）。エラーコードとエラー内容の一部詳細は以下に記載があります。

https://help.adjust.com/tracking/app-events/basic-event-setup/track-s2s-events#event-submission-responses

基本的にはエラーが発生してもコード上ではロギングし、CloudWatchに出力します。一部のエラーはCloudWatchを確認して再送する必要もあるでしょう。また、例外が発生したときでも失敗して停止はさせないようにしています。というのも、途中で失敗して再実行されると一部のイベントだけ重複して送信されてしまう恐れがあるからです。一部のエラーの時は数回リトライを実行し、うまくいかなければ諦めます。そのため、クリティカルな要件に使うことはできないので注意が必要です。