記録と計測

1件を追う記録と全体を見る数字

席の予約サービスで「取り消しに失敗した」と連絡が来たら、その要求の記録をたどります。ログは1件の出来事を残し、どの処理で何が起きたかを調べるために使います。

一方、失敗の割合や応答時間の分布を見るのがメトリクスです。全体の変化を数字で見つけ、詳しい原因をログで追うという使い分けをします。

全員が失敗する前に、一部の予約だけが遅くなることがあります。問い合わせを待つより、失敗の割合や応答時間の変化から気づくほうが早く手を打てます。

書いてよい項目を先に決める

ログには要求ID、処理の道筋、結果、かかった時間、利用者IDの5項目を残します。要求IDがあれば同じ要求の記録を結び付け、時間があれば遅い処理を探せます。

受け取った出来事を丸ごと保存する方法は避けます。メールアドレスやカード番号を一度書けば、ログを読める人がその情報を見られる状態になります。

保存後に表示を絞っても、元の情報は保存先に残ります。複製やバックアップにも広がるため、保存する前に項目を選びます。

危ない項目を挙げて除くのが除外リストです。入れてよい項目だけを選ぶ許可リストなら、新しい項目が追加されても、許可するまでログに入りません。

利用者IDも、その人の行動を結び付けられる情報です。名前やメールの表へのアクセスを分け、ログ自体にも閲覧権限と保存期限を設けます。

IDを使う目的は、同じ利用者の失敗を追うことです。必要がなければ残さず、残す場合もIDだけで安全だとは考えません。

予約サービスで解いてみる

DAU 3万人が1人6回アクセスすると、1日18万件の要求です。1要求に1行だけ残しても18万行になるため、月5万円の予算では量と保存期間も決める必要があります。

平均は約2 QPSですが、ピーク係数50の時間帯には毎秒100件を受けます。ログ1行ずつを人が読む方法では追いつかないので、まずメトリクスで異常の時間帯を絞ります。

予約の取り消しが240ミリ秒で終わり、出来事にはメールアドレスとカード番号も含まれていたとします。許可した5項目を選び、残りを落とします。

メールアドレスとカード番号はログに渡しません。あとから電話番号が増えても、許可リストを変えない限り保存されません。

メトリクスには、この要求を成功1件として加え、240ミリ秒の応答時間を集計します。利用者IDごとに集計項目を増やすと種類が膨らむので、全体監視には処理ごとの件数や割合を使います。

異常を見つけたら、該当する時間帯と要求IDからログを探します。全体を測る数字と1件を追う記録がそろっていれば、余分な個人情報を保存せずに調査できます。