Sentry - Ichizoku

Next.jsのデバッグ手法はどうしたらいい？開発から本番公開までの実践的ヒントを解説

Article by: Matt Henderson, Sarah Guthals デバッグ…　それはすべての開発者にとって必要不可欠なスキルです。Next.js を使って動的で高性能なアプリケーションを構築する際、Chrome DevTools や console.log() だけでは対応しきれない場面もあります。またアプリケーションが成長していくにつれて、より効果的で体系的なデバッグ手法が求められるようになります。今回の記事では Next.js のデバッグワークショップで紹介した実践的なヒントを交えながら、開発段階から本番環境まで役立つデバッグ手法をご紹介します。今回は Next.js に特化した内容ですが、React アプリのデバッグについてもこちらで紹介しています。ぜひご一読ください。効果的な Next.js のデバッグツールとテクニックデバッグはエディタでコードを書きながらローカル環境でテストしている段階から始まります。まずはそこから解説していきます。そして最終的には、本番環境にデプロイされた後、開発チームではなく実際のユーザーがバグを発見するような場面でのデバッグ方法まで理解できるようになるはずです。 1. React Developer Tools を活用する Next.js は React を基盤としたフレームワークであり、幸いなことに React Developer Tools を使えば、コンポーネントの階層や props、state を直感的に確認できます。React DevTools を活用すると、以下のようなことが可能になります。・コンポーネントツリーを視覚的に把握できるため、動的ルーティングやサーバサイドレンダリング（SSR）を使用しても階層構造を理解しやすくなる・リアルタイムで state や props を解析、編集を行える・再レンダリングのトラッキングが可能になる・React Suspenseの遅延読み込みの挙動を可視化できる […]

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を呼び出し、エディタ内の自動インストゥルメンテーション機能を利用できます。 […]

インデックス不足でDBが遅い… Sentryで問題を見つけ修正する方法とは？

Article by: Will McMullen 遅いデータベースクエリは、開発者にもユーザーにも悪影響を及ぼします。リソースを浪費し、テストの遅延を引き起こし、動作が重くなることによってユーザーは不満を抱きます。しかし、多くの場合、驚くほど意外な解決策があります。それがインデックスです。ここでは、インデックスの仕組みと、その活用タイミングについて解説します。スキーマの種類を問わず役立つ内容です。すでにインデックスの基本と使い方を理解していて、遅いクエリの監視やデバッグ方法を知りたい場合は実践例をご覧ください。インデックスとは？インデックスとは何かご存じですか？簡単にいえば、データベースの「GPS」のようなものです。インデックスがないと、データベースは全ての行（レコード）を1つずつチェックしながら探し回らなければなりません。そうするとまるで迷子の観光客のように、目的地へ辿り着くまでに時間がかかってしまいます。しかし、インデックスがあれば無駄な回り道をすることなく、一直線でユーザーの目的地（ここでいう処理）へ辿り着くことができます。インデックスを技術的に解説すると、カラムの値を行にマッピングする小さなデータ構造のことを指しており、検索を高速化する役割を果たしています。例を見てみましょう。ユーザーテーブルやコレクションからメールアドレスを検索する場合、SQLデータベースではメールカラムに対するインデックスを次のように作成できます。 MongoDBやその他のNoSQLのドキュメント型データベースも、同様の方法でインデックスを活用します。例えば以下のコードのように、MongoDBではusersコレクションのemailフィールドを検索する際にインデックスを利用できます。インデックスは決して魔法のように万能ではありません。アルゴリズムの観点では、まるで魔法のように感じられることがあります（バイナリ検索木やハッシュマップを思い浮かべてください）。クエリがインデックス付きのフィールドを含む場合、データベースはテーブル内全ての探索を回避し、インデックスを使って効率的にデータを探します。これにより、クエリ速度が大幅に改善するのです。インデックスは万能ではないことを理解し、適切に使わなければ逆効果になることもあります。以下がその例の一部です。・書き込みの遅延データを追加・更新するたびにインデックスも更新されるため、書き込み処理が遅くなる・ストレージの増加インデックスを保持するための追加のストレージが必要・パフォーマンスの低下インデックスを増やしすぎると、データベースの最適化ツールが適切なインデックスを選びにくくなり、かえって処理が遅くなるそれでは次に、インデックスを適用すべきケースを具体的に見ていきましょう。 SQLとNoSQLにおけるインデックスの使いどきすべてのカラムやフィールドに、インデックスを付ければよいわけではありません。データベースへの負荷を抑えながら最適なパフォーマンスを得るには、インデックスの効果が最も大きい箇所に焦点を当てることが重要です。どこにインデックスを適用すべきか、この後の内容を踏まえて検討してみましょう。 SQLで一般的なインデックス主キー(Primary Key) 各テーブルには、一意の識別子となる主キー（例：id）があります。ほとんどのデータベースでは、主キーに対して自動的にインデックスが作成されるため、最も高速にデータを検索できます。外部キー(Foreign Key) テーブル同士を関連付けるキー（例：注文テーブルと顧客テーブルを結びつける customer_id など）のことです。これらのフィールドにインデックスを設定すると、JOIN処理のパフォーマンスが大幅に向上します。フィルター付きカラム WHERE・ORDER BY・GROUP BY などのフィルター条件に頻繁に使うカラムは、インデックスを設定することで検索速度を向上できます。例えば、次のSQLクエリをご覧ください。SELECT * FROM products WHERE category […]

セッションリプレイ機能で、デバッグをさらに正確かつ迅速にする方法

Article by: Sarah Guthals 開発者なら誰しも、デバッグに時間がかかることを痛感した経験があるでしょう。なかなか再現できないバグを追いかけたり、あいまいなユーザー報告を頼りに問題を特定しようとしたりすると、シンプルな修正のはずが何時間もの作業になってしまうこともありますよね。ログやメトリクス、トレースを活用すれば原因の特定に役立ちますが、それだけではユーザーへの影響を正確に把握するのは難しいものです。そこで役立つのがセッションリプレイです。ユーザーセッションをビデオのように再生できるこのツールを使えば、デバッグ効率が飛躍的に向上します。ユーザーからの報告を待つ必要も、あいまいな再現手順に振り回されることも、すべての環境を完璧に再現する必要もありません。セッションリプレイを使えば、「どこで」「何が起こったのか」を正確に把握することが可能です。この記事では、Sentryのセッションリプレイの仕組みと、それがどのようにデバッグの効率化、ユーザーとのやり取りの削減、さらにはアプリケーションのパフォーマンス向上に役立つのかを詳しく解説します。セッションリプレイとは？もし、ユーザーがアプリを操作する様子をリアルタイムで映像として確認できたらどうでしょうか？クラッシュやパフォーマンスの問題が発生するまでの流れを、正確にたどることができたらどうでしょうか？セッションリプレイは、まさにそのための機能です。ユーザーのクリック、スクロール、入力操作などを記録し、それをネットワークアクティビティやコンソールログ、エラーの詳細、さらにはCore Web Vitalsとあわせて表示します。これにより、問題発生までの流れを可視化し、トラブルシューティングの際の「推測」をなくすことができます。従来のデバッグ手法であるスタックトレースやログは、バグの再現や原因の特定に必要な情報をすべて提供できるとは限りません。特に、問題の発生状況が不明確な場合、それだけでは十分なコンテキストを得るのが難しいこともあります。セッションリプレイを活用すれば、ユーザーがどのような操作を行い、それに対してアプリがどのように反応したのかを視覚的に確認できます。そのため推測に頼ることなく、より素早く正確に問題の原因を特定できます。なぜセッションリプレイを活用すべきなのかセッションリプレイの利点は、開発者のワークフローやチームの体制、ユーザーの特性、アプリケーションの種類によって多少異なります。しかし、デバッグの効率化やユーザー体験の向上といった点で、どんな開発環境にも共通して有益なメリットがいくつかあります。デバッグ効率を飛躍的に向上させるエラーレポートを受け取った際、詳細を確認するために何度もユーザーとやり取りをした経験はありませんか？問題の説明を詳しく聞いたり、スクリーンショットを依頼したり、ネットワークログを取得してもらったりするのは、開発者・ユーザー双方にとって大きな負担となります。セッションリプレイを使えば、こうした手間を省くことができます。ユーザーが問題を報告する前の段階から、エラーが発生するまでの操作をビデオのように正確に再現できるため、原因を素早く特定し、スムーズに修正作業に取り掛かることが可能なのです。さらに詳しくセッションリプレイを活用して、ユーザーの追加情報なしで問題を解決する Next.jsのデバッグでAPIの読み込み時間を短縮し、より快適なユーザー体験を提供再現が難しい複雑なバグにも対応可能バグの再現は、特に発生頻度が低いものほど厄介な存在です。フロントエンドとバックエンドの複雑な連携によって発生する問題は、一つひとつの要因を切り分けて特定するのに数時間かけてしまうことも珍しくありません。 Sentryのセッションリプレイを活用すれば、これらの問題が発生した瞬間をリアルタイムで自動記録できます。どのUI操作がバックエンドのエラーやAPIリクエストの失敗につながったのかを正確に把握できるため、無駄な試行錯誤を減らし、迅速に修正へとつなげられます。さらに詳しくセッションリプレイの機能強化: バックエンドエラーの導入エンドツーエンドの可視化を実現 Sentryのトレース機能と組み合わせることで、セッションリプレイはフロントエンドのクリックからバックエンドのAPIコールまで、処理の流れを可視化します。例えば、APIのレスポンスが遅くてユーザー体験に影響を与えている場合、セッションリプレイを使えば、ユーザーがその影響を受けた正確なタイミングを特定できます。さらに、Sentryのネットワークトレースを活用すれば、サーバーの応答遅延や設定ミスによるエンドポイントの問題などを素早く特定でき、迅速な対応が可能になります。さらに詳しく開発者向けセッションリプレイ: より速いトラブルシューティングへの近道ユーザー体験の向上をサポートバグを素早く修正するだけでなく、問題が広がる前に先手を打つことも重要です。セッションリプレイを活用すると、ユーザーがどのようにアプリを操作しているのかを把握でき、特定の操作で行き詰まったり、パフォーマンスの問題に直面したりしている箇所を可視化することが可能です。こうした問題を事前に修正することで、ユーザー体験を向上させ、アプリの継続利用につなげることができます。さらに詳しくセッションリプレイを使って複雑なスタックトレースをデバッグする […]

手遅れになる前に！不安定なテストを見つけて対策する方法

Article by: Artem Zakharchenko この記事は、JavaScript用のAPIモックライブラリ「MSWJS」の作成者であるArtem Zakharchenkoによるゲスト投稿です。彼はEpicWebや自身のブログでも、テストに関する記事を執筆しています。テストの不安定さ（フレーク性）は大きな課題です。検出して修正するには膨大な時間がかかるだけでなく、テストの最も重要な価値である「信頼性」を損なう原因にもなります。信頼できないテストは、存在する意味がありません。そのメンテナンスに費やす時間も、結果的には無駄となってしまい、本来なら開発に充てられたはずの貴重な時間までも奪ってしまいます。私はこれまでに、フレークテストへの対処法をご紹介してきましたが、今回はその根本原因である「不安定なテスト（フレークテスト）をいかに見つけるか」についてお話ししていきます。フレークテストの根本原因テストを重ねる中で学んだことの一つに、「テストの不安定さはシステムのあらゆる層に潜んでいる」ということです。テストの書き方、セットアップの方法、使用しているツール、さらにはそれらを実行するハードウェアに至るまで、どの部分にも問題の種は潜んでいます。エンドツーエンド（以降、E2Eと表記）テストが特に不安定だと言われるのは、決して偶然ではありません。システムの端から端まで、多くの要素が絡み合うため、どこで問題が発生してもおかしくありません。それに加えて、E2Eテストはメンテナンスコストが高く、チームの誰もが対処をためらうような厄介な存在になることも多くあります。さらに厄介なのは、フレークテストの「たまに失敗する」という性質が、問題の深刻さを見落としやすくすることです。複数の層が関わっていると、「たまたまどこかで問題が起きただけ」と片付けてしまいがちです。「再実行」ボタンを押してテストが通れば、それで良しとしてしまうことも少なくありません。残念ながら、ほとんどのチームは初期のフレークテストをこうして放置します。一度無視し、二度無視し、気づけばCIの結果に一喜一憂しながら、テストが緑になるまで再実行を繰り返す。そんな状況に陥ってしまうのです。〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 E2Eテスト自体を諦めてしまったチームと話したことがあります。最終的に、テストスイートの信頼性が失われてしまったことが原因でした。しかし、本来の自動テストはそうあるべきではありません。フレークテストに対処する方法大規模なチームでは、特にフレークテストの問題が見過ごされることがあります。そもそも、自分がそのテストの不安定さに直面していないかもしれませんし、何度も再実行する必要がない場合もあります。影響を受けているチームメンバーも、「仕方がないもの」と受け入れてしまうことが少なくありません。しかし、そんなテストのフレーク性は最終的にチーム全体の生産性を低下させます。重要なプルリクエストが、ただテストが通るまで再実行を繰り返す「リトライゲーム」のせいで滞ってしまうのは、非常に厄介です。私自身も、そうした状況に何度も直面してきました。だからこそ、私はビルドを常に安定させ、フレーク性を見つけ次第、徹底的に排除することに注力しています。そのためにも、フレークテストを検出し、追跡できるツールを活用するのは非常に有効です。最近、CodecovがTest Analyticsを発表したので、早速試してみることにしました。最も一般的なフレークテストの原因を意図的に再現し、それをどのように検出・修正できるのかを検証するのが、一番の近道だからです。フレークテストの検出を検証するここでは、Vitestのブラウザモードを使用して、シンプルなブラウザ内テストを実施します。今回テストするのは、ユーザーの投稿リストをレンダリングする<App />コンポーネントです。かなりシンプルな内容ですが、鋭い方なら既に問題に気づいているかもしれません。しかし、もし私がそれに気づかなかったとしたら、どうでしょうか？私はこのテストを書き、実行し、成功を確認し、変更を承認しました。そして今、このテストはチーム全員のメインブランチで実行される状態になっています。ここで、テスト分析を導入してフレークテストを追跡すると、どのような影響があるのかを見てみましょう。 CodecovのTest Analyticsを導入する Test Analyticsは Codecov の一部として提供されており、フレークテストの検出機能も備えています。公開リポジトリに対しては無料で利用でき、プライベートリポジトリでは Pro またはEnterprise プランが必要です。プロジェクトへの統合はわずか3ステップで完了します。 Codecov […]

【締切終了】Sentry 日本語記事投稿プレゼントキャンペーン

☆キャンペーン期間延長☆ 引き続きご応募お待ちしております！＼Sentry日本語記事投稿キャンペーン延長決定／今日から今月末（3/31）まで期間を延長決定！前回も最大31名に賞品が当たる予定でした。。けど投稿者が下回ったので。。。＼全員に賞品を配りました🤡／ Sentryを日頃使っていてもいなくても大丈夫引き続き240ドル分のクーポンをお配り致します🚀… pic.twitter.com/OoIQ80Wdsb — Sentry Japan (@SentryJapan) March 17, 2025 キャンペーンのポイント最大31名に豪華景品が当たるチャンス！ Mac miniやVRヘッドセットなど、当選後にお好きなプレゼントを選択可能！先着100名の方には特典をご用意！参加者全員にSentryクーポンをプレゼント！「Sentryを使ったことがある方はもちろん、使ったことがない方にもチャンス」Sentryをもっと便利に使うためのTipsや導入事例、活用方法を共有しましょう！」という企画！抽選でのプレゼントもあるのでぜひ気軽にご参加ください！こんな人におすすめ既にご活用されていて、知見やアイデアをお持ちの方 Sentry を使い始められたばかりの方 Sentryに興味があり、これから使っていきたいとお考えの方（無料で使えるプランもご提供しています）豪華景品ラインナップ最大31名様にプレゼント！当選された方は、当選した賞からお好きなプレゼントが選べます！ ⭐️ Sentry賞 1名様 ⭐️ Mac Mini Mac miniが、さらに小さくなって登場。M4チップまたはM4 Proチップを搭載。Apple Intelligenceのために設計。ポートを背面に、そして前面にも用意。初めてのカーボンニュートラルなMacです。 apple.com/jp/mac-mini/ ⭐️ 最も助けられたで賞 1名様 ⭐️ […]

【必読】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オブジェクトを構築し、計算し、配列に追加し、その配列をソートして返します。 […]

【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 Nativeの新しいデバッグ手法

これはSimon Grimmによるゲスト投稿で、SimonはGalaxies.devの創設者です。Galaxies.devでは、Simonが開発者にReact Nativeを学ぶための迅速なコースと個別サポートを提供しています。是非ご覧ください。従来、React Nativeアプリのデバッグは、面倒な作業として開発者を悩ませてきました。開発者にとって一般的にデバッグがReact Nativeの最大の課題と考えており、これが開発時間のかなりの部分を占めていることはよく知られています。しかし、良いニュースがあります！この課題は、改善されつつあるということです。 React Nativeのデバッグ環境は、ここ数年で大きく変わりました。Expo はデバッグを大幅に簡単にする新しいプラグインのセットに取り組んでおり、Flipper は非推奨となり、React Nativeチームは古いツールよりも大幅に改善された新しいDevToolsに取り組んでいます。新しいReact Native DevToolsは素晴らしいですが、それでもまだ課題がいくつか残っています。このチュートリアルでは、React Nativeアプリのデバッグに利用できるさまざまなツールを探り、それらをどのように組み合わせて包括的なデバッグ戦略を作成するか見ていきます。 JavaScriptからネイティブコードまで全てをカバーし、アプリで何が起こっているのかを正確に把握し、すべてのエラーを追跡できるようにします。新しいReact Native DevToolsの良い点新しいReact Native DevToolsの特徴は、Web開発の体験に合わせていることです。 DevToolsは、（Expoプロジェクトの場合）次のコマンドを実行し、ターミナルで「j」を押すことで開くことができます。これにより、少し馴染みのあるビューが表示されます。主な機能は以下の通りです。 Logs: アプリからのログを表示し、フィルタリングする。 Source & Breakpoints: JavaScriptコードをデバッグする。 Components Explorer: コンポーネントの階層を可視化し、propsやstateを検査する。さらに、Expoのネットワークタブを使用してネットワークリクエストを検査することもできます（現在はunstable(不安定)とマークされていますが、最終的にはDevToolsのコア機能となる予定です）。 React Nativeチームの努力のおかげで、新しいDevToolsは旧バージョンより大幅に改善され、非常に安定していると感じられます — しばらくしてから再接続できる機能も含まれています。さらに、コンポーネントツリーを直接デバッグできる機能により、別のツールを使う必要がなくなり、ほとんどのReact開発者はこのようなビューに馴染みがあるはずです。しかし、これらすべては始まりに過ぎません。チームはすでに次の機能を計画しています。 Performance panel：進行中（来年を目標にしています）。 Network panel：進行中（来年を目標にしています）。 Third party Chrome extensions（サードパーティ製のChrome拡張機能）：初期探索中。Expoと協力中（予定時期未定）。しかし、まだいくつかのギャップがあり、最初はためらっていたものの、Reactotronは今でも重要であることに気づきました。 […]

【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() […]

Archives: Sentry