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
820
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のVibe Coding
satoshi256kbyte
0
24
GitHubとGitLabとAWS CodePipelineでCI/CDを組み比べてみた
satoshi256kbyte
4
250
生産性の壁を越えろ! 何がなんでも計測する
satoshi256kbyte
1
31
オープンセミナー2025@広島「君はどこで動かすか?」アンケート結果
satoshi256kbyte
0
270
オープンセミナー2025@広島LT技術ブログを続けるには
satoshi256kbyte
0
180
AWS Summit Japan 2024と2025の比較
satoshi256kbyte
0
21
はじめてのKiro、今あなたは岐路に立つ
satoshi256kbyte
1
80
AWS Summit Japan 2024と2025の比較/はじめてのKiro、今あなたは岐路に立つ
satoshi256kbyte
1
310
フルリモートで社内にどうやって自分の居場所を作るのか?
satoshi256kbyte
12
18k
Other Decks in Programming
See All in Programming
AIを活用し、今後に備えるための技術知識 / Basic Knowledge to Utilize AI
kishida
22
5.9k
旅行プランAIエージェント開発の裏側
ippo012
2
930
速いWebフレームワークを作る
yusukebe
5
1.7k
250830 IaCの選定~AWS SAMのLambdaをECSに乗り換えたときの備忘録~
east_takumi
0
400
Performance for Conversion! 分散トレーシングでボトルネックを 特定せよ
inetand
0
2.4k
Android 16 × Jetpack Composeで縦書きテキストエディタを作ろう / Vertical Text Editor with Compose on Android 16
cc4966
2
260
複雑なドメインに挑む.pdf
yukisakai1225
5
1.2k
はじめてのMaterial3 Expressive
ym223
2
890
The Past, Present, and Future of Enterprise Java with ASF in the Middle
ivargrimstad
0
160
OSS開発者という働き方
andpad
5
1.7k
CloudflareのChat Agent Starter Kitで簡単!AIチャットボット構築
syumai
2
510
プロポーザル駆動学習 / Proposal-Driven Learning
mackey0225
2
1.3k
Featured
See All Featured
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
810
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Faster Mobile Websites
deanohume
309
31k
Six Lessons from altMBA
skipperchong
28
4k
It's Worth the Effort
3n
187
28k
The Invisible Side of Design
smashingmag
301
51k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.1k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.9k
Typedesign – Prime Four
hannesfritz
42
2.8k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
Git: the NoSQL Database
bkeepers
PRO
431
66k
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だとバックエンドのログが⼤事 • ログに⼀⼿間かかると調査をしてもらえない →技術継承の⾯でもよろしくない • 本資料の内容を意識してなかった⼈は試してみてください
ありがとうございました