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

RDS_AuroraパフォーマンスインサイトのデータをAthenaとQuickSightで見る

 RDS_AuroraパフォーマンスインサイトのデータをAthenaとQuickSightで見る

JAWS-UG 名古屋 データ分析を学ぶ 2021/05/31

B1dca90d4b3ffd2ccd918774e1ba170d?s=128

hmatsu47
PRO

May 31, 2021
Tweet

Transcript

  1. RDS / Aurora パフォーマンスインサイトの データを Athena と QuickSight で見る JAWS-UG

    名古屋 データ分析を学ぶ 2021/05/31 まつひさ(hmatsu47)
  2. 自己紹介 松久裕保(@hmatsu47) https://qiita.com/hmatsu47 名古屋で Web インフラのお守り係をしています (ほかに書くことがなくなったので省略) 2

  3. 今日の内容 • パフォーマンスインサイトとその問題点のおさらい • API 経由で S3 にデータを書き出してみる ◦ Lambda(Python)で

    S3 へ • Glue クローラを使って Athena へ ◦ Athena でクエリを実行してみる • Athena から QuickSight へ ◦ QuickSight でグラフ化してみる 3
  4. パフォーマンスインサイトとは • RDS / Aurora の負荷とその内訳を示すもの ◦ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_ PerfInsights.Overview.html •

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

    カウンターメトリクス ◦ 性能に関係するカウンター値を個別にグラフ表示 • データベースのロード ◦ 負荷の高さと内訳をグラフ表示 5
  6. データベースのロード 6

  7. データベースのロード • 合計:単位時間あたり平均コネクション数 • 内訳:待機イベント毎の所要時間 ◦ 上位 9 個(※)+ CPU

    時間(緑)で計 10 個 (※)「上位 9 個」は選択期間内における上位 9 個 ◦ 正規化した SQL(文)上位 10 個の待機イベント内訳も表示可能 ▪ SQL(文)正規化 ≠ DB(テーブル)正規化 ▪ 空白・クォート等を揃え、 パラメータを「?」に置き換え • トークン化 7
  8. 待機イベント 8 時間が掛かる処理 • ログの書き出し ◦ MySQL の場合バイナリログもある • なんらかのロック・mutex(排他制御の待ち時間)

    • データの書き出し • データの読み取り(ストレージから>メモリから) • クライアントの接続
  9. 問題点 • 選択期間内の上位 10 個 ≠ 対象時間の上位 10 個の場合 (※)待機イベントの場合は

    CPU を含めて 10 個 ◦ 一部の待機イベント・SQL(文)が漏れる ◦ 合計値が本来より低くなる ▪ 一般的なワークロードでは SQL(文)が数十種類以上になるはず • 待機別よりも SQL 別のスライスのほうが実際の合計値から乖離しやすい 9
  10. 対策 : 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 でグラフ化 10
  11. 11 ① S3 転記用の Lambda 関数を作成・実行

  12. 12 https://github.com/hmatsu47/performance_insights_to_s3 (今回は lambda_function_events.py のコードを使用) https://qiita.com/hmatsu47/items/9814d5c69c136c185c41 ① S3 転記用の Lambda

    関数を作成・実行
  13. 13 ② S3 に転記されたデータを確認

  14. 14 ③ Athena でワークグループを作成し、データソースを接続

  15. 15 ④ Glue クローラを追加・実行

  16. 16 ④ Glue クローラを追加・実行

  17. 17 ⑤ Athena でクエリを実行

  18. 18 ⑥ QuickSight で Athena をソースとするデータセットを作成

  19. 19 ⑦ QuickSight でデータセットを編集

  20. 20 ⑦ QuickSight でデータセットを編集(日付フィールドが文字列のままだと都合が悪いので編集して日付形式へ)

  21. 21 ⑦ QuickSight でデータセットを編集(必要な計算フィールドを追加)

  22. 22 ⑧ QuickSight でデータセットをグラフ化(ビジュアルタイプを選びフィールドを割り当て表示形式を調整)

  23. 23 ⑧ QuickSight でデータセットをグラフ化(グループ化フィールド変更)

  24. 24 ⑧ QuickSight でデータセットをグラフ化(別グラフ追加)

  25. まとめ • API で書き出したデータを使うと細部を可視化可能 ◦ RDS のマネジメントコンソールでは表示できない部分も • ただし限界はある ◦

    負荷が高い SQL(文)の抽出とチューニングにはある程度使える ◦ 遅い原因が不明な SQL(文)では待機イベントの抽出が必要だ が、SQL(文)を特定してその待機イベントを調査…のような使 い方がしづらい ▪ 多くのケースで秒単位のデータが必要だが、書き出しの負担が大きい ◦ API にはレートリミットがある 25