Sentryの「守護神」になれ：バーストトラフィックを制御し、真の異常だけを射抜くためのレートリミット戦略
優秀なエンジニアは「エラーが起きたこと」を知るが、一流のエンジニアは「エラーが起きるべきではない場所で、何が起きているか」を見抜く。
Sentryは強力な味方だが、設定を怠ればたちまち「ノイズの山」と「クォータ超過によるイベント損失」という二重苦に陥る。特に、突然のトラフィックバーストで重要なアラートを逃した瞬間、あなたのオブザーバビリティは死を迎える。
本稿では、Sentryのレート制限の深淵に触れ、現場で即戦力となる防衛策を伝授する。
—
1. なぜ「クォータ上限」に達するのか：真因はコードではない
多くのチームが「トラフィックが増えたから」という理由でクォータ上限に達するが、それは半分正解で半分間違いだ。真因は「制御不能なエラーの連鎖（Error Cascading）」にある。
- 依存関係の崩壊: 外部APIが一時的に503を返した際、フロントエンドが再試行を繰り返し、1ユーザーの操作が数千のログを生む。
- 不適切な`beforeSend`: クライアント側で発生する「無視すべきDOMエラー」や「ブラウザ拡張機能由来のノイズ」を放置している。
これらを放置することは、「大火災の最中に、火災報知器の電池を抜く」ようなものだ。
—
2. 実践：プロジェクトを守る「段階的ドロップ」の技術
Sentry SDK側で制御を完結させるのが最も低コストだ。`beforeSend`を単なるフィルタリングではなく、「インテリジェントなサンプリング」として再定義する。
SDK設定のベストプラクティス (JavaScript/TypeScript)
Sentry.init({
dsn: “YOUR_DSN”,
// 1. レート制限の核：重要度に応じたサンプリング
tracesSampleRate: 0.1, // 全トラフィックの10%に絞る
beforeSend(event, hint) {
const error = hint.originalException;
// 2. 既知の「ノイズ」を即座に破棄（ネットワークエラー等）
if (error && error.message && /NetworkError|Failed to fetch/i.test(error.message)) {
return null; // このイベントをDropする
}
// 3. 重要度の高い例外のみ「強制送信」
if (event.level === ‘fatal’ || event.level === ‘error’) {
return event;
}
// 4. 重要度が低いものは確率的にドロップ（間引き）
return Math.random() > 0.5 ? null : event;
}
});
—
3. チーム開発で生き残る：設定の共有と「神」ルール
チーム全体で同じノイズを送り続けていないか？設定をコードとして管理し、DRY（Don’t Repeat Yourself）を徹底する。
推奨構成：`sentry.config.ts` の共通化
各サービスに設定を散らばらせず、社内ライブラリとして設定を注入する。
// @company/sentry-config
export const getBaseSentryConfig = (serviceName: string) => ({
release: process.env.VERSION,
environment: process.env.NODE_ENV,
// チームで統一すべきタグ管理
initialScope: {
tags: { service: serviceName },
},
// 送信前に必ず通す共通フィルター
beforeSend: (event: any) => {
// 開発環境での過剰なログを抑制
if (process.env.NODE_ENV === ‘development’) return null;
return event;
}
});
—
4. プロの隠しコマンド：生産性を最大化するTips
開発スピードを上げるショートカット
- `Cmd + K` (Sentry画面): コマンドパレットを開く。プロジェクトの切り替えや、特定のIssue IDへのジャンプが爆速になる。
- `Shift + J` / `K`: Issueリストの項目をキーボードだけで選択可能。マウスには戻れない。
絶対に入れるべきプラグイン
- GitHub/GitLab Integration: これを入れないのは裸で戦場に出るのと同じ。Issueから直接PRを作成し、デプロイ後の「誰がこのバグを混ぜたのか」を特定する速度が10倍になる。
- Sentry CLI: CI/CDパイプラインに組み込み、ソースマップのアップロードを自動化せよ。これがないと、Sentryのスタックトレースはただの「読めない暗号」だ。
—
5. 結論：オブザーバビリティは「捨てる勇気」から始まる
全てを監視しようとするのは傲慢だ。本当に価値のあるエラーだけを射抜き、残りを取りこぼさないためにサンプリングする。 これこそが、大規模トラフィックを捌くための唯一の正解だ。
今すぐチームの`beforeSend`を見直してほしい。そこに「捨てられるはずのゴミ」が混じっていれば、それがあなたのクォータを食いつぶし、本当に救うべきユーザーを沈めている原因かもしれない。
明日の朝、Sentryのダッシュボードを見た時に「ノイズのない静寂」と「重要なアラートの確かな通知」があれば、あなたはアーキテクトとして一つ上のステージに登ったことになる。
健闘を祈る。