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
RDS/Auroraパフォーマンスインサイトを使ってみる(ちょっとだけAPI編)
Search
hmatsu47
PRO
April 30, 2021
Technology
0
280
RDS/Auroraパフォーマンスインサイトを使ってみる(ちょっとだけAPI編)
JAWS-UG 浜松 AWS 勉強会 2021#4 2021/04/30
hmatsu47
PRO
April 30, 2021
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
8
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
hmatsu47
PRO
0
10
PostgreSQL+pgvector で LlamaIndex の Property Graph Index を試す(序章)
hmatsu47
PRO
0
11
HeatWave on AWS という選択肢を検討してみる
hmatsu47
PRO
0
6
HeatWave on AWS のインバウンドレプリケーションで HeatWave エンジン有効時のレプリケーションラグを確認してみた!
hmatsu47
PRO
0
16
CloudWatch Database Insights 関連アップデート
hmatsu47
PRO
0
28
さいきんの MySQL との付き合い方 〜 MySQL 8.0 より後の世界へようこそ 〜
hmatsu47
PRO
0
29
ベクトルストア入門
hmatsu47
PRO
0
25
Aurora DSQL について
hmatsu47
PRO
0
27
Other Decks in Technology
See All in Technology
生成AIで小説を書くためにプロンプトの制約や原則について学ぶ / prompt-engineering-for-ai-fiction
nwiizo
4
2.2k
Snowflake Summit 2025全体振り返り / Snowflake Summit 2025 Overall Review
mtpooh
2
400
M3 Expressiveの思想に迫る
chnotchy
0
110
CursorによるPMO業務の代替 / Automating PMO Tasks with Cursor
motoyoshi_kakaku
0
160
Agentic Workflowという選択肢を考える
tkikuchi1002
1
540
PHP開発者のためのSOLID原則再入門 #phpcon / PHP Conference Japan 2025
shogogg
4
850
A2Aのクライアントを自作する
rynsuke
1
190
プロダクトエンジニアリング組織への歩み、その現在地 / Our journey to becoming a product engineering organization
hiro_torii
0
130
TechLION vol.41~MySQLユーザ会のほうから来ました / techlion41_mysql
sakaik
0
190
Amazon S3標準/ S3 Tables/S3 Express One Zoneを使ったログ分析
shigeruoda
4
540
How Community Opened Global Doors
hiroramos4
PRO
1
120
Delegating the chores of authenticating users to Keycloak
ahus1
0
130
Featured
See All Featured
Balancing Empowerment & Direction
lara
1
380
Visualization
eitanlees
146
16k
Faster Mobile Websites
deanohume
307
31k
YesSQL, Process and Tooling at Scale
rocio
173
14k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
490
Building Applications with DynamoDB
mza
95
6.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Rebuilding a faster, lazier Slack
samanthasiow
82
9.1k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
VelocityConf: Rendering Performance Case Studies
addyosmani
330
24k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3k
Transcript
RDS / Aurora パフォーマンスインサイトを 使ってみる(ちょっとだけ API 編) JAWS-UG 浜松 AWS 勉強会
2021#4 2021/04/30 まつひさ(hmatsu47)
自己紹介 松久裕保(@hmatsu47) https://qiita.com/hmatsu47 名古屋で Web インフラのお守り係をしています MySQL 8.0 の薄い本を作って配っていました ◦
Qiita の記事: https://qiita.com/hmatsu47/items/ceb75caf46e3c761095d ◦ GitHub リポジトリの他、印刷版を BOOTH で配布していました ◦ 5 月発行予定の 8.0.24 対応版を最後に更新停止する予定です https://note.com/hmatsu47/n/n3ad586c31dce 2
今日の内容 • パフォーマンスインサイトとは • 管理コンソールで見てみる ◦ Aurora MySQL 5.7 互換版(2.09.2)
▪ mysqlslap & sysbench の結果をグラフ化 • API 経由で使ってみる ▪ Lambda(Python)で S3 へ ▪ S3 → Glue → Athena → QuickSight(グラフを比較) 3
パフォーマンスインサイトとは • RDS / Aurora の負荷とその内訳を示すもの ◦ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_ PerfInsights.Overview.html •
カウンターメトリクス ◦ 性能に関係するカウンター値を個別にグラフ表示 • データベースのロード ◦ 負荷の高さと内訳をグラフ表示 4
カウンターメトリクス ※ここからしばらく過去発表の再利用 5
データベースのロード 6
データベースのロード • 合計:単位時間あたり平均コネクション数 • 内訳:待機イベント毎の所要時間 ◦ 上位 9 個(※)+ CPU
時間(緑)で計 10 個 (※)「上位 9 個」は選択期間内における上位 9 個 ◦ 正規化した SQL(文)上位 10 個の待機イベント内訳も表示可能 ▪ SQL(文)正規化 ≠ DB(テーブル)正規化 ▪ 空白・クォート等を揃え、 パラメータを「?」に置き換え • トークン化 7
待機イベント 8
待機イベント 9 時間が掛かる処理 • ログの書き出し ◦ MySQL の場合バイナリログもある • なんらかのロック・mutex(排他制御の待ち時間)
• データの書き出し • データの読み取り(ストレージから>メモリから) • クライアントの接続
補足:RDBMS で SQL(文)を処理する流れ • パーサ・アナライザが構文解析 • オプティマイザ・プランナが実行計画を決定 ◦ 構文解析結果・実行計画をキャッシュする RDBMS
もある • エグゼキュータが実行 ◦ MySQL ではハンドラを介してデータを読み書き 10 構文解析 パーサ・アナライザ リライタなど 実行計画 オプティマイザ (プランナ) 実行 エグゼキュータ など
補足:RDBMS のデータ更新処理の流れ • トランザクション COMMIT →最初にログを書き出す ◦ WAL・Redo ログなど •
データページの更新箇所はまとめて書き出す ◦ チェックポイント処理 ▪ チェックポイントまでの間はメモリ上に変更点を保持 • Aurora の場合はチェックポイント処理を行わない ◦ ストレージノードがデータページの書き込み処理を行う 11
待機イベント [1] Aurora 独自のもの • MySQL 互換版(代表例) ◦ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide /AuroraMySQL.Reference.html#AuroraMySQL.Reference.Waitevents
• PostgreSQL 互換版(代表例) ◦ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide /AuroraPostgreSQL.Reference.html#AuroraPostgreSQL.Reference.Waite vents 12
待機イベント [2] MySQL • Performance Schema の Wait Event Summary
Tables ◦ 5.7 系(英語マニュアル) ▪ https://dev.mysql.com/doc/refman/5.7/en/wait-summary-tables.html ▪ https://dev.mysql.com/doc/refman/5.7/en/performance-schema-wait-tables.html ◦ 5.6 系(日本語マニュアル) ▪ https://dev.mysql.com/doc/refman/5.6/ja/wait-summary-tables.html ▪ https://dev.mysql.com/doc/refman/5.6/ja/performance-schema-wait-tables.html 13
待機イベント [3] PostgreSQL • pg_stat_activity ビューの wait_event ◦ pg_stat_activity ビュー
▪ https://www.postgresql.jp/document/12/html/monitoring-stats.html#MONITORING-STAT S-VIEWS-TABLE ◦ wait_event_type / wait_event 列 ▪ https://www.postgresql.jp/document/12/html/monitoring-stats.html#WAIT-EVENT-TABLE 14
管理コンソールで見てみる • Aurora MySQL 5.7 互換版 ◦ カウンターメトリクスを変えてみる ◦ データベースのロードのスライスを切り替えてみる
▪ 待機別のスライスから SQL 別のスライスへ ◦ トップ SQL を確認する ▪ 上位の SQL(文)からチューニングしていく • 上位 10 個まで 15
16
17
18
注意点など • 選択期間内の上位 10 個 ≠ 対象時間の上位 10 個の場合 (※)待機イベントの場合は
CPU を含めて 10 個 ◦ 一部の待機イベント・SQL(文)が漏れる ◦ 合計値が本来より低くなる ▪ 一般的なワークロードでは SQL(文)が数十種類以上になるはず • 待機別よりも SQL 別のスライスのほうが実際の合計値から乖離しやすい • 待機イベントを見てもチューニングは難しい ◦ 処理時間が掛かる SQL(文)から順にチューニングするのが王道 19
API 経由で使ってみる • API で値を取得する方法 ◦ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights. API.html • 今回は
Lambda Python で Boto3 低レベルクライアント (PI)を使って S3 に(正規化した)SQL(文)を転送 ◦ https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/pi.html ◦ S3 に転送したデータを Glue 経由で Athena から参照 ▪ さらに QuickSight でグラフ化 20
21 https://github.com/hmatsu47/performance_insights_to_s3 https://qiita.com/hmatsu47/items/b689db489e75836b0d7d
22
23
24
25
26
27
28
まとめ • ある程度直感的に見ることができる • 値の取り扱いには注意が必要 ◦ 待機イベントの個々の意味を知っておく必要がある ◦ 画面に表示されていない待機イベント・SQL(文)がある ▪
画面上の合計値が実際とズレている可能性がある • 特に SQL 別のスライス ◦ 待機イベントを見てもチューニングは難しい ▪ 処理時間が掛かる SQL(文)から順にチューニングするのが王道 • API をうまく活用すると良い 29