バックエンドログ設計

きっかけ

新規に携わらせていただいたプロジェクトがReactNativeで構築されている環境向けの動画の動作を提供するパッケージ作成全般。

その業務ではログを見てバグ調査をすることが多く、また自身もバックエンドの設計においてこの辺り考えたこともなかったため、一度きちんと整理と言語化をしたいと思った

ログの役割

そもそもなぜログを使用するのかわからないと、どういう時にログを書くべきかわからない。

ログの主な役割としては下記

• 障害発生時の原因追跡
• ユーザー行動の記録
• セキュリティインシデントの監視
• パフォーマンス分析と改善
• アプリケーションの監視と保守

ログの基本

• ログフォーマット・・・メッセージ以外に何を記載するかのフォーマット。例えば「[INFO]メッセージ」みたいな感じ。他の設計が決まってくればこの辺は決まるので、最後に決めればOK
• ログレベル・・・DEBUG、INFO、WARN、ERROR、FATALなど。ログが多すぎても見ずらい(汚れる)ため、欲しいログのタイプを分別して好きなログをタイプ別に絞り込めるようにする。
• ログ出力場所・・・標準出力、ファイル、ログ収集サービス（CloudWatch、Datadogなど）を選択。
• ログローテート・・・ログファイルが際限なく肥大化しないよう、一定のルールでログファイルを分割・切り替え・削除する仕組み。どれくらいログが残ったら、どのようにファイルを分けて、不要なログをいつ削除するかを決める。(他にも色々ありそうだけど、ざっくりこれくらい把握)

各ログレベルの目的

• DEBUG・・・プログラムの不具合（バグ）を直すため。変数の中身、細かい処理の分岐、SQL文の詳細など。
• INFO・・・システムが正しく動いていることを確認するため。どの順序で何が動いているかを把握する
• WARN・・・まだエラーではないが、ディスクの空き容量が減っているなど、このままだと問題が起きそうな状態
• ERROR・・・処理が失敗した、またはデータが保存できなかったなど、すぐに対応や確認が必要な問題
• FATAL・・・致命的なエラー。システムがこれ以上動かない、またはデータが壊れるような最悪の状態

ログでやりがちなNGパターン

• すべての例外をERRORで出す：業務エラー（例：バリデーションエラー）はWARNで十分。
• ログの重複：ミドルウェアとアプリの両方で同じログを出すとノイズになる。
• 大量のログ出力：ディスク枯渇やパフォーマンス劣化の原因になる。

あとは読んでみて参考になった記事

https://zenn.dev/dove/articles/aef7e6617038ee。・・・失敗談も書いていてあってなるほどってなる。ベストプラクティスだけではなくて、どうするとダメなのか、失敗ケースを学ぶことはすごく大切