Sentryでデバッグするヒント / Sentry Debugging Tips - Ichizoku

Fortune 500,000社のための今後の展望。あと80％です…

デイビッド・クレイマーがサイドプロジェクトに最初のコミットを行ったのは16年前のことでした。彼とクリス・ジェニングスがこのサイドプロジェクトを単純な問題を解決するために存在する会社に変えたのは12年前のことです。それ以来、我々は多くの人が考える「観測可能性」とは少し異なる道を歩んできました。Sentryは、ログを収集して監視ボックスをチェックすることを望むプラットフォームでも会社でもありません。 12年経った今でも私たちは、開発者のためのデバッグの簡素化という1つの重要な問題に注力しています。しかし、より重要なことは、開発者コミュニティからのサポートなしにはできないことです。私たちは現在10万以上の組織をサポートしており、昨年のARRは1億ドルを突破しました。素晴らしいことですが、なぜ気にする必要があるのでしょうか？どちらも恣意的な数字に過ぎません。しかし、これらのマイルストーンは、単に自分たちを褒め称えるための口実ではないのです。さてこの話は一旦横に置いておき、代わりに皆さんとSentryの次の展開に焦点を当ててまいります。（それでも足りない場合は、私たちのコミュニティでお祝いする楽しい方法がありますが、その前にどうかお付き合いください） Sentryのチーム 2019年、デイビッド・クレイマーはCEOからCTOに移行する際、Sentryを率いるために私を雇いました。ここまでは順調でした。本日、クレイマーと私は、次期CTOとしてセントリーに入社するデイヴ・ローゼンタールを迎え入れます。クレイマーは、新設された最高製品責任者の役割に移行します。デイヴは、世界で最も革新的な企業のいくつかで、新興企業の創業者と技術リーダーの経験があります。彼は今月初旬に入社し、私たちは彼をチームに迎えることに興奮しています。一方、CPOへの正式な肩書き変更については、クレーマーからのコメントをお読みください。(私が「公式」と言ったのは、多くの点で、彼は常にSentryのCPOだったからです）。 Sentryのプロダクトそして、クレイマーのオープンソースのサイドプロジェクトとして始まったSentryは、10万以上の組織と数百万人の開発者が自信を持って出荷できる会社に成長しました。当初から、そして現在もSentryは「発見」と「解決」という2つの成果を重視しています。私たちは、開発者が問題を知るだけでなく、ワークフローの中で問題を解決する方法をリアルタイムで示すことを可能にします。これが、Sentryが100,000以上の組織で信頼されている理由であり、この哲学を倍加することが、次の100,000以上の組織にサービスを提供するために成長する方法なのです。 Sentryバージョンの理想的な開発者アシスタントは、あなたの指先で利用可能なすべての関連するコンテキストであなたの問題をデバッグするのに役立ちます。私たちは、あなたのワークフローで最も重要な問題、あなたが働く場所（PRコメントを考えてください）、そしてソフトウェアの問題を素早く修正するのに役立つ信号の最も鋭い接続されたビューを提供することに対応し続けます。ですから、問題に行き着いたものの、ビデオのような問題の再現が必要な場合、あるいはスパンウォーターフォールを調査する必要がある場合、Sentryのデータストリームを使えば、どんな種類の問題でも簡単にデバッグすることができます。多くの企業は、ボトムアップ戦略（製品主導の成長、あるいはPLGと呼ばれることもある）で成功を収め、規模が大きくなると、スイッチを入れて企業バイヤーに売り込み（そして企業バイヤーのために構築し）始めるのが一般的です。しかし、Sentryは違います。PLGはとにかく、ソート・リーダーシップの訓練なのです。もしあなたが、販売戦略に関係なく、市場に出せる最高の製品を作っていないのであれば、なぜビジネスをしているのでしょうか？私たちは、想像上の「ペルソナ」を満たすために製品に機能を追加したりはしません。Sentryは開発者用ツールなのです。Sentryは、Fortune 500社だけでなく、Fortune 500,000社向けにも開発しています。そして私たちは、オープンソースにおける持続可能性の危機を解決するために私たちの役割を果たしながら、オープンに構築し続けます。ワークフローが変わっても問題は解決しない Gitが登場するずっと前の話です。当時のエンジニアは、パンチカードを使ってソフトウェアをリリースしていました。バグを修正するために「パッチ」（文字通りのパッチ。開発者がソフトウェアを構築する方法は今も変わり続けています。私たちが（購入者ではなく）実践者に焦点を当て続けるということは、Sentryが彼らが自信を持って出荷できるように支援するということです。あなたのペアプログラミングのパートナーがCopilotであろうと、Codyであろうと、Devinであろうと、Augmentであろうと）バグを軽減する必要があることに変わりはありません。簡単に言えば、私たちはまだ作り終えていません。どのように進化しようとも、現代の開発者のワークフローにマッチする革新的なソリューションを出荷し続けます。ささやかな感謝のしるし当社のクラウド・サービスで10万を超える組織をサポートしていることは光栄なことであり、当然のことではありません。私たちは、ユーザーの一人ひとりにコミットしています。私たちが、これまで歩んできた道のりの一部であったすべてのユーザーに感謝する最善の方法は、彼らのために構築し続け、彼らの進化するワークフローのありふれた細部にまでこだわり続けることです。そして2番目に良い方法は？無料のお菓子です！今年の残りの期間中、私たちはコミュニティに10万ドルのSentryグッズをプレゼントします。詳細はこちらをご覧ください。未来の詳細がどのようなものになるかはまだわかりませんが、私たちはこれまで以上に、道を切り開く開発者の役割に自信を持っています。私たちの周りの世界を定義するソフトウェアを出荷する彼らのために、彼らとともに構築することは、私たちの特権です。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

デバッグの問題を軽減する5つの改善点

昨年Sentryでは、セッションリプレイやクーロンモニタリングのような新しい製品をリリースしました。しかし、新しい製品を作るだけでなく、ソフトウェアの問題をより速くデバッグするために、コアプラットフォームを改善する方法を常に探しています。 Sentryのローンチウィーク中にご覧いただけたと思いますが、私たちは以下の問題に対処する5つのQoL改善をリリースしました。修正ファイルに未解決の問題がないことを確認するには？コードが本番環境で動作しない場合、どうすればよいか？コンテキストの切り替えを減らすには？フロントエンドの問題をサーバーサイドのエラーにすばやく突き止めるには？これが最新情報です。修正ファイルに未解決の問題がないことを確認するには？ GitHubでレビューコメントを発行する GitHub でプルリクエストを開くと、Sentry はあなたが変更しようとしているコードに起因する既存の未処理の問題をコメントするようになりました。つまり、PR の一部として変更されたファイルに未解決のエラーやパフォーマンスの問題がある場合、提案した変更のリスクをよりよく理解したり、少し修正する時間を取ることができるようになるということです。詳しくはドキュメントやGitHubのディスカッションをご覧ください。コードが本番環境で動作しない場合、どうすればよいのか？ CI/CDツールやプラクティスがこれだけ進歩しているにもかかわらず、CD Foundationが調査した企業のうち、デプロイを毎日行っているのはわずか30%に過ぎないというのは唖然とします。開発者がより頻繁に本番環境にプッシュしない最大の理由の1つは、自分たちのソフトウェアが本番環境で実際に動作するかどうかわからないということのようです。 Release Healthの最新アップデートにより、デプロイメントが本番稼動した瞬間に、ソフトウェアが本番稼動しているかどうか、リリースの健全性を文字通りお伝えすることができます。不良リリース検出リリースが健全でない場合は、リリースページとリリースの詳細ページに表示されるため、リリースに関わったすべてのチームメンバーが何が問題だったのかを確認し、調査することができます。リリースの健全性を判断するために、エラーやクラッシュ率などに基づいて、独自のしきい値を設定することもできます。また、CI/CDパイプラインで私たちの新しいAPIをポーリングすることで、リリースの閾値のステータスを取得することができます(Sentry が不正なリリースを検出したときに、すぐに通知と Webhook を起動する機能を公開予定です)。コンテキストの切り替えを減らすには？ Slackとの統合強化私たちがより早く重要なリリースにたどり着こうとしているのは、不良リリースの検出だけではありません。 Slackとの統合により、コードベース内の新しい重要な問題に対してアラートを受け取ることができます。このアラートにはより多くのコンテキストが追加され、バグに関する適切な情報を適切なタイミングで、適切な場所で取得できるようになりました。更新されたSlack通知では、問題の詳細が表示され、Slackクライアント内で一般的なアクションにアクセスできます。以下のこれらでわかります。イベント数とユーザー数推奨される担当者そして、以下で出来るようになります。ノートとルールブックのURLを追加する issueのアーカイブ方法の設定課題セレクタで検索（課題を割り当てるチームメンバーを検索できます） Slackから直接、課題の割り当て、解決、アーカイブを行うことができ、より多くのデータを得ることができます。問題の詳細にリプレイを埋め込む問題の詳細をスクロールすると、ページにリプレイが埋め込まれるようになりました。セッションリプレイ機能は、映像でユーザーセッションの再現を提供します。これによって不具合の再現を支援し、ユーザーが問題を経験する前後に何が起こったかを確認することができます。問題の詳細ページを離れることなく、より迅速にデバッグすることが可能になります。フロントエンドの問題をサーバーサイドのエラーに素早く突き止めるには？問題の詳細におけるトレースナビゲータの改善各問題詳細ページのトレースナビゲータを更新し、トレースで特定のエラーが検出された場所や、このエラーに関連する可能性のある他の問題を簡単に視覚化できるようにしました。これにより、キーボードの上で顔を丸めることなく、「バックエンドのエラーがフロントエンドに問題を引き起こしているのか」という漠然とした質問に明確に答えることができます。トレースの改善やパフォーマンス監視の主なアップデートの詳細については、ローンチウィーク2日目に発表した内容をご覧ください。まとめ私たちは、あなたが本番を壊すことが少なくなるよう、最善を尽くしています。新しいパフォーマンス機能から、AI対応のコードレビューやAutofixの導入、そして上記のプラットフォームのアップデートまで、デバッグの酷さを軽減するために前進し続けています。 Sentryの最新情報を入手するには、Change logをチェックしてください。また、GitHub、Twitter、Discordでもお問い合わせいただけます。 […]

【Break Production Less】Codecovのプレリリース・フォーカスの紹介

テストプラクティスとツールの改善を支援しようとするソリューションは、世の中にたくさんあります。しかし私たちは、高品質なソフトウェアは、テストがいかにうまく行われているかに限らないと考えています。そのため、私たちはコードカバレッジの枠を超え、バンドル分析、テスト分析、AIを活用したコードレビューを備えた初のプレリリースプラットフォームの基盤を構築しています。 JavaScriptバンドル分析バンドルサイズが重要なのは、アプリケーションのパフォーマンス、帯域幅の使用量、ロード時間に直接影響するからです。バンドルが大きいとロード時間が長くなり、パフォーマンスが低下し、ユーザーエクスペリエンスが低下します。私たちは、開発者がこのような課題に立ち向かえるよう、JavaScript バンドル解析を展開しています。私たちのBundle Analysisは、Rollup、Vite、Webpackと連携し、エンドユーザーに影響を与える前に問題を診断するのに役立ちます。今すぐ Bundle Analysis を試して、GitHub issue で感想を聞かせてください。バンドル解析はすべてのCodecovユーザーが無料で利用でき、ほとんど設定なしで動作します。テスト分析欠陥のあるテストや、CIの実行に時間がかかるテストは、デプロイ失敗のリスクを高め、新機能を迅速にデリバリー（リリース）することを難しくします。そこで、テストの実行時間や失敗率のデータを提供し、不安定なテストを特定する Test Analytics を紹介します。テストの失敗に関する洞察を GitHub 内で直接提供することで、コードの行をスクロールすることなく、テストに欠陥がある箇所や失敗している箇所を確認することができます。これによって、問題の発見と対処がより速くできるようになります。😏 Codecov PR Commentでテストの失敗情報を取得するには、テスト結果をJUnit XMLファイルとして生成し、そのファイルをCodecovにアップロードするだけです。 Test Analyticsを使い始めるには、こちらのドキュメントをご覧ください。テスト失敗レポートは現在稼働中ですが、私たちはテスト管理プロセスを改善し、コードレビューのサイクルをスピードアップするために、Flaky Test Detectionを積極的に開発しています。テストの失敗や欠陥のあるテストについてどう思いますか？ GitHub issue でご意見をお聞かせください。 AIによるコードレビュー機能コードレビューで最悪なのは、自分のPRを誰かにレビューしてもらうことです。ああ、他のチームの誰かにあなたの変更をレビューしてもらう必要があるなら、幸運を祈ります。もしあなたがPRを開いた瞬間に、誰かもしくは何かがレビューしてくれたらいいと思いませんか？ Codecovの新しいAIコードレビュー機能は、まさにそれを可能にします。明らかなミスを特定し、開発者がコード変更のより複雑で重要な側面にコードレビューを集中できるようにする、物知りな友人のようなものだと考えてください。これは、レビューの迅速化、承認の迅速化、顧客への機能提供の迅速化、そして「最新の変更をレビューしてもらえますか」というメッセージの減少を意味します。まとめ Sentryはおそらく本番環境であなたのコードを監視していると思いますが、デプロイする前にはギャップがあります。そこで、SentryのCodecovチームは、コードカバレッジだけでなく、リリース前のすべてにフォーカスを移すことで、そのギャップを埋めようとしています。これはほんの始まりに過ぎません。私たちが境界を押し広げ、一度に1行のコードでソフトウェア開発の未来を形作り続けるように、私たちに加わってください。いつものように、あなたのご意見をお聞かせください。また、Codecovを初めてお使いになる方は、今すぐ無料でお試しいただくか、デモ利用のお申し込みをください。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

正しい指標を選ぶ：パーセンタイルと平均値のガイド

アプリケーションのパフォーマンスを測定するために、どのパフォーマンス指標を使用すればよいか分からない。そんなことでお悩みではありませんか？でも心配ありません。あなただけではなく、様々なプロジェクトで同様の悩みを抱えています。多種多様なオプションがあるため、適切なメトリックを選択する作業は難しいです。この記事では、各メトリクスの長所と限界について解説します。モニタリングに適したメトリックを決める際にお役立てください。なぜ正しいメトリックス（指標）を選ぶことが重要なのかパフォーマンス監視において、適切なメトリックスを選択することは、タスクに適切なツールを選択するようなものです。釘を打つのにレンチを使っても最良の結果が得られないように、パフォーマンス監視に誤った指標を使用すると、誤解を招くような解析結果につながる可能性があります。アプリのパフォーマンスの全体像を把握しなければ、ユーザー満足度の低下、最適化の機会損失、問題の解決時間の長期化などのリスクが生じます。例えば、アプリケーションのパフォーマンスを評価するために平均的な指標だけに頼っていると、UXに大きな影響を与える可能性のある「スパイク」や「ディップ」を見落とす可能性があります。逆に、p99のようなパーセンタイルを使用すると、レーダーを潜り抜けてしまうような、まれではあるが影響力のあるパフォーマンス問題を特定するのに役立ちます。平均：簡単な概要平均値は、パフォーマンス監視のためのわかりやすい指標です。すべてのデータポイントを合計し、データポイントの総数で割ることで、パフォーマンス全体のスナップショットを提供します。この指標は理解しやすく、計算も簡単であるため、魅力的な選択肢であると言えます。しかし、平均がうまく機能し、典型的な経験を反映するのは、データが比較的一貫している（つまり、大きな外れ値や歪みがない）場合だけです。例えば、移動平均はシステム全体が過負荷になりつつあることを知らせます。しかし、その他のユースケースでは、平均値で対応できる領域には限界があります。平均値の落とし穴データが均一でない場合、平均値は誤解を招くリスクを含みます。ページのロード時間をモニタリングする場合、平均値は役に立たないかもしれません。ユーザーデバイスは、ネットワークのような、あなたのアプリがコントロールできない、あらゆる種類の不安定な特性の影響を受けます。そこで、パーセンタイルの出番となります。パーセンタイル：ばらつきを理解するパーセンタイルは、データをその分布に基づいてセグメントに分割することで、パフォーマンスのより微妙なビューを提供します。理論的には、どのパーセンタイルもモニターすることができますが、実際には、p50、p75、p95、p99、p100の5つが使用されます。 p50（中央値）：データの50%が該当する値。p50は、データの中心的な傾向と典型的なパフォーマンスについての洞察を与えます。p50の上昇または下降は、中央値のパフォーマンスの変化を示し、データポイント間の応答時間の速さや遅さを反映します。 p75：データの75％がこの値を下回る。p75は、フロントエンド・アプリケーションにとって貴重な指標です。これは、ユーザーの状況に大きなばらつきがあるため、データの分布が予測しにくくなるからです。p75は、中心的なパフォーマンスの傾向と、フロントエンドで遭遇する幅広いUXとの間でバランスをとります。 p95：これは、データの95％が該当する閾値です。p95は、均一なデータを持つバックエンドアプリケーションにとって価値があり、ほとんどのユーザーが期待するパフォーマンスを捕捉し、ボトルネックを強調します。しかし、可変フロントエンドの設定では、p95は最悪のシナリオを意味し、典型的なUXを代表するものではありません。 p99: この値を超えるデータはわずか1%であることを示します。バックエンドアプリケーションのようにデータの一貫性が高いシナリオでは、p99がパフォーマンスの上限を示し、最も極端なケースを強調します。 p100（最大値）： p100は、計測器の問題やクライアント側の変数など、フロントエンド・アプリケーションにおけるノイズの原因を特定するために有用です。バックエンドアプリケーションでは、真のノイズや極端な異常値を示すことがあります。以下はバックエンドトランザクションのパーセンタイルの例です。典型的なパターンが観察されます。 p25からp75まで徐々に上昇し、p75からp95まで急な、しかしまだ緩やかな上昇が続きます。最後に、p99まで急上昇しています。興味深いことに、p100はグラフに含まれていません。その理由は、Y軸のスケールが大きくなるため、他のパーセンタイルの詳細が平坦な線に圧縮され、視覚化が歪んでしまうからです。続いてフロントエンド・アプリケーションの典型的なパーセンタイル・チャートをお見せします。このシナリオでは、p25からp50まで緩やかに上昇し、持続時間が適度に長くなっていることがわかります。続いて、p50からp90まで急上昇していますが、これはより急激な値の上昇を意味します。最適な指標の選択：バランスを取るどのメトリクスを監視するかは、アプリケーションのパフォーマンス目標に沿う必要があり、データのばらつきの大きさによって決まります。十分な情報に基づいた選択ができるように、選択肢を分類してみましょう。ユーザー・エクスペリエンスの観点ユーザーがシステムとどのように相互作用しているかを理解することを第一に考えるのであれば、p75やp95のようなパーセンタイルに注目してください。これらのメトリクスは、典型的なパフォーマンスの全体的なビューを提供しています。 p75とp95のどちらをトラッキングするかは、モニターしたいアプリケーションのタイプによって異なります。フロントエンド・アプリケーションのような変動性の高い環境では、p75を選択することをお勧めします。バックエンド・アプリケーションのようなデータの一貫性が高い状況では、p95の方が適しているかもしれません。異常値の検出少数のユーザー・サブセットに影響する異常値や稀な事象を特定することが重要な場合は、p95（フロントエンド・アプリの場合）またはp99（バックエンド・アプリの場合）を選択します。これらのパーセンタイルは、平均中心のメトリクスを使用した場合に発見できない可能性のある問題を特定するのに役立ちます。スケーラビリティの計画リソースの割り当てとシステムのスケーラビリティを計画することが目的であれば、平均値が適しているでしょう。負荷が増加している期間の平均を監視することで、システムがいつ容量の限界に達するかを特定することができます。 Sentry […]

FastCo.が選ぶ2022年最も革新的な企業の一つで、プラットフォームの安定性を最優先する

フィットネス業界では、ずいぶん前に「スマート」な機器をビジネスモデルに取り入れていました。最近では、ユーザー体験の高さで差別化をはかり、競い合っています。安定性と品質は、プロダクトの成功に不可欠です。これはトナール社の開発者たちにとっての最重要課題でした。「ユーザー数は多いのですが、バグを報告するユーザーは比較的少ないです。私たちは非常に安定した製品を持っており、目標はそれを維持することです。- トナール社、モバイルソフトウェアエンジニアリングシニアマネージャー、マックス・ラピデス氏」トナール社は、ニューヨークマガジンのベストスマートホームトレーニングソリューション2022年にランクインしています。また、メンズヘルスでも、ベストコネクテッドケーブルマシン2022にランクインしています。トナール社は、スマートホームトレーナーの業界水準を定めており、その標準を維持するために、開発者たちは製品がユーザーの期待に応えられるように、今までとは違うアプローチをとっています。彼らは、製品の問題を減らすだけでなく、完全に無くすことに注力しています。「エラーやクラッシュを減らそうという意識は持っていません。なぜなら、私たちは、システムがクラッシュすることを想定しておらず、システムはクラッシュしないと想定しています。」バグのないUXを実現するワークフロー当たり前ですが、システムエラーはどのシステムにも存在します。しかし、そのエラーがユーザーに影響を与えることを防がなければなりません。そのためには、パフォーマンスモニタリングと自動エラーレポートを開発作業に取り込む必要があります。マックスのチームは、Debug Symbolを使用して、エラーログをデバッグの段階で活用することでこれを実現しました。そして、スタックトレースからSentryが提供する追加のデータコンテキストを使用しています。例えば、このスタックトレースだけでは、必要なコンテキストデータがあまり得られないため、デバッグには使えません。しかし、マックスのチームがデバッグ用のシンボルをSentryにアップロードすると、シンボル化されたスタックトレースができてしまいます。「Sentryがなければ、これらのデバッグ用シンボルファイルを収集する必要があります。Sentryは、App Store Connectや CIシステムからのアップロードから自動的に収集します。これにより、不明瞭で難解なデータを人間が読めるものに変換することができるようになります。」トナール社がスムーズなUXを維持するもう一つの方法は、Sentryにパンくずリストを設定することです。これにより、問題を調査している開発者たちは、エラーにつながったユーザーのアクションを時系列で確認することができます。また、問題を再現し、迅速に解決するために必要なすべてのコンテキストも確認することができます。「これらのユーザーイベントは、デバッグに役立つアプリ内のユーザーのアクションの流れを表していることに気づきました。そこで、現在ではこれらのユーザーイベントもパンくずリストとしてSentryに送信しています。これにより、Sentryを起動したまま、問題が発生する前のユーザーの行動を正確に把握できるようになりました。」例えば、新機能のエッジケースのテストでQAエンジニアが、UIの問題を見つけることがあります。 Sentryは、ユーザーがエラーに至るまでに行ったHTTPリクエストや、ユーザーが行ったナビゲーションなど、その問題に関するリアルタイムのデータを表示してくれます。また、Sentryは担当チーム、Flutterのバージョン、ビルド番号などの詳細なコンテキストデータも提供してくれます。これにより、対処可能なバグレポートを提出することが簡単になります。バグレポートには、問題を再現し、最終的に解決する方法について、十分な情報が詳細に含まれています。コードを “即断即決で “修正することなどありえないトナール社は、2019年から続いている2週間のスプリントとデプロイの徹底した周期に従っています。しかも、そのペースは2019年から変わっていないそうです。規則的で予測できるリリースは、安定して高性能なユーザー体験を提供するための高い基準をチームに課すことになります。しかし、モバイルでは、その場でコードを修正することは、あまり現実的ではありません。「AndroidとiOSの両プラットフォームに対応したアプリを再構築する必要があります。そして、24時間から48時間かけてレビューを行い、Google PlayとApp Storeの両方にリリースすることができます。その後、ユーザーの端末で自動的にアップデートされるのを待ちます。重要な機能を追加する場合は、さらに3日ほどかかることもあります」そのため、マックスのチームはデプロイ前の約一週間、QAでビルドを確認し、リリース用のダッシュボードで監視するようにしています。リリースは個々のビルド番号で標準化されており、QAを通過すると、チームは最新のビルド番号を「ゴールドマスター」と宣言します。これで本番リリースの準備が整います。「Sentryで重大な問題が確認された場合、通常48時間以内に修正することが可能です。しかし、目標はこうした問題が本番環境で発生しないことです。」トナールのチームは、プラットフォームの安定性、復旧力、ユーザー体験に重点を置いています。マックスのチームは、開発能力とSentryのカスタムソリューションを組み合わせているため、以下のようなことができるようになります。詳細なコンテキストデータを含むエラーを積極的に監視します。プラットフォームの安定性とUXに直接影響を与えるエラーを簡単に優先順位付けすることができます。品質を犠牲にすることなく、きっちりとリリーススケジュールを維持します。アプリ内のユーザー行動を分析し、解決までの時間を短縮します。ユーザーに高いパフォーマンスのUXを提供することで、他社よりも優位になります。「Sentryは、私たちがプラットフォームの安定性を維持するのに役立ちます。 Sentryは、ユーザーたちに直接影響を与えるようなコードをリリースするのを防いでくれます。私たちにとって良い日とは、クラッシュがないときです…それが毎日ならいいですが」 Sentryは、アプリケーションコードの健全性を監視するために不可欠です。エラートラッキングからパフォーマンスモニタリングまで、開発者は、フロントエンドからバックエンドまで、アプリケーションをより明確に把握し、より迅速に解決し、継続的に学習することができます。 […]

Pythonのテストを数百の環境で高速に実行する方法

長文を読む気分ではない方は、ここからDjangoCon 2022で行われた講演（英語）を見ることができます。 Sentryの信念のひとつに「すべての開発者のために」というものがあります。すべての開発者をサポートしたいと思っています。しかし、すべての開発者が最新の技術や広く採用されている技術スタックを使っているわけではありません。そのため、古いバージョンのライブラリやフレームワークもサポートするように心がけて取り組んでいます。当社のSentry SDK for Pythonでは、次のことをサポートしています。約20種類のWebフレームワーク Python2.7を引き続きサポートします（！） Python 3.5から3.11まで対応しています古いバージョンのフレームワークをサポートしています。(例：8年前のDjango 1.8をサポートしています） SDKが正しく動作することを確認するために、テストスイートには約450の自動テストが用意されており、SDKに変更を加わるたびに実行されます。 7つのPythonのバージョンと約20のフレームワークをサポートしているため、それぞれのフレームワークのバージョンが2～9になると、テストを実行する環境は400を超えます。テスト用スタックテストスイートはpytestを使用して実行されます。テスト実行前に、Flake8とblackを使ってソースコードのリントとフォーマットを行い、mypyを使って型チェックを行っています。 Toxは、さまざまな環境でテストスイートを実行するためのツールです。ローカルマシンの異なる環境でテストスイートを実行するために、古き良きmakeを使用しています。そして最後に、GitHub ActionsをCIとして使用し、すべてのプルリクエストに対してすべての環境でテストスイートを実行できるようにしています。スローテスト私たちのテストセットアップは何年も前に作成され、時間の経過とともに多くのテストが追加されました。しかし、テストセットアップ自体をリファクタリングする時間がありませんでした。そのため、テストスイートを実行するのに約40分も時間がかかっていました。このようなテストスイートは、苦痛でしかありません。 SDKの新しいバージョンをリリースする際には、リリースごとにテストスイートを実行するため、テストが完了するのに最大で1時間もかかることもありました。これは由々しき事態です。そこで私たちは、テストスイートの改善に取り組みました。テストスイートを高速化するすべてのテストをリファクタリングすることなく、より速くテストを実行する方法について、いくつか考えました。どのようなことをしたのかをご紹介します。フレームワークごとにテストスイートを分割テスト実行にかかる時間を大幅に短縮開発者の生産性を向上考えた結果、テストそのものではなく、テストの実行方法を変えようという結論に至りました。まず、テストスイートを改善するのに着目したのは次のことです。それはいままでそれぞれのプルリクエストで、すべての環境でテストスイートを実行するGiHub Actionsランナー1つでToxを起動し、1つずつ実行していました。これは、テストを実行する上で最も遅い方法であり、1回の実行に38〜42分はかかります。アイデア1：toxでテストスイートを並列に実行する Toxのコマンドラインには、–parallel autoオプションがあり、利用可能なCPUコアの数だけテストスイートを並列実行することができます。これにより、すでにテストの実行時間は劇的に改善されました。今まで40分かかっていたテストが、25分程度になったのです。しかし、これではまだ「速い」とは言えません。 GitHub ActionsのランナーはCPUコアを2つしか持っておらず、使用できるCPUコア数には限界がありました。アイデア2：GitHub Actionsを使ったテストスイートの並列実行 GitHub ActionsのランナーのCPUを増やすことはできませんが、GitHub Actionsのランナーを増やすことは可能です（大きなマシンを購入しない場合）。そこで、テストを実行するすべての環境に対してGithub Actionsの設定yamlファイルを作成するスクリプトを作成しました。アイデアとしては、このようなものでした。しかし、GitHub Actionsの同時実行できるワークフローにも制限があることがわかりました。私たちはGitHub […]

Sentryでもっと早くトリアージし、安らかな睡眠を

開発者にとって、トリアージする月の1週間は、しばしば憂鬱でした。トリアージとは、バグが報告されるたびに、手作業でログを分析し、関係するスタックトレースがあることを期待し、そして記憶を頼りに適切なチームへ連絡することでした。トリアージをする開発者は、バグを適切なチームに連絡する必要があります。また、バグを調査するのに必要な情報を併せて報告する必要があります。十分な情報がない場合、開発者はプロダクトを作成するよりも多くの時間をデバッグに費やすことになります。現在、Sentryは400万人以上の開発者のトリアージとコンテキスト収集作業を最適化してくれます。しかし私たちは、さらに課題解決までの時間と課題解決率を向上するように努めています。課題解決率および解決までの時間の改善課題のトリアージは、4つのフェーズに分けることができます。検知通知アサインメント解決ユーザーからのフィードバックやインタビューに基づく、通知やアサインメントの改善は、より良い結果をもたらすと考えました。具体的な改善点として、以下の2点に着目しました。サジェストでアサインメントの改善関係ない通知によるノイズ低減アサインメントの改善とアラートノイズの低減簡単に課題を特定し、適切なチームや開発者にアサインすることができるようになります。各課題について、担当者はSentry組織内のメンバーまたはチーム内で、最も詳しい情報を持っています。 Sentryは、3つのシグナルに基づいて、課題をサジェストします。サスペクト（疑わしい）コミット – Sentryは、問題が起きたコードを最近変更した開発者を特定します。所有権ルール – Sentryは、イシューのタグやコードなどに基づいて、適切にSentryチーム/メンバーを見つけるためのルールを評価します。コードオーナー – SentryはGitHub/GitLabのCODEOWNERSファイルを解析し、コードに基づいて、イシューに適切なSentryチーム/メンバーを設定してくれます。お客様からのフィードバックを目にして、ユーザーが確実かつ迅速に課題をアサイン、解決するのに役立っていることを知りました。そして、より多くのユーザーがサジェストアサインを利用できるように、ここ数ヶ月で様々な機能を追加しました。 Git Blameを使ったサスペクトコミットについてサスペクトコミットは、Sentryでは問題の原因となっているファイルを最後に変更した人を表示するだけでした。しかし、Git Blame API連携することで、Sentryは特定のコード行を変更した人、および問題の原因となったコードのプルリクエストを特定することができるようになりました。また、イシューを自動的にコミット作成者にアサインすることができるようになりました。この機能は、GitHubまたはGitLab連携を利用すれば、誰でも利用できます。組織でこの機能を有効にする詳しい方法は、以下をお読みください。コードマッピングを自動で設定怪しいコミットを見つけるために、Sentryはエラーの原因となるファイルとリポジトリ内のソースコードファイルを結びつける必要があります。しかし、これを正しく設定するのはなかなか難しく、ユーザーがこの設定を怠っていることに気づきました。そのため、SentryのGitHub連携を利用するユーザーのために、この設定を自動化するようにしました。 Sentryは、Python、JavaScript、Node、Rubyなどのプラットフォームのソースコードと、エラーの原因となるコードを自動的にマッピングしてくれます。この自動化されたセットアップにより、Sentryはさらに多くの怪しいコミットを見つけてくれるようになります。不要なSentry通知を減らす Sentryでは、新しいプロジェクトを作成すると、デフォルトのイシューアラートルールが作成されます。しかし、このルールはアサインできる人がいないイシューに対して、同じプロジェクトで作業しているチームメンバーに対して、通知を行う可能性があることに気づきました。このアラートルールを使うことで、そのプロジェクトの全メンバーに迷惑をかけることなく、チームに通知できるように変更しました。より良い結果を出すためにここでは、ユーザーがどのように問題解決をするか、その過程を紹介します。 Sentryはイシュー担当候補者がいる場合、アラートルールに従って、適切な開発者、チーム、Slackチャンネルに通知することができます。これにより、開発者に不要な通知を減らし、チームにとって重要なイシューに集中してもらうことができます。この利点は、イシューの担当候補者が増えれば増えるほど大きくなります。さらに、Sentryがデフォルトのイシューアラートルールを変更したことで、問題を迅速にトリアージする能力を維持しながら、全体で不要な通知を33%削減することができました。 […]

フルスタックの可視化で遅さの根本原因を探る

ユーザーにとって素晴らしいアプリは、処理パフォーマンスが高いです。しかし、ページロードに10秒かかるアプリは決して良いとはいえません。ユーザーは安定しかつ高速なアプリケーションを望んでます。Sentryは、コードのどこに異常があるのか通知します。それだけでなく何が遅いのか、どう修正すればいいのかを詳細に出力します。パフォーマンスモニタリングを最大限に活用パフォーマンスモニタリングでは、複雑なケースが多々あります。その理由のひとつは、開発者のエコシステムが複雑であるということです。私たち開発者は、一つのプロジェクトでアプリケーション全体を構築することはありません。つまり、あるプロジェクトでの速度低下が、別のプロジェクトでのパフォーマンスのボトルネックになる可能性があるというわけです。私たちのプロジェクトのエコシステムが複雑になると、スタック全体を監視する必要が生じます。そこでSentryを使うと、速度低下を修正する方法についてのヒントを得ることができます。また、Sentryを使えば、原因となっているコードを特定することもできます。例えば、フロントエンドのリクエストからバックエンドの遅いAPIコールまでのトレースを追うことが非常に簡単になります。サービス間チャッター一般的に、フロントエンド（クライアント）側はバックエンド側と通信します。バックエンドは、DBサーバーやサードパーティサービスと連携します。 Eコマース会社を例に考えてみましょう。このストアのフロントエンドは、Webサイトとモバイルアプリを保持しています。どちらもAPI Gatewayを介して、情報をインベントリーサービスにルーティングします。そして、最終的に決済サービスに情報を転送します。クライアント（フロントエンド）から始まり、決済サービスまでのトレース内の各トランザクションは、連鎖的に影響を与える可能性のある呼び出しの連なりと言えます。しかし、すべてのサービスやプロジェクトにテレメトリー（処理の監視データ、計測データのこと）がなければ、開発チームはエンドツーエンドのトレースを完全に可視化することはできません。以下のケースを考えてみましょう。例えば、Webのメトリクスが良好であるとします。Web開発チームは満足しています。しかし、インベントリーサービスやチェックアウトフローの処理に長い時間がかかっている可能性が出てきました。このとき、何が問題なのか、どこに原因があるのか特定できず、チーム内で混乱が生じるリスクが発生します。原因を特定するには、各サービスがどのように通信しているかを理解する必要があります。あるサービスが他のサービスの応答を待っていると仮定します。であれば、アプリケーションのパフォーマンスはもちろん低下します。すると、ユーザーはページロードに長い時間待たされることになります。 …このように、Sentryを使用するとフロントエンドとバックエンドを横断的に分析することが可能になります。あるプロジェクトの操作が、別のプロジェクトの操作をどのように遅くしているかを見ることができます。プロジェクト横断的な視認性さて、それらの機能はどのように動作するのでしょうか。 SentryのSDKは、お客様のコードの変更を監視し、スループット、Apdex、User Misery、トランザクション期間などのメトリクスを測定します。複数のシステムに渡って、エラーの影響度合いを表示することができます。また、Sentryはトランザクションとスパンからなる分散トレーシングを取得します。これらのトランザクションとスパンは、個々のサービスと、それらのサービス内の個々のオペレーションを測定します。トランザクションは、ある操作をサポートするために呼び出されるサービスの単一のインスタンスを表します。測定・追跡したい（例：ページロード、ページナビゲーション、APIコール、非同期タスク）個々のオペレーションはスパンと呼ばれます。パフォーマンスの悪いスパンは、レイテンシーに影響を与える可能性があります。その結果、UX（ユーザーエクスペリエンス）が低下したり、スループットに問題が生じたりする可能性があります。これはアクセスがピーク時に達した時、サイトに悪影響を及ぼすリスクがあります。 Sentryの分散トレース機能により、あるプロジェクトの遅いスパンが、他のプロジェクトのトランザクションをどのように妨げているかを確認することができます。分散トレースでは、コードのどこで、何が遅いかを教えてくれます。また確認に手間のかかるサードパーティの依存関係も特定することができます。分散トレースは、Trace ViewとTrace Navigatorのバックボーンとなっています。トレースビューとトレースナビゲータは、プロジェクト間でスパンがどのように相互作用しているかを示すミニマップを出力します。遅いものを見つけるさて、先ほどのEコマースの例に話を戻します。フロントエンドはReactで構築され、バックエンドはPythonのFlaskフレームワークを使うことがわかりました。ある日、商品ページの読み込みが遅いことに気づきます。 SentryのPerformanceタブに行くと、/productsページのp50が7秒以上になっていることがわかります（一目でわかります！）。ページの読み込み時間が遅いのは、実際に開発中のReactプロジェクトにあります。しかし、その原因は一体どこにあるのでしょうか？それでは、実際に探してみましょう。 1. Transaction Summary […]

Sentryでクラウドサービスに関するコンテキストを増やす方法

Sentryを使用してSentryを構築している、とあるSentry社員がいました。彼は、ある課題に関する特定のサービスが、当社のクラウド環境のどこでホストされているかを知りたいと考えていました。これをきっかけにSentryでは、Python SDKに新しいクラウドデータ収集機能を作成し、Sentry社員だけでなく誰でも利用できるようにしました。この機能の目的は、クラウドでホストされているサービスから問題が発生したときに、そのサービスに関する特定の情報を調べることで、根本原因を突き止め、より速く修正し、製品版のリリースを可能にすることです。 Python SDKは、AWS EC2およびGCP GCEのリージョンとホスティング環境に関する基本情報を取得するようになりました。これによって、クラウドホスティングの設定に関連する問題や複雑さを迅速に特定することができるようになり、作業時間を大幅に減らすことができます。この新しいコンテキストは、クラウド技術のベテランであろうと、未経験者であろうと、クラウドに分散されたサービスについて十分な情報に基づいた意思決定をするために必要な情報を提供します。ぜひ実際に使っていただき、GitHubのディスカッションで感想を聞かせてください。どのようにこれをリリースしたのか、舞台裏をご紹介しましょう。私たちは、OpenTelemetry SDKsからインスピレーションを得ました。OTelは、テレメトリーデータとSDKを含むツールのなかで、誰でも使える標準的なものとして有名です。やはり、意見や感想をもらうことは私たちSentry開発者としても学びになります。私たちのOTelの開発業務についてもっと知りたい方は、最近のブログ記事をご覧ください。または、ぜひここでご意見をください！ IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

【モバイル開発】未来は宣言型にある

モバイル開発のエコシステムは常に非常に多様であると言えます。（デスクトップ）ウェブ開発のエコシステムよりも多様だと言えるでしょう。日々、ウェブ開発者向けのフレームワークやツールは増えているようですが、その多くはJavaScriptの上に構築されています。その多くは、互いに似たようなパターンを実装しています。一方、モバイルのエコシステムには、コアとなる複数の言語セットがあり、そのためモバイル向けのツールやフレームワークの違いを識別するのは非常に簡単です。モバイルのネイティブプラットフォームの代表格といえば、ネイティブのAndroidとiOSの2つがあります。どちらも最近興味深いイノベーションがありました。近年Jetpack ComposeとSwiftUIの導入がありました。ネイティブアプリの開発は、React NativeやFlutterアプリの開発と非常によく似ています。React NativeもFlutterも、最初から宣言型アプローチをとっています。 AndroidとiOSも現在、宣言型のアプローチを採用しています。モバイル開発の未来は、宣言型であると言えるでしょう。ちょっとした歴史 React NativeやFlutterは常に宣言型のアプローチをとってきましたが、AndroidとiOSは当初はそうではありませんでした AndroidはViewを活用していました（今もそうですが）。ViewはXMLファイルです。 Button、TextView、LinearLayoutなどのウィジェットを使ってユーザーインターフェイスを定義します。開発者はこれらのウィジェットにIDを割り当てます。これらのIDは、Javaファイルの中でウィジェットを参照するために使用されます。ファイルでは、機能と動作を開発します。以下は、Viewファイルの例です：このようにウィジェットのリファレンスを作成することになります。 iOSには、Auto Layout、UIAppearance、Objective-Cの@property宣言、KVCコレクション演算子、Combineといった宣言型の機能がありました。しかし、それでもある程度の命令型のコードを書く必要がありました。例えば、iOSにはStoryboardsがありました（今もあります）。Storyboardsは、私たちがUIを構築するために使うグラフィカルなツールですが、実際にはXMLファイルです。しかし、開発者はXMLのコード自体にはほとんど触れません。ここでは、StoryboardsでUI要素を追加し、参照とアクションを作成する方法を紹介します。宣言型に移行する記憶を呼び覚ますと、命令型アプローチとは、目的のUIを実現するまでのステップバイステップの指示を出すことです。宣言的アプローチとは、最終的なUIがどのような状態になるかを記述することです。 Androidの新しいJetpack ComposeはKotlinで書かれています。これはマークアップ言語であるXMLとは対照的なプログラミング言語です。先ほどのXML Viewの例は、Jetpack Composeではこのようになります。ご覧のように、このアプローチでUIを構築すると、必要なコードはかなり少なくなります。プログラミング言語を使えば、ウィジェットへの参照を作成し、そのウィジェットにロジックを取り付ける代わりに、変数とコールバックを直接使用することができます。値に変化があれば再構成（リレンダリング）が行われるため、UIは常に最新の状態に保たれます。 iOSのSwiftUIはほとんど同じで、Jetpack Composeの代わりにSwiftで構築されています。先ほどのStoryboardの例は、SwiftUIではこのようになります。ここでもコード量がぐっと減ります。ここはプログラミング言語なので、Buttonのラベルを直接定義することができます。参照を作成することなく、onClickコールバックを提供することができます。命令型UIKitで作業しているときに、問題が見つかりました。ViewをView階層に追加する前に、Viewの制約を有効にする必要があります。 subview.leadingAnchor.constraint(…)の行とview.addSubview(view)の行を入れ替えるとエラーにならずに動作します。最初にこのエラーに遭遇したとき、何が起こっているのか理解するのに時間がかかりました。理解しやすくなるまで、さらに何度かこのエラーを発生させてみました。しかし、新しい宣言的アプローチでは、この問題に遭遇することはないでしょう。 AndroidとiOSにおけるこの宣言型へのシフトは、より良い開発者体験とより速い開発への大きな一歩となります。プログラミング言語を使ってUIを宣言型で定義することで、AndroidやiOSの開発者が抱える多くの苦悩を解決することができます。ここでは、宣言型アプローチの利点を紹介します。テーマ設定が簡単になり、より動的になります。ステートマネジメントは自然に感じられ、新しい宣言的アプローチにおいて重要な役割を果たします。コンポジションアプローチでは、要素をネストすることでUIを構成することができますダイナミックレイアウトや条件付きレンダリングが簡単にできるようになりました。なぜでしょうか？それは制御構造や分岐ロジックを持つプログラミング言語を使ってUIを構築しているからです XMLを介するよりもSwift/Kotlinのコードを介した方がgrepがしやすくなります。プログラミング言語の他の部分に適用されるのと同じツールを使って、より体系的にコードを再構築することができます。 PRのコード差の方がわかりやすくなります。 UI要素は、マークアップ言語とは対照的に、実際のデータ構造（関数、クラス、構造体）で構築されています。そのため、Viewのユニットテストも行うことができます。もちろん、気にかけるべき欠点は常にいくつか存在します。 SwiftUIとJetpack Composeはまだ生まれて数年しか経っていません。ドキュメントの不足、コミュニティの小ささ、いくつかのパフォーマンスの問題（例えばAndroidの遅延カラム）などの欠点があり、また以前のフレームワークからのすべてのコンポーネントがサポートされているわけではありません。より複雑なUIを構築しようとすると、制限があります。SwiftUIとJetpack Composeの両方は、まだ進化し、改善されています。 […]

Sentry Category: Sentryでデバッグするヒント / Sentry Debugging Tips