JAWS-UG 浜松 AWS 勉強会 2021#4 2021/04/30
RDS / Aurora パフォーマンスインサイトを使ってみる（ちょっとだけ API 編）JAWS-UG 浜松 AWS 勉強会 2021#4 2021/04/30まつひさ（hmatsu47）
View Slide
自己紹介松久裕保（@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/n3ad586c31dce2
今日の内容● パフォーマンスインサイトとは● 管理コンソールで見てみる○ 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.Waitevents12
待機イベント [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.html13
待機イベント [3] PostgreSQL● pg_stat_activity ビューの wait_event○ pg_stat_activity ビュー■ https://www.postgresql.jp/document/12/html/monitoring-stats.html#MONITORING-STATS-VIEWS-TABLE○ wait_event_type / wait_event 列■ https://www.postgresql.jp/document/12/html/monitoring-stats.html#WAIT-EVENT-TABLE14
管理コンソールで見てみる● 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
21https://github.com/hmatsu47/performance_insights_to_s3https://qiita.com/hmatsu47/items/b689db489e75836b0d7d
22
23
24
25
26
27
28
まとめ● ある程度直感的に見ることができる● 値の取り扱いには注意が必要○ 待機イベントの個々の意味を知っておく必要がある○ 画面に表示されていない待機イベント・SQL（文）がある■ 画面上の合計値が実際とズレている可能性がある● 特に SQL 別のスライス○ 待機イベントを見てもチューニングは難しい■ 処理時間が掛かる SQL（文）から順にチューニングするのが王道● API をうまく活用すると良い29
hmatsu47
dskst
iwashi86
uzulla
nozomiito
ad5jp
sbtechnight
kentosuzuki
aiji42
asazutaiga
carta_engineering
oracle4engineer
afnizarnur
skipperchong
caitiem20
frogandcode
eileencodes
hatefulcrawdad
holman
vanstee
paulrobertlloyd
jcasabona
pedronauck
aarron