RDS Performance Insights を使って DB の負荷を監視する

こんにちは、スタメンでバックエンドのエンジニアをしている河井です。
私の所属するバックエンドチームでは、普段からサービスのパフォーマンス監視とチューニングを継続的に行っています。
今回は、データベース負荷のモニタリングに使っている Performance Insights というツールの活用方法をまとめてみます。

Peformance Insights について

Performance Insights(パフォーマンスインサイト)とは、Amazon RDS で提供されている機能で、DB の負荷のモニタリングが簡単にできます。

ざっくりとまとめると、

  • 指標がシンプルなので DB の負荷状況を直感的に把握できる
  • SQL クエリが表示されるため問題箇所の特定がしやすい
  • リアルタイム更新なので即座に負荷内容を分析できる

といったメリットがあります。

有効化についてはこちらを参照ください。

ダッシュボードの見方

ダッシュボードが見やすくて便利なので、基本的にこちらを使います。
RDS コンソールのサイドバーにある「パフォーマンスインサイト」からアクセスできます。


パフォーマンスインサイトへのリンク


画面は3つのパートに別れていて、上から、カウンターメトリクス、データベースのロード、SQL ステートメントダイジェストとなっています。
基本的にはデータベースのロードとSQLステートメントダイジェストを使うので、この2つについて解説します。

データベースのロード

データベースの負荷を時系列で表示しています。負荷は平均アクティブセッション(Average Active Session、AAS)という指標で表現されています。
平均アクティブセッションとは、一定時間内に処理中または処理開始を待ちのセッションの数で、この数が多いほど DB に負荷がかかっているといえます。

データベースのロード


上記画像では、スライス基準という項目が、「待機」 になっています。
スライス基準とは AAS の内訳を何基準で表示するかという設定項目です。
待機基準では、データベースの一連の処理のうちどのイベントでどのイベントでの待機時間が長くなっているかを知ることができます。
各種イベントの詳細についてはこちらを参照ください。

グラフの上部にある破線は今見ている RDS インスタンスの仮想 CPU 数を表しています。
CPU での待機数だけでこのラインを超えると、CPU 数が不足しているといえます。
上の画像では一箇所そのラインに到達していますが、待機の内訳を見ると CPU の割合は低いです。
そのため、CPU が原因となって負荷が高まっているわけではないと判断できます。

次に、スライス基準を SQL に変えてみます。

スライス基準SQL


SQL 基準を選択することで、各クエリごとにどれだけ待機しているかを知ることができます。
ぼかしを入れてあるところには SQL クエリが表示されており、どのクエリによって負荷が発生しているのか?を判定できます。

SQL ステートメントダイジェスト

SQL ステートメントダイジェストでは、 簡略化された SQL クエリが負荷の高いものから順に表示されています。
ダイジェストではパラメータが name = ? のように置き換えられており、同じクエリの影響をまとめた値になっています。

SQLステートメントダイジェスト


さらに詳細を見たいときは▷をクリックし、実際のパラメータが入った個々のクエリを見ることができます。
TUNAG では企業ごとに柔軟な設定が可能なため、予期せぬ設定で負荷が高まることがあります。
パラメータありの状態でクエリを見て企業を特定し、原因究明までスピーディに行えるようになりました。

監視の設定

上記は負荷がかかっているタイミングが特定できている前提で話をしていました。
負荷が高まっていること自体に気づくために、データベースのロードが一定数を超えたら通知されるようにしてみます。

設定可能な項目

CloudWatch Alarm でデータベースのロードを監視することができるので、設定手順を説明します。
データベースのロードに関するメトリクスは3種類あります。

  • DBLoad
  • DBloadCPU
  • DBLoadNonCPU

DBLoadCPU は待機要因を CPU のみに限定したもの、DBLoadNonCPU は CPU 以外の要因で待ちが発生しているもの、DBLoad はその合計値となっています。
バックエンドチームでは次のような使い分けをしています。

  • DBLoadCPU: CPU 数不足の検知
  • DBLoadNonCPU: 非効率なクエリ発行の検知(インデックスが効いていない、DB への同時アクセス数が多すぎるなど)

設定手順

どの指標を使うにしても設定は同じなので、DBLoad のアラームを設定してみます。
まずは CloudWatch コンソールにアクセスし、サイドメニューの「アラーム」を選択、「アラームの作成」と進みます。

CloudWatch Alarm の設定


進んだ先の画面で、"DBLoad" で検索→「RDS > データベースメトリクス」を選択→監視したい DB インスタンスにチェック→メトリクスを選択と進みます。

メトリクスと条件の設定


メトリクスを取得する間隔や閾値は、普段負荷が高まるときの AAS を参考に決めましょう。
最後に、通知先を設定して終了です。

まとめ

Performance Insights のダッシュボードの見方からアラートの設定方法までざっくりとまとめてみました。
これを使い始めてから劇的にクエリの改善が進んだので、まだ使っていないという方はぜひ触ってみてください。

最後に、株式会社スタメンでは一緒に働く仲間を募集しています。
ご興味のある方はぜひ下記のページをご覧ください!

エンジニア採用サイト
エンジニア募集ページ(Wantedly)

参考資料

パフォーマンスインサイトを使用する
Performance Insights で Amazon RDS for MySQL をチューニングする

アイキャッチ Photo by Chris Liverani on Unsplash