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

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

Transcript

1. RDS / Aurora パフォーマンスインサイトの
   データを Athena と QuickSight で見る
   JAWS-UG 名古屋 データ分析を学ぶ　2021/05/31
   まつひさ（hmatsu47）
   

   View Slide

2. 自己紹介
   松久裕保（@hmatsu47）
   https://qiita.com/hmatsu47
   名古屋で Web インフラのお守り係をしています
   （ほかに書くことがなくなったので省略）
   2
   

   View Slide

3. 今日の内容
   ● パフォーマンスインサイトとその問題点のおさらい
   ● API 経由で S3 にデータを書き出してみる
   ○ Lambda（Python）で S3 へ
   ● Glue クローラを使って Athena へ
   ○ Athena でクエリを実行してみる
   ● Athena から QuickSight へ
   ○ 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. パフォーマンスインサイトとは
   ● RDS / Aurora の負荷とその内訳を示すもの
   ○ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_
   PerfInsights.Overview.html
   ● カウンターメトリクス
   ○ 性能に関係するカウンター値を個別にグラフ表示
   ● データベースのロード
   ○ 負荷の高さと内訳をグラフ表示
   5
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

9. 問題点
   ● 選択期間内の上位 10 個 ≠ 対象時間の上位 10 個の場合
   （※）待機イベントの場合は CPU を含めて 10 個
   ○ 一部の待機イベント・SQL（文）が漏れる
   ○ 合計値が本来より低くなる
   ■ 一般的なワークロードでは SQL（文）が数十種類以上になるはず
   ● 待機別よりも SQL 別のスライスのほうが実際の合計値から乖離しやすい
   9
   

   View Slide

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
    

    View Slide

11. 11
    ① S3 転記用の Lambda 関数を作成・実行
    

    View Slide

12. 12
    https://github.com/hmatsu47/performance_insights_to_s3
    （今回は lambda_function_events.py のコードを使用）
    https://qiita.com/hmatsu47/items/9814d5c69c136c185c41
    ① S3 転記用の Lambda 関数を作成・実行
    

    View Slide

13. 13
    ② S3 に転記されたデータを確認
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

25. まとめ
    ● API で書き出したデータを使うと細部を可視化可能
    ○ RDS のマネジメントコンソールでは表示できない部分も
    ● ただし限界はある
    ○ 負荷が高い SQL（文）の抽出とチューニングにはある程度使える
    ○ 遅い原因が不明な SQL（文）では待機イベントの抽出が必要だ
    が、SQL（文）を特定してその待機イベントを調査…のような使
    い方がしづらい
    ■ 多くのケースで秒単位のデータが必要だが、書き出しの負担が大きい
    ○ API にはレートリミットがある
    25
    

    View Slide