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

637 Views

April 16, 22

スライド概要

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

profile-image

Qiita や Zenn でいろいろ書いてます。 https://qiita.com/hmatsu47 https://zenn.dev/hmatsu47 MySQL 8.0 の薄い本 : https://github.com/hmatsu47/mysql80_no_usui_hon Aurora MySQL v1 → v3 移行計画 : https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book

シェア

埋め込む »CMSなどでJSが使えない場合

各ページのテキスト
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.

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

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.

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

12.

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

13.

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

14.

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

15.

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

16.

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

17.

⑤ Athena でクエリを実行 17

18.

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

19.

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

20.

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

21.

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

22.

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

23.

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

24.

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

25.

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