【Sentry＆エッジデプロイメント】レイテンシの測定と改善方法
Article by: Kyle Tryon 本ブログの内容 レイテンシの特定 なぜエッジコンピューティングが重要なのか エッジで計算するには？ TL;DR Google の研究者たちが 2017 年に行った調査によると、次のような結果が得られました。 ページの読み込み時間が 1 秒から 3 秒になると、ユーザーが離脱する確率は 32% 増加する。 これは8年以上も前の話です。そして正直なところ、それからユーザーの忍耐力が増したとは考えにくいでしょう。 Web Vitals とは、Google が定義した一連のパフォーマンス指標で、ユーザー体験を測定するためのものです。たとえば次のような要素に着目しています。 LCP（Largest Contentful Paint）：主要コンテンツが読み込まれるまでの時間 INP（Interaction to Next Paint）：ページが入力に反応するまでの速さ CLS（Cumulative Layout Shift）：アプリの視覚的な安定性（＝コンテンツが予期せずずれ動くかどうか） わずか 1 秒の遅延でさえ売上の減少や登録機会の損失につながる可能性があるため、あらゆる観点からレイテンシ（遅延）を調査することが重要です。 どれだけ最適化されたアプリケーションであっても、プルリクエスト（PR）だけでは解決できないボトルネックが少なくとも1つは存在します。それが「距離（distance）」です。 レイテンシの特定 見えないものは、直すことができません。 たとえば、あなたのサービスがアメリカ国内の単一サーバー上で稼働している場合、アジアやヨーロッパといったより遠方にいるユーザーは、単純にリクエストの移動距離が長くなるため、読み込み速度が遅くなるのは自然なことです。 ここでは、Sentry を使って地域ごとのレイテンシの影響を測定・可視化するための基本的なセットアップ手順を紹介します。 テスト環境の構築 今回は、フロントエンドアプリとバックエンド API […]
【Laravel】デバッグとログ記録
Article by: Kyle Tryon 本ブログの内容 サンプルプロジェクトのセットアップ Monolog を使った Laravel のログ記録 Laravel をデバッグするために使うべきツール Laravel アプリのパフォーマンス問題をトラブルシュートし修正する 本番環境で Sentry を使って Laravel をデバッグ・ロギングする Laravel をよりスマートにデバッグする ロジックエラー、失敗した HTTP リクエスト、気付かれずに消えるバックグラウンドジョブ。ソフトウェアはあらゆる「楽しい」形で壊れます。強靭なシステムと脆いシステムの違いは、エラーを完全に回避できるかどうかではありません。何が問題だったのかを、いかに素早く、明確に把握し、修正できるかにかかっています。 Laravel はしっかりとした基盤を提供します。構造化ログ、リアルタイムでの内部観察、そして組み込みのパフォーマンス監視。開発やステージング環境では、dd()、Log::debug()、Monolog、Telescope、Debugbar、Xdebug といったツールを使って、内部を覗き込むことができます。しかし、本番環境はまったく別物です。 本番環境でフロントエンドとバックエンド両方のエラー、遅延、そして再現が難しいエッジケースにわたる完全な可視性を確保するために、Sentry は Laravel アプリに統合され、必要な時に必要なコンテキストを、異なるサービスを横断して提供します。 このガイドでは、いくつかの Laravel デバッグツールについて説明します。それぞれが何をするのか、どのような場面で使うべきか、そしてログを掘り返したり環境ごとに何が悪かったのかを推測したりせずに、適切なインサイトを得る方法を解説します。 前提条件 すでにお使いのコンピュータに Laravel 12 がインストールされている場合は、それを使用できます。 ただし、このガイドでは別のアプローチを取り、Docker コンテナ内でサンプルを実行します。Docker を使うことで、この記事内のコードはあらゆるオペレーティングシステム上で実行でき、セキュアなサンドボックス内で個人ファイルから安全に分離され、特定のバージョンの Laravel、Node、PHP をインストールする必要もありません。 また、このガイドでは Git がインストールされていることを前提としていますが、必要であればサンプルリポジトリを手動でダウンロードして解凍することもできます。 サンプルプロジェクトのセットアップ Laravel […]
ダウンタイムの一般的な原因とウェブサイト監視のメリット
Article by: Lewis D. 本ブログの内容 どの Sentry 機能が使用されているのか ウェブサイト監視による過負荷の検出 アップタイム監視による不良デプロイの検知 アップタイム監視による依存関係問題の検知 なぜアップタイム監視だけではセキュリティ脆弱性を検知できないのか ユーザーに指摘される前にダウンタイムのアラートを受け取る ダウンタイムは、最も都合の悪い瞬間に発生します。例えば、「クイックデプロイ」の直後や、思い切って5分間離れた時などです。トラフィックの急増によってエンドポイントの一つが集中的にダウンし、他のエンドポイントもダウンしてしまうかもしれません。あるいは、自信を持って本番環境に直送した「小さな変更」が原因かもしれません。 どちらの場合も、ユーザーはサイトにアクセスできず、現在は本番環境でライブデバッグを行っています。 この記事では、基本的なウェブサイト監視によって、ステータスページの更新、Slack の通知、ツイートなどの前に、より早く問題を発見できる方法を解説します。シンプルな Node.js Express アプリを用いて、監視によってパターンやボトルネックが明らかになり、ひょっとするとコーヒーを飲み終える時間を稼ぐことができる方法をご紹介します。 本題に入る前に少し余談ですが、物事をシンプルにし、完全に理論的な話にならないようにするために、基本的な Node.js Express アプリを立ち上げ、完全なエンタープライズ監視スタックにすることなく、実用的な監視機能だけに接続しました。 私が設定した内容は次のとおりです。 Sentry トレーシングなので、何かが壊れたときにアラートが届きます。 ソース マップは Sentry Wizard 経由でアップロードされます。縮小されたスタック トレースは最悪だからです。 アプリを軽量ホスティングサービスに投入 Sentry にアップタイム監視アラートを作成しました。これは、パブリックエンドポイントにpingを送信し、応答が停止した場合にアラートを出します。トレーシングとは別に動作するため、アプリがエラーを投げていなくても、全く応答していない状態を検知します。 どの Sentry 機能が使用されているのか この記事で紹介する Sentry のすべての機能とその役割を簡単にまとめたマップを以下に示します。 特徴 監視対象 以下に使用されている箇所 アップタイム監視 パブリックURLまたはエンドポイントにアクセスできるかどうか エンドポイントによってサイト全体がクラッシュしたときに、最初のアラートが出され、その後、別の分離されたエンドポイントルートに対してアラートが出されます。 エラー監視 処理されない例外とログに記録されたエラー 不適切なデプロイ後に発生した パッケージ欠如によるスタックトレース […]
アプリケーションのパフォーマンスを関数呼び出しレベルまでデバッグ ― 継続的プロファイリングとUIプロファイリングの導入
Article by: Will McMullen 本番環境で何かの動作が遅くなった場合、古い習慣に陥りやすいものです。ログをいくつか追加し、メトリクスを送信し、ローカルで問題の再現を試みます。意欲があれば perf や py-spy に手を伸ばすかもしれません。トレースは役立ちますが、特にスタックの深い部分では、「なぜ遅いのか」を説明するには不十分なことがあります。 つまり、開発者がアプリケーションの挙動を、直感に頼って推測せざるを得ない場面が生じます。たとえば、プロパティドリルによってレンダリングが肥大化していたり、状態変更によって不要な再レンダリングが発生していたり、あるいはサードパーティ製のライブラリが静かに 500 個のイベントリスナーを起動していたりするかもしれません。 こうしたときにこそ、プロファイリングが役に立ちます。プロファイリングは症状を指摘するだけでなく、CPUを消費している関数呼び出しやファイル、行番号を正確に表示します。 本日、私たちは Continuous プロファイリング と UI プロファイリング の2つの強力なプロファイラーをリリースします。実行時の動作を関数レベルで可視化し、ボトルネックを迅速に特定して解決するための機能を提供します。 バックエンドのボトルネックを特定して解決する Continuous プロファイリング 開発マシンでは問題なく動作していました。ステージングテストも問題なし。しかし、本番環境で実際の負荷がかかると、その重要な API エンドポイントが突然遅くなったり、バックグラウンドワーカーが予期せず大量のメモリを消費したりすることがあります。ログは正常に見え、トレースによってサービスがアクセスされたことも確認できているのに、内部のボトルネックが特定できない…。そのようなとき、開発者は再現が困難な問題や、隠れた非効率性を推測するしかありません。 継続的プロファイリングは、このような状況において、バックエンドの実行状況を常時可視化を提供します。長時間実行されるワークロード、リアルタイム API、「ローカルでは問題なかった」と片付けられがちなコードパスの解析に最適です。 特に、以下のような場合に役立ちます。 CPU ホットスポット：あるエンドポイントが突然 CPU 使用率が3倍に急増し、原因が分からない場合、プロファイリングは機能レベルのボトルネックを直接特定できます。 バッチジョブ：何時間も静かに実行される（時にはクラウド請求を倍増させる）あの夜間処理。いまでは、それが どこで時間を費やしているのかを正確に確認できる ようになりました。 ML パイプライン：あるモデルパイプラインで発生していたレイテンシのスパイクを、プロファイリング を使ってわずか 10 分ほどで、10 秒短縮しました。調べてみると、パイプラインの一部が「想定以上の処理」をしていたのです。詳細はこちらをご覧ください。 アナリティクス：あなたの「インサイトエンジン」が、実際には数百万行を回すだけのループにすぎないこともあります。プロファイリングは、ログやメトリクスでは見えない非効率を、プロダクション環境に影響が出る前に発見する手助けをします。 バックエンドサービスのパフォーマンスは、ブラックボックスのままである必要はありません。Continuous プロファイリング を使えば、インフラコストの最適化、API レスポンスの遅延削減、スループットの向上が可能になり、Slack が通知であふれる前に非効率を簡単に見つけられます。 現在、Node.jsとPythonを標準でサポートしています。 […]
Vercel マーケットプレイスに新カテゴリー追加・Sentry 対応開始
Article by: Cody De Arkland 来年にかけて、これまでの10年間よりも多くの人々がアプリケーションを構築・出荷するようになるでしょう。あらゆる経験レベルの開発者によって「ローンチ」されるアプリケーションが増えるにつれ、「何が壊れたのか」「なぜ壊れたのか」、そしてそれを修正するための明確な道筋を理解することが、ますます重要になります。 こうした背景から、Sentry は Vercel の新たな Observability Marketplace カテゴリーにおいて、最初のプラットフォームとしてローンチされました。 Sentry は、ソフトウェアを構築するすべての人が、メトリックの行をたどってデバッグを強いられたり、特別なダッシュボードビューを手作業で作成して問題の原因を探ったりすることなく、安心してソフトウェアを出荷できるようにしたいと考えています。 Sentry を開発が生まれる現場へ ソフトウェアの開発速度が加速する中で、コードが壊れることは避けられません。そこで、Vercel を通じて Sentry を簡単に利用できるようにすることで、開発者は壊れたコードを迅速に修正するための最短ルートを手に入れることができます。 私たちは、開発者が最も利用するエコシステムへの継続的な投資を通じて、最良の開発者体験を提供することに注力しています。これにより、開発チームはソフトウェアの出荷において最も重要な部分に集中できるようになります。 この開発者体験の大部分は、Next.js のような主要なプラットフォームにおいて、可能な限り摩擦のない体験を提供できているかどうかにかかっています。 開発者は、1 行のコマンドを実行するだけで Next.js 上で Sentry を導入できます。これにより、クライアント・サーバー・エッジにわたる設定が自動的に行われ、コードのソースマップが生成され、エラー境界も実装されます。 Next.js アプリケーションでは、初回の設定コマンドを実行するだけで、エラーモニタリング、リプレイ、トレーシングが自動的に構成されるようになっています。これにより、アプリケーションの遅延や複雑なハイドレーションエラー、RSCに関する問題まで、あらゆる不具合を開発チームが迅速にデバッグできるようになります。 しかし、これで終わりではありません！ 現在、Next.js に特化した新しいインサイトダッシュボードの開発に取り組んでいます。これは、Next.js を利用する開発者に対し、フレームワーク特有の視点からの環境モニタリング機能を提供することを目的としています。 フレームワーク固有のインサイトページは、特定のフレームワークに投資した開発者に、監視プラットフォームから最も価値を得ている情報に密接に一致するインサイトを提供するように設計されています。 私たちは、従来型の監視ツールについて、非常に多くの冗談を言ってきました。というのも、それらはしばしばユーザーを複雑なダッシュボードに縛りつけ、過剰に複雑なデータの解釈を強いるからです。そのため、一見すると Next.js 専用のダッシュボードは、かえって過去に戻るように感じられるかもしれません。 ですが、ぜひ私たちの意図を聞いてください。開発者や運用チームが、Sentry の各機能からより多くのコンテキストを得られることに、私たちは強い関心を持っています。 Next.js アプリケーションは、フロントエンドとバックエンド、RSC、SSRといった技術のユニークな組み合わせを特徴としています。これらの特性に最適化されたビューを構築することで、開発者や運用チームがアプリケーション全体の状況をより深く理解し、適切な判断を下すための助けとなります。 Vercel マーケットプレイスでの Sentry Native 統合 本日（April 8, […]
【PHP】パフォーマンスを改善する方法
Article by: Richard C. 本ブログの内容 前提条件 プロファイリングとは？ SPX を使った PHP プロファイリング トレーシングとは？ OpenTelemetry を使った PHP のトレーシング フロントエンドを含む分散トレーシング オンラインサービスを使ったプロファイリングとトレーシング クリーンアップ PHP のパフォーマンスを改善するヒント 次のステップ PHP アプリは一見シンプルに見えますが、何かが遅くなり始めると状況は一変します。ページの読み込みに数秒余計にかかったり、原因がはっきりしないままサーバーコストが増加していたりしませんか？そんなときに役立つのがパフォーマンスモニタリングです。 このガイドでは、PHP アプリケーションのパフォーマンスを監視・改善する方法を解説します。プロファイリングやトレーシングを使ってコードのボトルネックを特定し、アプリを最適化する方法を学びましょう。Docker を使っている場合でも、すでにローカルに PHP をインストールしている場合でも、例に沿って進めることができます。 このガイドの内容は PHP 8 に対応しており、将来的な変更の程度によってはそれ以上のバージョンにも適用可能です。 前提条件 本ガイドに含まれるすべてのコード例は、Docker を使って任意のホスト OS 上で実行できます。Docker をお持ちでない場合は、こちらからダウンロードしてください。 すでに PHP がインストールされている場合、Docker は不要です。 次のセクションでは、プロファイリングとトレーシングを使って処理が遅いコード部分を特定する方法を紹介します。最後には、サイトのパフォーマンスを改善するためのベストプラクティスのチェックリストも掲載しています。 プロファイリングとは？ アプリケーションのプロファイリングとは、パフォーマンスデータを記録し、改善の余地があるコードを特定するために分析することです。パフォーマンス指標には、アプリがユーザーのために機能を実行するのにかかる時間、実行中に使用される CPU、メモリ、ディスク、ネットワーク帯域などが含まれます。これらすべての指標の値が低いほど、ユーザー体験が向上し、サーバーコストの削減にもつながります。 記録された結果を分析することで、意図よりも高い値の指標を特定し、その原因となっているコード行を見つけます。 […]
【Python】エラーと例外処理の実践的なヒント
Article by: Abdul D 本ブログの内容 Python におけるエラーと例外 − その違いとは Python におけるエラー Pythonにおける例外 なぜ Python において例外・エラー処理が重要なのか Sentry は Python アプリのエラー監視にどのように役立つのか Python のコードで、原因か分からないエラーメッセージに遭遇したことはありませんか？ それはあなただけではありません。経験豊富な開発者でさえ例外に直面するため、効果的に対処する方法を理解することが重要です。 基本的な構文エラーはコードエディタやデバッグツールによって早期に検出できますが、より複雑な問題は実行時に発生することが多く、体系的な例外処理のアプローチが求められます。 経験の有無にかかわらず、すべての Python 開発者が例外処理を習得することで恩恵を受けられます。本ガイドでは、エラーと例外の違いを理解し、一般的な例外の種類を確認したうえで、Python アプリケーションにおける適切な対処方法を学びます。 また、Sentry を使ってリアルタイムで例外を監視・追跡する方法についても解説し、アプリケーションのパフォーマンスと安定性に関する詳細なインサイトを得る手段を紹介します。 Sentry トレーシング Python におけるエラーと例外 − その違いとは 完璧なコードを書くことは非現実的な期待であり、すべての開発者はコーディングミスによる予期しない動作に直面するものです。これらの問題は一般的にエラーと例外の2つに分類されます。 エラーはプログラムの実行を完全に妨げる根本的なコーディングミスです。エラーは通常コンパイル時に検出され、修正されるまでコードは実行されません。 例外はエラーの一種であり、プログラムの実行中（ランタイム）に予期しない状況、例えばゼロ除算のような場合に発生します。 result = 10 / 0 # Raises ZeroDivisionError エラーとは異なり、例外はコード内で捕捉して処理することができます。 エラー処理 vs デバッグ […]
JavaScript にも Debug ID が必要
Article by: Abhijeet Prasad 数か月前、Sentry は Debug ID 用の新しい NPM 組織（名前空間）を作成し、その配下に複数のパッケージを公開しました。https://www.npmjs.com/org/debugids これは、JavaScript Debug ID がエコシステム全体で正式に認知されるための大きな一歩です。同時に、Sentry がオープンスタンダードを牽引し、合意形成に取り組む成熟度を示しています。 ———————————————————————————– 💡 要点まとめ Debug ID は JavaScript ファイルとそのソースマップを結びつける決定論的かつグローバルに一意な値です。 Sentry は Debug ID を Sentry 独自の機能にとどまらず、JavaScript エコシステム全体で広く利用される概念にしようとしています。 Debug ID をソースマップ仕様に追加するため、tc39 に公式提案を提出し、ブラウザ API も含めた標準化を推進しています。 誰でもツールやアプリに Debug ID 機能を追加できるよう、各種プラグイン・ツール・ポリフィルを公開済みです。また、バンドラーやソースマップツールへの対応を JavaScript コミュニティと協力して進めています。 詳しく知りたい方は、ぜひ読み進めてください。 Debug ID とは何か 現代のウェブサイト開発者は、JavaScript […]
【React Native】ログ出力ガイド
Article by: Matthew C. コンソールによる基本的なログ出力は、アプリのデバッグや理解を始める上で良い出発点です。より大規模で複雑なアプリでは、追加情報の記録やログの永続化が有効になります。 このガイドでは、React Native においてログを作成・表示する方法、カスタムログをファイルに保存する方法を学びます。 JavaScript のログを中心に扱いますが、Sentry の React Native SDK を使用し、従来のログを超えたエラー・例外の自動報告やそれに至るイベントの可視化方法についても紹介します。 コンソールメソッドとログレベル React Native では、Web ブラウザと同じコンソールメソッドが使用できます。 ほとんどのコンソールメソッドには、重大度（Severity）のレベルが割り当てられています。以下の 4 段階があり、軽いものから重いものの順に、それぞれの用途を示しています。 Verbose（冗長）：デバッグ用のログメッセージ。 Info（情報）：コードが期待通りに動作しているときのログ（例：ユーザーが支払いを完了した時）。 Warning（警告）：問題につながる可能性のあるイベントのログ。 Error（エラー）：実際のエラーのログ。 以下の表はよく使われるコンソールメソッドと、それぞれに割り当てられたログレベルを示したものです。 console.debug メソッドは、console.log や console.info と同様に動作しますが、ログレベルが異なります。console.trace メソッドは、スタックトレース（関数の呼び出し履歴）をコンソールに出力するために使用されます。 console.time と console.timeEnd メソッドを組み合わせて使用することで、処理にかかる時間を測定できます。 オブジェクトのログ出力 本番環境のアプリケーションでは、文字列よりもオブジェクトをログに出力した方が良い場合があります。 構造化されたログ出力（Structured Logging）により、JSON としてパース可能なログファイルが作成されます。これにより、監査ツールでログをデータベースのように検索できます。可能であれば、あらかじめログプロパティのセットを定義しておくと、ログの整理や検索がしやすくなり、エラー追跡や分析がよりスムーズになります。 コンソールログの表示方法 React Native の開発サーバーを起動すると、Metro […]
【Mobile Vitals】ユーザーがアンインストールする前にモバイルアプリの動作遅延を修正
Article by: Will McMullen, Markus Hintersteiner モバイル開発者なら、この苦労をよく知っているはずです。小さなリグレッションが本番環境では大きな問題につながることがあります。しかも、それを修正するのは簡単なパッチを即座に反映すれば済むというものではありません。Webアプリと違って、モバイルアプリの修正にはアプリストアの審査を通す必要があり、場合によってはクライアントとのミーティングに参加し、再現が難しい問題のデバッグに取り組むこともあります。 ★1レビューが届く前に、こうした問題を検知することが極めて重要です。幸いなことに、Sentry がこの作業をこれまでになく簡単にしてくれました。 Mobile Vitals ― インサイト機能に新たに追加されたこのツールは、アプリの起動や画面の読み込み、描画が遅い箇所をハイライト表示することで、フリーズやラグによる操作不良を、ユーザーが怒ってアプリを終了してしまう前に迅速に対処できます。React Native、Flutter、Android、iOS ― どのプラットフォームで開発していても活用できます。では、何ができるのか見ていきましょう。 （ちなみに「Mobile Vitals」については数年前にも取り上げています。この新ツールの仕組みに興味がある方は、こちらの記事もあわせて読むと面白いと思います。） Mobile Vitals は何を計測しているのか？ 1：アプリ起動のパフォーマンス インスタグラムでレシピを延々と見ていたら、突然カロリー計算アプリの良さそうな広告が表示されました。試しにダウンロードしてみたものの、なぜか初回の起動に20秒、2回目以降でも10秒かかる。さて、あなたはどうしますか？ オレオを食べながら、遅い起動に耐えるか、それとも体重計に戻るか… Sentry はユーザーがイライラしてアプリをアンインストールする「無駄なカロリー消費」を防ぐために、アプリ起動のパフォーマンスを計測します。ここで注目しているのは、コールドスタートとウォームスタートの2つの指標です。 コールドスタート第一印象は取り返しがつきません。Sentry はコールドスタートを個別に計測することで、最新のパッチが第一印象を台無しにしないかどうかを確認できます。 ウォームスタート iOS や Android のメモリ管理は複雑で、アプリをバックグラウンドで「ウォーム」に保ちながら、一部のタスクを停止することがあります。最近使用したアプリ一覧から再び起動するときには、アプリがすぐに立ち上がることが求められます。 重要なのは、上位の指標だけではありません。ウォームスタートにおいて、Sentry は iOS および Android アプリに対して非常に細かく自動で計測を行います。たとえば iOS では、実行前処理、UIKit、フレームレンダリングなど、さまざまなネイティブ処理を個別に確認でき、アプリの読み込みを遅らせているボトルネックを特定・修正できます。 各画面をクリックすると、その画面に至るまでの最新のアプリ読み込み状況が一覧で表示され、さらに詳細に掘り下げて、どの処理がボトルネックになっているかを確認できます。 2：画面読み込みのパフォーマンス コメントページを開くたびに毎回5秒かかるようでは、誰もコメントを残しません。話はそれだけシンプルです。 Sentry は各画面の読み込みについて TTID と TTFD を計測することで、UX の重さを軽減するのに役立ちます。 TTID（Time to Initial […]