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
710
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
密集、ドキュメントのコロケーション with AWS Lambda
satoshi256kbyte
0
190
【PHP】破壊的バージョンアップと戦った話〜決断と説得
satoshi256kbyte
0
140
今更聞けないセキュリティ用語の基礎知識 2025新春
satoshi256kbyte
0
110
AWS re:Invent 2024個人的まとめ
satoshi256kbyte
0
200
今年一番支援させていただいたのは認証系サービスでした
satoshi256kbyte
1
300
おもにクラウドの話してます#4 OPスライド
satoshi256kbyte
0
60
AWS認定資格を勉強した先に何があったか
satoshi256kbyte
2
270
Amazon Aurora Serverless v2のアプデと、Amazon Aurora PostgreSQL Limitless DatabaseのGAについて
satoshi256kbyte
0
170
GitHub Actionsのキャッシュと手を挙げることの大切さとそれに必要なこと
satoshi256kbyte
5
480
Other Decks in Programming
See All in Programming
Pythonでもちょっとリッチな見た目のアプリを設計してみる
ueponx
1
560
GoとPHPのインターフェイスの違い
shimabox
2
190
クリーンアーキテクチャから見る依存の向きの大切さ
shimabox
1
240
Honoをフロントエンドで使う 3つのやり方
yusukebe
7
3.3k
負債になりにくいCSSをデザイナとつくるには?
fsubal
9
2.4k
CDK開発におけるコーディング規約の運用
yamanashi_ren01
2
110
AIの力でお手軽Chrome拡張機能作り
taiseiue
0
170
時計仕掛けのCompose
mkeeda
1
300
Amazon Bedrock Multi Agentsを試してきた
tm2
1
290
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
j5ik2o
10
3.6k
動作確認やテストで漏れがちな観点3選
starfish719
6
1k
CI改善もDatadogとともに
taumu
0
110
Featured
See All Featured
Being A Developer After 40
akosma
89
590k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.1k
Typedesign – Prime Four
hannesfritz
40
2.5k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
4
330
Mobile First: as difficult as doing things right
swwweet
223
9.3k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
We Have a Design System, Now What?
morganepeng
51
7.4k
Visualization
eitanlees
146
15k
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
BBQ
matthewcrist
87
9.5k
Faster Mobile Websites
deanohume
306
31k
Automating Front-end Workflow
addyosmani
1368
200k
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だとバックエンドのログが⼤事 • ログに⼀⼿間かかると調査をしてもらえない →技術継承の⾯でもよろしくない • 本資料の内容を意識してなかった⼈は試してみてください
ありがとうございました