Trace Explorer でスパンからメトリクス、グループ、アラートを取得する方法
Article by: Will McMullen どこかで、わずかに引っかかるアプリを開発した経験は、誰しも一度はあるでしょう。あるいは、どうしてもうまく最適化できないクエリに悩まされたことがあるかもしれません。Chrome の DevTools にあるネットワークウォーターフォールでは、その裏側で実際に何が起きているのかを完全に把握することは困難ですし、OTelによるトレーシング（正直に言えば、Sentryでのトレーシングも）も、やはり難解でした。 しかし本日から状況が変わります。私たちはトレーシングデータのための全く新しい Explore ビューをリリースしました。これにより、スパンデータを分類、絞り込み、並べ替えることで、パターンや具体的なトレース事例をこれまで以上に容易に見つけ出すことができます。 また、デフォルトまたはカスタムのスパン属性を使って、pXX（パーセンタイル）などのスパンベースのメトリクスを作成し、それをもとにアラートやカスタムダッシュボードウィジェットを構成することも可能となりました。 さらに、スパンをタイムスタンプ順に並べ替えることが、ついに可能になりました。ただし、これだけではありません。さっそく詳細を見ていきましょう。 ※この機能は Sentry のアーリーアダブタープログラムに参加しているすべてのセルフサーブ（自己登録）ユーザーに提供されています。まだ参加していない場合は、Sentry の設定画面から有効にしてください！ Sentry の Trace Explorer における新機能 アプリケーションがますます複雑化する中で、わずかなパフォーマンスの低下でも深刻なユーザー影響を引き起こす可能性が高まっています（最終的にユーザーの離脱という深刻な事態につながることもあります）。遅延の原因を簡単に特定できず、それを特定のサービス、エンドポイント、API、あるいはデータベース呼び出しに関連付ける手段がなければ、生のトレースデータを注意深く確認する（最悪の場合はログを手作業で確認する）必要があり、複数のツールに分断された断片的なデータを手動で追いかけることになります。 このような課題を解決するのが、新しい Trace Explorer です。スパンデータの活用方法が大幅に刷新され、以下の機能が追加されました。 スパンベースのメトリクススパン属性を集計し、p95(measurements.lcp) のようなメトリクスとして扱うことができます。これにより、パフォーマンスにおける境界ケースの検出や、大量の API ペイロードの追跡、さらにはアラートやダッシュボードの設定が可能となり、アプリケーションのシグナルを常に把握できるようになります。 クエリ可能なカスタム属性token_usage、region、cart_value など、アプリケーションに関連するカスタム属性をクエリおよび測定することが可能です。これにより、共通パターンを特定し、ユーザーにとって最も重要な体験に焦点を当てたアラートやダッシュボードを設計できます。 アクションにつながる Trace Explorerスタック全体にわたるトレースデータを迅速にフィルタリングおよびグループ化し、クエリを保存・共有することができます。「なぜチェックアウトページの読み込みが遅いのか？」といった問いに即座に対応できるだけでなく、どのユーザーが影響を受けているかもすばやく把握できます。 これらの機能は、パフォーマンスモニタリング・アラート・ダッシュボードの高度なセットアップを素早く構築できるように設計されており、トレースデータの価値を最大限に引き出すことができます。しかも、最小限のコストと構成で実現可能です。 技術的に見ても非常にスマートな仕組みですが、実用面においてはさらに高い効果を発揮します。ベータ版で多数の企業と連携を行う中で、以下のような代表的なユースケースが明らかになりました。 CDN画像のパフォーマンス分析image_url や cdn_provider のような属性を付加し、プロバイダー別に画像の遅延を並べ替えて分析できます。事前のメトリクス変換や処理は不要であり、クエリ実行時に動的に処理できます。 AI消費量の追跡APIコール数、トークン使用量、モデル名などを測定可能です。スパイクが発生した際には、対象のトランザクション、ユーザー、環境、リポジトリを正確に特定できます。 ECサイトにおけるチェックアウト追跡cart_value や payment_method といった属性を用いてチェックアウトフロー全体を追跡できます。これにより、高額な取引でパフォーマンスが遅延しているケースを特定し、即座にトリアージすることが可能です。 新しい Trace Explorer でスパンメトリクスを設定・活用する 1：重要な箇所にコードを計測挿入する（インストゥルメントする） Sentry […]
Javaにおけるロギングとデバッグのガイド
Article by: Abdul D なぜロギングとデバッグが重要なのか？ プログラムの開発中、プログラムの実行フローを追跡し、コード内の問題を特定するために、単純な println() ステートメントを使っているかもしれません。しかしプロジェクトが大きくなり、複雑になるにつれて、プリント文はすぐに散らかってしまいます。プログラムの実行を追跡するためのより良い方法はロギングです。ロギングはアプリケーションの動作を一貫して整理された方法で追跡する手段を提供し、問題を体系的に特定し、解決できるようにします。 このガイドでは、Java でのロギングの設定方法、基本的なデバッグツールを効果的に使用する方法、そして安定した保守可能なアプリケーションを作成するためのベストプラクティスについて探ります。 また、Sentry が Java アプリケーションでエラーを監視し管理する手助けをどのようにするかについても見ていきます。基本と合わせて、高度なテクニックを理解することで、Javaプロジェクト内の問題に自信を持って取り組むための準備が整います。 Java でロギングを設定する方法 もしかするとコードのロギングとデバッグのために System.out.println() を使用したことがあるかもしれません。 次のように出力されます。 Debugging: Starting the programDebugging: Result is 8 このようなコンソールロギングは、小規模なプロジェクトや簡単なテストには役立つことがありますが、いくつかの制限があります。保存されていないコンソールログはプログラムが停止すると消えてしまい、何が起こったのかの履歴を保持することが難しくなります。また、ログメッセージを重要度別に分類することができず、出力結果で重要な問題を見逃しやすくなります。 Javaでの基本的なロギングは、組み込みの java.util.logging パッケージを使用することで実現できます。この組み込みフレームワークを使用すると、アプリケーション内で情報メッセージ、警告、エラーなど、さまざまなイベントを簡単に記録して出力できます。 java.util.logging を使用すると、各メッセージの重要度を示すためにログレベルを指定できます。 SEVERE：アプリケーションが正しく動作しない可能性のある重大なエラーを示します。 WARNING：注意が必要な潜在的な問題を示します。 INFO：アプリケーションの実行進行状況に関する一般的な情報を提供します。 CONFIG：設定関連のメッセージを示します。 FINE, FINER, FINEST：デバッグ目的で詳細な情報を提供します。 これらのログレベルは次の構文を使って使用できます。logger.<LEVEL>(“<YOUR_MESSAGE_HERE>”) ロギングを有効にするには、module-info.java ファイルに以下を追加する必要があるかもしれません。 requires java.logging; 以下はロガーを設定し、異なるレベルでメッセージをログに記録する方法です。 以下が出力されます。 ロギング例の出力 ログメッセージがタイムスタンプで記録され、ログステートメントが呼ばれたクラス名とメソッド名が含まれている点に注目してください。この情報は、複雑なアプリケーションでバグを追跡する際に非常に貴重です。 Javaでのログレベルの設定 上記の例では、INFO、WARNING、SEVEREメッセージのみがログに記録され、CONFIG と FINE メッセージは記録されていないことに気付くかと思います。 これはデフォルトのログレベルが […]
Sentry と Pinia との組み合わせで、Vue と Nuxt のエラートラッキングを強化する方法
Article by: Steven Eubank 本番環境で問題をデバッグする際に大切なのは、その瞬間のコンテキストです。 Sentry はすでにスタックトレースやパンくずリスト、ユーザー情報などの豊富なエラーデータを提供していますが、エラーが発生した時点でアプリケーションがどんな状態だったのかまでが分かれば、再現手順や修正方法が迅速に得られ、リリースに大きく役立ちます。 Sentry の Pinia 統合は、まさにそれを実現してくれる機能です。エラーが発生した時点で Pinia の状態を自動的にキャプチャするため、Vue または Nuxt アプリケーションでどんな問題が発生したのか詳細まで把握できます。 それでは、Vue および Nuxt アプリケーションで実際に導入する手順を確認していきましょう。 Sentryでショッピングカートの不具合も素早くデバッグ Pinia のパイナップルロゴ🍍にインスパイアされた「Pineapple Paradise」というオンラインストアを例に挙げてご紹介します。 この Vue アプリでは、Pinia を使ってショッピングカートの状態を管理しています。 オンラインストアが期待通りに動作する方法を模倣していて、ユーザーは商品を閲覧し、ショッピングカートに追加します。アプリの状態管理は全て Pinia が担っています。 以下はショッピングカートの状態を管理するコードのシンプルな例です。 Vue アプリに Sentry と Pinia の統合を追加する Sentry のPinia統合をセットアップするのは、他のフレームワークと同様にとても簡単です。 main.js ファイルで、Sentry Vue SDK をインポートし、必要なオプションで init メソッドを呼び出し、次に pinia.use(createSentryPiniaPlugin()) を呼び出すように追加すれば完了です。 以下はその例です。 アプリの状態から不具合のコンテキストを見つける 例えば今、ユーザーが好きなパイナップル関連の商品でチェックアウトしようとした瞬間、サイトがクラッシュして購入を諦めてしまったとします。 このとき関連するすべてのコンテキストと共にエラーイベントが Sentry に自動送信され、次のような情報が記録されます。 […]
モバイル向けセッションリプレイが一般公開！ユーザー体験を簡単に改善する方法を徹底解説
Article by: Jasmin Kassas, Sarah Guthals モバイル向けセッションリプレイがついに一般公開されました。 セッションリプレイの偉大さについて大袈裟に語ることもできますが、今回は趣向を変えて、A…I…があなたのために一句詠みます。 画面が固まる 開発者はため息 リプレイ明かす犯人は…… .addListener 忘れていた 俳句になっているかどうかはさておき、要するに Sentry はユーザーの操作を動画のように再現できるため、どのデバイスで問題が発生しているのか、他の端末を使って再現確認しなくても、不具合の箇所や体験が途切れているポイントをすぐに確認できます。 今どき iPhone 12 Mini が家に転がっている人なんてそうそういませんよね？少なくとも、私たちの手元にはありません。あなたのところはいかがですか？ さて、本題に移ります。もし実際の問題をセッションリプレイでどのようにデバッグできるのか知りたい方は、この先をご覧ください。そうでない場合は、iOS、Android、Flutter、React Nativeのセットアップ方法をまとめたドキュメントをぜひご覧ください。 セッションリプレイでどう解決するのか 奇妙なバグの通知を受け取り、クラッシュダンプを見てもなぜユーザーがその状態に至ったのかわからなかった… 開発者であればそんな経験はよくあるでしょう。 その度に状態を把握するためランダムなログを無闇に差し込み、それを再リリースしてユーザーにアップデートを強制するも的が外れてまたやり直し… そんなことを繰り返していませんか？ しかしセッションリプレイならそんな手間を省くことができます。エラーや操作の流れも含めて確認することができるため、ユーザーがエラーに至るまでに何をしていたのかが正確に確認できます。 ここからは、過去6ヶ月間のベータ期間に Sentry のお客様が実際に体験された事例をご紹介していきます。 モバイルアプリの状態を正確に把握する モバイルアプリは実にさまざまな形式があり、その多くは複雑なUIフローや状態を保持しています。セッションリプレイを使用することで、アプリがどのような状態なのかを正確に把握することができ、問題の原因になっているUIフローを見つけることができます。 以下の画像のように、バックエンドのエラーも含めて全体像を掴むのにとても役立ちました。 セッションリプレイがなければ、問題が起きた時の再現手順を特定するのに不要な手間がかかります。これは複雑な条件（手順や状態）をデバッグする際に特に役立ちます。 バックエンドのエンドポイントエラーにも対応 ユーザーがどのような操作をしていたか分からない状態で、サーバーのエラーをデバッグするのは本当に骨が折れます。 しかしセッションリプレイを使えば、エンドポイントに到達するまでのユーザー操作をそのまま見ることができます。またタイムラインビューを使うことでサーバーエラーが発生した正確なタイミングに一瞬でジャンプすることもできます。 とあるお客様の事例を挙げると、アプリがフォアグラウンドに戻った際にプロフィールを更新しようとして、400エラーが発生していたことがありました。 原因はその時点でユーザーがログアウトしていたからでした。修正はシンプルで、今では AppState イベントを監視しユーザーがログアウト状態ならすぐにログイン画面へリダイレクトするように修正しています。 モバイル特有の問題も見逃さない セッションリプレイのパンくずリストを使えば、ユーザーの操作履歴とともにデバイスに関する重要な情報も取得できます。どの瞬間に、どのような操作や理由によって問題が起きたのかを正確に特定します。 例えば「コードに問題はなかったのに、ネットワークが突然切れてオフラインになったこと」が原因だった（調査する開発者にとっては、これほど最悪なケースはありません）としても、セッションリプレイを見れば一目瞭然です。 このパンくずリストは、従来のログでは見えない部分に光を当ててくれる貴重な手掛かりになります。 モバイル向けセッションリプレイ導入手順 セッションリプレイをアプリに組み込むためのステップは以下の通りです。 […]
【Sentry Profiling】Autofix の遅延問題をどのように解消したのか徹底解説
Article by: Rohan Agarwal プロファイリングと聞くと「インフラコストをスケールに応じて最適化するためのわずかな節約に役立つもの」という誤解を抱いている方が多くいらっしゃいます。いわゆる「ミリ秒単位での削減が全て」というアプローチだと思っていないでしょうか。 しかし実際はそうではありません。私たちは自社のプロファイリングツールを使用し、ユーザーインタラクションを各セッションにおいて数十秒単位の時間短縮を可能にしました。数学がお好きな方のために補足すると、それは「重要なミリ秒」どころか、4桁も大きく異なる数値でした。 この記事では、私たちがどのような課題に直面し、何を発見し、どのようにして解決に至ったのか解説します。そしてプロファイリングが単なるミリ秒の削減にとどまらず、なぜパフォーマンスや顧客体験の向上に欠かせない存在なのかについてもご紹介します。 処理速度は、開発者にとってもユーザーにとっても重要 私たち Sentry 開発チームは、デバッグワークフローの改善に一貫して取り組んできました。 その中で「生成AIを活用するなら、 Autofix というツールを作るのが最適だ」と考えました。Autofix は問題の詳細とコードベースを密接に統合させ、課題の文脈を理解した上で解決策を導き出すツールです。完全に独立して動くのではなく、開発者と一緒に作業しながら根本原因を特定し、正確なコード修正を提案するという少しユニークなアプローチを取っています。 Autofix の本来の目的は「デバッグを速くすること」でしたが、実際に使用してみるとどうにも遅いと感じていました。特にコールドスタート時は鈍く、通常よりも10〜20秒以上も余計に時間を要し、こうした遅延は私たち開発チームだけでなく、初期導入されたお客様にも影響を及ぼしていました。 このままでは Autofix を世に出しても中途半端なものになってしまうのではないかという危機感が高まっていました。何としてもローンチまでにパフォーマンス課題を解決しなければなりません。とはいえ、AI駆動のワークフローをデバッグするのは困難です。 問題はサードパーティのLLMプロバイダーからの遅延応答が原因なのだろうか。だとすると、設計そのものを変更しなければなりません。それともタスクキュー（Celery）が非力なインフラでボトルネックになっているのか… 仮説を確かめるには大掛かりな調査が必要となり、もし仮説通りだったとしても、その対応にはアーキテクチャ全体を見直すような大規模改修につながります。いずれにしても大変です。 そこでふと考えました。 「もしかすると、私たちがすでに持っている可視化データの中にヒントがあるのでは……？」 そこで登場したのが Sentry Profiling です。早期導入ユーザーの実際のデバイスから実行データを分析することで、思いがけない2つのボトルネック、「冗長なリポジトリ初期化」と「インサイト生成中の不要なスレッド待機」を明らかになりました。これらに対し、キャッシュの導入とスレッドの最適化を行ったことで、実行時間は数十秒短縮され、Autofix は大きく向上しました。しかも、アーキテクチャには一切変更を加えていません。 プロファイルとは？どのように活用すればいい？ もしすでにご存知であれば、ここは読み飛ばしていただいて構いません。念のため、初めての方に向けて簡単に説明します。 プロファイリングとは、関数の呼び出しや実行時間、リソース使用状況などの情報を本番環境でリアルタイムでキャプチャし、実際のユーザー体験に影響しているCPUやブラウザレベルのパフォーマンス課題を特定するための手法です。 CPUプロファイリングはCPUサイクルがどこで使われているか追跡し、非効率な関数や不要なループ、重たいブロック処理などを見つける際に役立ちます。またブラウザプロファイリングは、主にフロントエンドに焦点を当て、ページの読み込みやレンダリングの遅延、長時間実行されているレンダリングタスクなどの情報を取得することが可能です。最後にモバイルプロファイリングは、ネイティブおよびハイブリッドアプリの画面表示などのパフォーマンスを分析します。 これらのデータは全て「フレームグラフ」として視覚的に表示され、時間経過とともに変化するコールスタックの様子を確認できます。最初は少し慣れが必要になるかもしれませんが、以下のように読み取ることができます。 X軸（時間）：コード実行のタイムラインを示します。各ブロックの幅は、関数呼び出しの時間の長さを示します。 Y軸（コールスタックの深さ）：関数呼び出しの階層を示し、コードレベルでの関数間の親子関係を示します。 カラーコード：Sentry ではアプリケーションコード、システムコード、シンボル名、パッケージなどに色分けがされており、それぞれを直感的に識別できます。 さらにプロファイルは分散トレースと組み合わせて表示することもできるため、ブラウザ、クライアントCPU、ネットワーク呼び出しの流れをひと目で把握できるようになります。Sentry では個別のプロファイル（単一トランザクションのプロファイル）、集約されたプロファイル（平均的な処理の傾向）、差分プロファイル（コードの変更前後の比較）といった形式でパフォーマンス問題を素早く特定できます。 プロファイリングを有効にするには、アプリケーションの起動時にSDKをできるだけ早く初期化し、profiles_sample_rate オプションを 1.0 に設定することでサンプリングされたトランザクションをキャプチャできます。 例えば、Pythonアプリでは次のように設定します。 問題1：コールドスタートに時間がかかる 問題 Autofix の目的は、アプリケーション内のバグについてできるだけ早く開発者にインサイトを提供することです。しかしルートコード分析を行ったり、コード修正を提案したりするたびに数秒もの明確なスタートアップの遅延が発生し、その後も長時間の処理が続いていました。 これでは最先端のAIエージェントとしては動作が重く、時代遅れに感じられてしまいます。この状況が改善されなければ、開発者はワークフローへの不満を抱き、Autofix が低く評価されてしまう恐れがありました。 […]
【Visual Studio App Centerが廃止】次に Sentry を勧める理由を解説
Article by: Sarah Guthals Visual Studio App Center が廃止されることは以前から知っていました。正式な廃止日が2025年3月31日と発表され、いよいよカレンダーを見ると2025年。そろそろ App Center の代替案を選定し、他のツールへの移行準備を本格的に進めるべき時期が迫りました。 *なお、Microsoft は App Center Analytics & Diagnostics 機能に限り、製品サポートを2026年6月30日まで延長する予定です。ただし App Center の他の機能については 2025年3月31日で提供が終了します。移行には綿密な計画と手間がかかりますので、早めに対応を進めることをおすすめします。 この記事ではスムーズな移行に役立つガイドをお届けします。他の参考リソースへのリンクも盛り込んでいますので、ぜひご活用ください。 Visual Studio App Center からの移行方法 Visual Studio App Center にはモバイル開発者がよく利用していた5つの主要な機能がありました。それはクラウドベースのビルド、デバイステスト、配布、コードプッシュ、そして分析＆診断です。 これらの機能にはそれぞれ推奨される代替ツールがありますが、チームにとってどのツールが最適かを慎重に見極めることが重要です。機能の違いはもちろん、ツールの互換性、API や拡張性、さらにはユーザーエクスペリエンス（UX）も移行のしやすさを大きく左右します。 以下では、App Center の各機能ごとに推奨される代替ツールをご紹介します。 クラウドベースのビルド：App Center では、iOS や Android アプリをクラウド上でビルドいる機能が提供されていました。 代替として、Ionic をおすすめします。Ionicは、Cordova や Capacitor、React Native といったフレームワークで開発されたアプリを複雑な手順を踏むことなく、iOS および […]
SentryのRollback、Hack Week発のプロジェクトが本番稼働へ
Article by: Malachi Willey ❗❗もしあなたが Sentry を使っていて、今が2024年なら、今すぐ読むのを止めて、まずは rollback.sentry.io にアクセスしてみてください。自分専用のRollbackが手に入ります！ ほんの数週間前、私たちは Sentry Rollback という機能をリリースしました。 これは Sentry で初めてとなる「年次レビュー体験」です。 イメージとしては、Spotify Wrapped（Spotifyが毎年行っているユーザーの音楽の好みをハイライトする機能） の開発者版のようなもので、Sentry を通して過ごした1年を振り返ることができる独自の機能です。 見た目はスタイリッシュで、ちょっと（というか、かなり）皮肉も効いています。あなたの成果をしっかり称えながら、ついでに失敗も軽くあざ笑います。成功というのは、失敗の上に成り立ちますからね。 Rollback の起源は少しユニークです。最初は社内向けに「何か面白くて笑えるものを作ろう」という軽い気持ちからスタートしました。しかしそれが、気が付けば本格的なプロジェクトに成長していました。今回は、その歩みをご紹介していきます。 クエリ結果が得られないことに何度も悩まされたのではないでしょうか。私たち自身もその例外に何度も頭を抱えた結果、ついに修正することに踏み切りました。 始まり：Rollback のアイデア誕生 毎年、Sentryでは社内ハックウィークを開催しています。これは Sentry 社員全員が普段の業務から離れ、自分の「作りたいもの」に自由に取り組む1週間です。ルールは「何を作ってもOK」ただ一つ。「こんなものがあったらいいのに」と思ったら、それを作るだけです。 多くのハックウィークのプロジェクトは、その週が終わると役目を終えますが、中には社内で使い続けられるものもあります。そして時々、本番環境に飛び込すプロジェクトが生まれることがあります。Sentry Rollback はその一つでした。 チーム編成から始まった Rollback ほとんどのハックウィークのプロジェクトは、エンジニア同士が数人集まってチームを組んで進めます。同じチーム内で完結することも少なくありません。 しかし、Rollback は違いました。エンジニアリング、プロダクト、マーケティング、デザイン、さらにはセールスコピーまで、社内全体から人が集まり、Sentry 全体で取り組む「全社プロジェクト」となったのです。 多様な視点が加わったことで、Rollback はごく初期の段階から「まるで本物のSentryの製品（TM）」のような完成度を見せはじめました。なぜなら、必要な要素がしっかり揃っていたからです。 出荷とクラッシュ、そして再スタート… Rollback Rollback を他の年次レビューと差別化するため、まず取り組んだのは名前を決めることでした。私たちはあまり堅い印象になりすぎないようにしているので、ちょうどいいユーモアのある名前が必要だと考えました。 利用者ターゲットの99%がエンジニアのため、開発者の心に響く名前でなければなりません。Sentry Replay、Sentry Shipped、Sentry Wreckedなどのアイデアが出ましたが、最終的に「Rollback」に決定しました。 「Rollback」という名前は、まるで過去に戻って1年分のバグを再体験するようなイメージを呼び起こします。開発者がひと目見て、直感的に理解できるネーミングです。 今年、あなたも一度は“ロールバック”したのではないでしょうか？私たちはもちろんしましたよ！ MVPを最速で作ることから始める ハックウィークの限られた数日間で、Rollback のような体験を作るのは簡単なことではありません。 プロジェクトはチームを跨いで関わる部分も多いため、綿密な進行管理が必要でした。プロダクトマネージャーは、優先順位を理路整然と決め、初期のデザインやワイヤーフレームといった障害になりそうな要素を排除していきました。その結果、対象スコープも最小限になりました。 ハックウィーク版では、Sentry の従業員のために動作することだけに焦点を当てました。複雑なインフラ構成は避け、データベースも使わず、パフォーマンス最適化に悩む必要性もなくしました。ひたすらコンセプトの実証だけに集中し、クスッと笑える動作を目指しました。 ハックウィークの優勝者 […]
Sentryを活用したクエリのレート制限のデバッグ方法について
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: クエリが拒否される前に「警告ゾーン」で知らせる […]
アプリを高速化し、インフラコストを削減！サーバーサイドキャッシュの活用術
Article by: Will McMullen もし100ミリ秒未満の応答時間に驚いたことがあるなら、その背後には「キャッシュ」がある可能性が高いでしょう。 キャッシュは、システムのパフォーマンスを支える縁の下の力持ちです。よく使用されるデータを保存しておくことで、データベースやAPIへのアクセスを減らし、アプリの応答速度をミリ秒単位で短縮します。 今回はキャッシュがどのように機能するのか分解し、代表的な活用事例をご紹介していきます。 キャッシュとは？ キャッシュは、データの通り道に置かれる短期的な記憶装置のようなものです。よくアクセスされる情報を、時間のかかるデータベースや外部APIから毎回取り出すのではなく、すぐ使えるように一時的に保存しておきます。 動作の流れはとてもシンプルです。 最初のアクセス（キャッシュミス） まずアプリは指定されたキーに対応するデータがキャッシュにあるかをチェックします。なければ、アプリは時間やコストのかかる処理（たとえばデータベースクエリ）を実行し、その結果をキャッシュに保存してからユーザーに返します。 2回目以降のアクセス（キャッシュヒット） 次回、同じデータが必要になった場合は、データベースを介さずキャッシュから直接取得します。このルートは非常に高速で、ユーザー体験が一気に向上します。 キャッシュはスピード感のあるUXを実現したり、インフラの負荷を軽減したりするうえでとても頼れる存在です。理論上、どのようなデータもキャッシュできますが、特によく使われるのは以下のようなものが挙げられます。 コストの高いクエリの結果 「ユーザーXのカート情報」や「特集商品」のように、何度も同じ結果が返されるデータ 計算されたメトリクスや分析結果 毎回計算し直す必要がなく、元データが更新された時だけ再計算すれば良いデータ 静的アセット 画像やフォント、CSSなど、普段は変更されないものの頻繁に使用されるデータ それではキャッシュを設定して、実際にパフォーマンスのメリットを確認してみましょう。 PythonでシンプルなRedisキャッシュを設定する 「キャッシュと言えば Redis」と呼ばれるほど、世界中の開発者に使われている信頼性の高いオープンソースのツールです。 私が気に入っている説明は Simon Willison のワークショップで耳にした『Redis は素晴らしい小さなサーバー』というひと言です。Redis はインメモリで動く Key-Value 形式でデータを保持します。 またデータベースやキャッシュ、メッセージブローカーとしても使用されています。とにかく高速で効率的なことが特徴で、リアルタイムに動作することが求められるアプリケーションにピッタリです。 今回はこの Redis を使って、データベース呼び出しをキャッシュかすることに焦点を絞ります。Redis の導入で、たとえ開発用のノートPCでも 1秒あたり数十万件の処理をミリ秒単位で処理できるようになります。 メモリ上に保存するため高速ですし、キャッシュだけでなく永続性や原子性のあるストレージとしても活用できます。主要な SQL や NoSQL の負荷を軽くし、全体のパフォーマンス改善にもつながるというわけです。 Redis を導入するためにデータベースを移行したり設定を大きく変えたりする必要はありません。Pythonを使って PostgreSQL のキャッシュ層として […]
【VSCode + Sentry】Pythonのデバッグを快適にする方法
Article by: David Y. Sentry は開発者がバグのあるコードを迅速かつ効果的に修正できるよう支援しています。この記事では、VSCode と Sentry Python SDK を活用し、Python コードをデバッグするための中級から上級レベルのテクニックを幅広く紹介します。 Python デバッグの例 デバッグを行うには、まずバグのあるコードが必要です。 そこで今回は短い Python スクリプトを用意しました。このスクリプトは、外部の JSON ファイルからユーザーデータを取得し、内部のデータ構造に格納するといったものです。 こうしたコードは、メールニュースレター管理ツールにユーザーアカウントをインポートする際にも利用されることがあります。 このコードは、小規模で完璧にフォーマットされた users.json を使用した単純なテストケースで正常に動作します。しかし、管理されたテスト環境を離れると例外が発生する可能性が出てきます。考えられる失敗パターンは以下のとおりです。 users.json が存在しない users.json に無効な JSON が含まれている 一部のユーザーに必要なフィールドが欠落している 一部のフィールドのデータ方が想定と異なる 以下のセクションでは、さまざまなデバッグ環境を使用し、これらのケースを調査していきます。 実際に試しながら進める場合は、上記のコードをコピーしてシステム上の空のディレクトリに users.py というファイル名で保存してください（users.json は後ほど作成します）。 VSCode で Python をデバッグする方法 VSCode は、Python を含むさまざまなプログラミング言語で使用できるグラフィカルなデバッグインターフェースを提供しています。 まだ VSCode をインストールしていない場合は、こちらでインストールファイルと手順を確認できます。 以下では、VSCode のデバッグ機能をセットアップし、Python スクリプトをデバッグする方法 […]