いつ何を記録するか（ログ、メトリクス、SREとは）
「ログをきちんと書いて」だとか「メトリクスをきちんと取って」と言われても、何がきちんとしたログ・メトリクスなのかが分からないと、何をすればいいのか分かりませんよね。闇雲にログやメトリクスを取りすぎても余計な情報に溢れてしまって、大切な情報を見逃しやすくなってしまいます。
では、何を基準にログ・メトリクスを取ればいいのでしょうか？
ログの基準
ログは、何か起きたときに実際にいつ何が起きたのか、なぜそれが起きたのかを知るために書くものです。つまり、その情報を与えてくれないログは騒音になってしまいます。
ログは、基本的に大切なことが起きる前と起きた後に書きましょう。
例えばデータベースへの書き込みを行う前と後にログ。そこでエラーが発生すればログ。逆に、同じくデータベースにアクセスする場合でも、読み込みの場合はシステムに変化をもたらさないので、エラー時のみのログで十分な場合が多いです。
ここで、ただ「今からデータベースに書き込みをします」というログを残すのではなく、どんなデータを書き込みするのか、どれほどの量のデータを書き込みするのか、どこに書き込みするのかなどをログすることで、何が起こっていたのかを見返しやすくなります。
ログのレベル
多くの場合、ログにはレベルが定められています。
一般的なのはdebug、info、warning、errorなどで、用途によってどのレベルで書くかを選べる様になっています。どのレベルをどの用途で使うかはチームによって違いますが、例えば以下のように使い分けをすることができます：
-
debugは「念のため」をログする- データベースの読み込み前後など
-
infoはシステムに影響を及ぼすことをログする- データベースの書き込み前後など
-
warningは大したことではないが、本来起こってはいけないことをログする- 何かに失敗したが、回復方法（例：バックアップに接続する、自動的にもう一度やりなおす）がある場合など
-
errorはすぐにでも知らなければならないことをログする- 何かに失敗し、どう回復したらいいか分からない場合など
レベルを使い分けると、例えば以下のようなことが出来るようになります：
- ログを見ているときにそれぞれのログがどれほどの重要度を持っているのかを表す
- まずは
errorレベルのログを抽出、その後その周りのログを見るなど
- まずは
- 本番環境では
info以上のログしか残さないことで、本番環境のログをきれいに保ちつつ、開発中のログには念のために必要以上の情報を残す
メトリクスの基準
メトリクスは、サービスが顧客を満足させられる状態にあるのかを知るために取るものです。つまり、顧客にとって大切でないメトリクスは意味のないものになってしまいます。
メトリクスは、顧客の目線から見て大切なものを取るようにしましょう。
例えばWebアプリケーションだとホームページの読み込み速度や、そのアプリケーションの肝となる機能の成功率、反応速度などです。
この辺はSRE（Site Reliability Engineering）と深く関係してくるので、少しSREについても見てみましょう。
SRE（概念）
SREとは、めちゃくちゃ簡単に言うと、「こういう風にメトリクスを取り、利用しましょう」という考え方を記したものです。ここではSREの全てを記すわけではなく、あくまでも芯となる部分だけを紹介します。
SREは、以下の考え方から成り立っています：
- メトリクスは、ビジネスの目標と密接な関係がなければならない
- メトリクスの目標は、多くなれば多くなるほど、高くなれば高くなるほど開発や運営にお金がかかる
そして、以下の３つの概念から成り立っています：
- SLA（Service-Level Agreement）
- Agreement: 同意
- SLO（Service-Level Objective）
- Objecive: 目標
- SLI（Service-Level Indicator）
- Indicator: 指標
SLA（同意）
SLAとは、顧客と同意したサービスの状態のことを言います。例えばあなたのサービスが99.99%アップタイムを顧客に約束しているなら、それがSLAとなります。SLAを約束できなかった場合、顧客に一部お金を返済したりすることになります。
サービスによって、SLAはある場合とない場合があります。
SLO（目標）
もしSLA（同意）がある場合は、まず最低でもそれを満たすためのSLO（目標）が必要になります。例えば顧客と99.99%アップタイムを同意しているのなら、SLOも99.99%アップタイムを目標にする、という風になるでしょう。
この場合、具体的に何が「アップタイム」なのかも定義する必要があります。例えばツイッターを例にとると、ツイートを読めることがアップタイムに入るのか？ツイートできることも入るのか？ＤＭは入るのか？などです。
また、SLAとは関係ないSLOも存在しますし、サービスにSLAが存在しない場合でも、SLOは存在します。
例えばツイッターの場合、ツイートの成功率や早さなどにSLAはありませんが、ツイートをするのに成功率が99.9%、早さは平均３秒以内というSLOを定めるのもいいでしょう（今僕が適当に作ったSLOなので、実際のサービスとは一切関係ありません）。
大切なのは顧客にとって大切なものだけを計測し、「顧客が満足する最低ライン」を定め、それをSLOにするということです。
なぜ大切なものだけ、しかも最低ラインかと言うと、目標は多ければ多いほど、高ければ高いほど開発にも運営にもお金がかかるからです。なので必要最低限の目標を設定するということは、一番安く顧客を満足させられるラインを明確にするということになるのです。
また、SLOは単純で計測しやすいものである必要があります。複雑なものは計測しにくいだけでなく、どう改善したらいいかも分かりにくくなってしまいます。SLOは必ず簡単な文章で表せられるものにしましょう。
例：
- ツイートは成功率99.9%、早さは平均３秒以内とする
- ホームページの読み込みは成功率99.99%、早さは平均３秒以内とする
SLI（指標）
SLI（指標）は、SLO（目標）を実際に計測した指標となります。例えばツイートの成功率のSLOが99.9%だった場合、SLIは99.95%（SLOを満たしている）かもしれませんし、99.5%（SLOを満たしていない）かもしれません。
SLIも同様に、SLOに関係ないものは計測しないようにすることで、全体のコストを下げるようにしましょう。
終わりに
闇雲にログを書いたりメトリクスを取っていると、情報量が多くなりすぎて何が大切な情報なのか分かりにくくなってしまいます。ログやメトリクスの役割を理解することで、その役割を果たす最低限の実装をすることができます。
もしアプリケーションを高速化したい場合は、下の記事に高速化の仕方を書いたので、よければそちらもご覧ください：
もし質問などがあれば、お気軽にコメントやツイッターで声かけてください：
Discussion