先月に引き続き登壇参加です。
今回は、参加者募集が始まっているのに気付かずにいたところ、JAWS-UG 名古屋の杉本さんにお声掛けいただきました。
話したネタはこれ↓です。今回は画面操作の時間があったので、スライドだけを見ても話のつながりが分かりづらいのですが。
（一応、動画のアーカイブはあるらしいです。）
例によって（？）普段どおりの RDS / Aurora ネタですが、直感的に分かりそうで、実は細かいところが分かりづらいパフォーマンスインサイトの話でした。
分かりづらい点としては、以下のようなものがあります。
- 「待機イベント」の概念
- 対象とする RDBMS によって「イベントをどう区分するか」が違う
- すべての待機イベントを集計しているわけではない
- 対象時間（1 秒・1 分など）における上位 9 件までを集計している模様（それ以下は省略？）
- RDBMS の待機イベントとしては存在しない「CPU」という区分とその意味
- マニュアルでは明確な説明はないが、おそらく「全体の処理時間 - 個々の待機イベント時間 = CPU で計算している時間」と捉えたものだと思う
- 表示期間（Start to End）における上位 9 件と対象時間（グラフ 1 本分＝ 1 秒・1 分など）における上位 9 件が違う場合の表現
- 個々の時間の待機イベントが一部表示されないので、合計値がずれる
- これのせいで、上に書いた「全体の処理時間 - 個々の待機イベント時間 = CPU で計算している時間」という関係性も、グラフ上は正確に表現されなくなる
こうして箇条書きにしたものを読んでも意味が分かりづらいと思いますので、是非、API（CLI v1）を使って、
- 60 秒間のデータを、粒度 60 秒で取得（1 組分のデータ）
- 60 秒間のデータを、粒度 1 秒で取得（60 組分のデータ）
や、
- 60 分間のデータを、粒度 60 分で取得（1 組分のデータ）
- 60 分間のデータを、粒度 1 分で取得（60 組分のデータ）
などを見比べて、集計値にどのような違いが出るかを比較してみてください。イメージが湧くと思います。
ちなみに時間は 5 分オーバーしましたが、事前に「今回は予定セッションが少ないので時間は超過しても良いです」という話を伺っていたので、無暗に話を省略することは避けました。
このあたりの説明に終始してしまったため、肝心の
- パフォーマンスインサイトを使って何を読み取りどう性能改善していくか？
というポイントが説明できなかったことが悔やまれます。
※基本的には SQL（文）の上位にランクインしたものからチューニングしていくのが良いのですが（SQL（文）の書き替えによりアクセスパスを見直して平均アクセス行数を減らす、無駄に多く実行されている SQL（文）の実行頻度を減らすようアプリケーションを改修する、など）、特に更新系の SQL（文）については見方が難しいところがあるので注意が必要です（トランザクションを使っている場合は更新処理そのものの負荷が COMMIT （または END ）文に集中するので INSERT ・ UPDATE ・ DELETE 文がランク上位に入りづらい＝可視化されにくい、など）。
その他のセッションでは、エイチームさん（の一部？）の ECS 環境の構築ポリシーや、AWS からテンプレート提供されている分散負荷テストツールの実行イメージ、機械学習をスポットインスタンスで実行するときのお勧めインスタンスが分かったり…という感じで地味に収穫がありました。
実参加者が少なかったのがちょっと残念でしたが。
