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 […]
【新機能】Web Vitals Performance Issue
Article by: Ben Coe 新しい種類の Performance Issue として、Web Vitals Performance Issues を導入しました。Web Vitals の指標が、パフォーマンスに関する当社の「meh」または「poor」のしきい値に下がった場合、アプリケーション内の改善余地が最も大きいページを対象に、これらの課題が作成されます。 これらの課題は Seer Issue Fix を念頭に置いて構築しました。私たちの目的は、Vitals スコアの低下を通知するだけではありません。スコアを改善するために取れる具体的な手順を提示し、可能な場合は問題の修正まで支援することです。 Web Vitalsとは？なぜ気にする必要があるのか Web Vitals は、サイトのユーザー体験がパフォーマンスの基準値と比べてどの程度かを把握するための標準指標です。Vitals の良いスコアを持つウェブサイトが必ずしも素晴らしいユーザー体験を保証するわけではありませんが、Vitals の評価が悪いウェブサイトはほとんどの場合、ユーザー体験も悪いと言えます。 とはいえ、たとえユーザー体験の向上にはそこまで関心がないとしても、Web Vitals は Google の検索ランキングや Shopify でのリスティングにも影響します。要するに、ビジネスの成果に直結します 🤑。 中でも、最も重視すべき 3 つの Core Web Vitals は次のとおりです。 Largest Contentful Paint (LCP)：ページ内で最も大きな要素が表示されるまでにどれくらい時間がかかるのかを測定します。読み込み速度の指標。 Interaction to Next Paint (INP)：ページ要素を操作したとき、次のフレームが表示されるまでにかかる時間を測定します。インタラクティビティの指標。 Cumulative […]
【React Native】パフォーマンス改善戦略：最新の手法とツール
Article by: Simon Grimm 本記事は、Galaxies.dev の創業者である Simon Grimm によるゲスト投稿です。Galaxies.dev は、ハンズオン形式のコース、専門家のガイダンス、そして個別サポートを通じて、開発者が React Native を習得できるよう支援するプラットフォームです。 React Native のパフォーマンスは、これまで以上に重要になっています。 新しいアーキテクチャが安定版となり、アプリが電光石火のネイティブ体験と競い合う中で、ユーザーは1秒未満の読み込み時間と滑らかな60fpsの操作感を期待しています。遅いアプリはユーザーを苛立たせるだけではなく、最終的な利益にも直結します。実際、100msの遅延でもコンバージョン率が7%低下し得ることを示す調査があります。 そこで、朗報です！ 新しいアーキテクチャを備えた React Native 0.80 以降に、Expo Router や Reanimated 4 といった最新ツール、そして Sentry による包括的なモニタリングを組み合わせることで、開発者は高パフォーマンスなアプリを作るための強力な手段を手にできます。ただし、大きな力には、それに見合う技術が必要です。 本ガイドでは、起動時の最初の印象という重要な局面から、高負荷時でも滑らかなアニメーションを維持する方法まで、React Native アプリのパフォーマンスをあらゆる面で最適化するための実証済みの戦略を解説します。 本記事で扱う内容は次のとおりです。 操作可能になるまでの時間（TTI）の短縮する React の最適化 60フレーム/秒（FPS）を達成する リスト表示のパフォーマンスを改善する 丁寧な状態管理 各トピックには、今日から実装できる実際のコード例と実践的なツール選定のおすすめを含めています。 さらに、Sentry が提供するシグナル（指標）を見ながら、アプリ内で何が起きているのか、そしてどう直せばよいのかを理解する方法も掘り下げます。 React Native アプリを、パフォーマンスの強力なアプリへと変えていきましょう。 1. 操作可能になるまでの時間（TTI）を短縮する TTI はアプリ起動後に「使える状態」になるまでの速さを測る指標です。アプリアイコンをタップしてから、ラグや処理中スピナーで待たされることなく、ユーザーが実際に […]
そのままで動くLaravel パフォーマンスモニタリングも同様
Article by: Will McMullen Laravel アプリを初めて立ち上げたときのことを覚えていますか？ルーティング、認証、ORM、キューがすべてスムーズにつながり、ほとんど手間がかからなくなったはずです。これこそ、Laravel が「最初から生産的に感じられる」理由のひとつです。 しかし、アプリの動作が遅くなり始めたとき、Eloquent クエリが重くなる、ジョブがいつまでも終わらない、キャッシュミスが増えていく。その原因を見つけるのは簡単ではありません。Laravel には多くのツールが備わっていますが、それらをつなぎ合わせて全体像を把握するのは、これまで開発者の手に委ねられていました。 Sentry の新機能「Laravel Insights」を使えば、アプリ内部で何が起きているのかを、より明確に把握できます。エラー、遅いジョブ、データベースクエリ、キャッシュの利用状況、ルートごとのパフォーマンスなどを可視化し、既に追跡している課題と関連づけて表示します。さらに、それらがユーザー体験に実際どのような影響を与えているのかも確認できます。 すべてがつながっています。特定のルートから発生した遅いジョブをたどり、その原因となったクエリを特定し、キャッシュが改善に寄与したのか、それとも逆効果だったのかまで把握できるのです。 Laravel を先回りして最適化 これは新しい製品でも、新しいタブでもありません。Laravel アプリで基本的な Sentry のインストルメンテーション（エラーおよびトレーシング）が設定されていれば、Insights → Backend の中で Laravel プロジェクトを開くだけで次の情報を確認できます。 Recommended Issues：本番環境で新たに発生した、または深刻化している課題を表示 Requests & Duration：リリースごとの負荷の変化やアプリのパフォーマンスを追跡し、リグレッションが発生していないか確認 Jobs：バックエンドジョブの実行時間や失敗率の傾向を監視し、SendWelcomeEmail::dispatch($user); が常に時間通りに動作しているか確認 Queries：コストの高いデータベース呼び出しを特定し、トランザクションを最適化 Caches：キャッシュミスが多発している箇所を特定し、無効化の問題を修正 Routes：リクエスト数、ユーザー数、総処理時間、pXX 指標ごとにソートし、早期にパフォーマンス低下を検知 一人で開発している場合でも、スタートアップのスケールアップ段階にあっても、これらのインサイトによりアプリの挙動を簡単に把握でき、ユーザーが気づく前に問題を修正できるようになります。 さらに深く掘り下げ、アラートを作成 たとえばキャッシュミスの急増、データベース時間を食い尽くす暴走クエリ、異常に滞留しているキューなど、もし何かおかしな兆候を見つけたら、クリックひとつで詳細を掘り下げることができます。 Laravel Insights の各ウィジェットには 「Open in Explore」（Exploreで開く）ボタンがあり、ドロップダウンをクリックすると Sentry のクエリビルダーに直接移動できます。そこで次のようなことが可能です。 特定のサービス、ルート、ユーザー、または環境に絞り込んでクエリをカスタマイズ ブラウザの種類、ユーザーアカウントの状態、リクエスト元など、Sentry に送信している任意のタグ（デフォルト・カスタム問わず）でグループ化 […]
【SvelteKit】オブザーバビリティが10倍強化 ー その全貌を解説！
Article by: Lukas Stracke Svelte チームは先日、 SvelteKit の完全なオブザーバビリティとトレーシングのサポートを追加したことを発表しました！ これは SvelteKit と Sentry のユーザーにとって朗報です。なぜなら、Sentryはすでにこの新機能と互換性があるからです。 さらに、このニュースは JavaScript エコシステム全体にとっても大きな意味を持ちます。SvelteKit は、ESM ベースのメタフレームワークとして初めて、インストゥルメンテーションとトレーシングを標準でサポートしたのです。 ここからは、なぜこれが重要な一歩なのか、そしてSvelteKitがどのようにして他のESMフレームワークのお手本となったのかを見ていきましょう。 何が起こったのか SvelteKit バージョン2.31.0 以降では、サーバーサイドインストルメンテーションと SvelteKit が生成するスパンを有効化できるようになり、サーバーサイドのトレースを大幅に強化できるようになりました。これは、SvelteKit アプリケーションにオブザーバビリティを追加したい人にとって大変朗報です。 理由は以下のとおりです。 まず、SvelteKit では instrumentation.server.js という専用ファイルを用いたテレメトリのインストゥルメンテーションがサポートされました。このファイルはサーバーサイドのインストゥルメンテーションを初期化します。ビルドの最終成果物に組み込まれ、OpenTelemetry のような自動インストゥルメンテーションが、サーバーサイドリクエスト処理の全体を確実に捕捉できるタイミングで評価されるようになっています。 さらに Svelte チームはそこで止まりませんでした。SvelteKit はリクエストハンドラー、load 関数、フォームアクション、さらにはリモート関数に対しても専用のスパンを発行するようになりました。これにより、アプリケーションのリクエストライフサイクルのどの部分が最も時間を消費しているのか、あるいはアプリケーション内の異なるパフォーマンス特性を理解することが、はるかに容易になりました。 そして極めつけに、Sentry の SvelteKit SDK はバージョン 10.8.0 以降で、この SvelteKit の公式インストゥルメンテーションとトレーシング機能に完全対応しています！ SvelteKit のオブザーバビリティを Sentry で使う方法 […]
【必読】APIコールの時間を削減する方法！5秒以上から100ミリ秒未満に改善できる…？
私のプロフェッショナルなキャリアで触れたデータベースは、100％がSQLデータベースだったため、私のデータベースに対する考え方（この言葉遊びを楽しんでください！）は常にリレーショナルモデルが基本でした。 しかし、2020年に小さなサイドプロジェクト（Twitchのストリームにインタラクティブ性を提供するBot）を立ち上げた際、当時のデータ保存要件にはリレーショナルモデルは必要なく、NoSQLソリューションであるMongoDBを選びました。 4年後の2024年、この小さなサイドプロジェクトは予想以上に大きく成長し、テキストベースのゲーム「Pantherworld」へと進化しました。この進化について興味がある方は、どのように小さなTwitchボットからゲームに成長したかを解説した私の2024年のカンファレンス講演「Entertainment as Code」をYouTubeでチェックしてください。 Pantherworldは2024年4月から、私のTwitchチャットインターフェースを通じて、24時間、週7日、数百人にプレイされています。ゲーム内のイベントは、私のストリームで発生するイベントに基づいています。例えば、新しいフォロワーを獲得すると、ランダムなワールドアイテムがランダムなゾーンに出現します。プレイヤーの目標は、Twitchチャットでテキストコマンドを使って世界を移動し、アイテムを収集してインベントリを埋めることです。アイテムには希少なものもあります。 プレイヤーがゲームの進行状況を追跡できるようにするため、私はフロントエンドのコンパニオンアプリを作成しました。このアプリは、NoSQLデータベースからAPIを介してゲームデータを取得します。ゲームが多くのプレイヤーを惹きつけるにつれて、明らかにスケーラビリティ（拡張性）の問題があるAPI呼び出しが一つありました。 それは、リーダーボードデータを取得するエンドポイントでした。このエンドポイントは非常に遅く、その原因が分からなかったため、フロントエンドでスケルトンローダーを追加しました（単に空白画面を表示するのではなく）。遅さを隠そうとしましたが、実際に見るのはとても辛かったです。 重要なのは、私のデータベースに対する思考モデルが常にリレーショナルなものであったことを繰り返し強調することです。 そのため、私は自分がNoSQLをうまく使えていないのだろうと思っていましたが、どこで間違えているのかは分かりませんでした。さらに、このアプリは4年にわたる開発の中で大きく進化し、そのデータモデルの要件がリレーショナルモデルを必要とするようになりました。最初の直感的な反応としては、全体をリファクタリングしてSQLデータベースを使うようにしようと思いました。しかし、4年も経ったレガシーアプリをリファクタリングし、数十万のNoSQLドキュメントをSQLに移行するのは現実的ではありませんでした。 そこで、コードの最適化方法を理解するためにトレースを利用することに決めました。 トレーシング(Tracing)とは何か？ トレーシングは、アプリ内で発生するすべてのイベント（関数呼び出し、データベースクエリ、ネットワークリクエスト、ブラウザイベントなど）をキャプチャする技術で、アプリがどのように動作しているかを理解し、パフォーマンス向上のための改善点やバグ修正ができる箇所を特定するのに役立ちます。 Sentryでは、個別のイベントはスパンとして名前付けされ、これらは各スパンと一緒に送信されるHTTPヘッダーを通じてトレースビューで接続されます。また、これらのイベントをアプリやサービスの全スタックに渡ってキャプチャすることができ、これを分散トレーシングと呼びます。 MongoDBデータベースクエリのトレーシングサポートを追加する方法 MongoDBデータベースクエリのトレーシングは、Sentryの最新のJavaScriptおよびPython SDKで標準でサポートされています。追加の設定は不要です。 私のバックエンドAPIはExpressアプリなので、最新のSentry Node SDKを使用しています。Sentry SDKの初期化コードは別のファイルにまとめることが推奨されています。私の例では、そのファイルをinstrument.tsと呼んでいます。 以下に、最も関連性のあるオプションを示した簡略化されたSDK設定を示します。 tracesSampleRate オプションは、Sentry SDKにトレーシングを有効にするよう指示します。このオプションは0から1の間の値を取り、アプリがSentryに送信するトレースの割合を設定します。アプリのユーザー数やSentryアカウントのプランに基づいて、この値を調整することをお勧めします。 Distributed Tracing（フロントエンドアプリからバックエンドアプリへのトレース）を有効にするには、tracesSampleRateを設定するだけでなく、フロントエンドのSentry SDK設定にbrowserTracingIntegrationを追加する必要があります。ただし、Next.jsやNuxtなどのフルスタックフロントエンドフレームワークは、デフォルトでbrowserTracingIntegrationを追加するため、このルールは適用されません。 バックエンドでは、SentryがMongoDBを含むアプリケーション内のすべてのモジュールを自動的に計測できるように、他のモジュールを要求する前に instrument.js ファイルをインポートすることを確認してください。 私が実際にアプリケーションで使用しているエントリーポイントファイル app.ts の先頭部分でのインポート例をご紹介します。以下の通りです。 MongoDBのクエリをExpressアプリでトレースする設定が完了したので、次にリーダーボードのコードがなぜここまで遅かったのかを調査してみましょう。 なぜ単一のAPI呼び出しが5秒以上かかっていたのか コードの最適化を行う前のトレースのスナップショットがこちらです。 API呼び出しの所要時間が強調表示されています。/world/leaderboard APIへのHTTP GETリクエストは、およそ4秒〜8秒かかっていました。 単一のAPI呼び出しに対する（ズームアウトされた）トレースビューでは、一連のリクエストウォーターフォールと重複したデータベースクエリが表示されています。これは改善が必要です。 API呼び出しを短縮する方法を探る前に、フロントエンドアプリから/ world / leaderboard に対する呼び出しが行われるときに何が起こるのかを見てみましょう。 リーダーボードAPI呼び出しは、プレイヤーの配列を返します。 各Player（プレイヤー）オブジェクトには、username（ユーザー名）、items count（アイテム数）、wealth_index番号（wealth_indexは、すべてのインベントリアイテムの合計で、そのアイテムのレアリティで掛け算された値）が含まれます。 こちらが元のコードで、少し簡略化されています。コードは以下のことを行います。 Itemsコレクションをクエリして、ユーザーに割り当てられたすべてのアイテムを取得し、アイテムをuserIdでグループ化し、そのアイテムのカウントを返します。 各プレイヤーについて、getAllItemsForPlayer()を呼び出します（これによりItems コレクションが再度クエリされます）。 各プレイヤーについて、Playerコレクションをクエリします（このクエリの目的は、アイテムデータと一緒に保存したくなかったuserDisplayNameを取得するためだけです。SQLのジョインがあれば便利でした）。 各Playerオブジェクトを構築し、計算し、配列に追加し、その配列をソートして返します。 […]
【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リクエストについて、バックエンドの操作に集中することができます。 【モバイルパフォーマンス】コールドスタートとウォームスタートからコード行数まで モバイル開発者にとって、本番環境でパフォーマンスの問題を発見し、それを修正するのは時間の浪費につながります。 特に、アプリの起動が遅いという苦情があったときにデバッグしようとすると大変です。これを解決するために、私たちは、コールドスタートとウォームスタートの根本的な原因を、原因となっているコードまで検出して追跡できるように、まったく新しいワークフローを構築しました。 簡単に復習すると、コールドスタートとは、アプリがまだ実行されていない状態で起動することです。 ウォームスタートとは、アプリがバックグラウンドからフォアグラウンドになることです。 例を見てみましょう。 […]