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

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

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