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
5
580
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
Amazon Neptuneで始める初めてのグラフDB ー グラフDBを使う意味を考える ー
satoshi256kbyte
2
49
おもにクラウドの話してます#3 OPスライド
satoshi256kbyte
1
21
AWS CodeCommitの次として考えた場合のAmazon CodeCatalyst
satoshi256kbyte
1
300
アプリケーションエンジニアがDistributed Load Testingで 負荷テストをしてみる〜Ver.B〜
satoshi256kbyte
2
58
アプリケーションエンジニアがDistributed Load Testingで負荷テストをしてみる〜Ver.A〜
satoshi256kbyte
2
96
AWS App Studio (Preview)は何分でアプリを作れるのか
satoshi256kbyte
0
250
AWS CodeGuruでPythonのコードを自動レビューしてもらおう
satoshi256kbyte
1
140
Gitでコンフリクトが起きたらコミットしよう
satoshi256kbyte
1
54
ワクワク状態を維持するレトロスペクティブ
satoshi256kbyte
1
110
Other Decks in Programming
See All in Programming
ゲームボーイアドバンスでSwiftを動かそう
k_koheyi
0
510
LR で JSON パーサーを作る / Coding LR JSON Parser
junk0612
2
170
健康第一!MetricKitで始めるアプリの健康診断 / App Health Checkups Starting with MetricKit
nekowen
4
790
月間4.5億回再生を超える大規模サービス TVer iOSアプリのリアーキテクチャ戦略 - iOSDC2024
techtver
PRO
1
570
Boost Your Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
1
930
フロントエンドのテストからアクセシビリティをしれっと広めていく
nano72mkn
3
700
Ebitengineの1vs1ゲーム WebRTCの活用
ponyo877
0
330
私の考える初学者がBlazorできるまでの学習方法
tomokusaba
1
240
デザインシステムとコンポーネント指向によるフロントエンド開発プロセスの革新 / Innovation in Frontend Development Processes through Design Systems and Component-Oriented Architecture
nrslib
7
5k
BasicBasic認証
sadnessojisan
5
2.5k
オートマトン学習しろ / Do automata learning
makenowjust
3
100
REXML改善のその後
naitoh
0
150
Featured
See All Featured
Into the Great Unknown - MozCon
thekraken
28
1.4k
How to Think Like a Performance Engineer
csswizardry
15
910
The Mythical Team-Month
searls
218
43k
[RailsConf 2023] Rails as a piece of cake
palkan
44
4.6k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
28
2.2k
The Art of Programming - Codeland 2020
erikaheidi
48
13k
A better future with KSS
kneath
235
17k
Bash Introduction
62gerente
608
210k
Principles of Awesome APIs and How to Build Them.
keavy
125
16k
Ruby is Unlike a Banana
tanoku
96
10k
Creatively Recalculating Your Daily Design Routine
revolveconf
215
12k
Documentation Writing (for coders)
carmenintech
65
4.3k
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だとバックエンドのログが⼤事 • ログに⼀⼿間かかると調査をしてもらえない →技術継承の⾯でもよろしくない • 本資料の内容を意識してなかった⼈は試してみてください
ありがとうございました