ランダムなチャンクから本当のコードへ：SentryでNext.jsのソースマップをつなぐ
Article by: Sergiy Dybskiy, Anton Bjorkman Next.js アプリをリリースするとき、あなたが書いた React や TypeScript は、ユーザーが実際にダウンロードするものではありません。Next.js はパフォーマンスには優れている一方でデバッグには最悪な形で、コードをコンパイルし、ミニファイし、分割し、チャンクへとシャッフルします。 この記事では、そのパイプラインがどのように動くのか、ソースマップと Debug ID がそれらをどのように元のコードへ結び付けるのか、そして Sentry が読みにくいスタックトレースではなく、実際のファイル名と行番号を表示するように設定する方法を解説します。 コードに実際に何が起きるのか 一般的な Next.js アプリでは、React＋TypeScript のソースはビルドパイプラインを通り、JavaScript、HTML、CSS へコンパイルされます。その出力はミニファイされ、ユーザーが必要なものだけをダウンロードできるようにチャンクへ分割されます。 これらはページの読み込みには良いことです。しかしエラーが起きたとき、スタックトレースが app/page.tsx ではなく static/chunks/12345-something.js を指すようになると、あなたにとってはあまり良いことではありません。 あなたのコードは見覚えのあるものから、まったく見覚えのないものへと変わります。そこで登場するのがソースマップです。コンパイルされた各バンドルチャンクには、2つの重要なメタデータがあります。Debug ID と対応するソースマップを指す sourceMappingURL です。 Sentry はアップロードされたミニファイ済みファイル上の Debug ID を使って、アップロードされたソースマップ上の一致する Debug ID を見つけます。このペアがそろうと、Sentry はスタックトレースをデミニファイし、元のファイル、行、列へマッピングし直して、バンドラーが生成したコードではなく、あなたが実際に書いたコードを表示できます。 開発ツールではきれいなスタックトレースが出るのにSentry ではチャンクになる理由 開発時はブラウザ上では問題なく見えます。dev でアプリを動かし、サンプルのエラーを投げると、ブラウザの開発者ツールは実際のファイル名とソースを含む、読みやすいスタックトレースを表示します。 これは next […]
AIによるキャッシング戦略と計測
Article by: Lazar Nikolov, Ben Coe 最低限の製品（MVP）と本番対応のアプリを分けるものは、磨き込み、最終調整、そしてパレートの法則でいう「最後の20%」の作業です。ほとんどのバグ、エッジケース、パフォーマンス問題は、リリース後に実ユーザーがあなたのアプリケーションを使い込むようになって初めて表面化します。これを読んでいるということは、おそらく作業の80%地点にいて、残りに取り組む準備ができているはずです。 本記事では、アプリケーションのキャッシングを扱います。テールレイテンシの削減、データベースの保護、トラフィックのスパイクへの対処にキャッシュをどう使うか、さらに本番環境で稼働し始めてからそれをどのように監視するかを解説します。 本記事は、MVP を本番環境に持ち込む際に生じる共通の課題を扱うシリーズの一部です。 本番環境で大規模データセットをページネーションする：OFFSETの限界とカーソルの利点 AIによるキャッシング戦略と計測（本記事） キャッシングのメンタルモデルを構築する 適切なキャッシングはパフォーマンス、スケーラビリティ、コスト効率を何倍にも高めます。正しく行えば、ミリ秒未満の応答を実現し、オリジンサーバーを潰すことなくトラフィックの急増を吸収できます。一方、誤ったキャッシング（過度なキャッシング、不適切な無効化、誤った戦略）は、微妙なバグや古いデータ、デバッグが難しく、しかも多くのユーザーに影響が及んだ後になってようやく表面化する劣化したユーザー体験（UX）を生みます。 キャッシングの機会を探す前に、何をキャッシュすべきで、何をキャッシュすべきでないのかについてのメンタルモデルが必要です。 以下のチェックリストをご覧ください。 ✅ 大半が当てはまるならキャッシュを検討 高コスト：CPUが遅い、入出力（I/O）が遅い、DBが重い、大規模な結合／集計、外部API 高頻度：呼び出し回数が多い（1分あたりのリクエスト数（RPM）が高い）、またはホットパス上にある（ページ読み込み、コアAPI） 再利用可能：同じ入力が繰り返される（キーのカーディナリティが低い） ある程度安定：データが毎秒変わらない（または多少の古さを許容できる） スパイク負荷：突発的なトラフィックで、キャッシュがアクセス集中（サンダリングハード）を吸収できる テールが痛い：P95/P99が悪く、キャッシュミスが遅いリクエストと相関している 古いデータを返しても安全：ユーザー影響が小さい、または stale-while-revalidate（SWR）を使える 無効化が簡単：TTL（time to live）が機能する、または更新に明確なトリガーがある ペイロードが小さめ：メモリコストが妥当で、シリアライズが安い ❌ 次のいずれかに当てはまるならキャッシュしない（または慎重に） キーのカーディナリティが高い：ユーザーごと／ページごと／フィルターごとに爆発する → ほとんどがキャッシュミスになる（ページネーションは特殊ケース。後述の注記を参照） 変化が激しい：正確性のために鮮度が必須 個別対応／権限制御がある：キーのミスでデータ漏えいが起きやすい 無効化が難しい：明確なTTLがない、更新が予測できない すでに速い：5msの短縮は複雑さに見合わない キャッシュスタンピードのリスク：再計算コストが高い＋有効期限が同期される（ロック／ジッターが必要） ページネーションされたエンドポイントをキャッシュする際には特別なルールがあります。まずは1ページ目と一般的なフィルターをキャッシュしてください。1ページ目と少数の一般的なフィルターは通常ホットで再利用されるため、キャッシュの効果が大きくなります。一方、ページ番号が増えるほどキーのカーディナリティが爆発し、再利用は急落します。そのため、深いページは自然にキャッシュミスになりますが、それで問題ありません。全ページで均一なヒット率を達成することではなく、バックエンドの保護と入口（エントリーポイント）でのテールレイテンシ削減を最適化対象にしてください。 本番環境でキャッシング機会を見つける 何をキャッシュすべきかが分かったら、次に考えるべきは「キャッシュが実際に効く場所はどこか」です。本番環境のシステムでは、良いキャッシュ候補はたいてい「痛み」として現れ、通常は3つの形を取ります。 バックエンドでの問題（ここから始めましょう） バックエンドとフルスタックのシステム において、これが最も手を打ちやすいシグナルです。 […]
SentryがXcodeBuildMCPを買収
Article by: Cameron Cooke, Josh Cohenzadeh 本日（2026年2月11日）、Sentry が XcodeBuildMCP を買収したことを発表いたします。XcodeBuildMCP はオープンソースの MCP サーバーで、AI エージェントにネイティブのiOS／macOS アプリをビルド、テスト、デバッグする機能を提供します。 XcodeBuildMCP はエージェント型の Apple プラットフォーム開発における定番ツールとなっており、GitHub のスター数は4,000を超え、活発なコミュニティがあります。ビルド、実行、デバッグ、操作、検証という開発ループ全体を解放し、ユーザーが好みのエージェント型開発環境にとどまったまま作業できるようにします。 この買収の一環として、XcodeBuildMCP の作者兼メンテナーである Cameron Cooke も Sentry のチームに加わり、Sentry のモバイル向けツール群、そして新しいエージェント型開発の環境を継続的に改善していく取り組みを支えてくれます。 なぜ Sentry に適しているのか Sentry はソフトウェアの信頼性を高め、開発者がアイデアから本番環境へ最短で到達できるようにすることに注力しています。モバイルチームにとって、この道のりは依然として困難であり、そのため私たちは2025年に Emerge Tools を買収しました。 Apple プラットフォーム向けのツールはエージェント的なワークフローへの採用が再び遅れており、開発者たちはますます重厚な IDE よりも Cursor や Claude Code、Codex CLI のようなツールで作業を行うようになっています。 XcodeBuildMCP はそのギャップを埋めるのに役立ちます。開発者が持つ現実世界での能力をエージェントにも与えることで、自律的に反復し、人間に都度コントロールを戻すのではなく、変更を検証できるようになります。 XcodeBuildMCP で可能になること 主な機能は以下のとおりです。 […]
【Size Analysis】Sentryで提供開始
Article by: Max Topolsky, Steve Zegalia Sentry は 2025年5月に Emerge Tools を買収しました。これにより開発チームに最適なモバイルツールを提供する準備が整いました。そして主力製品の1つである Size Analysis を正式にすべての Sentry ユーザーに提供を開始しました。これで、アプリサイズをもう心配する必要はありません。 CI パイプラインでの自動監視 アプリサイズが増えていく最も一般的なパターンは、少しずつ積み重なっていくことです。小さな変更が時間とともに蓄積し、気づけばモバイル通信でのダウンロード上限を超えているという警告が出るようになります。そうした小さな変更は、加えた時点であれば簡単に最適化できますが、1年後に対処しようとすると、途端に難しい作業になります。 Size Analysis は CI ワークフローに統合できるため、アプリサイズの状態を継続的に把握できます。すべてのビルドをアップロードして差分比較できます。サイズに変化があったときは、単に変わったことがわかるだけでなく、なぜ変わったのか、さらにサイズを小さくするために実施できる推奨修正があるかどうかまで確認できます。 よくあるシナリオを見てみましょう。SDK を追加する場合です。 ここに、Kingfisher を追加した際のステータスチェックがあります。Size Analysis を使うと、すぐに次のことがわかります。 この PR により、ダウンロードサイズは約500 kB、インストールサイズは約1.5 MB増加しています。 この PR が失敗したのは、「Install Size の差分が 1 MB を超える場合はチェックを失敗させる」という事前設定済みのしきい値があったためです。 「Comparison Page」を確認すれば、差分が想定どおりであることを確かめたうえで、PR を承認できます。このページでは全体のサイズ変化だけでなく、サイズが変化したすべてのファイルを表形式とビジュアルの両方で確認できます。 この場合、これは意図した差分であることが明らかなので、ステータスチェックを承認し、PRをマージできます 🎉。 次のシナリオを見てみましょう。新しいヒーローイメージを追加する場合です。 全体のサイズ差分は今回も確認できますが、今回は2つの Insights […]
【Sentry サンプリング戦略】すべてを見ようとすると結局なにも見えなくなる
Article by: Kyle Tryon 要約：一律のサンプリングレートは無駄や非効率につながることがあります。独自のサンプリングロジックを用いて、ノイズを減らしつつ100%のシグナルをキャプチャし、アプリケーションの監視方法を細かく調整しましょう。 高トラフィックの本番環境では、テレメトリはユーザー体験への最も直接的なリンクです。Sentry に送られるすべての Span、Trace、Log、Replay は、本番環境で実際に何が起きているのかを高い精度で可視化してくれます。 しかしその可視性から最大限の価値を引き出すには、シグナルとノイズをどう切り分けるかを理解しておく必要があります。安定したレガシールートにおける通常の「ページ読み込み」を、チェックアウトフローや新機能リリースのような重要な体験と同じ強度で扱っていては、収集するデータを最適化できているとは言えません。 スケールしても持ちこたえ、クォータも圧迫しないオブザーバビリティ戦略を構築するには「一律サンプリング」を超えていく必要があります。重要な箇所や変化の速い箇所では高解像度のデータを優先し、安定しているシステムでは設定を最適化する必要があります。 すべてを100%サンプリングすればいいのでは？ 可能です！ アプリが小規模だったり、まだ新しかったりするなら、それが実際に正しい方針である場合もあります。しかしスケールしていくにつれ、「すべてを100%」はたいてい現実的な選択肢ではなくなります。 理由はいくつかあります。 シグナル対ノイズ（Signal-to-Noise）: テレメトリデータはひと目で何が起きたかわかるときに、より役立ちます。チェックアウト中にユーザーが問題を経験した100件を見つけるために、100万件の「ユーザーがボタンをクリックした」span を解析しなければならないのは、あなたにとっても、クエリにとっても、そして私たちと同じ情報を利用する可能性のあるLLMにとっても、効率的ではありません。 ネットワーク負荷（The Network Footprint）: SDKは高度に最適化されていますが、あらゆる操作、あらゆる関数呼び出しは、積み重なると負荷になります。必要なものだけをサンプリングすることで、価値ある情報を収集しながら、高いパフォーマンスを維持できます。 基本の調整項目：静的サンプルレート Sentry を初期化する際には、送信するデータ量を調整するための主要なオプションが4つあります。まず最初のステップはそれぞれがどう連動するのかを理解することです。 sampleRate：エラー向けです。何かが壊れたら、毎回必ず把握したいので、私たちはほぼ常にこれを 1.0 のままにしています。 tracesSampleRate：トラフィックの一断面を取得します。パフォーマンスデータの量を管理するための主要な調整レバーです。 replaysSessionSampleRate：セッション開始時点から、セッション全体を記録します。高精細（high-fidelity）なので、通常は「平均的な」ユーザーがどうナビゲートしているかを見るには、ごく小さい割合で十分です。 replaysOnErrorSampleRate：バッファです。エラーが発生した場合にのみリプレイを送信し、エラーに至るまでの 60秒間 のアクティビティを記録します。 精密な制御：tracesSampler Trace は私たちが持つ指標の中でも特に重要である可能性が高く、パフォーマンス監視、エラー監視、そしてすべてのデータを相互に結びつける役割を担っています。本番環境では、トレースの100％をサンプルすることがほとんどの場合推奨されます。しかし、特にトラフィックが非常に多いアプリケーションでは、戦略的にトレースするのであれば、すべての Trace を収集する必要はありません。 一律の割合を指定する代わりに、Sentry では tracesSampleRate に tracesSampler 関数を渡せます。これにより、リクエストのコンテキストに基づいて、リアルタイムに判断を下せるようになります。 […]
【Next.js SDKがTurbopackに対応】少ないコードで高速ビルド、テレメトリーはそのまま
Article by: Sergiy Dybskiy 要約：Next.jsでTurbopackがデフォルトとなったため、バンドラーに依存しないようにSDKを再構築しました。その結果、コード量の削減、ビルドの高速化、そしてこれまでどおりのテレメトリーを実現しました。このブログでは、その過程を説明します。 何年もかけてツールを構築してきたのに、支えていたものが突然非推奨になり、アプローチ全体を見直さなければならなくなる。そんな経験はありますか？ そして念のためですが、これは Ralph Wiggum の話ではありません。私たちのコミュニティで合意してその名前で続けることにした、再帰エージェントプラクティスについての話でもありません。 これは、Next.js が Turbopack を展開し、Webpack を非推奨にしたこと（Next.js v16 からは Turbopack がデフォルトになっています）、SDK におけるテレメトリアプローチを見直したことについてです。 以前の状況 以前は next build を実行すると、Webpack ローダーがすべてのページ、API ルート、ミドルウェア、サーバーコンポーネントを横取りしていました。 このローダーは次のことを行っていました。 ファイルを解析し、タイプを判定する Rollup を使用し、 Sentry ラッパーテンプレートとバンドルする 元のコードを計装済みのバージョンに置き換える これはうまくいきました。しかし、それには6種類のラッパーテンプレート、360行の Webpack ローダー、約1,667行の計測コードを維持する必要がありました。Next.js の新機能が追加されるたびに、サーバーコンポーネントやルートハンドラー、App Routerといったものに対して新しいテンプレートを書く必要があり、Webpackの内部が最後に確認したときから変更されていないことを祈るしかありませんでした。 私たちは、すべてのファイルに「Sentryでラップされたドッペルゲンガー」が存在する並行世界を構築していました。こういったアーキテクチャはうまく機能する時には良いのですが、うまくいかなくなると、どの層が壊れたのかを追うのは至難です。 現在の取り組み Next.js には、組み込みの OpenTelemetry 計装機能があります。これにより、すべてのリクエスト、ミドルウェアの実行、レンダー処理ごとにルート情報つきの スパン を出力します。コードをラップする代わりに、それを受け取るようにしています。 上のスニペットは「きれいなバージョン」です。実際には、標準の […]
【Log Drains 提供開始】プラットフォームログを直接Sentryへ
Article by: Allison Rogers, Paul Jaffre Sentry は Log Drains に対応しました。これにより、アプリケーションコードの変更や手動でのプロジェクトキー検索をすることなく、簡単にログを Sentry へ転送できます。すでに別の場所にログがある場合でも、コード変更なしで、Sentry上でエラーやトレースと並べて確認できるようになりました。 すぐに試したい方は、クイックスタートガイド をご確認ください。 ログを1か所に集約し、Issue のコンテキストと関連付ける 2025年9月に Sentry で Logs を一般提供した際の目的は、ログ、トレース、エラー、リプレイを単一のプラットフォームで確認できるようにすることでした。そしてフィードバックで特に多かったのは、「適切なログが適切な Issue にデフォルトで紐づいていてほしい」という点でした。 「Sentry をアプリに統合したところ、急に「もうひとつ目が増えた」ように感じています。私たちは Logs にも活用していて、デバッグが大幅に楽になりました。Sentry がエラーを報告すると、関連するログがその場ですぐに確認できます。もうひとつ大きな利点は、各ログエントリにユーザー情報が自動でタグ付けされることです。そのため手作業で付ける必要がありません。」 Log Drains を使用することで、プラットフォームのログ（およびトレース）が自動的に Sentry に流れ込み、アプリケーションコード外のプラットフォームレベルのイベントにも「もうひとつの目」が届くようになります。 「例を見せてほしい」と思った方は DevEx チームが Sentry で Vercel ログについて説明する動画をご覧ください。 アプリケーションのエラーやトレースと一緒にプラットフォームのログを一箇所に集約することで、チームはビルド、デプロイ、エッジランタイム、データベース、認証レイヤーにわたるシステムの動作を全体的に把握できます。追加のエージェントを実行したり、アプリケーションコードに触れたりする必要はありません。 ダッシュボードを行き来したり、ログの保持期限が短いせいで大切な情報を失ったりすることなく、エンジニアは Sentry上でエンドツーエンドに問題を調査できます。 今すぐ始める：すべてのプランで5GBのログが含まれています（追加分は1GB$0.50）。 チームはどのように Log […]
Sentryでマイクロサービスと分散システムを監視
Article by: Richard C. 5つのサービス、キュー、そして自分が所有していないデータベースに触れるリクエストをデバッグしようとしたことがあるなら、分散システムの監視がなぜ難しいのかはすでにご存じでしょう。 ログはそれぞれ別の場所に存在し、リクエストはフローの途中で見失われ、そして本番環境で何かが壊れると、断片から何が起きたのかを再構成することになります。 マイクロサービスは設計上これをさらに悪化させます。1つのリクエストが、小さく独立してデプロイされる複数のサービスへと広がり、しばしば非同期にやり取りします。そして、リクエストが自分が管理しているサービスを離れた瞬間に、可視性は通常、急激に落ち込みます。 このガイドでは、Sentry のトレーシングとロギングを使ってリクエストをエンドツーエンドで追跡し、本番環境では通常あまりに時間がかかりすぎる次の疑問に答えられるようにする方法を紹介します。 このリクエストは実際にどこへ行ったのか どのサービスが遅延させたのか、あるいは失敗したのか ログを手作業でつなぎ合わせずに、それをどうやって確認すればよいのか 前提条件 マイクロサービスの経験は不要です。この記事を理解するうえで、Web サービスを書いた経験があると役立ちます。 チュートリアルに沿って進めるには以下が必要です。 Docker：サンプルアプリの実行に Docker を使用します。Docker を使うことで、プログラミング言語の各種バージョンをインストールしなくても、どのOSでもアプリが動くことが保証されます。また、個人ファイルから安全に隔離されたセキュアなサンドボックス内で実行できます。 Sentry アカウント：サンプルアプリケーションを Sentry のプロジェクトのいずれかに接続したい場合、Sentry アカウントが必要です。 また少しわかりやすくするために、実行が必要な操作には ▶️ を付けています。 サンプルケーススタディ この例は意図的にシンプルにしていますが、実際のシステムはもう少し複雑です。 ただし失敗の起こり方は同じです。リクエストは複数の先へ広がり、処理は非同期に進み、何かが壊れると元のコンテキストはたいてい失われています。 では簡単な例を使って、マイクロサービス設計がどのように、そしてなぜ機能するのかを確認しましょう。たとえば、ユーザーが「作る必要のある商品」を注文できるウェブサイトがあるとします。商品は物理的な3Dプリントの物体から、デジタルの納税証明書まで、何でもあり得ます。 現時点ではプロセス全体を処理し、すべてのデータを1つのデータベースに保存するモノリシックな Web サーバーがるとします。 設計は次のとおりです。 ウェブサイト、注文管理、そして商品の製造（工場側）をそれぞれ別のチームが担当しており、各チームはシステム全体を壊さずに、自分たちのコードやデータベースのテーブルに対する改善を独立してデプロイしたいと考えています。 そこで単一のサービスとデータベースを3つの独立したサービス（web、order、factory）に分割することにしました。 システムは次のようになります。 各サービスは他のサービスのアドレス（URL）を把握しています。たとえば order サービスが factory サービスに商品の製造開始を依頼したい場合、order サービスは HTTP の POST […]
正常に見えるダッシュボードに潜む危険信号
Article by: Milin Desai 最近、ある企業の開発責任者（会社名は出せないのですが）からこんなふうに言われました。 「あなたのおかげで、本当にユーザーに影響を与える問題を見つけて解決できました。次は、それが標準的な SLO やシステム指標よりも重要だということを CTO に納得してもらう必要があります。」 CTOがシステムと基本的な稼働時間を測定するのは間違いではありません。ただ、それは基準線にすぎません。だれもがあらゆるものを監視しようとしていますが、ユーザーに関係することについては何も見えていないのです。 従来型モニタリングの罠 稼働率は素晴らしい。レイテンシはSLOの範囲内。エラーバジェットも問題ない。ダッシュボードは緑一色。 それでも、ユーザーはまだ失敗しています。システムが落ちているからではありません。システム自体は問題ないのです。けれども「ユーザーがボタンをクリックする」から「ユーザーが欲しかった結果を得る」までのどこかで、何かが壊れました。静かに。 アラートは出ない。しきい値も超えない。ただ、ユーザーが諦めて離脱しただけです。 コードは壊れます。そこが問題の核心ではありません。問題は、それが3週間後に発覚することです。大口の顧客が苛立って離脱しそうになり、営業チームがエスカレーションして初めて分かるのです。 マネーモーメント どのプロダクトにも「マネーモーメント」がいくつかあります。ユーザーが成功できるか、あるいは収益を失うかを左右する、プロダクト内の特に重要なポイントです。「APIは落ちていないか」でも「ページは読み込めたか」でもありません。ユーザーが本当にやりに来た「その行為」のことです。 最近聞いた例をいくつか挙げます。 ある小売企業はブラックフライデーを完璧な稼働時間で乗り切りましたが…コンバージョン率が12%も下がってしまいました。マネーモーメントである「購入手続きの完了」が、特定のブラウザ拡張機能を使っているユーザーで機能していませんでした。サーバーエラーはなし、アラートもなし。3週間分の売上を失いました。修正にかかったのは1時間ですが、問題に気づくまでには非常に長い時間がかかりました。 ある決済企業はすべてのSLOを満たしていましたが…顧客から「ランダムに失敗する」という苦情がありました。マネーモーメントである「送金が実際に完了し、確認まで終わること」が、国際送金では断続的に失敗していたのです。原因はタイムアウトのエッジケースで、ダッシュボードには平均値しか表示されていませんでした。影響を受けていたのはユーザーでした。修正は6行のコードで済む内容でしたが、何か月分ものノイズの下に埋もれていました。 あるB2Bプラットフォームはどの指標でも健全に見えていましたが…ところが、マネーモーメントである「新規顧客が“なるほど”と実感する瞬間」が、特定の設定を持つエンタープライズアカウントで壊れていました。監視より先に営業がそれを見つけました。ダッシュボードはどれもシステムが「稼働中」だと言っていましたが、プロダクトは壊れていたのです。 毎回、同じパターンです。 測っている対象が間違っています 違いはこうです。 多くのチームが測っていること すべてのサービスは動いているか 指標はしきい値の範囲内か システムは健全か 本当に重要なこと ユーザーは目的を達成できたか できていないなら、どのコードが壊れたのか どれだけ早く直せるか 前者は横方向です。あらゆるものを監視して、何かを拾えることに期待する。 後者は縦方向です。マネーモーメントをエンドツーエンドで追う。壊れたらすぐに分かる。リリースまでたどる。修正する。 両方を行うこともできます。もしダッシュボードが緑でもユーザーが失敗しているのであれば、何が欠けているかがわかります。 実践するべきこと 複雑ではありません。 マネーモーメントに名前を付けましょう50もの異なるフローではなく、プロダクトが機能するかどうかを左右する3〜5つのポイントを特定してください。ユーザーにとって重要で、彼らが目的を達成できるかどうかを左右する瞬間です。ユーザーが成功する瞬間、離脱する瞬間はどこでしょうか。 セグメント別に監視しましょう平均ではなく、顧客ティア別、地域別、デバイス別、リリース別です。最大の顧客を混乱させるバグは、集約されたメトリクスには現れません。 リリースと結びつけましょうマネーモーメントが失敗した場合、最初にすべき質問は「何が変わったか」です。数分で答えられないようであれば、目を閉じたまま飛んでいるようなものです。 アラートまでの時間ではなく、修正までの時間を測りましょう誰もダッシュボードがどれだけ早く真っ赤になったかには関心がありません。壊れたコードをどれだけ早く発見し、修正をリリースできたかが重要です。 […]
本番環境で大規模データセットをページネーションする：OFFSETの限界とカーソルの利点
Article by: Lazar Nikolov 、Ben Coe MVP（Minimum Viable Product）と本番環境に耐えるアプリアプリを分ける要素は、仕上げ、最終調整、そしてパレートの法則で言うところの「最後の20%」の作業です。多くのバグやエッジケース、パフォーマンス問題は、リリース後にユーザーの殺到でアプリケーションに大きな負荷がかかったときに表面化します。この記事を読んでいるあなたは、おそらく80%地点にいて、残りを片付ける準備ができているはずです。 この記事では、大規模データセットをスケール環境でページネーションする際に、どこで問題が起こり得るのか、そしてデータベースのインデックスが結果をどう左右するのかを見ていきます。 本番の洗礼（ローンチ後の現実） テスト中はすべて順調でしたが、しばらくするとページの読み込みに時間がかかるようになりました。 このような状況に備えて、Sentry をローンチ前にセットアップしておくことをおすすめします。カスタムのインストゥルメンテーションを何もしなくても、データベースクエリが遅くなったときに Sentry が知らせてくれます。 スクリーンショットには、Sentry での Slow DB Query の問題が表示されています。Drizzle ORM と node-postgres を使用したおかげで、Sentry は自動的にすべてのデータベースクエリを計測してくれました。このテレメトリデータによって、Sentry は遅いデータベースクエリを検出して表示できます。 少しスクロールすると、リクエスト情報が表示されます。 ここから分かることは次のとおりです。 クエリは GET /admin/tickets リクエスト内で実行されています。 OFFSET を含むため、オフセットベースのページネーションです。 実行されたのは 321 ページです。 実行時間は3.85秒でした。 Seer はインデックス不足の可能性が高いと推測しています。 では、実際にインデックスが不足しているのか確認しましょう。 Seer の言った通りでした！大規模なデータセット、データベースインデックスの不足、そしてオフセットベースのページネーションの組み合わせがこの問題を増幅させています。 データベースにインデックスがなく、かつページネーションがオフセットベースのため、今回のように321ページのような高いページ番号に移動すると、データベースは 321 × page_size 行 […]