データベースパフォーマンスの監視と最適化：実践ガイド

アプリケーションアーキテクチャを全体として捉え、各部分がどのように連携しているかを理解することは非常に重要です。特定の側面だけを見るのではなく、まず「オブザーバビリティ(可観測性)」を整え、その上で「監視(モニタリング)」を行うのが基本の流れです。

この記事では、アーキテクチャの中でも特に重要なデータベースに焦点を当て、パフォーマンスの監視と最適化の方法を解説します。ここで紹介する原則の多くは、スタックやデータベースの種類(PostgreSQL、MongoDBなど)に関わらず応用できます。

なぜデータベースのパフォーマンス監視が必要なのか？

あるクエリが極端に遅く、アプリケーションがその結果を待つために動きが止まってしまう——エンドユーザーやアプリの一部にとって深刻な事態です。

交通渋滞と同じように、ある場所で起きた問題が別の場所を停滞させることがあります。多数のクエリの処理が遅延している場合、原因は他のクエリが妨げになっていることにあるかもしれません。

目標は、問題がアプリケーションの他の部分に波及する前に、その発生源を特定することです。その次のステップとして、監視を活用してアーキテクチャを積極的に最適化し、高速化の余地を探ります。まずは最初のステップから始めましょう。

ステップ1：計測（インストゥルメンテーション）から始める

データベース監視の第一歩は、「何を計測すべきか」を正しく定めることです。基本となるのは次の2点です。

• エラー

• パフォーマンス

パフォーマンスについては、以下の指標が特に有用です。

• クエリ所要時間の平均値と90パーセンタイル値

• 総スループット——スループットが問題になった際にトリガーやフラグを設定できる

幸い、このデータ収集はAPMソフトウェアが担ってくれます。多くのAPMでは、計測したい項目を設定するだけで済みます。たとえばAppSignalを使えば、ほとんどセットアップなしにデータの収集・集計が自動的に行われます。面倒な重労働はツールが引き受けてくれるのです。

ステップ2：出発点として影響の大きいクエリを見つける

アプリケーションへの計測の組み込みが完了し、実際のデータが流れ始めると、パターンが見えてきます。AppSignalでは、ナビゲーションの「Improve」セクションに、最も遅いAPIリクエストと最も遅いクエリを表示する画面を用意しています。

この画面は、最適化作業の絶好の出発点になります。デフォルトでは、スロークエリは「影響度」順にソートされます。影響度は「スループット × 平均クエリ時間」で計算され、頻繁に実行されるクエリほど上位に現れます。

ソート条件を切り替えることで、実行回数の多いクエリ、最も遅いクエリ(ただし夜間に一度だけ走るバックグラウンドジョブなら無視できるかもしれません)、そして影響度の最も大きいクエリをそれぞれ把握できます。

寄り道：個別のクエリを修正する

ここまで来れば、修正に取りかかるべきクエリが見つかるはずです。

スロークエリをクリックすると、右側に詳細情報が表示されます。スループットやレスポンスタイムから、クエリ名そのものまで確認できます。

ピーク時のレスポンスタイムにカーソルを合わせ、「何が起きたのか」オプションをクリックしてズームインすると、その時点・そのサンプルで発生したエラーや、ホスト上で何が起こっていたかがわかります。

特に代表的なアンチパターンである「N+1問題」は一目でわかるように表示されます。N+1問題とは、前のクエリの結果1件ごとに新たなクエリが実行されてしまう状態です。

クエリ数はN+1となり、Nは最初のクエリ結果の件数です。初期クエリの結果が1件ならN+1=2、1,000件ならなんと1,001回のクエリが発行されることになります。これは深刻です。

もしクエリがN+1アンチパターンに該当していれば、ラベルが付いているのですぐに見つけられます。

解決方法についてはここでは触れません。N+1クエリについては別記事で詳しく解説しています。

さて、いくつかの重大な問題を修正し、それらがいつ発生したのか、最悪のレスポンスタイムがいつだったのかも把握できたとしましょう。

ステップ3：パターンを見極める——何が問題なのか？

監視というのは、しばしば「問題が起きたとき」に注目します。しかし監視の難しさの一つは、自分の環境にとって何が「問題」なのかを定義することにあります。また、自然に解消する問題で警告を受けるのと、解消しない問題を見逃すのと、どちらがマシでしょうか？

まず、クエリのスループットと所要時間の平均を見てみましょう。これはAPMソフトウェアで設定できます。AppSignalでNode.jsを監視し、PostgreSQLをデータベースとして使っている場合、重要なメトリクスをまとめたダッシュボードが自動的に作成されます。

node-postgresダッシュボードには、次のようなデータが表示されます。

自分のアプリでこれを設定したい方は、参考資料をご覧ください。

時間範囲を切り替えると、1時間の平均では埋もれてしまう短いピークと、時間範囲を広げても高止まりし続けるピークの両方が見えてきます。

スロークエリ画面での経験から、主な犯人とそのピークのタイミングについて、すでに心当たりがあるはずです。

スループットの短いピークの中には、問題ないものもあります。たとえばホストが他のプロセスを実行していて、一時的にクエリが遅くなっているだけかもしれません。

注目すべきは、長引くクエリ時間の増加や持続的なスループットの急上昇です。95パーセンタイルと平均を比較することで、遅いクエリが全員に影響しているのか、一部のユーザーだけなのかが判断でき、修正すべき箇所を絞り込むヒントになります。

ステップ4：どんなアラートなら夜中に起こされてもいいか？

私たちが通常おすすめするのは、「うるさい」側から始めることです。まずはメールやSlackなど、眠りを妨げないチャネルでアラートを受け取るトリガーを設定し、PagerDutyのような緊急性の高いチャネルは後回しにします。

「event_duration」メトリクスにカスタムメトリクストリガーを作成し、meanフィールドを選択すれば、アプリの平均クエリ時間に関するアラートを受け取れます。90または95パーセンタイルを選択すれば、アプリが遭遇する最も遅いクエリについてのアラートになります。

次に、通知したいイベントの種類と名前空間に合わせて「group」と「namespace」タグを設定します。たとえばgroupには「active_record」(Rails)、「postgres」(Node.js)、「ecto」(Elixir)、namespaceには「web」や「background」を指定します。

1週間ほど運用すると、パターンが見え始め、どのケースに注意が必要で、どのケースは自然に解決するのかがわかってきます。

そうしたら、トリガーを調整してノイズを減らし、特定のアラートで起こしてほしい場合のためのチャネルを追加しましょう。

ステップ5：データベース監視のセットアップ完了

理論上は、これで立派な監視体制が整ったことになります。必要なデータは流入し、問題が表面化する前に警告するトリガーも設定し、大きな犯人も特定しました。これで完成……のはずですが？

現実には、アプリの利用が拡大して新しいボトルネックが生まれたり、コード変更がデータベースに影響してクエリ時間が伸びたり、巨大なペイロードを持つ特定のフィールドが問題を引き起こしたりします。どれほど経験を積んでも、新しい問題やボトルネックは必ず発生します。

しかし、適切なセットアップがあれば、警告を受け取り、アーキテクチャの深部まで掘り下げて問題を解決する方法を知っている——その安心感があります。

さらに、他のネジが緩む前に、影響の大きいクエリを改善する喜びを味わえるかもしれません。それこそが私たちの一番好きなことです。そう、シロップワッフルと並んで。

AppSignalを試して、シロップワッフルをもらおう 🍪

シロップワッフルの話が出たので——私たちは世界中にシロップワッフルを送っています。Ruby、Elixir、Node.js向けのAppSignal APMをぜひ試してみてください。無料トライアルを開始してご連絡いただければ、サービスとしてシロップワッフルの箱をお送りします。