Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DB調査をしやすくするためのログ設計
Search
Satoshi Kaneyasu
May 24, 2024
Programming
6
830
DB調査をしやすくするためのログ設計
[第34回 中国地方DB勉強会 in 広島](
https://dbstudychugoku.connpass.com/event/316403/)での発表資料です
。
Satoshi Kaneyasu
May 24, 2024
Tweet
Share
More Decks by Satoshi Kaneyasu
See All by Satoshi Kaneyasu
お客様とSIerではじめたスクラム開発(で得た学び)
satoshi256kbyte
0
75
From Pipenv to UV: Migrating to a Monorepoto Tame a Complex Repository
satoshi256kbyte
0
12
複雑化したリポジトリをなんとかした話 pipenvからuvによるモノレポ構成への移行
satoshi256kbyte
1
1.1k
ディレクトリ構成と設定ファイルから考えるSIerのVibe Coding
satoshi256kbyte
0
38
GitHubとGitLabとAWS CodePipelineでCI/CDを組み比べてみた
satoshi256kbyte
4
350
生産性の壁を越えろ! 何がなんでも計測する
satoshi256kbyte
1
36
オープンセミナー2025@広島「君はどこで動かすか?」アンケート結果
satoshi256kbyte
0
280
オープンセミナー2025@広島LT技術ブログを続けるには
satoshi256kbyte
0
190
AWS Summit Japan 2024と2025の比較
satoshi256kbyte
0
21
Other Decks in Programming
See All in Programming
その面倒な作業、「Dart」にやらせませんか? Flutter開発者のための業務効率化
yordgenome03
1
130
What's new in Spring Modulith?
olivergierke
1
150
デミカツ切り抜きで面倒くさいことはPythonにやらせよう
aokswork3
0
240
bootcamp2025_バックエンド研修_WebAPIサーバ作成.pdf
geniee_inc
0
110
なぜあの開発者はDevRelに伴走し続けるのか / Why Does That Developer Keep Running Alongside DevRel?
nrslib
3
410
Software Architecture
hschwentner
6
2.3k
Cursorハンズオン実践!
eltociear
2
1.1k
NixOS + Kubernetesで構築する自宅サーバーのすべて
ichi_h3
0
860
3年ぶりにコードを書いた元CTOが Claude Codeと30分でMVPを作った話
maikokojima
0
290
Web フロントエンドエンジニアに開かれる AI Agent プロダクト開発 - Vercel AI SDK を観察して AI Agent と仲良くなろう! #FEC余熱NIGHT
izumin5210
3
530
組込みだけじゃない!TinyGo で始める無料クラウド開発入門
otakakot
0
270
10年もののAPIサーバーにおけるCI/CDの改善の奮闘
mbook
0
830
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
340
57k
Bash Introduction
62gerente
615
210k
RailsConf 2023
tenderlove
30
1.2k
Mobile First: as difficult as doing things right
swwweet
224
10k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Designing for Performance
lara
610
69k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
115
20k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Become a Pro
speakerdeck
PRO
29
5.5k
Transcript
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だとバックエンドのログが⼤事 • ログに⼀⼿間かかると調査をしてもらえない →技術継承の⾯でもよろしくない • 本資料の内容を意識してなかった⼈は試してみてください
ありがとうございました