RDS_Auroraパフォーマンスインサイトを使ってみる(ちょっとだけAPI編)

6.8K Views

April 16, 22

スライド概要

JAWS-UG 浜松 AWS 勉強会 2021#4 2021/04/30

profile-image

Qiita や Zenn でいろいろ書いてます。 https://qiita.com/hmatsu47 https://zenn.dev/hmatsu47 MySQL 8.0 の薄い本 : https://github.com/hmatsu47/mysql80_no_usui_hon Aurora MySQL v1 → v3 移行計画 : https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

RDS / Aurora パフォーマンスインサイトを 使ってみる(ちょっとだけ API 編) JAWS-UG 浜松 AWS 勉強会 2021#4 2021/04/30 まつひさ(hmatsu47)

2.

自己紹介 松久裕保(@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

3.

今日の内容 ● パフォーマンスインサイトとは ● 管理コンソールで見てみる ○ Aurora MySQL 5.7 互換版(2.09.2) ■ mysqlslap & sysbench の結果をグラフ化 ● API 経由で使ってみる ■ Lambda(Python)で S3 へ ■ S3 → Glue → Athena → QuickSight(グラフを比較) 3

4.

パフォーマンスインサイトとは ● RDS / Aurora の負荷とその内訳を示すもの ○ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_ PerfInsights.Overview.html ● カウンターメトリクス ○ 性能に関係するカウンター値を個別にグラフ表示 ● データベースのロード ○ 負荷の高さと内訳をグラフ表示 4

5.

カウンターメトリクス ※ここからしばらく過去発表の再利用 5

6.

データベースのロード 6

7.

データベースのロード ● 合計:単位時間あたり平均コネクション数 ● 内訳:待機イベント毎の所要時間 ○ 上位 9 個(※)+ CPU 時間(緑)で計 10 個 (※)「上位 9 個」は選択期間内における上位 9 個 ○ 正規化した SQL(文)上位 10 個の待機イベント内訳も表示可能 ■ SQL(文)正規化 ≠ DB(テーブル)正規化 ■ 空白・クォート等を揃え、 パラメータを「?」に置き換え ● トークン化 7

8.

待機イベント 8

9.

待機イベント 時間が掛かる処理 ● ログの書き出し ○ MySQL の場合バイナリログもある ● なんらかのロック・mutex(排他制御の待ち時間) ● データの書き出し ● データの読み取り(ストレージから>メモリから) ● クライアントの接続 9

10.

補足:RDBMS で SQL(文)を処理する流れ ● パーサ・アナライザが構文解析 ● オプティマイザ・プランナが実行計画を決定 ○ 構文解析結果・実行計画をキャッシュする RDBMS もある ● エグゼキュータが実行 ○ MySQL ではハンドラを介してデータを読み書き 構文解析 実行計画 実行 パーサ・アナライザ リライタなど オプティマイザ (プランナ) エグゼキュータ など 10

11.

補足:RDBMS のデータ更新処理の流れ ● トランザクション COMMIT →最初にログを書き出す ○ WAL・Redo ログなど ● データページの更新箇所はまとめて書き出す ○ チェックポイント処理 ■ チェックポイントまでの間はメモリ上に変更点を保持 ● Aurora の場合はチェックポイント処理を行わない ○ ストレージノードがデータページの書き込み処理を行う 11

12.

待機イベント [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

13.

待機イベント [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

14.

待機イベント [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

15.

管理コンソールで見てみる ● Aurora MySQL 5.7 互換版 ○ カウンターメトリクスを変えてみる ○ データベースのロードのスライスを切り替えてみる ■ 待機別のスライスから SQL 別のスライスへ ○ トップ SQL を確認する ■ 上位の SQL(文)からチューニングしていく ● 上位 10 個まで 15

19.

注意点など ● 選択期間内の上位 10 個 ≠ 対象時間の上位 10 個の場合 (※)待機イベントの場合は CPU を含めて 10 個 ○ 一部の待機イベント・SQL(文)が漏れる ○ 合計値が本来より低くなる ■ 一般的なワークロードでは SQL(文)が数十種類以上になるはず ● 待機別よりも SQL 別のスライスのほうが実際の合計値から乖離しやすい ● 待機イベントを見てもチューニングは難しい ○ 処理時間が掛かる SQL(文)から順にチューニングするのが王道 19

20.

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 21

29.

まとめ ● ある程度直感的に見ることができる ● 値の取り扱いには注意が必要 ○ 待機イベントの個々の意味を知っておく必要がある ○ 画面に表示されていない待機イベント・SQL(文)がある ■ 画面上の合計値が実際とズレている可能性がある ● 特に SQL 別のスライス ○ 待機イベントを見てもチューニングは難しい ■ 処理時間が掛かる SQL(文)から順にチューニングするのが王道 ● API をうまく活用すると良い 29