event timeとprocessing timeについて

こんにちは。ソフトウェアエンジニアの田中伸弥です。

時系列データのevent timeとprocessing timeについて説明します。スマートフォンアプリのログシステムなどでは、このevent timeとprocessing timeを意識してシステムを設計する必要があります。

今回を含めて3回にわたって説明します。

1. event timeとprocessing timeについて
2. processing timeに基づくデータの保存
3. processing timeに基づき保存されたデータから、event timeに基づくデータを作成する

定義¹

• event timeとは、イベントが実際に起きた時刻
• processing timeとは、システムがイベントを観測した時刻。例えば、サーバにイベント記録された時刻

日本語だと、イベント時間とプロセス時間でしょうか? Azureのドキュメントではアプリケーション時間と到着時刻という言葉²が使われています。アプリケーション時間がevent time、到着時刻がprocessing timeに相当すると考えられます。いろいろ探しましたが、良い日本語訳が見つからないので英語のまま使用します。
定義だけでは分かりにくいので、例を用いて説明します。

例: スマートフォンアプリをリリースしており、そのアプリ内のボタンが、いつ、どれくらいクリックされているかを知りたい、という状況を考えます。システム構成は下図のような感じです。
システム概要 (version 1)

1. ユーザがアプリ内で、対象となるボタンをクリックすると、そのクリックイベントがアプリ内のバッファに追加される。
2. ある程度アプリ内のログが溜まったタイミングで、ログサーバに送信する。
3. ログサーバは、スマートフォンから受信したログを処理し、ストレージに格納する。
4. ストレージ内のデータを分析して、いつ、どれくらいクリックされているかを調べる。

下図で表示されている時刻はすべて日本標準時(JST)とします。

この例では、event timeは「ユーザがアプリ内のボタンをクリックした時刻」、processing timeは「ログサーバがスマートフォンからログを受信した時刻」とします。
アプリ内のイベントは、アプリ内である程度バッファに溜められ、インターネットを通じてログサーバへ送信されます。このため、event timeとprocessing timeには差(遅延)が生じます。データの分析はログサーバが受信した後になるため、アプリ内で実際にイベントが発生してから、しばらく経たないと分析は行えません。
スマートフォンのログのログサーバへの送信のタイミングはバラバラで、実際のクリックイベントが発生してから1時間後に送信されるかもしれないし、7日後に送信されるかもしれません。また、インターネットを介して転送するので、先に送信したログが、後に送信したログよりも後にログサーバに届く場合もあります。このような順不同に受信されるデータを、out-of-order dataとかunordered data³と言います。

現実のシステムでは、event timeとprocessing timeには、筆者の経験では1日から7日の差がある場合が多いです。例えば、”2018-12-01 09:00:00″(event time)にアプリ内のボタンをクリックした、というイベントを、ログサーバが受信するのは、その2日後の”2018-12-03 07:00:00″(processing time)かもしれません。データの分析はログサーバが受信した後になるので、event time とprocessing timeに2日の差がある場合、”2018-12-01″に起きたイベントのデータを分析できるのは２日後の”2018-12-03″となります。
event timeとprocessing timeの差が生じる理由として、以下のような事が考えられます。

• アプリ内である程度ログを溜めて(バッファリング)から送信するため。バッファリングをする理由としては、まとめてログを送信することでネットワークアクセス回数を減らすため、スマートフォンがWi-Fiに繋がるまでログを送信せずに待つため(モバイル通信量の削減)などがあります。
• ネットワーク遅延のため

バッファリングをせずに、アプリ内でイベントが発生する度にログサーバへログを送信すれば、event timeとprocessing timeの差を小さくできます。しかしその場合、以下のような課題があります。

• ネットワークへのアクセス回数が増え、アプリのパフォーマンスが低下する可能性
• ログ受信回数の増加により、ログサーバの負荷が上昇する可能性
• オフライン時のアプリ内イベントの収集が困難になる可能性
• モバイル通信量が増える可能性

ここまではevent timeとprocessing timeについて説明しました。
次回は、この順不同に受信されるデータ(unordered data)を考慮したデータの保存について説明します。

自己紹介
田中伸弥
Google JapanにてGoogle Playの検索や、Google Mapsのログ処理を担当。その後、Microsoft Development Ltd.にてBingの開発に従事。2018年よりFLYWHEELに参加。

Notes