ニーズや市場の変化に応じる「データドリブン開発」とは
田中氏が所属する株式会社うるるでは、NJSS（エヌジェス）という入札情報速報サービスを提供しており、このサービスを題材にログの全体像を説明した。
「一般的にデータドリブン開発とは、顧客の行動データや市場データなどを用いることで、顧客のニーズや市場の変化を捉えて、それに応じた開発を行っていくことです。こうした情報が出力されているのが、私たち開発者がよく知っているログです。ログに出力されている情報を十分に活用することで、データドリブンなサービス運用を実現していきます」
Webサービスの場合、次のような情報が出力される。サービスの状態としては、稼働率やエラー率・レスポンスの時間がある。サービスの利用状況としては、利用頻度や利用している機能がある。さらにセキュリティの情報として、アクセス情報などがある。
もちろんこれですべてではないが、こうしたログを十分に活用することで、データドリブンなサービス運用を実現するのだ。
ログ設計で明確にすべき4つのポイント
サービス運用にログを活用するには、まずログ設計が重要になる。
「ざっくりログ設計といっても曖昧になるので、今回は次のポイントにしぼってお話します。ログの利用目的、ログの重要度、ログの出力形式、ログの保管先の4つです」
ログの利用目的は、このログを利用して何を実現したいかだ。Webサービスの場合は、安定的なサービス運用となるだろう。これを手に入れるために、ログを活用するのだ。
ログの重要度は対象システムやレイヤーによって異なるが、アプリケーション開発を例にすると次のようになる。例えば、FATALはサービスを継続できないような致命的なエラーをあらわし、WARNは動作には影響しないが気を付けたほうがよい動作の警告をあらわし、INFOが正常動作の出力情報をあらわすという具合だ。
「これらの情報をうまく使い分けることによって重要度を決めていきます。本来はWARNとして出力されなきゃいけない情報がERRORとして出力されたり、その逆もあったりすると運用上の妨げになることがあるので、ここはきちっと意識をしないといけないと思います」
ログの出力形式は、どのようなフォーマットで出力するかである。Webアプリケーションであれば、タイムスタンプや出力元の情報、ログの重要度をあらわすログレベルなどある程度の内容は決まっているだろう。
「通常は、スライドの青文字の部分で確認することが多いです。メソッドとURLでどういった処理が行われたかを確認して、レスポンスコードでその処理結果がどうだったかを確認します。異常が起こった場合には赤文字の部分を追加で確認します。どこからという情報は、IPやリファラーで確認し、何が起きたかを詳細にて確認します。詳細部分にはスタックトレースをそのまま出力することが多いです」
ログの保管先とは、単純にログファイルが出力される場所である。田中氏が運用するNJSSではECSを使用しているため、基本的にCloudWatchに出力される。またAWSのサービスから出力されるログに関してはS3に出力している。さらに、リクエストログの一部は、CloudWatchではなくBigQueryに出力するようにしてある。このBigQueryをデータウェアハウスとして使っていて、Google Analyticsの情報も出力している。最後に、アプリケーションで発生したログやリクエストログの一部はDatadogなどのイベントトラッキングサービスに連携している。
もう一つ大事なのが、出力するタイミングである。特にサービス運用として考えた場合にはエラーが重要になる。アプリケーションの不具合の可能性があるので、早急に対応が必要になるからだ。エラーではないが特定の条件に合致した場合も注目する必要がある。たとえば、バリデーションエラーやログイン認証の失敗、規約上の上限といった具合だ。また想定通りの挙動だがユーザーとしてうまく利用できてない状況を記録していく。こうした状況の発生頻度が多いようであれば、何かしら改善の余地がある可能性がある。
NJSSにおけるログ活用の実際
そして田中氏は、NJSSにおけるログ活用を具体的に紹介した。
ログに関する構成は次の図のようになっている。ここで点線はリクエストの流れで、実線がログ出力にあたる。先ほど説明したように、ALBのログはS3へ保管し、ECSからは基本的にCloudWatchとBigQueryに出力する。またモニタリングする情報に関しては、DatadogやSentryへ連携をしており、異常を発見したときには最終的にSlackへ通知して、開発部内へ共有するようになっている。
では、実際にどのように運用にログを活用しているのだろうか。田中氏は、4つのポイントに整理して解説してくれた。
まずは、サービスの状態である。NJSSでは、リクエスト数やレスポンス・システムリソースの状態をチェックしている。リスエスト数では、どのサービスがどれくらい呼ばれているかを、DatadogやBigQueryに格納されたログを集計して把握している。レスポンスでは、Datadogに入れた情報から遅延がないかを把握しており、500エラーでリクエストそのものにエラーが多発してないかなどをALBのメトリックスなどで把握している。システムリソースでは、 CPUやメモリなどが過負荷になっていないかをCloudWatchやDatadogで把握している。
ここで田中氏は実際の画面を紹介した。左側がリクエストとレスポンスをDatadogで可視化したもの。右側がリソース状況としてCPUやメモリの使用率を可視化したものだ。このように、ぱっと見で視覚的に状況を分かりやすくしてあるのだ。
次にエラーの状況である。ユーザーに影響のある事象として、次の種類のエラーを把握している。アプリの不具合とは、アプリケーションで起きたイレギュラーな事象で、主にSentryで検知している。プラットフォームの不具合とは、サーバーやインフラ系の不具合を指している。
サーバーが停止していないかの不活監視、異常があった場合のAWSからの通知を検知している。また、データベースへの接続エラーが発生した場合も通知している。過負荷によるスローダウンとは、レスポンスが遅くなってしまったり、メモリが枯渇してしまったりといった事象を指しており、Datadogで閾値を設定してアラートしている。
ここで重要になるのが、見やすくする工夫だ。人の目で確認できる量には限界があるため情報量を減らす必要があるのだ。エラーが発生する場合には同時多発的に大量に出力される可能性もあるためSentryで通知頻度を制御している。
次にフォーマットの工夫である。必要な情報だけ整理して、SentryやDatadogの画面で確認できるようにしておく。
ここで田中氏は、実際のSentryの画面を見せてくれた。一番上にExceptionがあり、同じエラーが起きた場合にまとめておくことで、何を解決すべきかの優先順位を付ける参考にしているそうだ。
3番目のポイントはセキュリティの状態である。外部からの攻撃や侵入の記録に関しては、GuardDutyやWAF、VPCフローログで確認している。監査系のログに関してはデータベースへ記録する。システム変更に関しては、CloudTailやAWSConfigにて確認をおこなっている。これらの確認や通知はそれぞれの特性に応じておこなっているそうだ。
4番目のポイントはユーザーの利用状況である。URLによるアクセス情報や、どんなデバイスを使用しているかといったユーザーエージェント、どこを経由してきたかがわかるリファラー、ユーザーを特定できるIDなどの情報がある。こうした情報は、そのままBigQueryに格納して確認できるようにしている。
BigQueryにはGoogle Analyticsの情報も同時に格納している。そのため、連携することでより詳しい行動分析をおこなえる。
「今回ご紹介したようなことを行うことでサービス運用として一定の効果は得られると思います。SREの活動で使用できるSLAやSLOにも使用できます。最近は私たちのサービスでも、データドリブン開発を本格的に行うためにプロダクトオーナーやプロダクトマネージャー、事業企画の人たちといっしょになって、実際にデータを見てどのような改善ができるのか試行を始めています。今回は私たちが最初に作った仕組みを紹介しました。ミニマムに始められると思いますので、ご自身の会社でも実行するときの参考にしてください」田中氏は、このように語ってセッションを締めくくった。
