DB調査をしやすくするためのログ設計

[第34回 中国地方DB勉強会 in 広島](https://dbstudychugoku.connpass.com/event/316403/)での発表資料です。

Transcript

1. DB調査をしやすくするための ログ設計 〜バックエンド編〜 2024.05.25 SATOSHI KANEYASU
2. ⾃⼰紹介 ⽒名︓兼安 聡 所属︓株式会社サーバーワークス 在住︓広島（フルリモート） 担当︓DevOps、プロジェクトマネージャー 資格︓ 最近よく触るDB: Amazon DynamoDB、Amazon Timestream、Amazon Neptune など
3. •最近、ベテラン–若⼿というチームをよく組みます • 中間層いません •ログ設計について、議論が必要だと思っていませんで したが、必要性を感じたので今回この話題を挙げてみ ました はじめに
4. •⼩中規模のWEBシステムのバックエンド •⼩⼈数、DBA1名、アプリエンジニア若⼲名 本発表のターゲット
5. 調査の始まり • データ不整合 • レスポンス遅延 なら ユーザーからの連絡 • 負荷上昇 なら 監視機構からの通知
6. 次のステップ 連絡の後は バックエンドのログ へ • グラフ • Performance Insights （分析機能） を⾒てからバックエ ンドのログへ
7. ⼩中規模だとDBの情報は活⽤しづらい ⼩中規模だと、 DBサーバーの情報は、 スキル・環境の制約に より活⽤しきれない ことが多い 馴染みが深く 制約も⽐較的ゆるい こちらの情報を充実 化した⽅が効果が⾼ い
8. バックエンドのログで意識すること • ログレベルを使い分ける • 更新・削除件数やトランザクションはINFOで出⼒する • SQLはDEBUGで出⼒する（またはファイルを分ける） • SQLは完成系で出⼒する • バインド変数「︖」があるまま出⼒しない • SQLの実⾏時間を出⼒する • ログフォーマットにログインIDを含める • ログフォーマットにセッションIDやリクエストIDを含める
9. ログレベルを使い分ける • データの更新・削除件数を⾒て成功・失敗を判断 • パッと⾒でわからなければ⼀旦ログレベルをDEBUGにして 再現待ちにする • 正直なところ時間稼ぎの側⾯はある • トランザクションは（迷うところだが）DEBUG
10. SQLは完成系で出⼒する • 調査のためにバインド変数を置換するのは⾟すぎる • 抽出したSQLでデータ抽出したりEXPLAINに繋げたい • 「⼀⼿間かかる」と思われると作業を引き受けてくれる⼈が いなくなる ＜余談＞ • ORMを使ってれば基本SQLは⼀⾏になるはずなので、SQLに 改⾏があるとベタ書きしてる︖とヒアリングするかも
11. ログフォーマットにIDを含める • ID＝ログインID・セッションID・リクエストIDなど • IDでGrepすることで、特定ユーザーの操作や1アクション分 の操作を特定することができる • DBのグラフで時間帯特定 →バックエンドのログを⾒る →Grepして⼀連の操作を追う →ApacheやLBのログと付き合わせて更に特定
12. Performance Insightsはサポートへの 問い合わせに有⽤ • Amazon RDS Performance InsightsはAmazon RDSに備 わっている分析機能 • だいぶ有効な機能だと思う • AWSサポートに問い合わせる場合、 Performance Insights の情報を⾒せてほしいと⾔われることがある • Performance Insightsは無料だと7⽇分しか保存できない これだとサポートの⽅とのやり取り中に消失してしまうの で、有料を使うのがオススメ
13. まとめ • ⼩中規模システムのDBだとバックエンドのログが⼤事 • ログに⼀⼿間かかると調査をしてもらえない →技術継承の⾯でもよろしくない • 本資料の内容を意識してなかった⼈は試してみてください
14. ありがとうございました