こんにちは。Kaneyasuです。

昨日勉強会に参加していました。
そこで、フルスキャンしてるSQLがいっぱいあってこの先不安、怖いわーという会話をしていました。

その場では開発チームにSQLをよく知らないというか興味薄い方がいたからそういうことになったのかもね、なんて話していましたが、よく考えたらこれ、SQL以前のログの話な気がしてきました。
そう思ったら最近別のところでログの必要性を話したのを思い出したのでブログにしてみます。

なお、私はWebシステムのバックエンドの開発が一番多いので、バックエンドのログの観点で書いています。

コードレビューを依頼する前にログを見ておく

冒頭の話はORマッピングを用いたプログラムだと、意図しない重いSQL・大量のSQLが発行されることがあるという話です。
ORマッピングを使うと必ずそうなるわけではなく、大体は適切なパラメータを指定すればなんとかなります。
とはいえ、適切なパラメータを指定するのは楽ではない作業です。
熟練開発者は別ですが、大体はコード上だけで調整するのは難しく、ログを使って実際に発行されるSQLを見ながら調整することが必要です。
そういった事情から、コードレビューにおいてはレビュアーがコード上のORマッピングの使い方から出力されるSQLを想像しきるのは厳しいでしょう。
熟練開発者やノウハウの蓄積があるチームならば、危ないのでは？ぐらいの指摘はできるかもしれませんが、コードレビューでSQLの問題を指摘しきるのは難しいと思います。

他にも、ログを見ないとわからないこととしては、「Warning」があります。
画面上では動いているように見えるけど、実際にはログ上にはWarningが出ているということがあります。
良くないシステムでは、エラー出てるけど何もされてないということもあります。
これらは、将来的に大きな問題を引き起こす可能性を示唆する重大なヒントなのですが、これもコードレビューで見つけるのは非常に難しいと思います。

というわけで、個人的にはコードレビューを依頼する前にログを見ておくことはマナーかな・・・と思うには思います。
でも、それで回り切るとはいえないので、私は単体テストのテストケースにログ確認を入れるようにしています。

例）

ログにWarningが出ていないか
ログにErrorが出ていないか
不必要なSELECT文が大量に発行されていないか
大量のINSERT文が発行されていないか
大量のUPDATE文が発行されていないか
SELECT文の実行計画に問題がないか

最後のはおまけです。
チームでは一応確認するよう指示していますが、個人のテストレベルだと適度なデータがないのと、SQLに対する知識差があるので、あまり期待はしないようにしています。

ログへの意識を高めてもらうための説明

前項でログを見ることの重要性を述べましたが、私の周りでも人ごとのログへの意識差は大きいです。
意識の差は、保守の経験の有無で大きく変わります。
当然、保守を経験した人の方が意識は高くはなりますが、誰もが保守の経験の機会があるとは限りません。
私は、少しでもログへの意識を高めてもらうために、周囲に以下のような説明をしています。
私はWebシステムのバックエンドの開発が一番多いので、Webシステムで問題が起きた時を例にあげる説明すること多いです。

ログを見る順番の説明

問題があった時のよくある流れとして、アプリログでエラー発生を確認、Apache・Nginxログでアクセス元・日時を特定。
それを元にヒアリング、ブラウザで同様の操作をして再現、ブラウザのコンソールでエラーを確認、という感じで調査します。

ログの種類の説明

アプリログ
- Webフレームワークなら、SQLだけ・エラーだけのログも出力できることの説明
- AWSなら、CloudWatchのメトリクスフィルターを使えば、エラーの文言をフィルターしてアラートに繋げられることの説明
Apache・Nginxログ
- アクセス内容や、アプリログで出しきれていない情報があり得ることの説明
ロードバランサーのログ
- Apache・Nginxログのログ設定がふよろしくなくて、十分な情報が取れていない場合はこちらを見ます
ブラウザのコンソール
- Webサーバーに何を送ったのか、何が返ってきたのかがわかることの説明
OSのログ・DBサーバーのクエリログ
- 他のログに何も出てない時はこれらを見ることがありますが、初心者の方にはここまで説明はしないです。

ログの使い分けの説明

ログへの意識はあっても、ログをたくさん出すことに抵抗感を持つ方もいます。
確かにログを出しすぎるとパフォーマンスやストレージコストに影響を及ぼすのは確かです。
そういう方には、取り急ぎログの使い分けを説明するようにしています。

ログレベル

ログレベルは、ログの重要度を示すものです。
ログレベルによって、出力する内容を変えることができます。
大体のWebフレームワークやログライブラリでサポートされている機能です。
ログレベルレベルは、ERROR、WARN、INFO、DEBUG、TRACEなどがあります。
ログレベルはシステムの設定で変更できることが多いので、これを使ってログの出力量を調整することができます。
たとえば、INFOを指定すれば、出るログはERROR、WARN、INFOのみになります。
（使用するライブラリやFWによりますが）
開発時は情報を得ることを重視してDEBUGで、本番運用時はコストやパフォーマンスを重要視してINFOにしたりします。

ログレベルの使い分けの例

好みはあると思いますが、私は以下のように使い分けています。
本番運用でレベルをINFOにすればSQLが出なくなるのでログは少なくなる一方、最低限機能が動いたかどうかやデータの追加・更新・削除がされたかどうかはわかるようにしています。

INFO
- 開始・終了ログ
- 処理の区切り
- 追加・更新・削除件数
DEBUG
- SQL
TRACE
- ここは通った、通らなかったレベルのログ

#　最後に

長々とログの重要性を述べてしまいました。
開発作業や開発者への説明のヒントになれば幸いです。

宣伝

来月に広島市内でクラウドのお話をするオフラインの勉強会を開くことにしました。
2時間持つよう頑張ります。