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

自己紹介 ● 髙石 諒 ○ x.com/r_takaishi ○ github.com/takaishi ● ソフトウェア エンジニア / ポッドキャスター ● 現所属は株式会社フライル ○ クラウドインフラ中心にいろいろ ● 副業でスタートアップのクラウドインフラ・基盤整備 ● CloudNative Daysのシステム開発 

No content

No content

こういうの作ってます ● 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のジョブ定義をデプロイするツール 

2024年 

スロークエリ問題 ● RDBのスロークエリはユーザー体験悪化の原因の一つ ○ レスポンスが返ってこない ○ 他テナントで重いクエリが走っていると影響を受ける（ノイジーネイバー） ● 一応スロークエリログは通知していた ● 有効活用できていない ○ 通知数が多く見ることもできない ○ スロークエリがユーザーに対してどのような影響があるのかわからない 

早く気がつく 早く直す 発生を抑える 

打ち手 ● 早く気がつく ○ スロークエリ検知・通知の改善 ● 早く直す ○ データベースモニタリングの強化 ○ 改善時の検証・確認の高速化 ● 発生を抑える ○ Aurora Serverless v2 

早く気がつく：監視・通知の改善 ● それまで：スロークエリログを素朴にSlack通知 ● 閾値の問題でもあるが、通知数が多く対応できない ● どの処理で発生したクエリかわからない ○ ユーザーへの影響がどの程度あるか判断しにくい ○ バッチなどの非同期処理だと影響は小さいかもしれないが、ユーザーからのリクエストのよ うな同期処理だと影響が大きいかもしれない 

早く気がつく：監視・通知の改善 ● 閾値を変更 ● 監視対象をスロークエリからスローリクエストに変更 ○ Datadog APMを利用し、閾値ベースで監視・通知 ○ ユーザーへの影響を判断しやすい ○ APMのトレース情報にテナント情報を付与し、影響範囲がすぐわかるようにする ○ 実はアプリケーション側にも遅い要因があるな、なども気づきやすくなった 

早く直す：データベースモニタリングの強化 ● アプリケーションモニタリングはDatadog APMで実現 ● データベースはAWSのPerformance Insightsでモニタリング ○ Performance Insightsはデータ保存が7日までなら無料なので有効にした方がお得 ○ Waits、SQLなどいくつかの切り口で可視化 ○ メトリクスとあわせて調べられる ● もっとモニタリングしたい ○ スローリクエスト発生時、トレースからクエリの実行計画を透過的に見たい 

Datadog Database Monitoring ● 過去のクエリについて実行計画を確認できる ● クエリ間のブロックなども後から確認できる ● APMと連携してスローリクエストからシームレスにスロークエリを分析可能 ● しかし、導入当初はAPMとうまく連携できなかった ○ Prepared Statementに対応していなかった ○ 少し前に対応し、APMから透過的にスロークエリの実行計画を確認可能になった 

早く直す：スロークエリ改善の検証高速化 ● スロークエリが発生するようなデータを再現するのは大変 ● 本番環境で検証・確認したいが、本番DBをそのまま使うわけにはいかない ○ インデックスを追加するケースなど ● AWS RDSを使っているので、レプリカを作り、それを使えばいい ○ 間違って本番環境で操作してしまうと事故に繋がる ○ 当初は手作業かつダブルチェックしてレプリカを利用していた ● 安全にレプリカを作成・使える仕組みを実装 

発生を抑える：ノイジーネイバー問題 ● 長時間クエリが実行され続けると、他のクエリ実行にも影響がでる ○ PostgreSQLは基本的に1クエリを1プロセスで処理する ○ 他のクエリが実行待ちになり、連鎖的にパフォーマンスが悪化することがある ● 地道にクエリを改善しても、遅いクエリが実行される可能性はゼロではない ● RDSのDBインスタンスクラスを大きくする？ ○ 普段は大きいインスタンスが不要 ○ CPUリソースが足りなくなる度にスケールアップするのは大変 

発生を抑える：Aurora Serverless v2 ● ワークロードに応じて動的に性能を増減できる ○ CPU、メモリ、ストレージなど ● もしスロークエリによって1コアが占有されても他のクエリが実行できるよ うにスケールする ● ただしコストはかかる 

早く気がつく 早く直す 発生を抑える 

まとめ ● 早く気がつく ○ スロークエリ検知・通知の改善 ● 早く直す ○ データベースモニタリングの強化 ○ 改善時の検証・確認の高速化 ● 発生を抑える ○ Aurora Serverless v2 

ここにフライルの紹介スライドをいれる We are hiring!