Ichizokuは日本唯一のSentry公認販売業者です。
日本語のドキュメント、動画、サポート窓口で日本のお客様のSentry活用を支援します。

Sentryを活用したクエリのレート制限のデバッグ方法について

04/18/2025

Article by: Rachel Chen

Snubaは、Sentryを本番環境で動作させるための中核となるイベントデータの保存およびクエリサービスです。

これまで内部でレート制限を行っていたため、その挙動が見えづらく、サポート対応に時間がかかるケースがありました。Snubaのコードに精通していない限り、こうした詳細にはなかなか気づけません。

しかし、実際に顧客からの問い合わせを整理していく中でよく見かける問題が1つありました。それが「RateLimitExceeded」です。

クエリ結果が得られないことに何度も悩まされたのではないでしょうか。私たち自身もその例外に何度も頭を抱えた結果、ついに修正することに踏み切りました。

SentryがRateLimitExceededの問題を抱えていた理由

Sentry では、社内で運用している複数の ClickHouse クラスタを利用しています。

これらは、UI や API のデータ提供を担っています。また、ClickHouse リソースをどのように割り当てるかを決定するために「ClickHouse 容量管理システム」の中で割り当てポリシーのコレクションを用意しています。

Snuba にクエリが送信されると、容量管理システムがこれらのポリシーを適用し、クエリを受け入れるか、拒否されるか、あるいはスロットル（処理の一時的な遅延）するかを判断します。

Sentryが全体のレート制限をどのように改善したか

まずレート制限の仕組みをより明確に把握するため、Sentry のエンジニアたちがクエリ状況を確認できる「Snubaカスタマーダッシュボード」をインフラツール内に構築しました。

そしてこの取り組みによって、エラー関連のクエリが 96.628% の成功率であることがわかりました。

しかし、単に成功率を知っているだけでは、根本的な解決にはなりません。Datadog のようなインフラ監視ツールは非常に有用ですが、デバッグには向いていないためです。

そこで「私たちはそもそもデバッグツールを作っているのだから（それが Sentry です 😃）、この情報をSentry上で見られるようにしよう」と考え、実際にそうしました。

ステップ1: 開発者ワークフローの改善

まず Sentry に新機能を追加する前に、必要な情報が揃っていることを確認しました。

最初に Snuba カスタマーダッシュボードを使って全体の概要（何が起きているのか）を把握し、次に Sentry のトレースビューページでレート制限されたクエリの詳細（なぜ起きたかとどのように起きたか）に掘り下げます。

以下は、api.project-events リファラーから、拒否されたクエリを含むすべてのトレースを取得する例です。

ステップ2: クエリが拒否される前に「警告ゾーン」で知らせる

これまでSentry のユーザーはクエリが拒否され始めるまで、過剰なクエリを送っていることに気づけませんでした。そこで開発者の利用満足度を向上させるために「警告ゾーン」を導入しました。

この警告ゾーンでは、以下の2つを実現しています。

同一のユーザーからのクエリをスロットル（処理遅延）することで、負荷を分散しつつもクエリを通すようにしています。これにより、クエリは少ないスレッドでゆっくり実行されます。
スロットルされたクエリや、警告ゾーン内のクエリをフィルタリングできるようにし、Sentry の開発者が頻出クエリに対して素早く対応できるようにしました。

これにより、割り当てポリシーで「拒否された」かどうかを見るだけでなく、そのアカウントのクエリが「スロットルされているか」も確認できるようになりました。

ステップ3: Sentryでスロットル / 拒否されたクエリ情報を整理

Datadog のような監視ツールでは、どれだけのクエリが影響を受けたかは把握できますが、詳細なデバッグ情報までは得られません。傾向の把握には役立つものの、レート制限のしきい値といった細かい情報がなければ、根本的な改善提案を行うのは難くなります。

現在はSentry のエンジニアが Sentry 上で影響を受けたクエリをクリックし、カスタムタグの下に表示される有益なデバッグ情報を確認できるようになっています。

さらにこの情報は、トレースのスパン下にタグとしても表示されます。以下の例では、ID が aa73cba0b21d86bc のスパンがスロットルされたことが明示されています。

こうしたタグのおかげで Sentry のエンジニアは普段使っている Sentry のデバッグワークフローのなかで、必要なフィルタリングを行いながら、より詳細で包括的な状況把握ができるようになったのです。

これらの改善は、Sentryのユーザーにどんなメリットをもたらすのか？

今回の改善の目的は、Sentry のエンジニアがクエリのレート制限に関する問題を解決する際、デバッグの方法をわざわざ変えなくても済むようにすることでした。これらの変更によって、エンジニアたちはこれまで通り Snuba にクエリを投げることができます。

クエリが成功すれば、結果が返されるだけですが、もし RateLimitExceeded が表示され始めたら、それはクエリが拒否されてしまっていることを示します。

Sentry のイシューやスパンの詳細に新たな情報が追加されるため、原因を調べる手掛かりになります。

つまりクエリの結果が返されなくなり、困った場合は Sentaur に助けを求めれば、何が起きているのか、なぜそれが起きたのかを正確に把握することが可能になります。そして、allocation_policy.suggested タグを活用することで、次にやるべきアクションを提案してくれるようになります。