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

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

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

• https://qiita.com/hmatsu47

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

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

• https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.html

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

• https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.html

データベースのロード 6

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

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

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

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

• https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.API.html
• https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/pi.html

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

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

• https://github.com/hmatsu47/performance_insights_to_s3
• https://qiita.com/hmatsu47/items/9814d5c69c136c185c41

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

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

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

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

⑤ Athena でクエリを実行 17

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

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

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

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

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

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

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

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