Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

今日の内容 ● パフォーマンスインサイトとその問題点のおさらい ● API 経由で S3 にデータを書き出してみる ○ Lambda(Python)で S3 へ ● Glue クローラを使って Athena へ ○ Athena でクエリを実行してみる ● Athena から QuickSight へ ○ QuickSight でグラフ化してみる 3

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

データベースのロード 6

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

対策 : 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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

17 ⑤ Athena でクエリを実行

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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