【モンキーパッチはもう不要】Tracing Channels による、より優れたオブザーバビリティ
Article by: Sigrid Huemer ほとんどすべての本番アプリケーションは、さまざまなツールやライブラリを利用しています。たとえば、データベースやキャッシュと通信するためのライブラリ、あるいは Nest.js や Nitro のようなフレームワークです。本番環境で何が起きているのかを把握するために、アプリケーション開発者は Sentry のような APM（Application Performance Monitoring）ツールを利用します。 しかし、そこには本質的な問題があります。APM ツールが必要とするパフォーマンスデータは、多くの場合、ライブラリ自身からネイティブに提供されていません。そのデータ取得は、Sentry や OpenTelemetry のような APM ツール側へ委ねられており、それらが代わりにライブラリの重要な機能へインストルメンテーションを行っています。 インストルメンテーションとは？ アプリケーションを観測可能にするための最も基本的な要件は、その各コンポーネントや利用ライブラリをインストルメントできることです。インストルメンテーションとは、プログラム内部の動作を監視・分析し、診断データを生成するためのコードを追加するプロセスを指します。Sentry SDK や OpenTelemetry のインストルメンテーションは、まさにこの処理を内部で行っています。 たとえば、一般的な HTTP クライアントライブラリを考えてみましょう。アプリケーション開発者は、リクエストの開始と完了のタイミング、さらに URL、ステータスコード、ヘッダーといったメタデータを知りたいと考えます。 現在、ライブラリごとにこの対応方法は統一されていません。emitter.on(‘request’, …) のような独自フックを提供するものもあれば、リクエストを横取りするためのベンダー固有ミドルウェアを提供するものもあります。こうした場合、Sentry や OpenTelemetry は、オブザーバビリティデータを送信するプラグインを実装できます。 これは機能しますが、その負担はライブラリやフレームワーク側（たとえば Nuxt）にかかります。つまり、インストルメンテーション用 API を意識的に設計し、どこでそれを公開するべきかを判断しなければなりません。フックやインターセプタによって、適切な場所へオブザーバビリティコードを差し込める一方で、APM のメンテナーは、その API が将来にわたって安定して維持されることをライブラリ作者に依存しています。 さらに、共通規約も存在しません。ライブラリごとにフックの形もメタデータも異なるため、APM メンテナーはライブラリごとに大きく異なるプラグインを実装・保守し続ける必要があります。 サーバーサイド JavaScript はどのようにインストルメントされているのか JavaScript における従来のインストルメンテーション手法は「モンキーパッチ」です。これは、ライブラリのコードを実行時に書き換え、本来の処理に加えてオブザーバビリティデータも送信するようにする方法です。この手法が可能なのは、モジュールが変更可能で同期ロードされる CommonJS（CJS）環境に限られます。 […]
【Application Metrics】Unreal Engine のゲームパフォーマンスを監視する
Article by: Ivan Tustanivskyi あなたのUnrealゲームはエラーゼロの状態でリリースできたとしても、それだけで優れた体験になるとは限りません。戦闘中のスタッター、大型ボス戦での急激なフレームレート低下、マルチプレイヤーでのラバーバンディング。これらはいずれもクラッシュとしては現れず、Sentry にも表示されません。そのため、実際にプレイヤーが現場で何を体験しているのかを把握する手段がありませんでした。少なくとも、これまでは。 Unreal Engine には、ゲームパフォーマンスを測定し、実行時統計を収集するためのツールがすでに豊富に用意されています。しかし、そのデータはすべて開発者のマシン内に留まったままでした。 Unreal SDK の新しい自動パフォーマンスメトリクス機能は、このギャップを埋めます。FPS、フレーム時間、ネットワーク状態、そのほか一般的なゲームテレメトリを直接 Sentry に送信することで、どこでパフォーマンスが低下しているのか、どのハードウェアで発生しているのか、どのプレイヤーに影響しているのかについて、チームが実用的なインサイトを得られるようになります。Release & Health と組み合わせれば、各リリースが時間経過とともにパフォーマンスへ与える影響も追跡できます。 本題に入る前に、一点だけ触れておきます。すべてのゲーム開発者は、これまでに一度はプロファイラを使ったことがあるでしょう。自動パフォーマンスメトリクスはそれとは異なるものですが、関連するツールです。両者は同じ問題を異なるレイヤーから扱います。メトリクスは「どこでゲームが遅くなっているか」を見つけ、プロファイリングは「なぜ遅くなっているのか」を説明します。 Sentry が現在追跡するもの 現在、Unreal SDK は、全体的なパフォーマンスへ影響するいくつかの主要領域について、メトリクスを自動インストルメントします。対象には、フレーム時間、ネットワーク、ゲーム固有の統計などが含まれます。 フレーム時間 ゲームが快適に感じられるかどうかを最も直接的に示す指標です。フレーム時間は、「各フレームの処理にエンジンがどれだけ時間を使ったか」を示します。また、スレッドごとに分解することで、どのサブシステムがボトルネックになっているかを確認できます。 平均FPS 総フレーム時間 ゲームスレッド処理時間 レンダースレッド処理時間 GPUフレーム時間 ゲームスレッド、レンダリングスレッド、GPUの処理時間を比較することは、CPUがボトルネックになっているのかGPUがボトルネックになっているのか、そしてどのチーム（ゲームプレイ、レンダリング、コンテンツ）が修正を担当すべきかを判断する古典的な方法です。 FPSメトリクスの例（GPU別にグループ化） ネットワークインサイト マルチプレイヤーのパフォーマンスは、接続品質によって成否が決まります。しかし、クラッシュレポートだけではその状態を把握できません。これらのメトリクスによって、パケットロス、レイテンシ、帯域不足が、気づかれないまま体験品質を低下させていないかを確認できます。 送受信帯域幅 パケットスループットとパケットロス クライアントの ping と jitter アクティブ接続数 サーバービルドではさらに、ロードシェディング分析のために、クライアントごとの平均 ping、クライアントごとの帯域幅、飽和状態の接続数も取得できます（ネットワークメトリクスの完全な一覧を参照）。 これらのメトリクスは、マルチプレイヤーセッションがアクティブな間のみ存在します。ネットワーク機能を持たないシングルプレイヤーゲームでは、ここにデータは送信されません。また、一部の値はクライアント専用（ping、jitter）、あるいはサーバー専用（アクティブクライアント数、接続飽和）です。 Pingメトリクスの例 […]
【Sentry活用法】TTFB (Time to First Byte) を削減する方法
TTFB (Time to First Byte) とは、クライアントのHTTPリクエストからサーバーが最初のバイトを返すまでの時間を測定するための指標です。 TTFBが低いほど、サーバーの応答が速く、ページの読み込み時間が短縮されていることを表します。近年のWeb開発業界では、Webサイトをサーバー側でレンダリングする潮流が強まっています。 この方法はSEOに有利で、性能の低いデバイスでも快適にWebページを表示させるためユーザ体験を損なうことがありません。 しかし、このアプローチでは TTFB を犠牲にすることになります。 ページをビルド時に静的にプリレンダリングするのではなく、リクエスト時にサーバーで動的にレンダリングするため、ブラウザはサーバーからの応答を待つ時間が長くなります。その結果、TTFBが高くなり、TTFBが高いと他のWebバイタル指標も悪化します。 この記事では、TTFBが高くなる原因を特定し、それを改善する方法について探っていきます。 TTFBの測定方法 ここでは、サーバーサイドでレンダリングされたNext.jsアプリケーションを使用していると仮定します。 一部のページの読み込みが他のページよりも明らかに遅いことが分かったら、Chrome DevToolsを使用してどこで遅延が発生しているのか確認します。 残念ながら、ブラウザがサーバーからの応答を待つのに2秒以上かかったことはわかるものの、DevToolsではページ読み込みのタイムライン内で何がそれほど時間を要したのかを正確に測れません。 そのため、WebPageTestでテストを実行することを検討し始めるかもしれません。 問題があることは間違いない、ということはわかりますが、その原因は依然として不明なままです。 これらのツールは、ブラウザが見て感じることしか提示してくれません。 サーバーでの遅延が高いTTFBを引き起こしているため、ページを読み込む際にサーバーで何が起こっているのかを確認するには、別の種類のツールが必要です。それがトレース（Tracing） です。 トレース（Tracing）とは何か？ トレースは、パフォーマンスの問題をデバッグする際によく使用されるツールで、競合状態（race condition）などの複雑で奇妙なバグを見つけるのにも役立ちます。トレースは「スパン（span）」と呼ばれる最小の作業単位を作成します。 これらのスパンは互いにリンクされており、開始時間と終了時間を持ち、すべてが同じ「トレース」に属します。 測定したい関数やコードブロックを囲む形でこれらのスパンを作成します。また、使用するライブラリによっては、スパンが自動的に作成される場合もあります。この記事では、Sentry を使用します。 SentryはNext.jsと直接統合し、高いTTFBをデバッグするために必要なスパンのほとんどを自動的に作成してくれます。 トレースは「分散型」にすることも可能です。つまり、クライアント側でトレースを開始し、そのままシームレスにサーバー側のトレースを続行できます。これにより、クライアントとサーバーの両方で何が起こっているのかを1つのタイムラインで把握することが可能になります。 Sentryでは、このトレースとすべてのスパンを「フレームグラフ（Flame Graph）」と呼ばれる形式で視覚化します。 トレースに関する詳しい内容については「分散トレース：アプリケーションのデバッグとモニタリングのための強力な仕組み」で解説していますので、こちらをご覧ください！ Next.jsでSentryを使用してトレースを設定する Next.jsでSentryのトレースを設定するには、Sentryをインストールして構成するだけです。指示に従って設定を完了し、アプリケーションを実行すると、ページ読み込みのパフォーマンスデータがSentryに送信されるようになります。 このスクリーンショットから、ブラウザとサーバーの両方で何が起こったかを明確なタイムラインで確認できます。 getServerSideProps 関数が約500msかかっていることがわかります。この遅延の原因は、Cloudinaryへのリクエストであり、リソースが存在することを確認してからページをレンダリングするためのものです。 これを最適化できるでしょうか？ もちろん可能です。例えば、キャッシュを使用するか、リソースの存在を確認する別の（しかもさらに高速な！）方法を見つけることができます。 もし getServerSideProps 関数だけが原因であれば、最適化はこれで完了です！ しかし、今回はそれだけではありません。 getServerSideProps 関数が実行される前に、遅延の大部分が発生していることにお気づきでしょうか。 getServerSideProps 関数の前に、いったい何が実行されているのでしょうか？ 正解は『ミドルウェア』です！ ミドルウェアは自動で計測されないため、以下に示すコードを書いて計測を行う必要があります。 カスタム計測 こちらがミドルウェアの計測を行うための関数です。 まず認証を確認し、その後リクエストがフォトページ用かどうかを確認します。もしそうであれば、画像が存在するかどうかをチェックする関数を呼び出します（聞き覚えがありませんか？）。 次に、ロケールが正しく設定されているかを確認し、リクエストに追加のデータとタグを補完し、next() […]
【Sentry】TTFB(Time to First Byte)を減らし、ユーザ体験を改善する手法について
最近、私はただひとつの指標、TTFB（Time to First Byte）を改善することに集中することで、すべてのホームページのCore Web Vitalsを改善しました。 データを取得する方法に2つの小さな変更を加えるだけで、p75のTTFBを3.46秒から704msに短縮することができました！ （「p75」と「TTFB」については後述します） この記事では、私がどのように問題を発見し、それを解決するために何をしたのか。 そして、その過程で下した重要な決断について説明します。 Sentryパフォーマンス・モニタリングの使用 新しいサイトを立ち上げるとき、新機能を開発するとき、サイトが本当に遅いと気づいたときがありました。 2021年から22年にかけて、私はパフォーマンスを改善するためにWebサイトを一から作り直しました。 しかし時間が経つにつれ、私はサイトのさまざまな部分に実験的な技術をたくさん追加し、パフォーマンスが再び、恥ずかしくなるほど悪くなってしまいました。 ここ数ヶ月の間、Webサイトをロードしているときに私自身がこのことに気づいていましたが、Sentryパフォーマンス・モニタリングをサイトに追加したときに初めて全体像を見ることができました。 Sentryのようなパフォーマンス監視ツールを使用することの素晴らしい点は、OS、ブラウザ、モバイルデバイス、インターネット接続、その他ユーザーエクスペリエンスに影響を与える多くの要因すべてにわたって、Webサイトの実際のユーザーデータを表示してくれることです。 以前は、Google Lighthouseのようなツールを開発中やWebサイト構築中に使用して、新しいビルドごとにパフォーマンスを分析していました。実際のユーザーデータの方がはるかに価値があります。 Here’s what the performance looked like on my homepage before any modifications from February 14-21 2024. 2024年2月14日から21日まで、修正前の私のホームページのパフォーマンスはこんな感じでした。 最も緊急に改善すべきと目立ったのは、TTFB（Time to First Byte）でした。 TTFBとは、ブラウザがサーバーにリクエストをしてから、最初の1バイトのレスポンスを受け取るまでの時間を指します。 理論的には、TTFBが低ければ低いほど、ブラウザはより早くページの描画を開始することができ、ユーザーはより早くブラウザで何かを見ることができます。 結果的に、離脱する可能性が低くなります！ ここに表示されているTTFBの値は、75パーセンタイル（p75）のもので、3.46秒が全ホームページビューの75%に見られた最悪のスコアであることを意味します。 これはまた、25％のユーザーがページの読み込みに3.46秒以上待たされたことを意味します。 この悪いスコアは、レスポンスが送り返される前にサーバーで行われている処理が多すぎることを示していました。 ひとつはニュースレター・プロバイダからデータを取得して最新の購読者数を取得するもので、もうひとつはTwitch APIからデータを取得して最新のストリーム動画や現在進行中のライブ・ストリームの最新のサムネイルを表示するものです。 どちらの関数も、最初のHTTPレスポンスをメモリに取り込み、サードパーティのAPIからデータを取得し、それに応じてHTMLを書き換えます。 このアーキテクチャの目的は、静的に生成されたホームページに動的なデータを表示するために、メインのJavaScriptスレッドをブロックする可能性のあるクライアント側のデータ・フェッチを最小限に抑えることでした（スケルトン・ローダーは嫌いです）。 これは 「ユーザーに最新のものを見せる 」という観点では素晴らしいものでした。 しかし、HTTPリクエストが事実上重複してしまうため、ブラウザに何かを表示するのにかかる時間が2倍になってしまうことが問題でした。 そして静的な地域にある2つの別々のサードパーティ・サービスが、世界のどこからでも（エッジから）呼び出されることによるAPIの待ち時間の変化も加わり、ちょっとした混乱に陥り始めます。 正確なニュースレター購読者数は、私以外の誰が求めているのでしょうか？ […]
Supabase データベースとエッジ機能の監視
クラウドサービスが登場し始めた頃、多くの開発者は、オンデマンドでWebアプリケーションをデプロイするために、あらゆる種類のインフラをスピンアップして拡張できることに驚嘆しました。 しかし、大手のクラウドサービスプロバイダーは利用が複雑で、スケールアウトには費用がかかり、デフォルトのモニタリングソリューションはあまり洞察に富んでいないのが実情です。 その上、我々開発者は、物事が簡潔であることを望んでいます。 SupabaseとSentryはデプロイとモニタリングを簡素化します。 SupabaseはデータベースとEdge Functionのデプロイを容易にし、Sentryとの新しい統合はローカルと外部でのコードの監視を簡単にします。 新しいSupabaseとSentryの統合により、Supabaseを通してデプロイしたコードを数行のコードで簡単に監視できるようになりました。そのため、新しいWebサービスが爆発的に普及した場合、Sentryは認証されたEdge FunctionsとDBの呼び出しが監視されていることを確認し、手に負えない問題が発生した場合に警告を発します。 機器データベースの統合 SupabaseはJavaScriptクライアント @supabase/supabase-js を提供し、アプリケーションがプラットフォーム上で動作する Postgres データベースとやり取りできるようにします。 Supabaseチームのサポートにより、Sentryとの統合が可能になり、SupabaseのJavaScript SDKを利用してSentryでパフォーマンスモニタリング、ブレッドクラム、エラーのトレースを収集できるようになりました。 セットアップ コピーして、貼り付けて、さあ始めましょう。 以下のスニペットは、Sentry SDKとSupabaseクライアントをインストールして初期化し、前述のすべての洞察を収集するために必要なすべてを記しています。 エラーとトレースがSentryに確実に取り込まれるようにアプリケーションをセットアップするための詳細については、@supabase/sentry-js-integration documentationとrepoを参照してください。 Supabaseクライアントでは、ログインやユーザー管理機能の構築、大容量ファイルの管理、Deno Edgeファンクションの呼び出しも可能です。 Sentryは、あなたのコードがエッジ上で実行されているときでも、同様に監視されていることを確認するのに役立ちます。 エッジ機能サポート 2023年11月のローンチ・ウィークでは、できるだけ多くのプラットフォームで、できるだけ多くのデベロッパーにサポートを提供するために、私たちがどのように取り組んでいるかについてお話ししました。 特筆すべきは、これにはDenoも含まれているということだ。 Denoは、流行に敏感な開発者の間だけでなく、Supabaseのようなプラットフォームの成長によっても人気が高まっています。 Supabaseは、エッジ機能のランタイムとしてDenoを使用しています。Sentryは、当社のDeno SDKを通じてこれをサポートしています。 Denoは、Edgeランタイム上でコードを実行する機能を提供しますが、Sentryは、コードを確実に監視し、エラーやパフォーマンス課題が発生した場合にアラートを出すことができます。設定の詳細はこちらをご覧ください。 ピースをつなぐ Supabaseは、週末の片手間で構築でき、世界中に拡張できることを約束します。 Sentryとの統合により、エラーや遅いDBクエリがいつ、どのような理由で発生したかを確実に知ることができます。Sentryを初めて使う方はアカウントを作成することができます。 また、この統合に追加してほしい機能などがあれば、GitHubでもお問い合わせを受け付けています。ぜひご連絡ください。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
【必見】Sentry Performance でユーザ体験を改善する方法
本日、3つの新しいSentry Performance機能により、ユーザーに影響を与える問題の発見と解決がさらに簡単になりました。 INP（Interaction to Next Paint）が新たなCore Web Vitalになった 改善されたトレース体験 モバイル開発者がコールドスタートとウォームスタートでアクションを起こすための新しいワークフロー Core Web Vital に INP のサポート追加 Googleは3月12日、First Input Delay（FID）に代わる新しいCore Web VitalであるInteraction to Next Paint（INP）を発表しました。 FIDは最初のユーザーインタラクションの応答遅延を測定するのに対し、INPはページ上のすべてのインタラクションのパフォーマンスを測定するため、INPはページ全体の応答性をより正確に測定することができます。 ユーザーがページとインタラクションするとき、アクションが完了したこと、または何かが進行中であることを示す視覚的なフィードバックを表示することが重要です。 例えば、ショッピングカートに商品を追加する場合、カートのカウントはほぼ即座に更新され、商品が追加されたことを示すべきです。 ページが反応せず、視覚的なフィードバックがない場合、ユーザーはページが壊れていると思うかもしれません。 SentryがINPをサポートし、ページがすべてのユーザーインタラクションにどのように反応するかをモニターできるようになったのはそのためです。 SentryのWeb Vitalsのホームページには、INP、LCP、CLSのような指標を考慮したパフォーマンススコアが表示されます。 トレースでは、INPスコアから開始し、トレース内のスパンを使って、関連するエレメントとインタラクションのタイプを素早く特定することができます。また、Sentryのプロファイリングを使用している場合は、そのインタラクションに応答している間にブラウザがどのコードでブロックされたかを見つけることで、根本原因を診断することもできます。 このINPの新しいサポートにより、迅速な対応を講じることができ、問題に関連する可能性のあるすべてのトレースを検査したりする手間を省くことができます。 根本原因を追跡して、低い INP スコアを調査します。 もちろん、この同じ論理ワークフローで他のウェブ・バイタル（LCP、CLSなど）もモニタリングできるため、ユーザーに影響を与えるパフォーマンス問題の根本原因を迅速に突き止めることができます。 フロントエンドからバックエンドまで、エンドユーザーのパフォーマンスをデバッグする ページの読み込みが遅いなど、ひどいUX（ユーザーエクスペリエンス）は、非効率的なSQLクエリ、キャッシュ（またはその欠如）、その他のバックエンドのパフォーマンスの問題などに起因することがよくあります。 そのため、アプリケーションスタック全体の異なるサービスで発生した問題を結び付けることが、ユーザー向けのパフォーマンス問題をデバッグするために必要になります。 パフォーマンスのボトルネックを引き起こしているサービスまで、ユーザー側の問題を簡単に追跡できるようにするため、Sentryのトレースエクスペリエンスを簡素化しました。 当社の更新されたトレースビューは、マルチサービスアプリケーションの統一されたビューを提供し、コンテキストを失うことなく、スタック全体の重要な問題を簡単に特定できるようにします。 Sentryのトレースビューは、フロントエンドとバックエンドのサービスを統合的に表示します。 例えば、LCP（Largest Contentful Paint）のスコアが落ちたとしましょう。 Sentryを使うことで、トレースビューでスコアの悪いページロードの調査を開始し、APIリクエストのバックエンドの操作に焦点を当てることができます。 トレースビューでは、遅いデータベースクエリやフレームドロップのような関連するパフォーマンスの問題も表示されるので、実際のユーザーに影響を与える問題を即座に修正するために何をすべきか（または誰のせいにすべきかᘏ）を正確に知ることができます。 Sentryの新しいトレースビューでは、パフォーマンスの問題を引き起こしているAPIリクエストについて、バックエンドの操作に集中することができます。 【モバイルパフォーマンス】コールドスタートとウォームスタートからコード行数まで モバイル開発者にとって、本番環境でパフォーマンスの問題を発見し、それを修正するのは時間の浪費につながります。 特に、アプリの起動が遅いという苦情があったときにデバッグしようとすると大変です。これを解決するために、私たちは、コールドスタートとウォームスタートの根本的な原因を、原因となっているコードまで検出して追跡できるように、まったく新しいワークフローを構築しました。 簡単に復習すると、コールドスタートとは、アプリがまだ実行されていない状態で起動することです。 ウォームスタートとは、アプリがバックグラウンドからフォアグラウンドになることです。 例を見てみましょう。 […]
INPとは何か？
2024年3月12日、Googleは新しいCore Web Vital指標である Interaction to Next Paint (INP) を開始することを発表しました。INPは、FID（First Input Delay）に代わるもので、Googleによるサイトのパフォーマンス評価の方法を変え、最終的に検索エンジンの検索結果に影響を与えます。 TL;DR：3月12日以降にあなたのサイトが悪影響を受けないよう、今日からINPに最適化する必要があります。 INPへ変更した経緯 FID（First Input Delay）は、Webページがユーザーの最初のアクションに対してどれだけ速く反応するかを測定するために設計されました。一般的に良いとされるFIDスコアは、100ms以下とされています。 しかしChromeの使用データによると「ユーザーのページ滞在時間の90%は読み込み後に費やされる」ため、FIDではユーザー体験のすべてを把握することはできません。 そこで INPは、最初のインタラクションだけでなくページ上のユーザージャーニー全体にわたってクリック、タップ、キーの押下を観察するように設計することで、ページの全体的な知覚応答性を測定することが可能になっています。 最終的なINPの値は、ユーザーがアクションを実行してから視覚的なフィードバックを受け取るまでに観測された最長時間として計算されます。 ユーザーインタラクションの例としては、製品をカートに追加するボタンのクリック、展開可能なアコーディオンのクリック、折りたたまれたナビゲーションメニューのタップ、入力フィールドへの入力などがあります。 INPは、特定のアクションが実行された後、視覚的フィードバックが表示されるまでの時間（つまり、次のペイント-ここでペイントとは、ブラウザがスクリーンにピクセルを追加するプロセスのことです）に焦点を当て、インタラクションの最終的な効果（ネットワークリクエストやUIの更新など）は除外します。 開発ツールにおけるINPの調査 Chrome、Brave、Edge、ArcなどのChromiumベースのブラウザを使用して、INP測定値に寄与するアクションとイベントを調査する方法を見てみましょう。 INPが計測する以下のユーザーインタラクションのいずれかを受け付けるウェブページを選択します（スクロールやポインタの移動などは計測されない） マウスでのクリック タッチスクリーンを使ってデバイスをタップする 物理キーボードまたはオンスクリーンキーボードのキーを押す 今回は、Sentry Docsのホームページで “web vitals “を検索したときに何が起こるかを調査することにしました。 開発ツールパネルを開き、「パフォーマンス」タブをクリックします。 Webサイトのターゲット層にもよりますが、古いマシンや低速のインターネット上でのユーザー体験を分析するために、CPUやネットワーク速度を調整することはしばしば有用です。 より遅いCPUやネットワークをシミュレートしたい場合は、それに応じてオプションを設定してください。 記録ボタンをクリックし、ページ上でいくつかのインタラクションを実行します。 録画を停止し、プロファイルがロードされるのを待ちます。 すると、色分けされたブロックとラベルの付いたレーンの形で、多くのデータが表示されます。 INPの要因を分析する際に最も重要なレーンは、”Interactions”(ページ上で実行されたユーザーインタラクション)と “Main”(ブラウザのメインスレッド)です。 文脈上、メインスレッドは “ブラウザがユーザーイベントとペイントを処理する場所 “です。デフォルトでは、ブラウザはメインスレッドを使用して、ページ上のすべてのJavaScriptの実行、ページのレイアウト、あらゆる変更の再計算、メモリの確保と解放（ガベージコレクション）を行います。 つまり、長時間実行されるJavaScript関数がメインスレッドをブロックする可能性があり、レスポンスの悪いページや悪いユーザーエクスペリエンスにつながります。GoogleはINPメトリックを導入することで、開発者にこれを解決するよう促しています。 記録されたパフォーマンスプロファイルを見ると、メインスレッドのブロックが赤くハイライトされていることがあります。タスクにカーソルを合わせると、実行にかかった時間が表示され、そのタスクブロックの下には、そのタスクを構成する個別のイベントや関数呼び出しがすべて表示されます。 マウスやトラックパッドでズームイン/ズームアウトしたり、ウィンドウの右側にあるスクロールバーを使ってスタックを上下にスクロールすることができます。 レーンの下にあるサマリー・タブは、各タスクでどれだけの時間が異なるプロセスに割り当てられたかを示しています。 これはタスクによって異なりますが、通常は「スクリプティング」（つまりJavaScriptの処理）と「ローディング」に最も長い時間がかかっていることが明確になります。 では、メインスレッドのアクティビティと、インタラクションレーンを確認してみましょう。 この例では、Sentry Docsホームページの検索入力に “web vitals “と入力した状態です。 […]
【Sentry】モバイルアプリのパフォーマンス改善方法
何千ものモバイル開発者チームと協力してきた経験に基づいて、Sentryではモバイルモニタリングの成熟曲線を開発しました。 私たちは、チームが安定性を達成し、クラッシュの消火と修正がなくなると、ワークフローの合理化にシフトし、最終的にはモバイルアプリのパフォーマンスの最適化に集中するようになるという仮説を立てました。 先日のワークショップで、私たちはモバイル開発者たちに、D彼らがカーブのどこに位置するかを尋ねました。 するとその結果は驚くべきものでした。 ほとんどの開発者（41％）は「安定性の確保」の段階にいました。 また、4分の1近く（24％）が現在パフォーマンスを最適化しています。 集中力とリソースは必要ですが、パフォーマンスの改善はモバイルアプリの成功に不可欠です。開発者が成熟度カーブを上れるよう、当社はモバイル・パフォーマンスの問題を検出して修正する方法を改善しています。これらの改善は、4つの重要な要素に分けることができます。 TTID / TTFDを使って遅い画面を最適化する アプリの起動が遅い根本原因を特定する アプリケーションの応答性を向上 モバイル・サービス・ビューで主要メトリクスを確認 TTID / TTFDを使って遅い画面を最適化する モバイル画面のロード時間、特にTTID（Time to Initial Display）とTTFD（Time to First Display）に焦点を当てたトラブルシューティングのワークフローを開発しました。 TTIDは、ユーザーにアプリがロード中であることを知らせる最初のフレームを表示するのにかかる時間です。 TTFDは意味のあるコンテンツが画面に表示され、アプリが完全にインタラクティブになるまでの時間です。ニュース記事をスクロールしたり、おしゃれな洋服を買ったりするのに、数秒待たされるのは誰だって嫌ですよね。 TTIDとTTFDのどちらかが遅いと、ユーザーはすぐに離脱してしまいます。 TTIDとTTFDは、プロダクションでの遅いメトリクスに寄与する作業を強調します。Sentry の Screen Loads を使用すると、トラフィックが最も多いユーザー画面を確認し、リリース間で TTID と TTFD を比較できます。 これにより、新しいリリースで導入された潜在的なパフォーマンスのボトルネックが強調されるため、速度低下の原因となっているコード変更、依存関係、または資産を調査することができます。以下のスクリーンショットのように表示されます。 また、単一画面の画面ロード・サマリー・メトリクスを見たり、モバイル・デバイス・クラスでフィルタリングして、リリース全体の平均TTID / TTFDを見ることもできます。 サマリー・グラフの下には、最も時間のかかるスパンが表示されます。これらについては、データのフィルタリングも可能です。 これにより、どの操作が TTID または TTFD の遅さの原因となっているかを知るために必要なコンテキストが得られます。以下のスクリーンショットをご覧ください。 Screen Loadsは現在、すべてのAndroidおよびiOSユーザーに提供されています。 アプリの起動が遅い根本原因を特定する 当社の新しいモバイルパフォーマンスアップデートは、アプリの起動が遅い根本原因の特定にも役立ちます。 モバイルアプリの起動シーケンスとは、アプリの起動からTTIDまでのステップを指します。迅速なアプリの起動は、ユーザーに好印象を与え、高い満足度、継続率、コンバージョン率を確保するために非常に重要です。 コールドスタート（アプリが初めて起動されるとき）であれ、ウォームスタート（アプリがバックグラウンドからフォアグラウンドに移動するとき）であれ、アプリの起動時間はAppleやGoogle Playストアでのアプリのランク付けや発見にも影響します。 Sentryでは、SentryのパフォーマンスナビゲーションバーでApp Startを使用して、最近リリースされたアプリバージョンのパフォーマンスを監視できるようになりました。 下の例のように、あるリリースと次のリリースのコールド（またはウォーム）スタート時間を比較し、両方のリリースのイベント […]
すべての開発者のためのパフォーマンス監視 ウェブ・バイタルと機能回帰の問
パフォーマンス・モニタリング・ツールから適切な洞察結果を出すのは、フラストレーションが溜まるものです。一般的なモニタリングツールを使用すると、必要以上のデータが返されてしまい、そのデータを実際のソースコードで確認するまでに大変な手間がかかります。 Sentryが提供するパフォーマンス・モニタリングは、集中すべき課題をピンポイントで検出することで不要なデータを除外し、原因のコード行番号を的確かつ素早く表示します。その結果、より少ないノイズ、より実用的な結果として得ることができます。 本日、Web/モバイル/バックエンドの開発者がアプリのパフォーマンス問題を発見し、解決するための2つの新機能「Web Vitals」と「機能回帰問題」を発表します。 Web Vitals は、パフォーマンススコアから遅いコードまで確認可能 Web Vitalsは、ページの品質を測定するために、読み込み速度、インタラクティブ性、視覚的安定性のような指標として有効なもののみに統一しています。これらの指標を使用して、Web Vitalsメトリクスの加重平均を使用して計算された100点満点の正規化スコアであるSentry Performance Scoreを開発しました。 Sentryのパフォーマンス・スコアは、Google の Lighthouse のパフォーマンス・スコアと似ていますが、1つだけ重要な違いがあります。 それは、Lighthouseは管理されたラボ環境からデータを収集するのに対し、Sentryは実際のユーザー体験からデータを収集します。 私たちは、ラボ環境でしか関連性のないコンポーネントを除外しながら、Lighthouseにできるだけ近いスコアになるようにモデルを作成しました。 Web Vitals が最大の改善機会を特定する 全体的なパフォーマンス・スコアを向上させるには、パフォーマンスの改善が必要な個々の主要ページを特定することから始める必要があります。 これを簡素化し、すぐに本題に入るために、1つのページが全体のパフォーマンス・スコアに与える影響を示す「機会（Opportunity）」ごとにページをランク付けします。 それでは実際にSentry独自の課題の詳細ページをお見せします。この例では、Webアプリで最もアクセス機会の多いページを表示しています。これは当社の製品で最もよくアクセスされるページであるため、このページのパフォーマンスを向上させることは、Sentryの使用体験全体を大幅に改善することになります。 問題のあるページを特定したら、ユーザー体験が悪かったイベントを探します。 以下に、実際のユーザーが問題の詳細ページを読み込んでいることを示すイベントを表示します。 上のスクリーンショットでは、パフォーマンス・スコアが100点満点中9点（悪い）となったユーザーが表示されていますが、これは主に10秒以上のLargest Contentful Paint（LCP）が原因です。 このような最悪のケースは、ローカル開発中や理想的な条件下（ユーザーが高速ネットワーク接続やハイスペックなデバイスを使用している場合など）では明らかにならないパフォーマンスの問題を浮き彫りにしています。 これらのイベントの中には、『▶️（リプレイ）』ボタンがあることにお気づきでしょう。利用可能な場合は、そのページでのユーザーの実際の体験をビデオのように再現して見ることができます。アプリのパフォーマンスを最適化する場合、これらのリプレイは、ユーザーが劣悪な体験をしている場所を解析するのに役立ちます。 スパンウォーターフォールは、最も価値のあるオペレーションを強調します。 LCPが遅くなった原因を調べるには、イベントの「トランザクション」ボタンをクリックすると、ページ・ロード中に発生した操作の詳細な内訳が表示されます。これらの操作を「スパン」と呼びます。 最も関連性の高いスパンは、赤いLCPマーカーの前に発生するスパンで、これらのスパンはLCPブロックの可能性があるためです。LCPマーカーの後に発生するスパンは、ページ全体のパフォーマンスには影響を与えますが、最初のページロードには影響を与えません。 明らかにパフォーマンスのボトルネックになっているように見える最初のスパンは、app.page.bundle-loadスパンで、JavaScriptバンドルのロードにかかる時間を測定します。この場合、バンドルのロードだけでほぼ6秒、つまりLCPの総所要時間の約60％を要しています。 JavaScriptバンドルのロード時間は、主にそのサイズに依存します。バンドルのサイズを小さくすれば、ページ読み込み時間は大幅に改善されます。 しかし、バンドルの読み込み時間を50%短縮しても、LCPは12秒から7秒にしか短縮されません。 次の明確な改善箇所は、このui.long-task.app-initスパンに1秒近くかかっていることです。長いタスクのスパンは、ブラウザがJavaScriptコードを実行し、UIスレッドをブロックしている50ミリ秒以上の操作を表します。 これは純粋なJavaScriptの操作なので、さらに深く掘り下げて何が起こっているのか調べてみましょう。 ブラウザのプロファイリングは、ソースコードの原因となっている行を表示 従来までは、処理が長いタスクの原因となっているコードを特定することは困難でした。その理由は、プロファイラにアクセスできる開発環境で問題を再現する必要があったためです。 Sentryでは、これを解決するために本番環境（Chromiumベースのブラウザ）でブラウザJavaScriptプロファイルを収集するための新しいサポートを開始しました。これにより、実際のユーザーの問題をデバッグし、ユーザーベース全体で幅広いサンプルプロファイルを収集することができます。 以下の例では、ページ読み込みイベントに関連するプロファイルを開き、1秒ほどのタスクスパンの間に実行されたコードを見ることができます。 EChartsReactCore.prototype.componentDidMount関数の実行時間は558ミリ秒であり、これは長いタスクスパンの半分以上です。この関数は、オープンソースのEChartsビジュアライゼーション・ライブラリが提供するチャートをレンダリングするReactコンポーネントにリンクされています。これはまさに、Issues Detailsのページロード時間を短縮したい場合に注目すべき箇所のようです。 ここまでの流れを要約していきます。 まずパフォーマンス・スコアが低いページを特定します。 次に JavaScript バンドル・サイズを縮小して、特定の React コンポーネントを最適化することで、問題の詳細ページのパフォーマンスを大幅に改善できると判断しました。機会（Opportunity）スコアが高いページを見つけ、ページ読み込みイベントを分解し、プロファイルを使用して JavaScript パフォーマンスを深く掘り下げることで、製品の全体的なユーザー体験を向上させることができます。 Web […]
Sentry パフォーマンス – 関数回帰の問題： Pythonのプロファイリングの例
先日、アプリケーション全体で最も遅く、リグレッション（リリース後、パフォーマンスが低下）している関数を表示する機能を開始しました。 今回、新しいタイプのパフォーマンス・イシューで、関数レベルのリグレッションをデバッグできるようになりました。関数のリグレッション問題は、アプリケーションの関数がリグレッションしたときに通知されますが、単にリグレッションを検出するだけではありません。 関数リグレッションの問題は、Sentry Profilingをサポートしているプラットフォームであれば検出することができます。以下では、Pythonプロジェクトのバックエンドを例に説明していきます。 上のスクリーンショットは、Sentryのライブランニングサーバーコードのスローダウンを特定した、実際のFunction Regression Issueです。Redisに保存された顧客のレート制限をチェックする関数の持続時間が50%近くも後退したために発生しました。 上のグラフは関数の持続時間の経時変化を示し、下のグラフは呼び出し回数（スループット）を示しています。スループットもスローダウン期間中に増加していることがわかります。これは、負荷の増加がこの回帰の原因の1つである可能性を示唆しています。 上のスクリーンショットでは、同じ問題によって、どのAPIエンドポイントがリグレッションの影響を受け、どれだけパフォーマンスが後退したかといった他の重要な情報を見ることができます。このデータから、レート制限関数が多くのエンドポイントで広く使用され、呼び出された結果、バックエンド全体のパフォーマンスが大幅に低下したことがわかります。 回帰問題からプロファイルを確認して根本原因を見つける リグレッションした関数の問題では、リグレッションの前後にキャプチャされたプロファイルを簡単に確認できます。これらのプロファイルを比較することで、リグレッションの原因となった実行時の動作の変化を（コードレベルで）明らかにし、最も重要なコンテキストを提供します。 ここで実際に、リグレッションが発生する前にキャプチャされたプロファイル・イベントの例を見てみましょう。リグレッションが発生した関数は、サードパーティのredisモジュール内の2つの関数を呼び出していることに気づきました。 ConnectionPool.get_connectionとConnectionPool.releaseです。 これをリグレッション後に収集したプロファイルと比較したところ、これら2つの関数のうちの1つであるConnectionPool.get_connectionに以前よりも大幅に時間がかかっていることがわかります。 プロファイルの各関数フレームは、関数が定義された場所と実行された行番号のソース・コンテキストを提供します。この場合、redisモジュールでこのソースの場所を開くと、次の行（以下の画像参照）であることがわかりました。 この行はロックの取得を試みており、この行を実行したときの壁時間の大幅な増加は、複数のプロセスまたはスレッドが同時にロックを取得しようとしていることを示唆しています。このロックの競合がコード・レベルでのリグレッションの原因であることがわかります。 このロック競合の問題は、先にスループット・グラフで見たこと、つまりスループットが増加すると競合が起こりやすくなることとも一致しています。追加の調査を通じて、この関数のスループットの増加は、リグレッションの頃に始まったRedis接続数の増加に対応していることがわかりました。 今回の例を通じて、リグレッションした関数の問題が、プロファイリングデータを使ってリグレッションを引き起こしているコードに直接リンクするのに役立つことを説明しました。 今回の例はバックエンドのユースケースに焦点を当てていますが、この機能はSentry Profilingをサポートするどのプラットフォームでも機能します。 ファンクション・リグレッションの問題は、アーリー・アダプターの皆様には本日よりご利用いただけます。 結論 人々が使いたいと思うような差別化された製品を構築するためには、高性能なバーが不可欠です。ウェブ・バイタルとファンクション・レグレッション・イシューにより、すべての開発者がコードに接続することでパフォーマンスの問題を解決できる方法を提供していきます。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。