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にも使用できます。最近は私たちのサービスでも、データドリブン開発を本格的に行うためにプロダクトオーナーやプロダクトマネージャー、事業企画の人たちといっしょになって、実際にデータを見てどのような改善ができるのか試行を始めています。今回は私たちが最初に作った仕組みを紹介しました。ミニマムに始められると思いますので、ご自身の会社でも実行するときの参考にしてください」田中氏は、このように語ってセッションを締めくくった。
