Sentry 機能 / Sentry Features - Ichizoku

Cron監視の拡張

この1年間、我々はCronを構築してきました。小さなプロトタイプから始まったこの機能は、Sentryのエラー、パフォーマンス、信頼性モニタリングツールの本格的な機能へと生まれ変わりました。この機能自体はまだベータ版ではありますが、すでに1日あたり700万以上のチェックインを受け付けています。このような規模が大きくなった機能なので、信頼性を保証する方法について慎重な決断が必要でした。早期実施 Sentryの新しいCron監視機能とは、スケジュールされたジョブ（例：古典的なcronjobs、celery beatタスク、Sidekiq、Laravel Scheduled Tasks、あるいはsystemdタイマー）が通常通り動作しているか、あるいは実行に失敗したシナリオを検証し、アラートを出す方法のことです。これは、スケジュールされたタスクが “check-in “イベントを介して私たちに通知することで機能します。 Missed：予定時刻にチェックインしなかった場合、「チェックイン漏れ」となる Timed-Out：進行中のチェックインが完了しなかった場合、「タイムアウト」となる Error：status=errorのチェックインを送信すると、明示的にエラーとしてマークされる最初のプロトタイプでは、チェックインの取り込みはDjangoアプリケーションに組み込まれたいくつかのAPIエンドポイントによって処理されていました。物事をシンプルに保つために、チェックインは単に Postgres テーブルのエントリとして記録されます。チェックイン漏れを検出するために、1分間に1回、celery beatタスクを実行して、予定時刻にチェックインがなかったモニターを探すだけです。タイムアウトの検出も同様です。しかし、この最初のプロトタイプをアーリーアクセスユーザーに提供できるようにしたのは、今年に入ってからでした。アルファ版の機能であっても、私たちはすぐに勢いを取り戻し、信頼性とスケーリングについて考える時が来たということです。インジェスト・インフラストラクチャー私たちが最初に解決しようとした問題は、チェックインの取り込みでした。私たちのSDKが使用するAPIエンドポイントは、可用性が高く分散されています（私たちの分散取り込みインフラであるRelayを使用しています）。しかし、私たちのフロントエンドを駆動し、プロトタイプのエンドポイントが実装されたSentry製品のAPIは、このような保証がありません。 Relayが可用性を向上させるだけでなく、Relay経由でチェックインを実装するもう一つの大きな利点は、私たちのSDK群全体でCronチェックインを作成するためのサポートを迅速に実装できることです。これはRelayが統一された「エンベロープシリアライゼーションスキーマ」を使用しており、SDKが任意のイベント（もちろん最も一般的なのはエラーとトランザクションです）をRelayのポイント・オブ・プレゼンスに簡単に渡すことができるためです。 Cronのチェックイン・インジェストをRelayに移行するのは当然のことでしたが、プロトタイプのインフラを大きく変更する必要がありました。この改良された世界では、Relay は SDK からのチェックインイベントを受け付けます。これは従来の curl スタイルでのチェックイン用の API エンドポイントも提供します。これらのチェックインは検証され、正規化され、Kafkaトピックに入れられます。これにより、処理できるチェックインの量をスケールアップするためのノブをすぐに回すことができます。以下のようなイメージです。このアーキテクチャにより、ユーザーのチェックインを失うことなく、コンシューマーの問題を確実に回復することができます。Kafkaは問題のあるシナリオでもチェックインのバックログを維持することができ、負荷の要求に応じてコンシューマーの数を微調整することができます。チェックイン漏れを確実に検知 Cronのインジェストインフラストラクチャの可用性が改善されたので、私たちはチェックイン漏れ検出の信頼性に注目しました。 Sentryは通常、プラットフォームに送られたデータを処理します。未チェックインの検出は、我々のインフラにとって斬新な領域です。 1分間に1回のCelery beatタスクを使ってチェックインを検出するというプロトタイプのアプローチには、2つの大きな問題があることがすぐにわかりました。 Celery beatスケジューラのデプロイ中に、タスクがスキップされる短い期間があります。これは、1分間に1回のチェックイン・プロデューサ・タスクが、特定の1分間実行されないことがあることを意味します。このシナリオでは、すべてのユーザに自分のモニタのチェックインミスが通知されません。 Kafkaメッセージのバックログシナリオで、1分以上バックログしている場合、成功したチェックインが単にバックログにあるだけで、まだ処理されていないスケジュールされた時間のチェックインミスが発生する可能性があります。これらはどちらも問題があるだけでなく、エンドユーザーを混乱させます。私たちの目標は、モニターが停止したことを確実に伝えることなので、ミスしたチェックインを正しく検出することが重要です。では、チェックイン漏れをチェックするタスクが、1）毎日毎時毎分、無期限に実行され、2）チェックインが壁掛け時計の時間より遅れても影響を受けないようにするにはどうすればいいのでしょうか？ […]

エスカレーションする問題で、トレンドの問題をより早く見つける

どのissueを優先し、最初に解決すべきか判断することは、開発者が共通して直面する問題です。この問題に対処するため、Sentry は、エスカレーション、進行中およびアーカイブの課題ステータスのような新機能をリリースしました。さらに、優先度ソートを更新し、最も重要な課題をより簡単かつ迅速に特定できるようになりました。開発者が最も重要な課題を特定するのに役立つ機能を以下で紹介していきます。新しい問題状態の導入 Sentryは、新しい問題から始まり、進行中の既知の問題、解決またはアーカイブされた問題まで、問題のライフステージに関するより多くのコンテキストを提供するようになりました。修正された問題がいつクローズするか、進行中の問題やアーカイブされた問題がいつ劣化するかを簡単に発見できるように、RegressedとEscalatingという2つの新しいタブが追加されました。以前は “Regressressed “というステータスがありましたが、それはユーザーが以前に問題を解決（つまり修正）し、その問題が引き続きイベントを受信している場合にのみ表示されるものでした。しかしこのロジックでは、悪化しつつあり、優先されるべきissueが考慮されていませんでした。このロジックにより、無視のアクションとステータスをアーカイブに置き換えることにしました。以前は、「無視」機能は開発者が行える正確なアクションではありませんでした。問題を見えなくする最も簡単な方法でした。しかし、問題が悪化し始めた場合には役に立ちませんでした。というのも、いつ無視されなくなるかのしきい値を手動で定義しなければならなかったからです。現在では、アーカイブによってissueはアーカイブ・タブに移動し、issueがエスカレートして悪化し始めると、issueはエスカレーションに移動します。issueが以前にアーカイブされたか、一度も対処されなかったかにかかわらず、issueが通常よりも著しく多くのイベントを受信した場合に、新しいエスカレーションissueステータスが割り当てられます。また、その他の要因も考慮されます。これにより、issueフィードを整理しやすくなり、優先度の高いissueをより早く特定することができます。課題のエスカレーションはアルゴリズムに基づいて行われるため、どの課題に焦点を当てるべきかを手動で判断する必要はありません。ベータテストでは、アルゴリズムによってエスカレーションされた課題は、解決される可能性が3倍高いことがわかりました。また、エスカレーションのしきい値を手動で設定した場合と比較して、これらの課題が再度アーカイブされる可能性も低くなりました。ソートと検索の改善早急な対応が必要な問題を特定するために使用できるもう1つのツールが、課題ストリームの優先順位ソートオプションです。最近、優先順位ソート機能がアップグレードされ、年齢、全体的なイベント量、最近のイベント量に基づいて課題が順番に表示されるようになりました。例えば、イベント件数の多い新しい課題は、イベント件数の少ない進行中の課題よりも優先順位が高くなります。どのような課題を上位に表示すべきか、ご意見があればGitHub のディスカッションスレッドに投稿してください。また、重要な問題をより簡単に見つけるという精神に基づき、問題検索バーに人気フィルターを導入しました。問題への迅速な対応注意が必要な問題を素早く見つけることは、Sentryにおける良いユーザー体験の核心であると言えます。上記の改善は、Sentryにログインするたびに、「ホットフィックスに値する」問題を簡単に見つけられるようにするためのほんの始まりにすぎません。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

Node.jsのプロファイリングでコードレベルのボトルネックを解決する

プロファイリングは、最も重要なツールです。プロファイリングを利用することで、本番環境で実行中のプログラム情報を詳しく見ることができます。パフォーマンスのボトルネックは、ローカルで再現するのが非常に困難であったり、不可能であったりすることがよくあります。そのため、この機能はとても重要であるといえます。再現が困難である理由は、外部制約や本番環境特有の負荷が理由にあります。 Sentryでは、iOSとAndroidのプロファイリングのサポートをリリースした後、他のプラットフォームもサポートするように取り組んできました。そのうちの一つがNode.jsです。Node.jsのプロファイリングは、現在ベータ版です。 Node.jsのプロファイリングのセットアップ Node.jsのプロファイリングを設定するには、@sentry/profiling-node パッケージをインストールする必要があります。次に、パッケージをインポートします。その後、プロファイルに必要なサンプリングレートを設定します。プロファイリングは、当社のSentryパフォーマンス上で動作します。そのため、Sentryパフォーマンスもセットアップする必要があります。これらのセットアップが完了すると、Sentry.startTransactionとtransaction.finishの間のすべてのコードが自動的にプロファイリングされるようになります。プロファイリングは実際に何をしているのでしょうか？本パッケージは、内蔵のV8プロファイラを使用しており、サンプリング周波数が最大100ヘルツでスタックサンプルを取得します。プロファイル結果のスタックサンプルはSentryダッシュボードにアップロードされます。すると、そのサンプルをフレームチャートの形で可視化することができます。フレイムチャートでは、プロファイラが収集したスタックサンプルを時系列で確認することができます。これにより、プログラムがどの関数呼び出しに最も多く時間がかかっているのか確認することができます。自分たちのコードをプロファイリングしてわかったことまず、Chartcuterie（Slackで共有されるチャートリンクのサムネイル画像を生成するサービス）を実行するExpressサーバーにプロファイリングを導入し、フロントエンドのテストスイート全体と、社内のSlackボットにも導入しました。コードのプロファイリングを成功させるために、まず、すべてのサービスでSentryのパフォーマンスサービスがインストールされていることを確認します。 Sentryはサービス全体のレイテンシー問題を追跡するので、プロファイルとトランザクションを簡単に関連付けることができます。これにより、リクエストが遅くなっている原因を特定することができます。パフォーマンスのダッシュボードは、アプリケーションがどのように動作しているかを確認するのに役立ちました。プロファイリングを導入する前と後では、p75の時間を正確に追跡することができました。パフォーマンスの原因を探る-ネタバレ：テストコードとは限らない Sentryのフロントエンドのコードは、約400のテストファイルにまたがる4000のテストから構成されています。 CI環境からいくつかのプロファイルを確認した後、いくつかのテストでloadFixtures関数呼び出しの内部にかなりの時間がかけられているこることがわかりました。loadFixturesの呼び出しは setup.tsスクリプトの一部で行われます。これは、テストの実行前に実行され、テストが実行できる環境を準備します。フレームチャートを見ると、テストのセットアップコードがテスト時間の大部分を占めていることがわかります。そのため、テストセットアップが何を行っているのかを確認することにしました。擬似的なコードでは、loadFixturesは次のように動作しています。このコードには何の問題もありません。むしろ、このコードによって、require/import文を書かなくても、テストの内部で一部のコードをスタブ化することができるようになりました。しかし、これはメリットだけではありません。 stubsDir内にあるすべてのコードを（たとえテストで実際に必要とされないものであっても）ロードしてしまいます。この問題は、Jestがrequire.cacheを採用しないことが原因となり、さらに深刻なものになります。さらに、setupFilesAfterEnvで定義されたスクリプトが1ファイルにつき一回実行されるということも、問題の原因です。この問題を解決するために、JavaScriptのプロキシを活用し、require文を遅延ロードさせるようにしました。これにより、パフォーマンスに影響を与えることなく、問題を解決できました。また、具体的な修正内容はこちらでご覧いただけます。スローテストを探す Sentryのフロントエンドテストの中には、実行にかなり時間がかかるものがあります（時には数分を超えることもあります）。その理由はテストによって異なりますが、あるテストは、大きな依存関係グラフを持つ複雑なコンポーネントをテストしているためであったり、すべてのコードを初めてトランスパイル（あるプログラミング言語から、他のプログラミング言語に変換すること）すると、動作に時間がかかったりします。また、レンダリングに時間がかかるコンポーネントをテストしている場合も同じように動作が遅くなります。さらに言えば、私たちのテストはデフォルトのGitHub Ubuntuランナー上で実行しています。これはローカル開発で使っているM1チップのmacOS環境とはかなり異なる環境です。あるコードの実行が遅い理由として、さまざまなことが考えられます。しかし、プロファイリングがなければ、原因を正確に把握することは難しいでしょう。そのため、実際の本番環境から収集したプロファイルを持つことが非常に重要なのです。そこで、いくつかのプロファイルがウォーターフォールパターンを示していることに着目しました。上のフレームグラフでは、keyboardImplementationの呼び出しがウォーターフォール型になっており、テスト実行全体のおよそ7回呼び出されていることがわかります。これは、テスト時間の大部分を占めています。また、新しいチームメンバーが招待されたときに、ユーザーに表示されるモーダルをテストしていました。長文のメールを送信する際に、 userEvent.typeを繰り返し使用していました。そのため、コンポーネント全体の再レンダリングが発生していました。レンダリングを最適化するためにコンポーネント自体を書き直すことはすぐに対応できることではないため、現実的ではありません。しかし、おそらくそれが最良の解決策だったのでしょう。私たちは、userEvent.pasteを使用して、ユーザーがメールアドレスを入力することをシミュレートすることで、負荷を軽減することを選びました。これにより、文字列の各文字に対してイベントを発生させることなく、テストの速度を向上させることができました。当社のサービス以外の問題を発見する Chartcuterieサービスは、Slackのリンクが共有されるたびに、サムネイルを生成します。これにより、ダッシュボードを開かなくても、Slackですぐにチャートを確認することができます。しばらくの間、このサービスはメモリリークに悩まされており、その都度、再起動させる必要がありました。最終的に、メモリリークの原因はプロファイリングを活用する前に特定することができ、修正されました。メモリリークの根本的な原因を調査するのは難しく、簡単な修正作業ではありませんでした。 […]

Pythonのプロファイリングでコードレベルでボトルネックを解決

プロファイリングは、最も重要なツールです。プロファイリングを利用することで、本番環境で実行中のプログラム情報を詳しく見ることができます。パフォーマンスのボトルネックは、ローカルで再現するのが非常に困難であったり、不可能であったりすることがよくあります。そのため、この機能はとても重要なのです。再現が困難である理由は、外部制約や本番環境特有の負荷が理由にあります。 Pythonは、最も人気のあるプログラミング言語の一つです。 SentryもPythonをメインに開発しています。Pythonのプロファイリングは現在ベータ版です。しかし、sentry-sdk==1.11.0を利用することでWSGIアプリケーションで利用可能になります。これにより、実運用でのアプリケーションのパフォーマンスについて、コードレベルで把握することができます。 Pythonのプロファイリングを始めるには、SDK上でprofiles_sample_rateを設定するだけです。 SDKは100ヘルツのサンプリング周波数でサンプルを取得する別スレッドを実行します。プロファイルが終了すると、サンプルはSentryに送られ、プロファイルがフレームチャートとして可視化されます。フレームチャートは、エンドポイントや遅いトレースにおいて、頻繁に実行されるコードを素早く見つけ、リソース消費（例：CPU）を最適化することができます。 SentryプロファイリングでSentryを改善する長い間、Sentry上でPythonプロファイラの内部バージョンを実行することで、Sentryを最適化することができました。日付時刻と連携多くの人は、時系列で確認できることほど嬉しいことはありません。そのため、Sentryの様々なところで時系列グラフを用意しています。しかし、時系列グラフの生成には時間がかかります。処理が重い箇所を調査したら、 discover.discover – timeseries.transform_results が原因である可能性があることがわかりました。さらに調査を進めると、この関数が本当に原因であることがわかりました。たまに数百ミリ秒の遅さになることがあり、これはデータ取得のクエリよりも遅いです！実はクエリよりも後処理の方が遅いんです！コードを見ると、単純な変換をしているだけでした。そのため、根本的な原因はすぐには分かりませんでした。しかし、プロファイルを見ると、リクエストの大半が、ゼロフィル（データが全て0埋めになっている状態のこと）内で日付のパース処理だということがわかりました。ゼロフィル内の日付時間のパース処理でした！これを知った時は驚きました。検証するために、いくつかの簡単なベンチマークを行ました。また、日付と時刻の文字列をパースするいくつかの方法を比較してみました。それは衝撃的事実でした。なぜなら、dateutil.parser.parseからdatetime.datetime.fromisoformatに変更することで、数百倍速くなる可能性があるからです！ datetime.datetime.fromisoformatは完全なISO 8601通りのパース関数ではありません（とりあえずはPython 3.11までは）。しかし、我々はdatetime.datetime.isoformatに満足していました。なぜなら、この一行を変更するだけで、最悪な状況が大幅に改善されるからです。 Django：プリフェッチするかしないかプリフェッチはDjangoでよく採用されるテクニックです。これは、関連するオブジェクトにアクセスする時に、大量にデータベースクエリが発生するのを防いでくれます。オブジェクトごとに1つのクエリを作る代わりに、プリフェッチすることによって、関連するすべてのオブジェクトを一度に取得する一つのクエリを作ることができます。 Sentryの様々な場所でこの技術を採用しています。しかし、ユーザーのエンドポイントが非常に遅いことに気づきました。大きな影響を与えずに、関連するオブジェクトにプリフェッチを使用するようにしました。いくつかのトランザクションを見ると、興味深いことがわかりました。それは監視できていない期間があったのです。さらに最も興味深いのは、それがいくつかのデータベーススパンに散らばっていたことです。また、コードを調べてみると、これらのデータベーススパンは以下のクエリに対応していることがわかりました。最初のクエリはOrganizationMemberに対するもので、それに続く3つのクエリはprefetch_related内で指定された3つのルックアップに対するものです。プロファイルを調べると、prefetch_related_objectsがありました。これはDjangoの内部呼び出しで、リクエストの大部分を占めています。 OrganizationMemberとTeamの間の多対多の関係、そしてTeamとProjectの間の多対多のリレーションクエリをしていたことがわかりました。 prefetch_relatedを使ったクエリは高速でしたが、Djangoは結合処理を実行していました。つまり、一部のチームとプロジェクトを取得しただけですが、 DjangoはすべてのOrganizationMember、Team、Projectを繰り返し、関連するオブジェクトを属性として設定していました。この知識をもとに、クエリの書き換えに取り掛かりました。 Pythonでこの結合処理を実行したくはなかったのです。prefetch_relatedを削除し、関連するオブジェクトを手動でフェッチし、レスポンスを丁寧に構築することで、これを達成することができました。これにより、p95は50%近く減少しました！プロファイリングはパフォーマンスを補完するプロファイリングは、Sentryパフォーマンスを完璧に補完します。パフォーマンスが問題を大まかに把握することができますが、プロファイリングは正確なプログラムのコード行番号まで把握することができるので、簡単に問題を解決することができます。コードのプロファイリングをできるようにするために、まずすべてのサービスをSentryのパフォーマンス製品で接続するようにしました。 Sentryは、サービス全体のレイテンシー問題を把握することができます。これにより、プロファイルとトランザクションを簡単に関連づけることができ、遅いリクエストの根本原因を特定することができます。パフォーマンスのダッシュボードは、アプリケーションがどのように動作しているかのを把握するのにも役立ちました。プロファイリングを導入する前と導入した後を比較すると、P75の時間やスループットなどを簡単に把握することができました。早速いまからプロファイリングを始めてみましょう。最初に「パフォーマンスを計測する」を確認してください（わずか5行のコードで可能です）。 […]

コードカバレッジインサイト – スタックトレースで確認できるようになりました

その理由コードカバレッジとは、テスト手法の一つで、どのコードがテストされているかを知らせるもので、パーセントで表示されます。コードカバレッジは、コードの総行数のうち、全体の何割がテストされているのかを把握することができます。また、テストを書くことはとても大変です。しかし、コード変更があると、せっかく書いたテストコードも変更内容をテストできているかがわかりません。このストレスから、共同創業者のイーライ氏と私は、テスト駆動開発で解決したいと思うようになりました。私たちは、（まだ）存在していないものを作ることが好きです。また、ほとんどの開発者はエラーが発生するコードのテスト状況を見たいだろうと思っていました。しかし、SentryがCodecovを買収したとき、次のような反応が最も多かったです。それは私たちもとても感じていました。 Codecovを使ってコードレビューしても、デプロイ後の作業にはあまり役立ちませんでした。長い間、ユーザー／顧客向けの製品に携わる開発者は、”OK、でも次の問題は何？”ということに向き合ってきました。その問題は、おおよそ次のように表現されます。アプリでエラー・不具合内容を受け取るエラー周辺のデータを開く（アプリケーションのパフォーマンス監視と例外処理） “よし、でも次はどうする？“ 別画面で自分のIDEを開く 2つの画面を見渡し、コードのメンタルモデル（価値観やイメージのこと）を構築する。そのコードにテストがあるのなら、根本的な原因を修正する方法を考える。必要であれば、今後同様のエラーが発生するのを防ぐために、基となるソースコードを変更し、テストを記述・編集する。さらに一歩踏み込むと… もしエラーが発生するコードがテストされていない場合、次のステップは、このケースを中心にテストを書くことかもしれません。またはもしエラーが発生するコードがテストされていた場合、次のステップとして、問題のテストとコードのロジックとの関連性を調査します。例えば、テストケースに見落としがないかを確認します。 SentryのスタックトレースにCodecovを導入することは、本番前とデプロイ後のデータ連携を実現する最初の取り組みです。これにより、問題が発生した際のデバッグやパッチ適用がより迅速かつ容易になります。何を？ひとことで言うとCodecovのSentry連携を使えば、Sentry Issueのスタックトレースでエラーの原因となる未テストのコードを直接確認することができます。この機能を使うことで、さまざまなユーザー操作を考えたり、コードを手動で分析したりする必要はもうなくなります。 SentryにCodecovを導入すれば、テストするべき優先箇所を正確に把握できるので、時間を無駄にすることなく、信頼性の高いコードを維持することができます。テストカバレッジを改善するために、数ヶ月に一度「カバレッジ週間」を設けて、コードのテストを改善していました。しかし、SentryとCodecovの連携により、コードを分析し、テストカバレッジが必要な箇所を考えることはなくなりました。さらに、Sentryが取り組むべき箇所を正確に教えてくれるので、テストカバレッジの構築に費やしていた時間を約50%ほど削減できました。 – アレックス・ナサネイル（技術担当ディレクター）＠vectare.co.jp Codecovの使用方法前提条件： Sentryの場合 SentryのGitHubインテグレーションをインストールし、Codecovにテストカバレッジデータがあれば、使い始められます。また、GitHubインテグレーションにCode Mappingsをセットアップする必要もあります。これはテストカバレッジを表示するためのソースコードファイルを把握するのに必要です。 GitHubを使われていない方は、GitLabとBitbucketは対応中ですので、しばらくお待ちください。 Codecovの場合 Codecovにサインアップするだけです。一度アカウントを取得すれば、テストされていないコードが本番環境でエラーを引き起こしている箇所をワンクリックで確認できます。コードカバレッジは初めてですか？大丈夫です。詳しくはこちらをご覧ください。 SentryとCodecov – スタックトレースでコードカバレッジを即座に確認できるようになります。最も簡単な方法 – 全く何もする必要はありません。両方のサービスでセットアップされたときに、自動連携を有効にする日次ジョブを実行します。簡単な方法 – すぐにでも始めたい場合は、設定ページに移動し、「コードカバレッジインサイトの有効化」をオンにしてください。 […]

Sentryのプロファイリング：コードレベルでパフォーマンスのボトルネックを特定し排除する

ユーザーからロードが遅いと言われたため、ログやトレース、メトリクスを通して分析をしました。さらに、アプリケーションのパフォーマンスの原因を特定するために、利用可能なデータはすべて分析しました。しかし、それでもボトルネックの原因を突き止めることはできませんでした。もしかしたら、監視が十分じゃなかったのかもしれません。あるいは、本番環境と大きく異なる環境でテストしているだけかもしれません。いずれにせよ、根本的な原因を突き止めるのに、精神的負荷と時間がかかります。このようなパフォーマンスの悩みを解決するために、プロファイリング機能を構築しました。現在、Python、Node.js、iOS、Android、PHPでは、最新の料金プランで利用可能です。プロファイリングは、パフォーマンスの問題を引き起こしているプログラムの行番号までピンポイントで特定するため、Sentryのパフォーマンスを向上させます。プロファイリングは、関数の実行時にその実行時間に関する本番環境のデータを収集します。そして、その結果を集計して、あらゆる環境におけるアプリケーションのパフォーマンスを把握することが可能になります。実行時間を推測したり、パフォーマンステストを書いたりする代わりに、アプリケーション内で非常に多く実行されるコードを確認し、パフォーマンスのボトルネックを素早く特定することができます。さらに、プロファイリングは手作業による計測にかかる時間を短縮するため、導入後すぐにパフォーマンスを計測することができます。プロファイリングによってパフォーマンスチューニング作業がどれくらい楽になり、ボトルネックをどのように修正するのかをご紹介します。また、SDKのサポートに関する最新情報についてもご紹介します。こちらは、動作の遅い関数からアプリケーションフレームやコールツリーまで掘り下げて、問題の原因となっているプログラムの行番号を特定するデモ画面です。プロファイリングを始める準備はできていますか？詳しくは価格ページをご覧ください。トランザクションからプロファイルまで掘り下げる Sentryパフォーマンスでは、トランザクションと期間ごとに、個々のサービスとそのサービスのパフォーマンスを表すトレースを収集することができます。トランザクションを監視して、速度低下の原因となっている期間を特定するのに役立ちますが、多くのタスクで長時間実行される箇所の原因を特定するのは難しい場合があります。長期間を小さく分割して計測するのではなく、プロファイリングを使用することで必要なコンテキストを提供することができます。プロファイリングデータがあると、最も頻繁に発生するコールスタックが表示され、最適化すべきコードを教えてくれます。以下の例では、特定のコールスタックが収集したサンプルの84.3%に、アプリ内関数の最上位がBigTableKVStorage.get_manyで、GCPのビッグテーブルクエリを実行していることがわかります。詳細を見ると、その関数が定義されている正確なファイルと行番号がわかります。さらにデバッグが難しいシナリオとして『一部のデータが抜けているケース』が挙げられます。観測できていない箇所を推測する代わりに、プロファイリングはその時間帯に実行されるコードを教えてくれます。これによって、コードのどこを修正する必要があるかがわかるだけでなく、このプレビューによって、新しく監視する箇所を追加しなくても根本的な原因を見つけることができます。この例では、観測できていなかった474msまでの間が、Redisクラスタへの接続をしていたことがわかります。さらに、フレームチャートビューアでは、すべてのスレッドのデータを含むプロファイル全体を表示します。トランザクションデータはプロファイリングデータとインラインで表示されるため、その時間に関連する機能をシームレスに関連付けることができます。フレームチャートの操作方法と解釈方法についての案内を作成しました。開発者のヴィトール・カリクストはプロファイルを利用して、Azos Segurosの顧客保険金の分割払いサービスのパフォーマンスを向上させています。ヴィトールは、フレームチャートを使用して、パフォーマンスの問題に関連するプロファイルを掘り下げ、リクエストが遅くなっている原因の関数コールを特定し、迅速に対応しました。これにより、リクエストの実行時間が大幅に改善されました。フレームチャートを使って、顧客決済サービス内で最も遅いデータベースリクエストを見つけることができました。プロファイリングを使用することで、リクエストの実行時間を1000msから300msに短縮することができました。– アゾス・セグロス社 Vytor Calixto氏プロファイリングで改善されるパフォーマンス問題プロファイリングは、トランザクションデータをグループ化して、共通のパフォーマンス問題を検出するなど、パフォーマンス機能を補うものです。プロファイリングデータが問題をコードレベルで可視化することによって、検出できることが増えます。プロファイリング・データを活用する最初の新しい課題タイプは、iOSとAndroidでサポートされるJSON Decoding on Main ThreadとImage Decoding on Main Threadの2つです。例えば、画像のデコード処理（ファイルの解凍などのこと）をメインスレッドから別スレッドに移動させることで、メインスレッド時間を150ミリ秒程度短縮できたことがわかります。さらに、UIジャンクの発生やスクロール性能の低下を防ぐこともできます。 […]

Sentryの新しい予算配分とスパイク保護で安心して複数のプロジェクトを管理

本日、新しいSpend Allocation（予算配分）機能とSpike Protection（スパイク保護）のアップデートを発表します。これにより、Sentryユーザーは、プロジェクトがどのようにイベントを消費するかをよりコントロールできるようになります。私たちは、お客様がプロジェクトにSentryを簡単に追加できるように製品を開発してきました。しかし、コミュニティからは、ノイズの多いイベントデータを扱うプロジェクトで、イベント枠を消費しすぎないようにするための方法がもっと欲しいという声を聞き続けていました。そこで私たちは、Spend Allocation（予算配分）を構築し、Spike Protection（スパイク保護）を更新しました。これにより、Sentryを大規模に利用する皆様は、イベント消費のレベルが異なる複数のプロジェクトやチームを簡単に管理できるようになりました。なぜかプランによっては、毎月Sentryに送信できるイベント数に上限が設定されています。その数を超えると、Sentryはあなたのイベントを削除し始めます。この場合、アプリケーションの状態を把握することができなくなります。インバウンドフィルタ、メトリックアラート、レートリミットなど、イベント消費を管理するためのツールを用意していますが、さらにコントロールを容易にしたいと考えました。これにより、プロジェクトでイベントが大量に発生するような予期せぬ事態が発生しても、ペナルティを受けることがないようにできます。 Spend Allocation（予算配分）とSpike Protection（スパイク保護）の向上予算配分は、予約エラー、トランザクション、添付ファイルに対して、プロジェクトごとに最小限のイベントの閾値を設定することができます。この設定はリアルタイムで行うことができ、すべてのプロジェクトに公平な割り当てを行うことができます。また、スパイク保護のアップデートは、その名の通り、イベント量の予期せぬ異常な急増からお客様を保護します。 Spike Protection（スパイク保護） – 何が変わったか予約した容量を使いながら、月内に十分な視認性を確保できるようにしたい。しかし、インシデントは起こります。 Sentryに送信されるイベントが急増することがあります。このような場合、数時間または数分で月間クォータを使用することができます。ユーザーからのフィードバックに基づき、イベントスパイクからお客様を保護するための従来のアプローチには、主に2つの問題があることが判明しました。「調整」が早すぎる。数時間以上続く正しく認識されたスパイクを「非スパイク」と誤判定することがあった。スパイクの閾値が単純に高すぎる場合がある。その結果、スパイクが捕捉されないことがある。これらの要因により、スパイク保護機能の有効性が損なわれていました。そこで、スパイク保護の機能を以下のように改善し、ユーザーの保護を強化することにしました。スパイクはプロジェクトごとに検出されるため、よりきめ細かい制御と可視化が可能です。スパイクがトランザクションと添付ファイルを検出するようになりました。アルゴリズムが更新され、イベントスパイクの検出がより正確になりました。 Stats（統計）ページで、プロジェクトごとのスパイク防止閾値を確認できるようになりました。また、「スパイク保護のアップデートにより、イベント数上限を超えずに管理することができた」というお客様からの声もいただいています。「スパイク保護は、データ移行の失敗から私たちを救ってくれました。一晩中、そして朝のピーク時まで、1つのスパイクが原因で、1日のイベント量が6000%増加しました。Sentryは、数時間以内にすべてのクォータを使い果たすことから私たちを救ってくれました。」-Vectare社テクノロジーディレクター、Alex Nathanail氏フィードバックを共有し、改善の詳細を得るには、GitHubのディスカッションに参加してください。 3つのステップで、アカウントのスパイク保護をオンにします。 Organization（組織）の設定に移動する左のナビバーにある「Spike Protection」をクリックプロジェクトのすべて（または一部）に対してSpike Protectionを有効にするかどうかを選択します。なぜ、プロジェクトでスパイク保護を有効にしなければならないのか、という疑問があるかもしれません。スパイクに関係なく、すべてのデータを確認したいお客様もいらっしゃいます。例えば、開発・テスト段階であれば、すべてのイベントを見ることができれば便利です。 Spend […]

アプリケーションのパフォーマンスを機能的に操作する方法

私は開発者として、そのアプリケーションがどのように動作すべきか、非常に強い関心を抱いています。高速に動いた結果、何かを壊すことには興味がありません。正直、世界を変えることにも興味はありません。快適で人間工学に基づいたソフトウェアを作ることに興味があります。そして、その対価としてお金を貰いたいという思いが強くあります。私の会社「Buttondown」は、そんな思いから生まれました。Buttondownは、メールやニュースレターを送信するためのツールです。市場にはこの手のツールはたくさんあります。しかし、Buttondownの強みは「ミニマリスト」であるということです。開発者にとって快適な体験を提供しています。それはプログラムへのアクセス、アクセシビリティ、そしてパフォーマンスを優先しているためです。しかし、アプリケーションの性能は時間とともに劣化する開発者たちはみんな「高パフォーマンスを意識して開発しなければならない！」と考えています。その意志は常に正しいです。一方で、簡単なことではないことも知っています。新機能の立ち上げ時には、可能な限り慎重にリリースします。 APIルートごとのデータベース呼び出し回数や負荷テストなど、厳しいテストを実施しています。誰かが非常に遅いエンドポイントについてバグレポートを提出した場合（あるいは、タイムアウトに関する例外が発生した場合）、私はできるだけ早く対応します。これは簡単で、テストも可能です。しかし、性能は時間の経過とともに、ゆっくりと、静かに低下していきます。余分なループが一つ、最適化されていないデータベースを一回呼び出す……。それが積み重なっていくように、目に見える小さな問題が積み重なっていくのです。解約した顧客からメールを受け取って初めて、そのことに気づきます。彼らは口を揃えて「UX（ユーザ体験）がよくない」と言います。クラッシュしないので「問題ない」ように思っていましたが、アプリは知らぬ間に悪化していました。パフォーマンスを抽象的なものから実用的なものへと変化させる私は長い間Sentryを、他のユーザーの皆さんと同様エラー処理と問題報告のために使っていました。軽量なインターフェースと迅速なインストールプロセスにより、私は簡単に問題を処理し、優先順位をつけ、解決することができました。私は、電子メールの受信箱と同じように、ソフトウェアの問題をクリーンな状態に保っています。正直、パフォーマンス・モニタリングに注力しているときの私は、半信半疑でした。たくさんのデータやダッシュボードが送られてきて、それを毎朝監視して見なければいけないからです。非常に時間がかかる作業な上、結局人が見て判断しなければならないため、億劫に感じました。しかしその疑念は、Sentryの提供する「パフォーマンスのためのクリアで簡素なアクション層」を理解した途端に消え去りました。 Sentryは、パフォーマンスに関する情報を分かりやすい内容で通知してくれます。これまでは、分かりにくい折れ線グラフではないにしろ、答えを与える代わりに疑問を増やすだけのものが多かったのです。代わりに、Sentryは明確で解決可能な問題を提示してくれました。例えば、SentryはN+1エラー通知をしてくれるので、オンボーディングが重要なルートを高速化することができました。このようなことをPythonの2行で表現しました。そして、Sentryはこの遅いDB操作にアラートしてくれました。 Sentryは、送信メールのレンダリングと送信を倍の速度で行う方法を教えてくれました。 Sentryは、プログラムのどこでどのトランザクションがパフォーマンスの問題を引き起こしているのかを正確に教えてくれました。そのため、問題の根本原因を見つけるために、多くのダッシュボードやレポートの分析に時間を費やす必要はありませんでした。 Sentryを使ったおかげで、無駄な作業が減り、アプリのパフォーマンスに注力することができるようになります。 Sentryでは、コードエラーを処理するのと同じように、パフォーマンスの問題を処理することができるので大変便利でした。開発者にとってパフォーマンスが重要な理由多くの開発者たちは、アプリケーションのパフォーマンスを「あったらいいな」程度の機能として扱っています。開発計画や製品ロードマップを作成しているとき、アプリのパフォーマンスについて十分に考えていない開発者がいるのです。これはよくわかります。お客様の多くは、ページの読み込み時間の遅さやその他のパフォーマンスの問題を受け入れてくれると考えていることが多いからです。一方で、新機能を搭載しなければ、お客様は不満を募らせるだろうと考えています。ですから、パフォーマンスよりも新機能を優先することはよくあることです。しかし、ユーザーや顧客は性能を気にしており、意外とすぐその変化に気がつきます。しかし、実際にどう説明したらいいのかわからないこともあります。 Buttondownを使い始めてから数カ月後のあるお客様と電話をしたことがあります。お客様：よく分からないんだけど、[加入者向け管理画面] が操作しやすくなったんですよね。いずれにせよ、UX（ユーザー体験）を向上させたのは素晴らしいです！とはいえ、UXは1ピクセルも変わっていませんでした。変わったのは、スピードとパフォーマンスです。Sentryのおかげで、5秒のフィードバックループを1秒に短縮することができました。Sentryを使えば、それは本当に簡単なことでした。一部製品、一部プロセス：アプリケーションのパフォーマンスに関する考え方のオススメパフォーマンス問題の優先順位付けと、改善を厳密に行うことに関心のあるエンジニアにお勧めのプロセスがあります。これは、私がAmazonやStripeでエンジニアをしていたときに実際に効果が合った方法です。 […]

プロファイリング入門101：なぜプロファイリングなのか？

プロファイリングについて、3回に分けてご紹介する「プロファイリング入門」。今回は第2回目です！第1回目「プロファイリングとは何か？」はこちらからご覧ください。第1部：プロファイリングとは何か？第2部：なぜプロファイリングを使うのか？（当記事）第3部：プロファイリングツールとその使い方（近日公開予定）アプリ開発の成功には、素晴らしいパフォーマンスが重要であることはご存じかと思います。パフォーマンスを改善するためのツールはたくさんあります。最新のプロファイリングツールを使ってプロファイリングを行うことは、アプリのパフォーマンスを理解するために最も簡単で効果的な方法の一つといえます。プロファイリングツールは、1970年代から開発者が遅いコードを修正するのに役立ってきました。最近のプロファイリングツールは、より洗練され、より使いやすくなっています。そして、サービス終了までのあいだ継続的に稼働させることができます。例えば、遅いコードの経路を示す有用な可視化データを自動的に作成する機能があります。また、他のパフォーマンスツールとの統合や連携も可能です。シリーズの第1回目と同様に、この記事のほとんどの例は、フロントエンドとバックエンドの開発に関するものです。しかし実際には、プロファイリングツールはほとんどのコードに適応し、パフォーマンス向上に役立てることができます。なぜプロダクションでプロファイルするのか？ PythonのcProfileやGoのpprofのように、多くの言語にはプロファイリングツールが組み込まれています。これらのツールはとても便利で、何十年も前から使われています。しかし、使い続けていると次第に使いにくい場面も出てくるのは事実です。そんな時は、追加の可視化ツールを必要とします。これらのツールは、あなたのローカル環境上で動作することだけを想定しています。ローカルプロファイリングは限定的内蔵のプロファイラを使えば、コードの特定の部分について詳細なベンチマークを取得することができます。それにより課題のある箇所を見つけるのに役立ちます。しかし、大規模なシステムでパフォーマンスの問題を発見するためには、最適の策ではありません。ローカルプロファイラを使用すると、多くのオーバーヘッドがコードに追加されます。（一般的には200%以上追加されます）プロファイリングを使うということは、コードの性能を気にしているはずです。それにも関わらず、コードを2倍以上遅くしているのは矛盾します。そして、すべてのプロファイラで、追加されるパフォーマンスオーバーヘッドの量は、関数呼び出しの間で一定ではありません。つまり、プロファイリングで得られるCPU処理時間は、正確ではない結果となります。これでは正確に解析できないため、プロファイリングを実行する意味がありません。一般的に、ローカルでのプロファイリングだけでは、ユーザー体験を明確に把握することはできません。本番環境での速度低下の原因を、ローカル環境で再現するのは非常に困難であるためです。ご存知のように、開発マシンでのパフォーマンスは、コードが本番稼働しているときと常に同じとは限りません。したがって、開発環境のローカルプロファイリングで問題を発見し、実際に修正するのは非常に困難であるということがわかります。プロダクションにおける最新のプロファイリング最終的には、本番環境でパフォーマンスを測定することが、システムのパフォーマンスを正確に把握する唯一の方法となります。幸いなことに、ローカルのプロファイリングツールが作られて以来、プロファイリング技術は大きく進化してきました。最新のサンプリングプロファイラは、現在、本番環境で実行できるほど進化しています。（決定論的プロファイラとサンプリングプロファイラの比較は第1回目で詳しく説明しています）それは、パフォーマンスのオーバーヘッドを抑えて実行できるようになったためです。また、コードのパフォーマンスの詳細な情報を可視化して提供してくれます。それはローカル環境上のプロファイリングと遜色ない、有用で十分な解析結果を出力してくれます。例えば、Sentryのプロファイリングツールは、10%以下のオーバーヘッドを目標として実行しています。さらに、最新のプロファイリングツールは、すべてのユーザーセッションのデータを取得するように設計されています。つまり、コードが本番環境でどのように動作しているかを包括的に把握することができるのです。プロファイリングは<metrics/logging/tracing>と比較してどうなのでしょうか？他のツールを使って、本番環境からパフォーマンスデータを取得している方もいらっしゃると思います。『なぜプロファイリングをセットアップする必要があるのか』という疑問もあるでしょう。パフォーマンスを監視する方法を変更するのは、決して簡単な作業ではありません。しかし幸いなことに、プロファイリングはパフォーマンスを測定するための他の戦略とともに機能します。また、設定もそれほど難しくなく、得られるメリットも大きいです。最も大きなメリットは、プロファイリングデータが関数またはコードレベルの粒度を提供することです。これにより、開発者はパフォーマンスの問題を発見し、修正することが非常に簡単になります。システムメトリクスページロード時間、CPU使用率など、その他の事前設定されたメトリクスは、本番環境で稼働しているアプリのパフォーマンスを把握するために使用されます。また、効果的でオーバーヘッドの少ない方法を提供し続けます。メトリクスは、パフォーマンスの問題があることを知らせるには最適ですが、その原因まで突き止めることはできません。メトリクスは非常に低いオーバーヘッドで動作するので、使わない理由はありません。しかし、最近のツールと比較すると、その有用性は限定的となります。ロギングロギングは、パフォーマンスを含め、さまざまな方法でシステムの健全性を把握するのに便利です。しかし、ロギングからパフォーマンスデータを取得するには、多くの手間がかかります。 […]

PythonとNode.jsのプロファイリングβ版

数ヶ月前、PythonとNode.js SDKのユーザー向けにプロファイリングのアルファ版がリリースされましたが、本日、PythonとNode.js向けのプロファイリングをベータ版に移行しました。プロファイリングはベータ版の間、無料で使用できます。正式リリースが近づいたら、また更新情報をお届けします。プロファイリングは、コードのパフォーマンスボトルネックを発見するのに役立つ重要なツールです。 Sentryのプロファイラでは、実行速度の遅いクエリのコードのファイル/行番号まで正確に把握することができます。特定の関数の実行に時間がかかっている理由を即座に把握し、コード内の関数を最適化することでアプリケーションのパフォーマンスを向上させることができます。最新のリリースでは、プロファイリング製品にいくつかの改良を加えています。 Pythonのアップデート Geventのサポート：SentryプロファイリングがPythonのgeventをサポートするようになりました。geventライブラリ（Gunicorn WSGI HTTPサーバとよくペアになっている）を使用しているすべてのユーザーに影響があり、以前はデータを取得できなかったgeventコルーチン（リクエスト処理コード）内で実行されているコードを確認できるようになりました。 WSGIリクエストだけでなく、すべてのトランザクションのプロファイリングをサポート：以前は、SentryはWSGIリクエストのみをプロファイルすることができました。現在では、すべてのトランザクション（手動で開始したものも含む）がプロファイルされ、この動作はプロファイルをサポートする他のSDKとの一貫性を担保します。これらの機能アップデートはいずれも追加設定を必要とせず、SDKをアップデートすればすぐに動作し、プロファイリングのインサイトを確認することができます。 Node.jsのアップデート Node.js 18および19のサポート：SentryプロファイリングがNode.jsの最新バージョン（v18とv19）に対応しました。 Google Cloud Runに対応：Google Cloud Run環境にデプロイした際に、Node.jsプロファイラがセグメンテーションしてしまうバグを修正しました。これで、Google Cloud Runにデプロイした際に、本番環境で正常にプロファイリングできるようになります。このパッケージは、コンパイル済みのバイナリとともに提供されるため、ソースからのビルドはあまり必要ありません。製品の機能改善 SDKのサポート強化に加え、いくつかの新しいプロファイリング機能のアップデートにより、ユーザー体験（UX）を向上させました。Sentryプロファイリングでは、ユーザーは以下のことができるようになりました。フレイムチャートの関数からGitHubのコードへのリンクソースマッピングが設定されている場合、フレイムチャートの関数フレームを右クリックすると、GitHubのその関数のコードに遷移します。これにより、長時間実行される関数のソースコードに直接移動できるため、パフォーマンス問題の修正プログラムを素早く書くことができ、トラブルシューティングの時間を短縮することができます。これは、ソースコード管理が設定されているNode.jsとPythonのプロジェクトで機能します。トランザクションの処理時間をフレイムチャート上で可視化するトランザクションが関連付けられたすべてのプロファイルは、トランザクションからの期間をフレームチャート上に直接出力します。これにより、トランザクションとプロファイルを行き来することなく、特定の処理で実行されたコードを1つの統一された画面で簡単に把握することができます。期間から対応するプロファイルに移動する Sentryのトレースを有効にしている場合、トランザクションイベントの詳細ページに移動し、ウォーターフォールビューから期間を選択し、「View Profile」ボタンをクリックすると、その期間に発生するプロファイルの部分に移動することができます。これにより、パフォーマンス問題を抽象的な上層〜詳細な下層にまで目的に合った粒度で分析することができます。結論 Sentryのプロファイリング機能を繰り返し強化する中で、初期の多くのお客様から、Sentryパフォーマンスとプロファイリングは、パフォーマンスワークフローにおいて、しばしばうまく組み合わせて利用できるという話を聞きます。 Sentryパフォーマンスは、お客様がサービス全体をトレースし、動作の遅いデータベースクエリや外部呼び出しを特定することを可能にします。例えば、プロファイリングのお客様の一人は次のように述べています。 Sentryパフォーマンスで最も遅いAPIコールを確認することは非常に有用です。私たちはパフォーマンスの最適化を行い、p50とp95の劇的な改善を確認しました。” – Aunty Grace（オーストラリアのヘルスケア企業）の開発者、シェーン・ホルコム氏プロファイリングはトレースを補完するもので、CPU消費を抑えるためにコードのどの部分を最適化する必要があるかについて、ファイルや行レベルで詳細に知らせてくれます。パフォーマンスとプロファイリングを併用することで、プロファイルとトランザクションを関連付け、遅いリクエストの根本的原因を特定し、迅速に修正することができます。数回のクリックでプロファイリングを始められます。まず、パフォーマンスの計測が完了していることを確認してください（わずか5行のコードで完了します）。 P.S. プロファイラを聞いたことがない、プロファイリングとロギングやトレースとの比較を知りたい、あるいは単に興味があるという方は、プロファイリングとは何か、なぜ運用中のアプリケーションをプロファイリングする必要があるのかを説明するブログシリーズ「Profiling 101」をご覧ください。 Pythonのプロファイリングの例やNodeのプロファイリングの例については、こちらをご覧ください。また、GitHub、Discord、またはメール（profiling@sentry.io）にて、ご意見・ご感想をお待ちしています。 Sentryは、アプリケーションコードの健全性を監視するために不可欠です。エラートラッキングからパフォーマンスモニタリングまで、開発者は、フロントエンドからバックエンドまで、アプリケーションをより明確に把握し、より迅速に解決し、継続的に学習することができます。Sentryは、世界中の350万人以上の開発者と85,000以上の組織に愛され、Disney、Peloton、Cloudflare、Eventbrite、Slack、Supercell、Rockstar Gamesといった世界で最も有名な企業の多くにコードレベルの観測機能を提供しています。毎月、世界中で人気のサービスやアプリケーションから、数十億件の例外を処理し続けています。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

Sentry Category: Sentry 機能 / Sentry Features