sql_exporter と Prometheus を活用した Solid Queue の滞留監視と可視化 [DeNA インフラ SRE]

はじめに

IT 基盤部第二グループの無津呂です。

現在、私たちが運用を担当するプロダクトにおいて、ジョブキューシステムを Solid Queue への移行を進めています。

キューを安定して運用するためには、スループットの可視化と滞留監視が不可欠です。

本記事では、sql_exporter と Prometheus / Grafana を活用した、キューのスループット可視化および滞留監視の仕組みについて解説します。

Solid Queue の構成と監視の目的

本題に入る前に、Solid Queue の構成と監視の目的を整理しておきましょう。

私たちの環境では、アプリケーションサーバ (app) やバッチ処理 (batch) からキューにジョブを投入し、常駐プロセスである worker がキューからジョブを取り出して処理を行っています。

Solid Queue のバックエンドには MySQL を採用しており、ジョブの実体はデータベース上のレコードとして管理されています。

ジョブには「実行待ち (ready)」や「実行中 (claimed)」、「失敗 (failed)」といったステータスがあり、状況に応じて対応するテーブル間で遷移します。

（その他にも、指定時刻まで待機する scheduled、同時実行数の制限によりブロックされる blocked、定期実行用の recurring などのステータスが用意されています）

この仕組みにおける「キューの滞留」とは、何らかの原因で worker に消費されず、ステータスが変わったままテーブル上に残存し続ける異常な状態を指します。

ジョブの処理遅延はエンドユーザの体験を損ない、サービス全体の詰まりにつながる恐れがあるため、滞留監視は非常に重要です。

また、各ステータスのジョブ数やスループットを常時可視化しておくことで、異常にいち早く気づくだけでなく、worker の最適なキャパシティを判断するための指標としても活用できます。

こうした背景から、私たちはキューの滞留監視および可視化を実現する監視システムの構築に取り組みました。

次章では、具体的な構築要件について整理します。

監視要件と技術選定

監視システムを構築するにあたり、以下の 2 つの要件を特に重視しました。

• アプリケーションから独立した監視システム

Solid Queue のキュー監視では、Yabeda などの Ruby 向け計装ライブラリを用いてプロセス内からメトリクスを出力する手法が一般的です。

しかしこの方法だと、worker プロセス自体がダウンまたはフリーズした際にメトリクスの出力も途絶えてしまい、肝心の滞留を検知できないリスクがあります。

そのため、worker の死活状態にかかわらずキューの状態を監視し続けられるよう、アプリケーション層には一切手を加えない構成としました。

• 既存の監視基盤 (Prometheus / Grafana) の活用

すでに本環境で運用実績のある Prometheus と Grafana をベースにすることで、新たなツールの導入による運用コストの増大を防ぎつつ、アラート設定やダッシュボード構築を迅速に行えるようにしました。

これらの要件を踏まえた最適なアプローチとして、アプリケーション (worker) を介さず、データベースから直接キューの状態を読み取り、Prometheus に渡す方式を採用することにしました。

データベースからキューの状態を読み取るツールとしては、任意の SQL クエリの実行結果を Prometheus 形式のメトリクスとして公開できる sql_exporter を選定しました。

次章では、実際に構築した監視システムの全体像を紹介します。

監視システムの全体像

データベース (MySQL) に対して sql_exporter が直接クエリを発行しメトリクスを抽出。これを Prometheus で収集します。そして Grafana でキューの状態を可視化しつつ、Prometheus を活用してキューの滞留状況を監視します。

以下、sql_exporter によるメトリクス化のプロセス、Prometheus と Grafana を用いた収集・可視化の方法、そして Prometheus による滞留監視の仕組みを順に解説します。

Step 1: sql_exporter によるメトリクス化

収集メトリクスと SQL クエリの設計

キューの状態を把握するために、3 つの主要なメトリクスを設計しました。

各メトリクスの目的と、データベースからの抽出方法を以下に説明します。

(1) 各ステータスのジョブ数

現在のキューの状況を可視化するためには、ステータスごとのジョブ数を把握する必要があります。

Solid Queue ではステータスごとにテーブルが分かれているため、以下の SQL を用いて各テーブルのレコード数をカウントすることで、ジョブ数を取得できます。

より正確には、キュー名やジョブの優先度、ステータスごとに集計を行っていますが、これは後述する滞留監視用のメトリクスと同じ粒度に揃えるための措置です。

Solid Queue の各キューと優先度、ステータスごとのジョブ数を取得する SQL クエリは以下の通りです。

まず solid_queue_scheduled_executions テーブルから、キュー名、優先度、ステータスを「scheduled」としてカウントし、同様に solid_queue_blocked_executions（blocked）、solid_queue_ready_executions（ready）のデータを集計します。これら 3 つの結果を UNION ALL で結合しています。

次に、実行中のジョブ情報を取得するために、solid_queue_claimed_executions と solid_queue_jobs テーブルをジョインし、同様に failed や recurring のステータスも関連付けながら集計します。これにより、すべてのステータス（scheduled, blocked, ready, claimed, failed, recurring）におけるキューごとのジョブ数が取得できます。

上記のクエリ結果は、sql_exporter によって Prometheus が監視できる形式のメトリクスに変換されます。具体的には、キュー名、優先度、ステータスをラベルとして付与した solid_queue_job_count という名の時系列データが生成され、例えば「default キューで優先度 10 の準備中ジョブが 5 件」「優先度 20 の実行中ジョブが 2 件」といった形で出力されます。

ただし、このメトリクスはあくまでその瞬間の値を示すものであり、過度な信頼は禁物です。しかし、キュー全体の滞留状況や負荷傾向を大まかに把握する目的には十分活用できます。

(2) 最古ジョブのタイムスタンプ

今回の主目的である滞留監視を実現するには、各ステータスにおいて「最も長く待たされているジョブが、どれくらいの時間滞留しているか」を把握する必要があります。また、各ジョブには処理優先度が割り当てられており、優先度ごとに滞留監視の閾値を使い分ける運用方針のため、優先度ごとの滞留時間を可視化する必要性も生じます。

そこで今回は、キュー名・ジョブの優先度・ステータスごとの「最古ジョブのタイムスタンプ（Unix 時間）」を取得するメトリクスを設計しました。滞留時間を直接メトリクスとして出力することも可能ですが、Prometheus 側で計算した方がより自然な表現になるため、今回はタイムスタンプを取得する方式を採用しています。

SQL でタイムスタンプを抽出する際は、各ステータスの特性に合わせて以下のようにカラムを使い分けます。

• ready / claimed / failed / blocked : created_at（ジョブが各状態に遷移・作成された時刻）

• scheduled : scheduled_at（ジョブが実行されるべき予定時刻）

• recurring : run_at（定期タスクが実行されるべき予定時刻）

Solid Queue の各キュー状態（スケジュール済み、ブロック済み、準備中、占有中、失敗、定期実行）におけるジョブの最古作成時刻を把握するためには、複数のテーブルからデータを抽出し統合する SQL クエリが必要です。具体的には、solid_queue_scheduled_executions テーブルからは scheduled_at の最小値を、solid_queue_blocked_executions と solid_queue_ready_executions テーブルからは created_at の最小値を取得します。また、solid_queue_claimed_executions や solid_queue_failed_executions といったテーブルでは、ジョブ情報を含む solid_queue_jobs テーブルと結合し、それぞれのキュー名と優先度でグループ化して最古の時刻を算出します。定期実行ジョブについても同様に、solid_queue_recurring_executions とジョブ情報を結合して処理を行います。

これらのクエリ結果は、sql_exporter を経由して Prometheus が監視可能な形式のメトリクスに変換されます。

solid_queue_oldest_job_seconds{queue_name="default",priority="10",status="ready"} 1782864000

solid_queue_oldest_job_seconds{queue_name="default",priority="20",status="claimed"} 1782864010

solid_queue_oldest_job_seconds{queue_name="default",priority="30",status="failed"} 1782864060

...

(3) スループット

キューのスループット、つまり単位時間あたりにエンキュー（enqueue）またはデキュー（dequeue）されたジョブ数を可視化するメトリクスも必要です。

我々の運用環境では、完了したジョブは即座に物理削除されるため、「完了したジョブ数」を直接カウントしてデキュー速度を算出するのは困難でした。エンキュー速度についても同様の理由で計測が難しいことが判明しています。

そこで視点を切り替え、MySQL の performance_schema に注目しました。performance_schema 内の table_io_waits_summary_by_table テーブルには、テーブルごとの累積 INSERT および DELETE 回数が統計データとして格納されています。これを利用することで、キューや優先度レベルでの細分化はできませんが、各ステータス（テーブル）単位の大まかなスループットを把握できるようになりました。

SELECT OBJECT_NAME AS `table`, COUNT_INSERT AS `insert`, COUNT_DELETE AS `delete`
FROM performance_schema.table_io_waits_summary_by_table
WHERE OBJECT_SCHEMA = DATABASE()

上記の SQL クエリ結果を、sql_exporter を用いて以下のような Prometheus 形式のメトリクスに変換します。

solid_queue_global_io_counts{table="solid_queue_ready_executions",operation="insert"} 1000
solid_queue_global_io_counts{table="solid_queue_ready_executions",operation="delete"} 800
solid_queue_global_io_counts{table="solid_queue_claimed_executions",operation="insert"} 800
...

sql_exporter の設定ファイル

設計した 3 つのメトリクスを、以下のように sql_exporter の設定ファイルに記述します。

jobs セクションで接続先のデータベースを設定し、collectors 内の metrics で先ほど解説した各クエリとラベルのマッピングを定義しています。

global:
  scrape_timeout: 10s
  scrape_timeout_offset: 500ms
  max_connections: 3
  max_idle_connections: 3

Solid Queue の滞留監視と可視化：SQL Exporter と Prometheus の連携

DeNA インフラ SRE チームが取り組む、Solid Queue の運用監視において、SQL Exporter を活用したアプローチが注目されています。本稿では、Prometheus との連携を通じて、キュー内のジョブ滞留状況をリアルタイムで可視化する具体的な構成と、その効果について解説します。

監視対象となる Solid Queue の設定例を以下に示します。この設定では、solid_queue という名前のジョブを定義し、MySQL データベースからメトリクスを取得する構成となっています。

jobs:
  - job_name: solid_queue
    collectors: [ solid_queue ]
    static_configs:
      - targets:
          solid_queue_dev: 'mysql://user:${PASSWORD}@host:3306/solid_queue_dev'

この設定により、開発環境（solid_queue_dev）のデータベース接続情報を指定し、ユーザー名とパスワードを環境変数やシークレット管理を通じて安全に取得しながら、キューの状態を継続的に収集することが可能になります。これによって、ジョブの滞留時間や処理遅延といった重要な指標を、Prometheus のダッシュボード上で直感的に把握できるようになります。

SQL Exporter を用いることで、アプリケーション側のコードを変更することなく、既存のデータベース構造を活用して監視データを抽出できます。特に、Solid Queue が MySQL をバックエンドとして利用している環境では、この手法が非常に効率的です。パスワードなどの機密情報は ${PASSWORD} といった変数形式で管理することで、設定ファイルへの直接記述を避け、セキュリティリスクを低減しています。

本構成を導入した結果、DeNA インフラチームはジョブの滞留状況を早期に検知し、ボトルネックの特定やリソース調整を迅速に行えるようになりました。可視化されたデータは、運用担当者の判断材料としてだけでなく、システム全体の健全性を維持するための重要な指標としても機能しています。

次回の連載では、収集したメトリクスに基づくアラート設定や、実際のトラブルシューティング事例について詳しく取り上げます。

Solid Queue の滞留監視と可視化

Solid Queue のジョブ状況を把握するために、Prometheus と SQL Exporter を組み合わせた監視構成を採用しています。この設定では、solid_queue_job_count というゲージメトリクスを定義し、キュー名、優先度、ステータスをラベルとして付与することで、詳細な可視化を実現します。

具体的には、データベース内の各テーブルからジョブ数を抽出する SQL クエリを実行しています。solid_queue_scheduled_executions テーブルからはスケジュール済みのジョブを、solid_queue_blocked_executions からブロックされたジョブを、そして solid_queue_ready_executions から実行待ちのジョブをそれぞれカウントします。

さらに、実行中のジョブについては solid_queue_claimed_executions と solid_queue_jobs テーブルを結合して取得し、同様に失敗したジョブや再試行が必要なジョブについても関連テーブルを結合することで正確な数を算出しています。これにより、各キューの状態を包括的に把握することが可能になります。

collectors:
  - collector_name: solid_queue
    metrics:
      - metric_name: solid_queue_job_count
        type: gauge
        help: 'Current number of jobs'
        key_labels: [queue_name, priority, status]
        values: [job_count]
        query: |
          SELECT queue_name, priority, 'scheduled' AS status, COUNT(*) AS job_count FROM solid_queue_scheduled_executions GROUP BY queue_name, priority
          UNION ALL
          SELECT queue_name, priority, 'blocked' AS status, COUNT(*) AS job_count FROM solid_queue_blocked_executions GROUP BY queue_name, priority
          UNION ALL
          SELECT queue_name, priority, 'ready' AS status, COUNT(*) AS job_count FROM solid_queue_ready_executions GROUP BY queue_name, priority
          UNION ALL
          SELECT j.queue_name, j.priority, 'claimed' AS status, COUNT(*) AS job_count FROM solid_queue_claimed_executions ce JOIN solid_queue_jobs j ON ce.job_id = j.id GROUP BY j.queue_name, j.priority
          UNION ALL
          SELECT j.queue_name, j.priority, 'failed' AS status, COUNT(*) AS job_count FROM solid_queue_failed_executions fe JOIN solid_queue_jobs j ON fe.job_id = j.id GROUP BY j.queue_name, j.priority
          UNION ALL
          SELECT j.queue_name, j.priority, 'recurring' AS status, COUNT(*) AS job_count FROM solid_queue_recurring_executions re JOIN solid_queue_jobs j ON re.job_id = j.id GROUP BY j.queue_name, j.priority

• metric_name: solid_queue_oldest_job_seconds

type: gauge

help: '最も古い未完了ジョブの Unix タイムスタンプ'

key_labels: [queue_name, priority, status]

values: [oldest_ts]

query: |

SELECT queue_name, priority, 'scheduled' AS status, UNIX_TIMESTAMP(MIN(scheduled_at)) AS oldest_ts FROM solid_queue_scheduled_executions GROUP BY queue_name, priority

UNION ALL

SELECT queue_name, priority, 'blocked' AS status, UNIX_TIMESTAMP(MIN(created_at)) AS oldest_ts FROM solid_queue_blocked_executions GROUP BY queue_name, priority

UNION ALL

SELECT queue_name, priority, 'ready' AS status, UNIX_TIMESTAMP(MIN(created_at)) AS oldest_ts FROM solid_queue_ready_executions GROUP BY queue_name, priority

UNION ALL

SELECT j.queue_name, j.priority, 'claimed' AS status, UNIX_TIMESTAMP(MIN(ce.created_at)) AS oldest_ts FROM solid_queue_claimed_executions ce JOIN solid_queue_jobs j ON ce.job_id = j.id GROUP BY j.queue_name, j.priority

UNION ALL

SELECT j.queue_name, j.priority, 'failed' AS status, UNIX_TIMESTAMP(MIN(fe.created_at)) AS oldest_ts FROM solid_queue_failed_executions fe JOIN solid_queue_jobs j ON fe.job_id = j.id GROUP BY j.queue_name, j.priority

UNION ALL

SELECT j.queue_name, j.priority, 'recurring' AS status, UNIX_TIMESTAMP(MIN(re.run_at)) AS oldest_ts FROM solid_queue_recurring_executions re JOIN solid_queue_jobs j ON re.job_id = j.id GROUP BY j.queue_name, j.priority

• metric_name: solid_queue_global_io_counts

type: counter

help: 'テーブルごとの I/O 操作の総数'

key_labels: [table]

value_label: operation

values: [insert, delete]

query: |

SELECT OBJECT_NAME AS table, COUNT_INSERT AS insert, COUNT_DELETE AS delete

FROM performance_schema.table_io_waits_summary_by_table

WHERE OBJECT_SCHEMA = DATABASE()

Step 2: Prometheus と Grafana による収集・可視化

Prometheus では、sql_exporter が提供する /metrics エンドポイントのスクレイプ設定を追加しています。

Grafana では、以下のようなダッシュボードを構築してキューの状態を可視化しています。

ジョブ数と滞留時間のグラフ

default という名前のキューについて、左側にジョブの数、右側に滞留時間をそれぞれ表示しています。

スループットのグラフ

solid_queue_global_io_counts メトリクスから得られる各テーブルの INSERT / DELETE 累積回数を、PromQL の rate() 関数を使って秒間の平均回数に変換し、近似的なスループットとして表示しています。

enqueue / dequeue の速度を確認したい場合は、主に以下のポイントに着目するのが良いでしょう。

• enqueue 速度：ready テーブルの INSERT 速度

• dequeue 速度（処理開始時点）：claimed テーブルの INSERT 速度、または ready テーブルの DELETE 速度

• dequeue 速度（ジョブ完了時点）：jobs テーブル（全ジョブが共通して格納されるテーブル）の DELETE 速度

なお、claimed テーブルに記録されたジョブは、対応する jobs テーブル内のレコード削除に伴ってカスケード削除されるようになっています。そのため claimed テーブルの delete 速度は表面上ゼロに見え、dequeue 速度の指標としては利用できません。

滞留監視の閾値

移行前のキューシステムでは、ジョブの種類ごとに個別に閾値を設定して監視を行っていました。細かく調整できる反面、十数種類あるジョブそれぞれで閾値を管理する必要があり、運用負荷が課題となっていました。

Solid Queue ではこの個別管理を廃止し、ジョブの優先度に基づく汎用的な閾値運用へ移行しました。優先度は「High」「Normal」「Low」の 3 段階に分類され、ステータスと組み合わせることで滞留監視の閾値を設定します（表の数値は当社の環境・要件に基づいた一例です）。

アラートルール実装

Prometheus のアラートルールでは、time() 関数と solid_queue_oldest_job_seconds メトリクスの差分を計算することで、ジョブの滞留時間（秒）を評価します。

例えば、「ステータスが ready で優先度が High（閾値 1 分）」の場合のアラートルールは以下のようになります。

rules:
  - alert: SolidQueueReadyJobWait_PriorityHigh
    expr: |
      time() - solid_queue_oldest_job_seconds{status="ready", priority="10"}
      > 60
    for: 1m
    labels:
      severity: critical

まとめ

アプリケーション側への改修は行わず、独立した監視構成として sql_exporter から直接データベースを参照する方式を採用しました。これにより、Solid Queue のスループット可視化と滞留監視を実現しています。

本構成での運用はまだ始まったばかりですが、実際の運用状況に合わせて閾値やメトリクスの調整は十分可能です。この記事が、Solid Queue の監視体制を検討されている方々の参考になれば幸いです。