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
720
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
変化の激しい時代における、こだわりのないエンジニアの強さ
satoshi256kbyte
1
1.2k
密集、ドキュメントのコロケーション with AWS Lambda
satoshi256kbyte
1
240
【PHP】破壊的バージョンアップと戦った話〜決断と説得
satoshi256kbyte
0
180
今更聞けないセキュリティ用語の基礎知識 2025新春
satoshi256kbyte
0
140
AWS re:Invent 2024個人的まとめ
satoshi256kbyte
0
260
今年一番支援させていただいたのは認証系サービスでした
satoshi256kbyte
1
500
おもにクラウドの話してます#4 OPスライド
satoshi256kbyte
0
68
AWS認定資格を勉強した先に何があったか
satoshi256kbyte
2
280
Amazon Aurora Serverless v2のアプデと、Amazon Aurora PostgreSQL Limitless DatabaseのGAについて
satoshi256kbyte
0
200
Other Decks in Programming
See All in Programming
List とは何か? / PHPerKaigi 2025
meihei3
0
560
NestJSのコードからOpenAPIを自動生成する際の最適解を探す
astatsuya
0
190
snacks.nvim内のセットアップ不要なプラグインを紹介 / introduce_snacks_nvim
uhooi
0
340
複数ドメインに散らばってしまった画像…! 運用中のPHPアプリに後からCDNを導入する…!
suguruooki
0
430
‘무차별 LGTM~👍’만 외치던 우리가 ‘고봉밥 코드 리뷰’를?
hannah0731
0
530
ミリしらMCP勉強会
watany
2
390
아직도 SOLID 를 '글'로만 알고 계신가요?
sh1mj1
0
360
PHPでお金を扱う時、終わりのない 謎の1円調査の旅にでなくて済む方法
nakka
3
1.3k
신입 안드로이드 개발자의 AI 스타트업 생존기 (+ Native C++ Code를 Android에서 사용해보기)
dygames
0
500
Windows版PHPのビルド手順とPHP 8.4における変更点
matsuo_atsushi
0
370
なぜselectはselectではないのか
taiyow
2
310
Boost Your Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
120
Featured
See All Featured
It's Worth the Effort
3n
184
28k
Faster Mobile Websites
deanohume
306
31k
Designing for humans not robots
tammielis
250
25k
What's in a price? How to price your products and services
michaelherold
245
12k
The Language of Interfaces
destraynor
157
24k
Scaling GitHub
holman
459
140k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.2k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
25k
Designing Experiences People Love
moore
141
23k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.3k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
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だとバックエンドのログが⼤事 • ログに⼀⼿間かかると調査をしてもらえない →技術継承の⾯でもよろしくない • 本資料の内容を意識してなかった⼈は試してみてください
ありがとうございました