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

hmatsu47
PRO

April 30, 2021
Tweet

More Decks by hmatsu47

Other Decks in Technology

Transcript

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  6. データベースのロード
    6

    View Slide

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

    View Slide

  8. 待機イベント
    8

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

  16. 16

    View Slide

  17. 17

    View Slide

  18. 18

    View Slide

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

    View Slide

  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

    View Slide

  21. 21
    https://github.com/hmatsu47/performance_insights_to_s3
    https://qiita.com/hmatsu47/items/b689db489e75836b0d7d

    View Slide

  22. 22

    View Slide

  23. 23

    View Slide

  24. 24

    View Slide

  25. 25

    View Slide

  26. 26

    View Slide

  27. 27

    View Slide

  28. 28

    View Slide

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

    View Slide