TurnstileかreCAPTCHAか、無料上限と誤判定の代償で選ぶ
スタートアップ・ビジネス 1
SentryかNew Relicか、障害調査の起点で選択が分かれる
コード上の例外から修正箇所を探す開発チームにはSentry、サービスの遅延や障害をログやインフラの状態まで広げて調べるSREにはNew Relicが選びやすい。SigNozの同一Pythonアプリによる検証では、Sentryはエラーとコードの文脈、New Relicはアプリ全体の性能把握に強みが見られた。検証者は評価の一部に主観が含まれるとも明記しており、調査時間を測った比較ではない。
両製品ともエラー監視と分散トレースを扱う。違いが大きいのは、障害を受けた担当者が最初に必要とする情報と、そこから調査を広げる方向だ。既存のログ・インフラ監視が使えるかどうかに加え、New Relicでは取り込み量、Sentryではエラーやスパンなどの使用量が費用を左右する。
例外から修正箇所へ進むならSentry
Sentryはアプリに組み込んだSDKで例外を収集し、関連する発生をIssueにまとめる。Issueではエラーの種類や発生状況を見たうえで、スタックトレース、発生した環境、リリースなどをたどれる。同じ不具合の通知が繰り返されても、開発者は個々の報告を読み直すより、修正すべき問題として扱いやすい。
Pythonアプリの検証で確認されたSentryのIssueには、エラーメッセージ、影響を受けた利用者、問題が起きた箇所と周辺コードが示された。関連するトレースから、例外に至る処理も追える。リリース後に特定の操作で失敗が増えた場合、コードと発生条件を結び付けて調べる動線が役立つ。
New RelicにもErrors Inboxがあり、APMで収集したエラーをグループ化し、件数や発生率、関連するアプリ情報を見られる。したがって、エラーを追うために必ずSentryが要るわけではない。相違点は、エラーを修正作業の中心に置くか、遅延や基盤の異常と並ぶ信号として扱うかにある。
例えば、あるリリースで特定の例外だけが増えたという条件なら、スタックトレースとリリース情報から入る方が調査を絞りやすい。一方、複数のサービスで応答が遅くなり、各所で異なるエラーが出ているなら、個別のコードを直す前に共通の依存先を調べる必要がある。前者の作業を日常的に担うチームほど、SentryのIssueを起点にする価値が大きい。
遅延の範囲とインフラを結ぶならNew Relic
明確な例外が出ない遅延では、リクエストがどのサービスを通り、どこで時間を使ったかが重要になる。Middlewareの機能比較は、New RelicがAPM、分散トレース、ログ、ホストやコンテナの監視を横断して扱い、Sentryはコードに結び付くエラーと性能問題の調査に重点を置くと整理している。Middlewareも監視サービスを提供する事業者であり、この評価は統一条件の性能試験ではない。
New RelicのAPMでは応答時間や処理量、サービス間の依存関係を調べられる。必要なインフラデータも収集すれば、遅くなったサービスのトレースから、関連するログやホストの状態へ調査を広げられる。ただし、アプリの計装だけで全ホストや全ログが自動的にそろうわけではなく、監視対象ごとの収集設定が必要だ。
Sentryにも分散トレースがあり、処理のスパンや遅いデータベース呼び出しをエラーと関連付けられる。ログも扱うため、アプリ内の性能調査をエラーだけに限る製品ではない。一方、ホストやコンテナの状態まで同じ監視基盤で追いたい場合は、Sentryとは別の仕組みを組み合わせることになる。
開発者が失敗した処理から関連トレースへ進む運用なら、Sentryの調査範囲は仕事に合う。SREがまず障害の影響範囲を見て、サービス、ログ、基盤のどこに原因があるか切り分ける運用なら、New Relicの広さが効く。その広さには収集設定、権限、通知、データ量の管理も伴うため、機能の多さだけで導入負担は判断できない。
OpenTelemetryと既存のログ基盤で導入負担が変わる
すでにOpenTelemetryでアプリを計装しているなら、既存の送信経路をどう使えるかが選定に影響する。New RelicのOTLP受け入れ仕様は、トレース、メトリクス、ログをOpenTelemetryの経路から取り込む方法と、送信先や認証の条件を示している。既存の計装を利用できても、サービス名や属性が調査画面で意図どおり結び付くかは、導入する構成に左右される。
Sentryでは、エラーとトレースをIssueに結び付ける際、採用するSDKや連携方式が重要になる。OpenTelemetryのデータを送れることと、例外の周辺コード、リリース、利用者への影響まで同じ文脈で見られることは別の要件だ。開発チームが重視するのが修正に必要な情報なら、収集経路だけでなくIssueで得られる内容を比べる必要がある。
すでにログとインフラの監視基盤があり、足りないのが例外の詳しい調査なら、Sentryを追加して役割を分けやすい。反対に、ログ、APM、ホスト監視が別々で、障害のたびに時刻やサービス名を照合しているなら、New Relicへ監視信号を集める効果が大きくなる。どちらの判断でも、現在どのデータを収集できているかが、製品単体の機能表より先に効く。
併用も可能だが、同じエラーやトレースを両方へ送れば、取り込み量と通知の両方が増える。開発チームはSentryでコード上の問題を扱い、SREはNew Relicで全体の状態を扱う、と担当する判断を分けられる場合に意味がある。担当が重なるなら、障害時にどちらの通知を起点にするかも運用上の決め事になる。
料金はNew RelicのGBとSentryの使用枠を分けて見る
New Relicの公式料金表では、月間100GBの無料取り込み枠、有料版のOriginal Dataで超過分1GB当たり0.40米ドル、Data Plusで同0.60米ドルを示している。無料版にはフルプラットフォーム利用者が1人含まれ、有料版は取り込み量に加えて利用者権限別の料金、または対象プランのCompute方式を考える。ここでいう取り込み量は、送信前の生データ量ではなく、処理後にプラットフォームへ保存された量だ。
条件付きの試算として、Original Dataで月間50GBまたは100GBなら、取り込み量の超過料金は0米ドルとなる。月間500GBなら無料枠を超える400GBに単価を掛け、取り込み量の超過料金は160米ドルとなる。この金額は有料版でのデータ料金だけを計算したもので、利用者料金や追加機能を含む請求総額ではない。
無料版の上限を超えた場合は、自動的に超過料金を払って使い続ける仕組みではない。New Relicは、アップグレードしなければその月のデータ収集とプラットフォームへのアクセスが止まると案内している。ログを広く集める構成では、例外が少なくても保存量が増えうるため、費用と収集の継続性を同時に考える必要がある。
Sentryは同じGB単価だけでは比べられない。エラー、トレースのスパン、セッションリプレイ、ログなどは、それぞれの使用枠で把握する。Sentryの旧Developerプラン移行案内では、対象プランのトレース枠が月間トランザクションから月間スパンへ変わり、エラーやリプレイなどの既存枠は維持されると説明している。この変更は旧Developerプランについての案内であり、すべての契約に同じ移行が起きるという意味ではない。
月間データ量が同程度のアプリでも、両製品の請求は違う形で増える。Sentryでは例外の発生と計装された処理のスパンが別々の使用量になり、New Relicでは大量のログを取り込むと保存GBが増える。料金を比べるなら、必要な監視信号、収集量、調査に参加する人の権限を同じ運用条件で見積もることになる。
誰が障害調査を始めるかが選択を決める
アプリ開発者が例外の通知を受け、影響するリリースとコードを特定して修正する運用なら、Sentryを中心に据える理由は明確だ。既存のログ・インフラ監視が十分なら、その役割を置き換える必要もない。分散トレースは、Issueから原因を追うために必要な処理を中心に利用できる。
SREやプラットフォーム担当がサービス全体の遅延を把握し、担当チームへ原因を切り分ける運用なら、New Relicが主軸になりやすい。アプリ、ログ、インフラを横断する調査には利点がある一方、その利点は必要なデータを収集し、関係付けられて初めて生まれる。月間取り込み量と調査権限を含めて運用できるかが、導入後の使い勝手と費用の両方を決める。
関連記事：
関連記事
ニュースレターを購読
Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。
0