DB調査をしやすくするための ログ設計 〜バックエンド編〜 2024.05.25 SATOSHI KANEYASU

⾃⼰紹介 ⽒名︓兼安 聡 所属︓株式会社サーバーワークス 在住︓広島（フルリモート） 担当︓DevOps、プロジェクトマネージャー 資格︓ 最近よく触るDB: Amazon DynamoDB、Amazon Timestream、Amazon Neptune など

•最近、ベテラン–若⼿というチームをよく組みます • 中間層いません •ログ設計について、議論が必要だと思っていませんで したが、必要性を感じたので今回この話題を挙げてみ ました はじめに

•⼩中規模のWEBシステムのバックエンド •⼩⼈数、DBA1名、アプリエンジニア若⼲名 本発表のターゲット

調査の始まり • データ不整合 • レスポンス遅延 なら ユーザーからの連絡 • 負荷上昇 なら 監視機構からの通知

次のステップ 連絡の後は バックエンドのログ へ • グラフ • Performance Insights （分析機能） を⾒てからバックエ ンドのログへ

⼩中規模だとDBの情報は活⽤しづらい ⼩中規模だと、 DBサーバーの情報は、 スキル・環境の制約に より活⽤しきれない ことが多い 馴染みが深く 制約も⽐較的ゆるい こちらの情報を充実 化した⽅が効果が⾼ い

バックエンドのログで意識すること • ログレベルを使い分ける • 更新・削除件数やトランザクションはINFOで出⼒する • SQLはDEBUGで出⼒する（またはファイルを分ける） • SQLは完成系で出⼒する • バインド変数「︖」があるまま出⼒しない • SQLの実⾏時間を出⼒する • ログフォーマットにログインIDを含める • ログフォーマットにセッションIDやリクエストIDを含める

ログレベルを使い分ける • データの更新・削除件数を⾒て成功・失敗を判断 • パッと⾒でわからなければ⼀旦ログレベルをDEBUGにして 再現待ちにする • 正直なところ時間稼ぎの側⾯はある • トランザクションは（迷うところだが）DEBUG

SQLは完成系で出⼒する • 調査のためにバインド変数を置換するのは⾟すぎる • 抽出したSQLでデータ抽出したりEXPLAINに繋げたい • 「⼀⼿間かかる」と思われると作業を引き受けてくれる⼈が いなくなる ＜余談＞ • ORMを使ってれば基本SQLは⼀⾏になるはずなので、SQLに 改⾏があるとベタ書きしてる︖とヒアリングするかも

ログフォーマットにIDを含める • ID＝ログインID・セッションID・リクエストIDなど • IDでGrepすることで、特定ユーザーの操作や1アクション分 の操作を特定することができる • DBのグラフで時間帯特定 →バックエンドのログを⾒る →Grepして⼀連の操作を追う →ApacheやLBのログと付き合わせて更に特定

Performance Insightsはサポートへの 問い合わせに有⽤ • Amazon RDS Performance InsightsはAmazon RDSに備 わっている分析機能 • だいぶ有効な機能だと思う • AWSサポートに問い合わせる場合、 Performance Insights の情報を⾒せてほしいと⾔われることがある • Performance Insightsは無料だと7⽇分しか保存できない これだとサポートの⽅とのやり取り中に消失してしまうの で、有料を使うのがオススメ

まとめ • ⼩中規模システムのDBだとバックエンドのログが⼤事 • ログに⼀⼿間かかると調査をしてもらえない →技術継承の⾯でもよろしくない • 本資料の内容を意識してなかった⼈は試してみてください

ありがとうございました