【Next.js / Supabase オブザーバビリティ設計】バイブコーディングから本番運用へ
Article by: Sergiy Dybskiy ここ数年で、ソフトウェアの作り方は大きく変化しました。一方で変わっていないのは、そのソフトウェアが最終的に「実際の人間」に届くという事実です。あなたや私、そして私の母のような人たちです。 そして、そうしたユーザーが必然的に何かしらの不具合に遭遇したとき、アプリケーションの開発者であるあなたは、何が壊れたのか、どこで壊れたのか、そしてそれをできるだけ早くどう修正するのかを理解するための適切なツールとコンテキスト、そして認識を備えている必要があります。 私たちは日々、「自己修復するソフトウェア」に少しずつ近づいています。Next.jsアプリケーションを構築し、バックエンドサービスとしてSupabaseを利用している場合、以下で説明するツールは、より高品質なソフトウェアを生み出すことと、すり抜けてしまった問題を最小限の影響で修正するという、自己完結的なループに一歩近づく助けになります。 要約 Supabaseはクエリパフォーマンスのインサイト、行レベルセキュリティ（RLS）のアドバイザリ、Edge Functionのログを標準で提供しているが、フルスタックを横断したトレースはできない Sentryはそのギャップを埋める：Next.jsのフロントエンドからSupabase Edge Functions、Postgresまでをまたぐ分散トレースを一箇所に集約できる SupabaseからSentryへログをドレインすることで、エラー・トレース・インフラログの単一の信頼できる情報源を作れる SentryはN+1クエリ、遅いスパン、パフォーマンス劣化を手動設定なしで自動検出する SentryのAIデバッガー「Seer」は新しい問題に対して原因を自動で推定し、修正をコーディングエージェントに引き渡すことができる エージェントが生み出すスタック問題 AI支援開発には特有の失敗モードがあります。エージェントは動作するコードを生成できますが、そこにオブザーバビリティが組み込まれていないことが多いという点です。その結果、Next.jsアプリがSupabaseと通信する方法が3種類（直接Postgres接続、Supabase JS SDK、そしてDrizzle、エージェントが戦略を切り替え続けたため）混在することもあり得ます。さらにDeno上で動くEdge Functionが加わり、実行時に何が起きているのかを統一的に把握できない状態に陥ります。 もう一つの失敗モードはより見えにくいものです。エージェントはインデックスを忘れることがあります。ローカル環境ではデータが40行程度しかないため問題にならず、N+1クエリを書いてしまうこともあります。しかし本番にデプロイし、データベースが400行に増えると、検索クエリが突然10秒かかるようになります。Sentryはこれを自動的に検出できますが、それは最初から正しく計装されている場合に限られます。 この計装を正しく行うには、SupabaseとSentryがどのように組み合わさるかを理解する必要があります。 Supabaseの組み込みオブザーバビリティとその限界 Supabaseには堅牢な組み込みオブザーバビリティがあります。ダッシュボードのQuery Performanceパネルでは、どのクエリが最も頻繁に実行されているか、どれが最も時間を消費しているかを確認できます。パフォーマンス問題が発生した際に最初に見るべき場所です。 またAdvisorsは、RLSポリシーの不足などのセキュリティ問題を検出し、重要度に応じて優先順位付けします。Index Advisorは不足しているインデックスを指摘し、それらが本番インシデントになる前に可視化します。 Logsセクションでは、Supabaseのすべてのサブシステムから構造化ログを取得できます。対象にはEdge Functions、Postgres REST API（PostgREST）、コネクションプーラー、ストレージ、cronジョブなどが含まれます。これらのログはダッシュボード上でSQLを使って直接クエリすることも可能です。 これは確かに非常に有用です。ただし、Supabaseの内部で観測できる範囲に限定されるという制約があります。つまり、Supabaseの外側で起きていることまでは見えません。例えば、遅いPostgresクエリがNext.jsフロントエンドのどのユーザーアクションによって発生したのか、あるいはEdge FunctionのタイムアウトがAPIレイヤー全体にどのようなエラーの連鎖を引き起こしたのか、といった因果関係は把握できません。こうした情報を得るには、フルスタックを横断した分散トレーシングが必要になります。 SupabaseログをSentryに接続する SupabaseのデータをSentryに取り込む最も簡単な方法は、log drainを使うことです。Supabaseダッシュボードの「Logs > Drain」で送信先を追加し、SentryのDSNを貼り付けると、そのSupabaseプロジェクトのすべてのログが対応するSentryプロジェクトへ流れ込むようになります。 この仕組みについて、いくつか重要な点があります。 現時点では「全量送信（all-or-nothing）」であり、Supabase側でログレベルによるフィルタリングはできません。 ログがSentryに入った後は、Log Explorer上で severity:warn や severity:error のようにフィルタリングできます。 log drainはNext.jsアプリやEdge […]
JavaScript のオブザーバビリティを修正する：ライブラリ単位での改善
Article by: Abdelrahman Awad ここ数週間、私たちはクロスエコシステムでの取り組みとして、現在すべての JavaScript APM ツールを支えている「モンキーパッチング」をランタイムに組み込まれた仕組みに置き換える作業を進めてきました。ここでは、その背景と仕組み、そして現状について説明します。 この内容はサーバーサイド JavaScript（Node.js、Bun、Deno、Cloudflare Workers）のみに適用されます。ブラウザには diagnostics_channel が存在せず、またそれをポリフィルするために必要な非同期コンテキスト伝播の仕組みも備わっていません。 モンキーパッチングはスケールしない 私のチームメイトである Sigrid は、なぜモンキーパッチングが破綻しつつあるのか、そして TracingChannel がそれをどう解決するのかについて詳しく解説しています。 要点をまとめると、JavaScript のすべての APM ツール（Sentry を含む）は、実行時に require() や import をフックし、import-in-the-middle（IITM）や require-in-the-middle（RITM）を使ってライブラリをインストルメントしています。しかしこの仕組みは ECMAScript Modules（ESM）で壊れやすく、Node 以外のランタイムでは動作せず、バンドラとも衝突し、さらに制御できない内部実装に依存する構造になっています。また SDK は対象ライブラリより先に読み込まれていなければならず、そうでない場合は計測が静かに失敗します。 これは Sentry 固有の問題ではありません。JavaScript のインストルメンテーションを提供するすべての APM ベンダーが、同じ不安定さを抱えています。エコシステム全体が行き詰まっている状態です。 多くのライブラリメンテナーはオブザーバビリティを前提にしていません。何を公開すべきかも分からず、OpenTelemetry のような仕組みを導入することは標準化というより実装負担になります。これまで APM 側がパッチで吸収してきたため、ライブラリ側が対応する必要がありませんでした。 しかし、より良い方法があります。 TracingChannel：パッチ不要のオブザーバビリティ 2025年後半、私たちは Nitro、h3、そして unjs エコシステムの開発者である Pooya Parsa […]
【Android tombstone】ネイティブクラッシュ解析の大幅改善
Article by: Mischan Toosarani-Hausberger , Roman Zavarnitsyn （了読時間：13分） Androidにおけるネイティブクラッシュは、これまで本来あるべきよりもデバッグが難しいものでした。 Androidには独自のクラッシュレポーター（debuggerd）があり、クラッシュしたスレッド、実行中の他のすべてのスレッド、レジスタ状態、メモリマップを tombstone と呼ばれるファイルに記録します。tombstone は長年Androidの一部であり、実際にはAndroid最初期のコミットの頃から、形を変えつつ存在してきました。 問題は、Androidの歴史の大半において、アプリ内部から tombstone をプログラム的に読み取ることができなかったことです。そのため、SDKベースのネイティブクラッシュレポート機能（私たちのものを含む）は、プラットフォーム側ですでに存在している仕組みを独自に再実装せざるを得ませんでした。その代償として、バイナリサイズの増加、不完全なJavaフレームのシンボリケーション、さらに変化し続けるAOSPに追従するために維持しなければならないC++フォークが発生していました。 Android 11（SDK level 30）では ApplicationExitInfo が導入されました。さらに Android 12（SDK level 31）では、ApplicationExitInfo.REASON_CRASH_NATIVE に対する trace input stream へのアクセスが追加されました。 SentryのAndroid SDKは、バージョン8.30.0以降、Android 12以上を実行しているすべてのデバイスでこのストリームを読み取り、ネイティブクラッシュイベントとして送信します。これにより、ネイティブコードを使用するAndroidアプリのクラッシュレポートは大幅に改善されました。基本的なクラッシュ通知だけが必要なチームにも、詳細なデバッグ情報が必要なチームにも有効です。 ここからは、以前はどのように動作していたのか、既存のNDK統合を壊さずにこれをSDKへ組み込むために何が必要だったのか、そしてこれによってどのような改善がもたらされたのかを見ていきます。 tombstoneサポート以前：変化し続けるターゲットを追い続けるフォーク tombstoneサポート以前、Android SDKでは Native SDK（sentry-native）がネイティブエラーレポートの主要な仕組みとして使用されていました。AndroidはLinuxベースであるため、SDKのかなりの部分を再利用できました。しかし再利用できない部分については、2019年からAndroid固有コードの統合作業が始まりました。 特に、libunwindstack（現在も debuggerd、そして tombstone のスタックトレース生成に使用されているAOSPのプラットフォームアンワインダ）を統合したことは、Sentry Android SDKでネイティブクラッシュをサポートする上で重要な転機となりました。なぜかというと、Native Development Kit（NDK）には汎用的なスタックウォーカーが存在しなかったからです（今でも存在しません）。 libunwindstack はNDKの一部ではなく、Android Open Source Project（AOSP）のプラットフォームコードの一部であるため、通常の方法ではアプリ開発者から直接利用できません。Sentryは、NDKでビルドできるようプラットフォームコードへパッチを当てたリポジトリをフォークし、その後も上流のパッチ版に変更がないまま、そのフォークを維持してきました。 これにより、非常に複雑なAndroid […]
【Sentry トレーシング】Next.js [Object] not found エラーを調査
Article by: David Y. 本ブログの内容 サンプルアプリケーションのセットアップ エラーの再現 エラーの調査 エラーの修正 Next.js アプリケーションでエラーを特定するための Sentry トレーシング設定 Sentry トレーシングで可能なその他の機能 ローカル開発中は、ブレークポイントや console.log があなたの正気を保ってくれるかもしれませんが、本番環境の問題はまったく別の話です。本番環境では、エラーが複数のマイクロサービスに分散していたり、難読化されたコードに隠れていたりします。それらを追跡するのは至難の業です。 そこで活躍するのが Sentry のトレースとスパンです。フルスタックかつ分散された環境において、ネットワークリクエスト、API 呼び出し、DB 取得などすべてを簡単に可視化できます。 Sentry の分散トレーシングは、Next.js アプリを通過する各ネットワークリクエスト、API 呼び出し、データベースクエリを明確かつ実用的に可視化します。推測に頼ることなく、パフォーマンスのボトルネックや複雑な障害が発生している箇所を正確にマッピングできます。 分散トレーシングにより、例えばデータベースのレコード欠落や想定外のペイロードを返すエンドポイントなど、エラーの根本原因をすばやく特定し、エラーがユーザー体験全体にどう影響するかを正確に把握できます。さらに優れているのは、他人のコードをあさったり、リポジトリの権限を待ったりすることなく、本番トラフィックをデバッグできる点です。 Sentry が新たなエラーを検知した瞬間や、インサイトに予期しないスパイクが表示されたとき、特定のトレース ID に絞り込み、各リクエストを特定し、コールスタックが崩れ始めた正確な場所を突き止めることが可能なのです。 分散トレーシングなら、以下のような状況でも簡単にデバッグできます。 ソースコードへの読み書き権限がない場合 デバッグ用のコードを追加でデプロイできない場合 エラーメッセージがあいまいで不明瞭な場合 複数のマイクロサービスが原因の特定を難しくしている場合 本ガイドでは、ソースコードを見ることなく本番環境の問題を効果的にデバッグするために、Sentry のトレーシング機能を活用する方法をご紹介します。 手元でセットアップして進められる、サンプルのコース管理アプリを用意しました。 サンプルアプリケーションのセットアップ このコース管理アプリケーションは、TypeScript で記述されており、React フレームワークである Next.js を採用しています。型安全性の確保には tRPC を、データの永続化には PostgreSQL […]
React.js パフォーマンスガイド
Article by: Armin Ulrich 最もパフォーマンスが高い JavaScript フレームワークはどれでしょう？React、Vue、Svelte、Angular…？この問いに答えようとするとき、私たちはしばしばリアクティビティ、バンドルサイズ、メモリ使用量などのベンチマークの比較に迷い込んでしまいます。 もちろん、パフォーマンスの高いアプリを作るために最適なフレームワークを選びたいものです。しかし、React アプリに限らず、Web アプリ全般におけるパフォーマンス最適化のベストプラクティスに従わなければ、フレームワークの性能だけではアプリの恩恵は得られません。 では、どこから始めればよいのでしょう？パフォーマンスに影響するのは何でしょうか？ このガイドでは、Reactにおけるパフォーマンス最適化の基本を解説し、この分野をさらに深く学ぶためのツールやリソースを紹介します。 なぜパフォーマンスに投資すべきか パフォーマンス向上 = ユーザー体験の向上 遅いアプリに時間を割く人はいません。人々は素早く物事を済ませたいのです。あなたのアプリはそのための道具です。パフォーマンスはアプリとブランドへの信頼を築き、良好な体験を提供する助けになります。 パフォーマンス向上 = コンバージョン率と継続率の向上 優れたユーザー体験は、コンバージョン率と継続率（＝どれだけ多くの人が登録し、使い続けるか）を高めます。つまり、パフォーマンスはアプリの成功に直接貢献します。 パフォーマンス向上 = SEOの向上 検索エンジンはパフォーマンスの高いページを上位に表示し、ユーザーエンゲージメントも評価対象とします。ユーザーが必要な情報を効率よく見つけられて長く滞在するなら、それがSEOパフォーマンスにも良い影響を与えます。 パフォーマンス向上 = スケーラビリティの向上とコスト削減 パフォーマンスのベストプラクティスに則ったコードベースは、システムが複雑化しても保守や拡張がしやすく、インフラコストも少なくすみます。 React によくあるパフォーマンス問題 8選とその解決方法 パフォーマンスについて話すとき、通常はアプリの読み込み時間や応答性を測る指標を指します。 読み込み時間とは、アプリが必要とするコードやアセットをすべて読み込むのにかかる時間のことです。これには、FCP（First Contentful Paint）、LCP（Largest Contentful Paint）、TTI（Time to Interactive）などの指標が用いられます。 応答性または実行時パフォーマンスは、スムーズな（再）レンダリングに関わるすべての処理を指します。ここではReactコードそのもののパフォーマンスが大きな要因になります。応答性を測るための重要な指標にはINP（Interaction to Next Paint）があります。さらに、プロファイリングやモニタリングツールを使ってトランザクションの実行時間を測定したり、フレームレート、CPUやメモリの使用量を確認したりすることも可能です。 アプリの読み込みと操作感をどちらも高速に保つには、これら両方のパフォーマンス指標を考慮する必要があります。それでは、よくある問題とReact特有の、あるいはReactに限らない解決策を見ていきましょう！ 1. バンドルサイズが大きい アプリが大きければ大きいほど、読み込みに時間がかかります。これは当然のように聞こえますが、実際にはパフォーマンスを大きく改善できるポイントのひとつです。目標は常に、可能な限り少ないコード（およびその他のアセット）をブラウザに送ることです。 バンドラの使用と最適化Webpack […]
【PHP】デバッグとログの方法
Article by: Richard C. このガイドでは、PHP におけるエラーの仕組みと、それらをログ関数や Sentry を使って効率的にデバッグする方法を説明します。 このガイドの情報は PHP 8 に対して正確であり、将来の PHP バージョンの変更内容によっては、それ以降のバージョンにも適用できる可能性があります。 PHP のデバッグとロギングの前提条件 このガイドのすべてのコード例は、ホスト OS を問わず Docker 上で実行できます。Docker をお持ちでない場合は、こちらからダウンロードしてください。 すでに PHP がインストールされている場合、Docker は必須ではありません。ただし、Docker 上でコードを実行すると、以下のような利点があります。 Docker サンドボックス内で実行される悪意あるコードから、マシンを保護できます。 チーム内のすべてのプログラマーが、同じ IDE プラグインと PHP バージョンを使った共通の環境で作業できます。 物理マシンを再設定することなく、開発環境を本番サーバーと簡単に一致させることができます。 PHP の例外とエラー まずは、PHP における例外の仕組みを見ていきましょう。 エラーとはPHP 本体またはその拡張機能内で発生する内部的な問題です。例外とはPHP 開発者（つまりあなた）が書いた外部の PHP コードで投げたり捕捉したりできるオブジェクトの一種です。エラーと例外はどちらも Throwable オブジェクトです。 PHP が生成するすべてのエラーには型が含まれます。以下の PHP エラーの種類の一覧を見てください。それぞれの型の動作と、その原因となる状況について簡単に説明されています。 エラーには主に […]
Sentry のゲームエンジン対応でスムーズなプレイ体験を実現
Article by: Bruno Garcia Sentry はすでにご利用中のツールと直接統合され、Unity、Unreal Engine、Godot においてリアルタイムのクラッシュおよびパフォーマンスインサイトを提供します。 Unity：Sentry の Unity SDK により、C# のエラー、ネイティブクラッシュ、複数プラットフォームにまたがるパフォーマンスのボトルネックを検出できます。自動エラートラッキング、スクリーンショットの添付、オフラインキャッシュ機能によりデバッグが簡単になり、プレイヤーのデバイスがオフラインであっても重要なクラッシュデータを失うことはありません。（ドキュメント） Unreal Engine：PC、モバイル、コンソール向けに開発を行っている場合でも、Sentry の Unreal Engine SDK はエンジンレベルでクラッシュやエラーをキャプチャします。Unreal の組み込みクラッシュレポーターと統合されており、すべてのコンソールでシームレスに動作します。（GitHub） Godot：Godot を使用した開発においては、Sentry は専用の SDK を現在開発中です。これにより、作業フローを中断することなく、エラーの検出とパフォーマンスの向上が可能になります。（GitHub） ご使用のエンジンが何であっても、Sentry はプレイヤーに影響が及ぶ前に問題を特定し、修正する手助けをします。 プラットフォームをまたぐデバッグで足を引っ張られるべきではありません ゲームが PC、モバイル、コンソールなどさまざまな環境で動作する一方で、異なるプラットフォームにわたるクラッシュの追跡は非常に困難です。たとえば、Android では発生する問題が iOS では正常に動作することもあり、PlayStation 上でのクラッシュが開発マシンでは再現できない場合もあります。Sentry はあらゆるの荷プラットフォームにおけるエラーとパフォーマンスを一元的に監視することで、このような混乱を整理します。 すべてのプラットフォームを一元管理するダッシュボードWindows、macOS、Linux、Android、iOS、PlayStation、Xbox、Switch におけるクラッシュやパフォーマンスの問題を一か所で確認できます。散らばったログを探し回ったり、プレイヤーからの報告を待つ必要はありません。 すべてのエラーに完全なコンテキスト何が起きたのかを推測で済ませるのは終わりにしましょう。Sentry はスタックトレース、パンくずリスト、デバイス情報、さらに Unity や Unreal Engine のゲームにおけるスクリーンショットまでも提供し、クラッシュ発生直前の状況を正確に把握できるようにします。 より速く修正し、より賢くデプロイどのクラッシュが最も多くのプレイヤーに影響しているかを把握し、優先順位を付けて対応できます。また、リリースの健全性を追跡することで、問題の早期発見・対応が可能です。 ゲームのモニタリングとデバッグを始めましょう Unity や Unreal Engine […]
GitHub Actionsを使った Sentry Unreal Engine SDKの構築
Article by: Ivan Tustanivskyi ゲーム開発者にとって、シームレスなプレイヤー体験を提供することは非常に重要です。しかし、予期しないクラッシュやパフォーマンスの問題がゲームの評判を損ない、プレイヤーのエンゲージメントを妨げることがあります。 この問題に対処するためには、複数のプラットフォームで積極的なエラーモニタリングが必要です。 幸い、SentryはUnreal Engine専用に設計された強力なSDKを提供しており、開発者がデバッグとパフォーマンスの維持を効果的に行えるよう支援します。 しかし、Unreal Engine用のSDKを構築するのは容易ではありませんでした。設計時には、Unreal Engineの独特なアプリケーション構造やゲーム開発者が直面する課題を考慮しました。しかし、Sentryを真に効果的にするためには、開発中のエディタモードと製品版のゲームをさまざまなプラットフォームで動作させるために、エンジンとシームレスに統合する方法を見つける必要がありました。 本記事では、ゲーム開発者向けのデバッグソリューションを構築する際の課題と機会について解説します。以下のような方々にとって有益な内容となっているはずです。 Unreal Engine用のSDKを開発したい方 カスタムエンジンのプラグインにサードパーティライブラリを統合したい方 反復的なタスクを自動化し、開発ワークフローを効率化したい方 次世代の対策ゲームを支えるプラットフォームの構築方法に関心がある方 また、SentryのUnreal Engine SDKがサポートする以下のプラットフォーム向けのビルドとテストについても紹介します。 Android iOS macOS (x64 / arm64) Linux (x64 / arm64) Windows (x64) 注意: 本記事ではSentryのUnreal Engine SDKのすべての機能を説明していますが、フル活用するにはGitHubのリリースページからSDKをインストールする必要があります。Epic GamesのFab（旧Marketplace）で提供されているバージョンには一部制限があります。詳細については公式ドキュメントをご覧ください。 SentryのUnreal Engine SDKのアーキテクチャ設計 SentryのUnreal Engine用SDKは、ゲーム内クラッシュをキャプチャするためのクロスプラットフォームソリューションです。 複数のSentryネイティブSDKの上に構築された抽象化レイヤーとして機能し、統一されたC++/Blueprints APIを提供します。これにより、プラットフォーム固有の低レベルな実装に煩わされることなく、Unrealプラグインの設定に集中できます。 Sentry Unreal SDKには、ゲームビルド完了時にデバッグ情報ファイルを自動アップロードするSentry CLIも含まれています。 これらのデバッグファイルには、オリジナルの関数名、行番号、ファイルパス、スタックトレース、コールフレーム情報（CFI）などが含まれ、Sentryはこれらの情報を利用して、問題解決のための有益な洞察を提供します。 さらに、Unreal SDKはUnreal専用に構築されているため、SDKを導入するとAPIを呼び出し、エディタ内の自動インストゥルメンテーション機能を利用できます。 […]
【Unity開発】Sentry SDKを使用してパフォーマンスインサイトを有効にする方法
Sentry Unity SDKは、クラッシュの早期発見に効果的です。 以下をサポートしています。 IL2CPPのC# 例外での行番号サポート（リリースモードでも対応） Windows、macOS、Linux、Android、iOSでのネイティブクラッシュのキャプチャ C#を介して設定されたコンテキストは、ミニダンプを含むあらゆる種類のイベントに表示され、ゲームをエディターでビルドするときにデバッグシンボルが自動的にアップロードされる 私たちは、最良の『クラッシュ報告ソリューション』を提供していると確信しています。次に、ゲームのパフォーマンスに関する即座のインサイトを提供することを目標に掲げ、改良を進めていきました。 その中で、最初の問題に直面しました。 それは、Unityゲームの自動インストルメンテーションはどのようなものになるのか？という質問です。 SentryのパフォーマンスUXをUnityに適応する Sentryはスパンツリーの可視化を提供しており、モバイルおよびWebのインストルメンテーションは画面レンダリングに基づいています。 これらの概念をUnityに適用すれば良いと考えました。 その結果、最初のインストルメンテーションをゲームのスタートアッププロセスとシーンの読み込みに絞り込みました。 すべてのゲームは必ず何らかの基点から始まり、どんなに大きなゲームでも小さなゲームでも、シーンを読み込む必要があります。 いまの段階では、ゲーム全体のインサイトを提供することは難しいですが、パッケージをインストールした直後にSentryが提供できるものをすべての開発者に示すことが可能です。 理想的なシナリオは、ユーザーからほとんど設定なしで即座に動作するものです。以下のスクリーンショットがそのプレビュー画面です。こちらが、Unity SDKの自動インストルメンテーションが提供する内容です。コードは一行も書かずに、すべてのUnityゲームで利用することが可能となります。 さらに興味深いのは、これをどのように構築したか、そしてそれがゲーム開発のパフォーマンスサポートの未来にとって何を意味するかです。だからこそ、私たちはとてもワクワクしています。そして、開発者であるあなたもきっと興奮するトピックとなっているはずです。 【Unity向け Sentry SDK】マルチプラットフォームツール Unityゲームは基本的にすべてのプラットフォームで動作します。 それをサポートするために、Sentry SDK for Unityは『SDKのためのSDK』になりました。ターゲットプラットフォームにネイティブなSDKとP/Invoke（FFI）を通じて統合され提供されます。 iOSで動作するのか？ もちろん。問題ありません。 Apple向けSentry SDKを含めてサポートします。また同様に、AndroidやネイティブのLinux、Windowsでも対応しています。 結局のところ、これがネイティブクラッシュキャプチャのサポートを実現した方法なのです。これらのSDKが共通して持っている特徴は、Unity SDKを支えるだけでなく、すべて自動インストルメンテーションを提供している点です。 しかし残念ながら、これは限られた利用範囲にとどまります。 Unityの成功の鍵となる要素はそのプラットフォームの抽象化です。 開発者はプラットフォーム固有の問題を気にすることなく、Unityの内部に集中できるメリットがあります。Unityゲームは通常、非常に薄いランチャー内に組み込まれているため、ナビゲーションイベントやUIアクティビティのような基盤となるプラットフォームの概念は、一般的に開発者には馴染みがありません。インストルメンテーションが、真に役立ち実行可能であるためには、SDKはUnity内で直接動作する必要があります。 【Unityライフサイクル】インストルメンテーションのための重要なポイントを見つける ゲームは非常に高速なループで動作しており、通常は1秒間に30回から60回の更新を行いますが、上限はありません。 すべてのティックを測定するためにスパンを作成することは現実的ではありません。 私たちは、キャプチャしたい論理的な操作のセットなど、いくつかの主要なアクションに注目する必要がありました。 トランザクションとスパンを定義する課題 Sentryには、何かがどれくらいの時間を要するかを測定するための2つの概念があります。それは「トランザクション」と「スパン」です。 トランザクションは、ページの読み込みや非同期タスクのような、活動やサービスの単一のインスタンスのことをいいます。 スパンは、トランザクション内でネストされた個別の測定値のことです。 概念的には、私たち開発者は、測定したい特定のアクションに対して、巨大なストップウォッチを使って開始と終了の場所を見つけようとしています。 そして、そのアクション内で小さなストップウォッチでキャプチャできるサブタスクを探しています。 しかし、トランザクションはゲームのフレームワーク内でどのように適合するのでしょうか？ ゲームエンジンにすでに組み込まれているサービスのインスタンスが、どのようにトランザクションとして表現されるのでしょうか？ Unityはそのすべての機能にもかかわらず、あらゆる種類のゲームを作成するための真っ白なキャンバスです。 つまり、一般的なライフサイクルを除けば、SDKがスパンを開始および終了するためにフックできる固定されたポイントはあまり多くありません。ボタンのクリックなど、ワンタイムのイベントはたくさんありますが、SDKはボタンクリックの背後で何が起こっているかにどうフックするのでしょうか？ SDKは、スパンを終了するタイミングをどう判断するのでしょうか？ スタートアップとシーンの読み込みのタイミングを測定する […]
Reactでフェッチウォーターフォールを特定する方法
フェッチウォーターフォールは、複数のフェッチリクエストが並列ではなく、逐次的に呼び出されるシナリオです。これは深刻なパフォーマンス低下につながります。 以下にその様子を示します。 この場合、2番目と3番目のリクエストは並行してフェッチされ、ページロードとデータ表示が4.053秒改善されます。フェッチウォーターフォールによるパフォーマンスへの悪影響は、スタッキングでも発生します。つまり、リクエストが多ければ多いほど、パフォーマンスへの影響は悪化します。 この記事では、トレースを使用してReactアプリケーションのフェッチウォーターフォールを特定する方法を見ていきます。 トレース入門 トレースとは、あるプロセスやフローを定義する操作やコマンドの論理的なグループを記述するスパンの階層からなるデバッグ・データ・セットをキャプチャするために、コードを「インスツルメンテーション」するプロセスのことです。ページのロードを例にとってみましょう。 ページロードを操作の流れとして記述しようとすると、（おおよそ）次のようになるはずです。 ブラウザがサーバーにページをリクエストする サーバーはHTMLで応答し、ブラウザはそれを解析する パース中に、ブラウザはリンクされたJSファイルに出くわす。JSファイルにはReactとページコードが含まれているので、ブラウザはそれを実行する。 ブラウザは、ページコードの指示に従ってコンポーネントのフェッチとレンダリングを行う。 さらに、ブラウザーは画像、ファビコン、CSSファイルなどのリソースをリクエストする。 これらの処理はすべて特定の順序で行われますが、その時間はデバイスの処理能力やインターネット接続の速度などの要因によって異なります。 この記事のトップにあるスクリーンショットは、APIにHTTPリクエストを送信する3つのhttp.clientスパンを示しています。それぞれ、特定の開始時刻、特定の終了時刻、そして雑多なデータが添付されています。上のスクリーンショットのトレース・ビューを見ると、3つのHTTPリクエストが次々と実行されていることがよくわかります。 プロジェクトの設定 まず、ReactプロジェクトにSentryをセットアップする必要があります。始めるには、Sentry React SDKをインストールする必要があります。 この時点で、すでにサインアップしているはずです。新しいReactプロジェクトを作成しましょう。 Create Project」ボタンを押すと、React SDKのインストール方法と初期化方法が表示されます。初期化設定は以下のようにします。 Sentry SDKの最も優れた点は、コードベースの大部分を自動的に計測してくれることです。フェッチのような既知の操作を自動的にスパンでラップし、Sentryインスタンスに送信するので、すぐにデータの検査を開始できます。 これで、アプリをデプロイして、ユーザーがアプリを使用している間に測定された実際のパフォーマンスデータを得ることができます。データが得られれば、フェッチウォーターフォールのようなパフォーマンスの問題を特定するための調査を始めることができます。 Reactでフェッチウォーターフォールを識別するには？ フェッチウォーターフォールの症状には、著しく遅いページロードが含まれるため、不審に遅いページロードを警戒する必要があります。 Performanceページを使用すると、疑わしい遅いページロードを簡単にピックアップして検査することができます。以下は、私たちのアプリのインデックスページのPerformanceページのスクリーンショットで、ユーザーが私たちのページを訪問している間にキャプチャされたトランザクションを示しています。 どのスパンが不審に遅いか、はっきりとわかります。そのうちの1つをクリックすると、トレース・ビュー画面が表示され、すべてのスパンを見ることができます。http.clientのスパンを拡大してよく見ると、ウォーターフォールが見えます。 この場合、3番目のリクエストグループは、どの結果にも依存しないので、2番目のリクエストの終了を待つ必要はありません。つまり、フェッチウォーターフォールを分解すると、2秒の改善を見ていることになります。 フェッチウォーターフォールを修正するには、その原因を調べる必要があります。フェッチウォーターフォールはサーバーに原因があることもあります。フェッチ・ウォーターフォールのよくあるケースの修正方法についてもっと知りたい方は、「Reactにおけるフェッチウォーターフォール」の記事をご覧ください。 これを見ると、トレースを使って他のタイプの問題も解決できると思うかもしれません。そして、それは正しいでしょう！トレースは本当に一般的なデバッグ手法で、Web Vitalの不具合、ネットワークの遅延、サーバーレスアプリケーションのコールドスタート、キャッシュの欠落やキャッシュ機構の問題、その他様々な問題やバグを特定し、デバッグし、修正するのに役立ちます。トレースは、”トレース “をたどって、いつ何が起こったか、どれくらいの時間がかかったかを調べるようなデバッグや修正に使うことができます。 結論 つまり、トレースはフェッチウォーターフォールの特定に役立つということです。 簡単に復習しましょう。 トレースとはデバッグテクニックの一つで、ページロードのような操作の流れを視覚化しやすくするために、デバッグデータをキャプチャすることです。 トレースとは、互いに関連し、開始時刻と終了時刻を持ち、任意のデータが付加されたスパンのコレクションです。 アプリケーションでトレースのキャプチャを始めるために、私たちはSentryのReact SDKをインストールし、アプリのトップで初期化し、変更を単純にデプロイしました。SDKは自動的にアプリをインスツルメンテーションするので、トレースデータをすぐに見ることができました。 キャプチャされたトレースをすべてリストアップし、その継続時間に基づいて、どのトレースが不審に遅いかを確認できました。 遅いページロードを検査すると、最適化するとページロードを秒単位で改善できるフェッチウォーターフォールが見つかりました。 この記事が、トレースとは何か、どのように始めるべきかを理解する助けになれば幸いです。それでは、よいトレースを！ IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。