スロークエリとの戦いの軌跡2024 / ゆるSRE勉強会 #10

https://yuru-sre.connpass.com/event/348136/

Transcript

1. スロークエリとの戦いの軌跡2024 髙石 諒 / @r_takaishi ゆるSRE勉強会 #10
2. 自己紹介 • 髙石 諒 ◦ x.com/r_takaishi ◦ github.com/takaishi • ソフトウェア エンジニア / ポッドキャスター • 現所属は株式会社フライル ◦ クラウドインフラ中心にいろいろ • 副業でスタートアップのクラウドインフラ・基盤整備 • CloudNative Daysのシステム開発
5. こういうの作ってます • tfclean (https://github.com/takaishi/tfclean) ◦ terraformの import/moved/removed ブロックを削除するツール • terraform-j2md (https://github.com/reproio/terraform-j2md) ◦ terraform planの結果をMarkdownとして整形するツール • batron (https://github.com/takaishi/batron) ◦ AWS Batchのジョブ定義をデプロイするツール
6. 2024年
7. スロークエリ問題 • RDBのスロークエリはユーザー体験悪化の原因の一つ ◦ レスポンスが返ってこない ◦ 他テナントで重いクエリが走っていると影響を受ける（ノイジーネイバー） • 一応スロークエリログは通知していた • 有効活用できていない ◦ 通知数が多く見ることもできない ◦ スロークエリがユーザーに対してどのような影響があるのかわからない
8. 早く気がつく 早く直す 発生を抑える
9. 打ち手 • 早く気がつく ◦ スロークエリ検知・通知の改善 • 早く直す ◦ データベースモニタリングの強化 ◦ 改善時の検証・確認の高速化 • 発生を抑える ◦ Aurora Serverless v2
10. 早く気がつく：監視・通知の改善 • それまで：スロークエリログを素朴にSlack通知 • 閾値の問題でもあるが、通知数が多く対応できない • どの処理で発生したクエリかわからない ◦ ユーザーへの影響がどの程度あるか判断しにくい ◦ バッチなどの非同期処理だと影響は小さいかもしれないが、ユーザーからのリクエストのよ うな同期処理だと影響が大きいかもしれない
11. 早く気がつく：監視・通知の改善 • 閾値を変更 • 監視対象をスロークエリからスローリクエストに変更 ◦ Datadog APMを利用し、閾値ベースで監視・通知 ◦ ユーザーへの影響を判断しやすい ◦ APMのトレース情報にテナント情報を付与し、影響範囲がすぐわかるようにする ◦ 実はアプリケーション側にも遅い要因があるな、なども気づきやすくなった
12. 早く直す：データベースモニタリングの強化 • アプリケーションモニタリングはDatadog APMで実現 • データベースはAWSのPerformance Insightsでモニタリング ◦ Performance Insightsはデータ保存が7日までなら無料なので有効にした方がお得 ◦ Waits、SQLなどいくつかの切り口で可視化 ◦ メトリクスとあわせて調べられる • もっとモニタリングしたい ◦ スローリクエスト発生時、トレースからクエリの実行計画を透過的に見たい
13. Datadog Database Monitoring • 過去のクエリについて実行計画を確認できる • クエリ間のブロックなども後から確認できる • APMと連携してスローリクエストからシームレスにスロークエリを分析可能 • しかし、導入当初はAPMとうまく連携できなかった ◦ Prepared Statementに対応していなかった ◦ 少し前に対応し、APMから透過的にスロークエリの実行計画を確認可能になった
14. 早く直す：スロークエリ改善の検証高速化 • スロークエリが発生するようなデータを再現するのは大変 • 本番環境で検証・確認したいが、本番DBをそのまま使うわけにはいかない ◦ インデックスを追加するケースなど • AWS RDSを使っているので、レプリカを作り、それを使えばいい ◦ 間違って本番環境で操作してしまうと事故に繋がる ◦ 当初は手作業かつダブルチェックしてレプリカを利用していた • 安全にレプリカを作成・使える仕組みを実装
15. 発生を抑える：ノイジーネイバー問題 • 長時間クエリが実行され続けると、他のクエリ実行にも影響がでる ◦ PostgreSQLは基本的に1クエリを1プロセスで処理する ◦ 他のクエリが実行待ちになり、連鎖的にパフォーマンスが悪化することがある • 地道にクエリを改善しても、遅いクエリが実行される可能性はゼロではない • RDSのDBインスタンスクラスを大きくする？ ◦ 普段は大きいインスタンスが不要 ◦ CPUリソースが足りなくなる度にスケールアップするのは大変
16. 発生を抑える：Aurora Serverless v2 • ワークロードに応じて動的に性能を増減できる ◦ CPU、メモリ、ストレージなど • もしスロークエリによって1コアが占有されても他のクエリが実行できるよ うにスケールする • ただしコストはかかる
17. 早く気がつく 早く直す 発生を抑える
18. まとめ • 早く気がつく ◦ スロークエリ検知・通知の改善 • 早く直す ◦ データベースモニタリングの強化 ◦ 改善時の検証・確認の高速化 • 発生を抑える ◦ Aurora Serverless v2
19. ここにフライルの紹介スライドをいれる We are hiring!