Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

B1dca90d4b3ffd2ccd918774e1ba170d?s=128

hmatsu47
PRO

April 30, 2021
Tweet

Transcript

  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. 待機イベント 9 時間が掛かる処理 • ログの書き出し ◦ MySQL の場合バイナリログもある • なんらかのロック・mutex(排他制御の待ち時間)

    • データの書き出し • データの読み取り(ストレージから>メモリから) • クライアントの接続
  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
  16. 16

  17. 17

  18. 18

  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. 21 https://github.com/hmatsu47/performance_insights_to_s3 https://qiita.com/hmatsu47/items/b689db489e75836b0d7d

  22. 22

  23. 23

  24. 24

  25. 25

  26. 26

  27. 27

  28. 28

  29. まとめ • ある程度直感的に見ることができる • 値の取り扱いには注意が必要 ◦ 待機イベントの個々の意味を知っておく必要がある ◦ 画面に表示されていない待機イベント・SQL(文)がある ▪

    画面上の合計値が実際とズレている可能性がある • 特に SQL 別のスライス ◦ 待機イベントを見てもチューニングは難しい ▪ 処理時間が掛かる SQL(文)から順にチューニングするのが王道 • API をうまく活用すると良い 29