これは ZOZO Advent Calendar 2024 カレンダー Vol.10 の 7日目の記事です
現在、自分が所属しているチームでは、Aurora MySQLを使ったマイクロサービスの運用を行っています。マイクロサービスの性能を維持・向上するためには、データベースのクエリチューニングが欠かせません。
今回は、普段自チームで実践しているクエリチューニングの改善ステップをご紹介します。
- 対象SQLの特定
- 実行計画の確認・問題点の把握
- 改修案の検討・検証
- 本番リリース・経過観察
1. 対象SQLの特定
パフォーマンスの悪いクエリを特定するために、以下のツールを活用します。
Slow Query Log
- ログを出力することで、特定の時間帯に発生するパフォーマンス問題も把握しやすくなります。
SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 1; -- 1秒以上のクエリを記録
Datadog APM / Database Monitoring（DBM）
- Datadogを使用して、API単位やクエリ単位で遅いクエリを特定します。
- APIベース（Datadog APM）：遅いAPIエンドポイントから問題のクエリを絞り込みます。
- クエリベース（Database Monitoring（DBM）：データベース全体で遅いクエリを監視します。
- 以下の記事でのように、私のチームも以下ブログで紹介しているような形でDBおよびクエリの状況をDBMで見れるようにしています。
参考：Splunkと Datadog Database Monitoringを用いたDBパフォーマンスの可視化
Performance Insights
- AWSのGUIを確認して、アクティブセッション上位のSQLは常に確認するようにしています。
- インスタンスサイズによってはPerformance Insightsが使えないこともありますが、可能な限り活用するようにしています。
サービス要件に満たしていないクエリがないか、日々確認・スロークエリを発見したらすぐにチューニングの検討を始めます。
2. 実行計画の確認・問題点の把握
- 対象SQLが見つかったら、実行計画を確認し、問題点を洗い出します。
-
EXPLAINステートメントでアクセスパターンやインデックスの利用状況を確認します。 - 実行計画の見方や分析方法についてはここでは割愛しますが、詳細な分析を行い、クエリのボトルネックを特定します。
３. 改修案の検討・検証
- 実行計画から得た情報をもとに、以下のアプローチでクエリを改善します。
- インデックス最適化
- 結合の最適化：駆動表の選択や不要な結合の見直し
- リードモデル（参照系の場合は、そのクエリの参照に特化したテーブルを作成するなどの対応をする）
4.本番リリース・経過観察
- 改善したクエリを本番にリリースし、以下のツールで経過観察を行います。
Datadog APM / Database Monitoring（DBM）
- Datadog APM：遅いAPIエンドポイントのレスポンス改善を確認します。
- Database Monitoring（DBM）：クエリの実行時間やデータベース負荷を監視し、改善効果を検証します。
確認ポイント
- 1〜2週間の間、対応前後のパフォーマンスを比較
- 効果が見られれば対応終了。改善が不十分なら、再度1.対象SQLの特定から改善サイクルを回します。
最後に
- ZOZOTOWNを支える重要なサービスを運用する中で、データベースのパフォーマンスは常に意識しています。
- 日々の地道な監視と改善のサイクルを回し続けることで、安定したサービス提供を実現しています。