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
1
200
【PHP】破壊的バージョンアップと戦った話〜決断と説得
satoshi256kbyte
0
140
今更聞けないセキュリティ用語の基礎知識 2025新春
satoshi256kbyte
0
110
AWS re:Invent 2024個人的まとめ
satoshi256kbyte
0
200
今年一番支援させていただいたのは認証系サービスでした
satoshi256kbyte
1
300
おもにクラウドの話してます#4 OPスライド
satoshi256kbyte
0
61
AWS認定資格を勉強した先に何があったか
satoshi256kbyte
2
270
Amazon Aurora Serverless v2のアプデと、Amazon Aurora PostgreSQL Limitless DatabaseのGAについて
satoshi256kbyte
0
180
GitHub Actionsのキャッシュと手を挙げることの大切さとそれに必要なこと
satoshi256kbyte
5
480
Other Decks in Programming
See All in Programming
GitHub Actions × RAGでコードレビューの検証の結果
sho_000
0
280
時計仕掛けのCompose
mkeeda
1
310
第3回関東Kaggler会_AtCoderはKaggleの役に立つ
chettub
3
1.1k
XStateを用いた堅牢なReact Components設計~複雑なClient Stateをシンプルに~ @React Tokyo ミートアップ #2
kfurusho
1
940
メンテが命: PHPフレームワークのコンテナ化とアップグレード戦略
shunta27
0
190
もう僕は OpenAPI を書きたくない
sgash708
5
1.8k
負債になりにくいCSSをデザイナとつくるには?
fsubal
10
2.5k
1年目の私に伝えたい!テストコードを怖がらなくなるためのヒント/Tips for not being afraid of test code
push_gawa
1
350
PRレビューのお供にDanger
stoticdev
1
200
Writing documentation can be fun with plugin system
okuramasafumi
0
120
AIの力でお手軽Chrome拡張機能作り
taiseiue
0
180
Unity Android XR入門
sakutama_11
0
170
Featured
See All Featured
GraphQLとの向き合い方2022年版
quramy
44
13k
The Language of Interfaces
destraynor
156
24k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
420
Producing Creativity
orderedlist
PRO
344
39k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Being A Developer After 40
akosma
89
590k
Designing Experiences People Love
moore
140
23k
Speed Design
sergeychernyshev
27
800
Optimizing for Happiness
mojombo
376
70k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.2k
We Have a Design System, Now What?
morganepeng
51
7.4k
Into the Great Unknown - MozCon
thekraken
35
1.6k
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だとバックエンドのログが⼤事 • ログに⼀⼿間かかると調査をしてもらえない →技術継承の⾯でもよろしくない • 本資料の内容を意識してなかった⼈は試してみてください
ありがとうございました