Sentry - Ichizoku

コマンド1つでSentryをインストールする方法

今回は、Sentryのインストールと初期設定を簡単に行う方法を共有いたします。 Next.jsを使用し、ターミナル（コマンドプロンプト）でコマンドを1つ実行するだけで、新しいSentryアカウントの設定や新しいSentry Next.jsプロジェクトの作成ができるようになります。始めるのはとても簡単です。 sentry.io/signupにアクセスしてアカウントを作成したり、アプリ内からプロジェクトを作成したりすることももちろん可能です。しかし現在は、面倒なクリック作業なども省略し、自分のリポジトリに移動してこのコマンドを実行するだけで必要な設定は完了します。スクリプトが起動すると、ブラウザのタブを開いてサインアップフォームを表示します。必要な情報を入力してターミナル（コマンドプロンプト）に戻ると、インストールが完了した旨の文言が表示されます。この新しい方法では、next.config.jsファイルにSentry固有の要件が自動的に追加され、例外や遅延の問題の追跡を開始するために必要なファイルが作成されます。その内容を確認したい場合は『git status』を実行してご確認ください。 Sentryが無事導入できているか確認する場合は、ローカルでエラーをトリガーするか、変更をデプロイして例外や遅いトランザクションを実際に実行する必要があります。それもSentry for Next.jsで、たった1つのコマンド（npx @sentry/wizard -s -i nextjs）で完了します。詳しくは、GitHub、Twitter、またはDiscordでご意見をお聞かせください。 Sentryは、アプリケーションコードの健全性を監視するために不可欠です。エラートラッキングからパフォーマンスモニタリングまで、開発者はフロントエンドからバックエンドまで、アプリケーションをより明確に把握し、より迅速に解決し、継続的に学習することができます。 Sentryは、350万人以上の開発者と世界中の85,000以上の組織に愛され、Disney、Peloton、Cloudflare、Eventbrite、Slack、Supercell、Rockstar Gamesといった世界的有名企業の多くにコードレベルの監視機能を提供しています。毎月、世界中で人気のサービスやアプリケーションから、数十億件の例外を処理し続けています。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

Next.jsのよくあるエラーとその解決方法

バグは、ソフトウェア開発において最も厄介なものの1つです。ほとんどの場合、すぐに解決することができますが、中には修正に数時間から数日かかるような恐ろしいバグもあります。 Next.jsは、現在の世界で最も人気のあるWeb開発フレームワークの1つですが、バグから逃れることはできません。そこで、この記事では、さまざまなプラットフォームの開発者から報告された、最も一般的なNext.jsのエラーをいくつか紹介します。なぜこのようなバグが発生するのか、そしてどのように解決するのかについて説明します。ドキュメント/ウィンドウオブジェクトエラー Next.jsでよくあるエラーのひとつに、「document/windowが定義されていない」というエラーがあります。なぜ起こるのでしょうか？このエラーは、通常、インストールされたパッケージが、ページコンポーネントの中でブラウザのウィンドウオブジェクトに直接アクセスしようとしたときに発生します。例えば、Next.jsアプリケーションにindex.jsのサンプルページがあり、以下のようにブラウザのlocalStorageにアクセスしようとすると、「document/windowが定義されていない」というエラーが発生します。解決方法このエラーを解決するにはいくつも方法があります。ひとつは、ブラウザのウィンドウオブジェクトを必要とするコードブロックを実行するためにreactのuseEffect()フックを使用し、ページコンポーネントがマウントされているときにのみコードを実行するようにすることです。もうひとつの方法は、ブラウザのウィンドウを必要とするコードを独立したコンポーネントに変換し、Next.jsの動的インポート機能を使ってページコンポーネントにインポートすることです。 Nextの動的インポートは、必要に応じてコンポーネントを遅延ロードまたは動的にロードするために使用される機能です。さらに、ssrオプションを追加することで、使用時にサーバーレンダリングの有効・無効を設定することができます。※ちなみに「ssr」は、サーバーサイドレンダリングの意味があります。 ssrの値をfalseに設定するだけで、ブラウザのウィンドウやドキュメントに依存するコンポーネントや外部パッケージを読み込むことができるようになります。下図のようにすることで、ページ内で動的に読み込むようになります。ミドルウェアエラーミドルウェアは、リクエストの完了前にコードが実行され、受信したリクエストに基づいて、ユーザーに送信するレスポンスを書き換え、リダイレクトしたり、ヘッダーを追加したりすることができます。次の例は、Next.jsでミドルウェアを扱うときに遭遇する可能性のあるエラーの1つです。 Next.jsをカスタムサーバーで使用しており、設定でサーバーホストのURLを明示的に指定していない場合に発生するエラーです。また、Nxのようなモノレポビルドシステムを使用している場合、このようなツールがバックグランドでカスタムサーバーを作成するため、このエラーが発生します。 ※「モノレポ」とは、複数のプロジェクトやアプリケーションのソースコードを一元管理することです。解決方法このエラーは、サーバー設定ファイルでホスト名を指定することで簡単に修正することができます。 Nxを使用している場合は、プロジェクト設定ファイル（project.js）のserveオプションを修正することで対応できます。つまり、プロジェクト設定ファイル（project.js）を次のように修正します。ミドルウェアがトリガーされないまれにミドルウェアのコードが全くトリガーされない場合がありますが、それはミドルウェアのファイルが正しく配置されていない可能性があります。解決方法 Next.jsの古いバージョンでは、ミドルウェアのファイルは/pagesディレクトリに_middleware.jsとして作成していました。しかし、Next.jsの最新版では、このファイルをルートフォルダ、つまり/pagesディレクトリと同じ階層にmiddleware.jsとして保存する必要があります。そのため、ファイル構造は次のようになります。 API/スラッグエラー Next.jsには、データ取得のためのAPIとしてgetStaticPathsとgetServerSidePropsがありますが、これらの使い方を誤るとエラーが発生することがあります。そのうちのgetStaticProps APIでのエラーは、以下の通りです。このエラーは、next.jsのSSG（Static Site Generation）機能を使ってサーバーサイドで動的ページをレンダリングしているときに、ページのコンポーネントにgetStaticPaths関数が定義されていない場合に発生します。動的経路を使用するサーバーサイドレンダリング（SSR）または静的生成（SSG）ページを構築するためには、getStaticPaths関数を追加する必要があります。解決方法例えば、/pageName/[slug]がブログ記事に関する情報を表示するページとした場合、getStaticPaths関数でデータベースから利用可能なすべてのブログ記事のスラッグのリストを取得し、[slug]パラメータの値としてそれらを戻り値として返す必要があります。また、Next.jsのデータ取得APIは、すべてページコンポーネントの内部でのみ使用でき、通常のコンポーネントの外部では動作しないことも特筆すべき点です。モジュールエラーまた、Next.jsでよくあるエラーは、次のような「モジュールが見つかりませんでした。’moduleName’を解決できない」というエラーです。このエラーは、Next.jsではアクセスできないモジュールをインポートしているときに発生します。例えば、fsモジュールのように、クライアント側で利用できないモジュールを、あなたやサードパーティのパッケージがアクセスしようすると発生します。解決方法このエラーを解決するには、Node.jsまたはサーバー関連のコードをすべてNext.jsのデータ取得API（getServerSideProps、getStaticPaths、getStaticProps）の内部に置くようにしてください。 Node.jsモジュールに明示的にアクセスしようとしているのではなく、インポートしたパッケージが原因でエラーが発生した場合は、Next.jsの設定ファイル（next.config.js）に、次のようにwebpackのエントリを追加する必要があります。このコードでは、optionsオブジェクトのisServerプロパティをチェックして、現在のビルドがサーバーサイド用かクライアントサイド用かを判断しています。ビルドがサーバーサイド用でない場合（つまりisServerがfalseの場合）、fsモジュールはwebpack設定のresolveセクションでフォールバックリストに追加されます。これは、webpackがfsモジュールのimportに遭遇したとき、importを解決しようとせず、fsモジュールがアプリケーションにバンドルされないことを意味します。もし、Node.jsのモジュールを使っていないのに「モジュールが見つかりません」というエラーが発生する場合は、モジュールが正しくインストールされ、インポートされていることを確認してください。または、ファイル名やモジュール名が間違っている可能性もあるため、そちらについても確認するようにしましょう。クロスオリジンエラー（Next […]

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

ユーザーにとって素晴らしいアプリは、処理パフォーマンスが高いです。しかし、ページロードに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の日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

プロファイリング入門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の日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

Jetpack Composeのはじめかた

先日、宣言型UIへの移行方法に関する記事を書きました。 Androidアプリ開発も、「Jetpack Compose」で最近のトレンドである宣言的実装に加わりつつあります。 Androidスマホで動作するアプリを、ネイティブAndroidアプリと呼びます。これを制作する際に、もっと効率化しようと生み出されたのが「Jetpack Compose」です。 Googleによって制作されたこの新しい宣言型UIツールキットが、急速に普及しています。実際、昨年の「Android Dev Summit」で発表されたように、Androidアプリで人気上位1,000のアプリのうち、160が既にJetpack Composeを使用しています。従来のXML Viewとは対照的に、Jetpack Composeでは、UIがどのように見え、どのように振る舞うべきかを記述する「Composable Function」を使用して、UIを構築できることが特徴です。 Jetpack Composeを使用する主な利点は、より簡潔で理解しやすいUIコードを書くことができることです。これは、保守性の向上と開発期間の短縮につながります。 Jetpack Composeを使用する主なデメリットは、まだ生まれて間もない新しいライブラリであるため、使用できるエコシステム（OSバージョン）が限られていることです。つまり、従来のXML Viewによる開発で使えていたライブラリやツール、リソースの数が、Jetpack Composeだと比較的少ないということです。それでも、Jetpack Composeを学ぶことは、大きな意味を持ち、挑戦に値すると私たちは信じています。ここでは、あなたが始めるにあたり、私たちが役に立つと思ったいくつかのヒントを紹介します。 Jetpack Composeの使用開始方法 Jetpack Composeで作業するための推奨IDEは、Android Studioです。 Android Studioをダウンロードしインストールすると、新しいプロジェクトを作成するオプションが表示されます。新しいJetpack Composeアプリケーションを作成するには、空のComposeアクティビティ（Material v2を使用）、または空のComposeアクティビティ（Material3）（昨年の時点でバージョン1.0であるMaterial v3を使用）のいずれかを選択する必要があります。このスクリーンショットの右上に、両方のオプションが表示されています。これは、最も手軽にJetpack Composeを始める方法であるといえます。少し試したいという場合におすすめです。既存のAndroidアプリケーションにJetpack Composeを有効にしたい場合は、次のように修正を行いましょう。 1. アプリのbuild.gradleファイルに、以下のビルド設定を追加します。 2. Compose BOM（部品表）とComposeの依存関係のサブセットを依存関係に追加します。 Jetpack ComposeのUIはどのように構築されているのでしょうか？ Jetpack Composeでは、ビュー（レイアウト要素）の階層を定義するためにComposablesを使用しています。そして追加されたComposablesに視覚的な外観や動作の変更を適用するためにmodifierを使用します。コンポーザブルファンクション Composable関数（または単にComposableといいます）は、「@Composable」でアノテーションするだけで、Composable関数の中に入れ子構造でUIを定義することができます。 UIを定義するために、Composableの階層を返す普通のKotlin関数でもあります。 […]

コードマッピングとその重要性とは？

コードマッピングは、エラーとリポジトリ内のソースコードを結びつけるものです。エラーは、リポジトリのツリー構造とは異なる経路を持つことがあります。エラーまでの正確なパスを決定するためには、コードマッピングが必要不可欠です。このコードマッピングは、エラーまでのパスとリポジトリURLとの組み合わせによって成立します。 Sentryは、コードマッピングを使用して、課題の詳細ページでコンテキストと役立つデータを発行します。例えば、以下のようなものです。スタックトレース連動 Issue Detailsページから直接リポジトリ内のソースコードに移動することができます課題所有権とコード所有者パスルールを定義するか、リポジトリにあるコードの所有者ファイルを使用することで、課題（Issue）をチームに割り当てることができます。疑わしいコミットエラーが発生した際、どのプログラムのどの行で起きたのか、また誰が触ったかを分析することができます。変更を加えた人を担当者としてアサインし、問題を解決することができます。これらの機能によって、実装中に起きたエラーなどの解決にかかる時間を短縮することができます。また、エラー原因のコードの所有者（修正者）を迅速に特定することができます。これまでは、コードマッピングを設定するためのプロセスが複雑であることが課題視されてきました。そして、使いこなすことが難しいという課題を多くの開発者は以前から抱えてきました。そんな課題を解消するため、私たちは、そのプロセスを簡略化しました。また、コードマッピングを自動化する機能も新たに追加しました。コードマッピングの自動化に成功したプロセスについては、これからご説明します。また、どのように役立つのか、そして今後のリリース計画についてもぜひご覧ください。現在、自動コードマッピングは、GitHubインテグレーションをインストールしているお客様（Teamプラン以上）にのみ提供されています。また、限られた言語でのみ利用可能です。技術的な課題スタックトレースに対してコードマッピングを自動生成する機能を、私たちは数日で開発しました。しかし、『大規模プロジェクトで実行させる』という機能が最も大きな課題として私たちを悩ませました。 Sentryは、数万を超える組織やプロジェクトにご利用いただいています。そして、彼らが書いた多くのコードが格納される数多くのリポジトリを保有しています。私たちは、1時間に何十万通りにも及ぶさまざまなイシュー（フィードバックやバグ）を受け取ります。受け取ったイシューごとに処理を実行しなければなりませんが、この実行にかかるコストは高くつきます。ですので、より経済的でスケーラブル（拡張性がある）設計が必要になりました。 GitHubが設定した利用制限を守らなければならないため、GitHubのAPIをどのように使うかについて検討を積み重ねました。コードマッピングの導出は、GitHubのAPIを使用する唯一の機能ではありません。そのため、キャッシュを効率的かつ適切に使う必要がありました。これは、他のSentryの機能（GitHubからコミットを取得するなど）の動作に影響を与えるため、とても重要な検討事項です。 GitHubのAPIを利用したコードマッピングの導出スタックトレースに記載されているファイルを検索するためには、以下の2つの情報が必要です。ソースコードが存在するリポジトリファイルパスと一致させるために必要な変換工程例えば、このスタックトレースフレーム sentry/shared_integrations/client/base.pyは、Github の以下のソースファイルに接続しているとします。src/sentry/shared_integrations/client/base.py ソースコードがどこにあるのかを判断するためには、顧客の組織内のすべてのファイルとすべてのリポジトリのリストが必要です。リポジトリごとにファイルのツリーを作成するには、GitHub のふたつの API を使います。それは『組織リポジトリの一覧取得』APIと『ツリーの取得』API です。 1つ目の『組織リポジトリの一覧取得』APIは、その組織に関連するすべてのリポジトリをフェッチします。次にこれを使用して、各リポジトリのツリーをフェッチします。 2つ目の『ツリーの取得』API は、与えられたリポジトリのすべてのディレクトリとファイルを表すリポジトリツリーを返します。このAPIは 1回の呼び出しで、あるリポジトリのすべてのファイルにアクセスできるため、非常に便利です。レスポンスからツリー情報を抜き出し、ソースコードファイルでないものはすべて破棄します。エラーを発生させる可能性のあるファイルのみに絞り込むためです。すべてのリポジトリのツリーを入手したら、スタックトレースがあるプロジェクトの課題を選んで処理します。すべてのリポジトリの中で一致するファイルを見つけるために、すべてのフレームファイルのパスを探します。その際、リポジトリ内の任意の深さで正確なパスを検索します（例えば、src/foo/bar.py と project/src/foo/bar.py は sentry/foo/bar.py にマッチする、など）。ここで、Githubの検索APIを使うこともできたのですが『1時間に25リクエストまで』というAPI利用制限がありました。 […]

SentryファミリーにCodecovが参画：コードカバレッジとアプリケーション監視の融合

本日、CodecovはSentryファミリーに加わりました。Codecovは、2014年にコードカバレッジレポートツールとして始まり、それ以来Codecovはテスト分析分野のマーケットリーダーとして成長してきました。Codecovは、20以上のテストフレームワークでカバレッジを実用的なものにします。これまで100万人以上のソフトウェア開発者たちのテスト、カバレッジ、コードの信頼性に対するアプローチを改善するのに役立っています。テスト分析がアプリケーションの監視とどう関係するのでしょうか。それを理解するためには、まず、コードが適切にテストされないとどうなるかに着目する必要があります。コードを正しくテストせず（あるいは全くテストせず）、モニタリングに失敗したときに何が起こるのかに注目しなければなりません。ソフトウェアの停止が起こり、アプリケーションのパフォーマンスの問題が発生します。そしてそれは、顧客にとって劣悪な体験を生み出すことになるのです。ソフトウェアの停止は、問題の分析から始まります。実際に何が問題を引き起こしているのでしょうか？パフォーマンスの問題やその他のシグナルをつなぎ合わせて、根本原因を診断します。これがSentryの存在理由です。Sentryは、開発者の生産性を向上させるために存在します。私たちは、問題をできるだけ早く特定することに注力します。そして、開発者たちがその問題を素早く解決するための正しい情報とツールを手に入れることができるようにします。多くの開発者はこれをMTTR（平均復旧時間）と呼んでいます。Sentryは、問題が発生したときに開発者がそれを認識するのを助け、根本原因を示し、開発者らが臨めば問題をすぐに解決できるようにします。ソフトウェアチームがインシデント管理ではなく、本来の研究開発に割く時間を最大化できるよう、私たちは支援します。ソフトウェア開発ライフサイクルにおけるリリース前の段階において、ソフトウェアテストは高品質のコードを確実に開発するために最も重要です。Codecovは、より健全で高品質なコードを出荷することが、リスクの低減、より良いユーザー体験、そして開発者の生産性の向上につながると考えています。開発者の生産性を向上させるためのCodecovのアプローチは、コードが出荷される前のコードカバレッジと自動テストに重点を置いています。Sentryと同様、Codecovは常に開発者がコードの問題を認識するのを助け、望めばそれを解決できるように選択肢を与えることに重点を置いてきました。Codecovがソフトウェア開発ライフサイクルのプリリリース側に焦点を当てているとしても、SentryとCodecovの使命は同じです。両社とも、世界最高の開発者ツールを作り、開発者ファーストの考え方にこだわり続けたいと考えています。 SentryがCodecovと話を始めたとき、何万もの組織と協力してきたその道程について聞きました。つまり、それまでのコードカバレッジの概念は多くの開発者が使う便利な指標でありながらその指標の本来の意味については、ほとんど合意が得られていませんでした。 100％のカバレッジが目標なのでしょうか？完全にカバーされたコードベースが、なぜまだ壊れることがあるのでしょうか？100%がゴールでない場合、どの程度のテストが必要でしょうか？「ハッカーニュースコードカバレッジ」で検索して議論を読んでみてください。これらの議論は、答えが必要な質問が何かを明らかにしています。開発者はどのようにコードをテストするでしょうか？そのテストはどの程度弾力性がありますか？なぜコードベースの特定の部分をテストするのでしょうか？顧客やユーザーに対するリスクは？コードのコミットごとにすべてのテストを実行する必要があるのでしょうか？これらの質問は、Codecovが豊富な機能と今後のロードマップを確立するためのインスピレーションとなり、そして今後はSentryに統合されます。 Sentryのミッションは常に、ダッシュボードやツールの提供だけでなく、背景情報や洞察を通じて、開発者が高品質のコードを出荷できるようにすることです。Codecovチームは、この私たちのただ一つの焦点を共有しています。Codecovは、開発サイクルの早い段階で、アプリケーションのコード品質について、より包括的な洞察を開発者に提供します。 Codecovは、Sentryと同様に、開発者の既存のソフトウェア開発のワークフロー内で動作します。Codecovは、プラットフォーム、言語、CI/CDツールに関係なく、コードの品質に関するフィードバック、洞察、およびオーナーシップを提供します。今回の買収により、Sentryの顧客は、デプロイ前とデプロイ後の両方で、コード品質に関する洞察と保護から利益を得ることができます。 Sentryは、アプリケーションコードの健全性を監視するために不可欠なツールです。エラー追跡からパフォーマンス監視まで、開発者は、フロントエンドからバックエンドまで、アプリケーションをより明確に把握し、より迅速に解決し、継続的に学習することができます。 Sentryは、世界中の350万人以上の開発者と85,000以上の組織に愛され、Disney、Peloton、Cloudflare、Eventbrite、Slack、Supercell、Rockstar Gamesといった世界で最も有名な企業の多くにコードレベルの観察機能を提供しています。毎月、インターネット上で最も人気のある製品から数十億の例外処理を実行しています。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

プロファイリング入門101：プロファイリングとは何か？

アプリケーションの性能は重要です。パフォーマンスの高いアプリケーションは、優れたユーザーエクスペリエンスを保証し、大切な顧客を維持します。開発者は、パフォーマンス目標を達成するための適切なツールを使う必要があります。顧客から不満が出る前に、適切なツールを用意していなければならないのです。良好なパフォーマンスを確保するための開発者のツールボックスの中で最も優れたツールの一つがプロファイリングです。本番のコードがどこで遅くなるかを正確に予測するのは非常に困難です。プロファイリングツールを使えば、コードの中で遅くなっている行を正確に示すことができます。また、特定の最適化を行い、テストすることも可能です。この三回シリーズでは、プロファイリングとは何か、なぜ本番環境でコードをプロファイリングする必要があるのか、プロファイリングのための人気のツールを紹介します。第1部プロファイリングとは？プロファイリングとは何か？（この記事です！）第2部：なぜプロファイリングなのか？第3部：プロファイリングツールとその使い方（近日公開予定）プロファイリングとは何か？プロファイリングツールは何十年も前からありますす。新しいものではありません。プロファイリングとは、プログラムのリソース使用状況のスナップショットを取得する方法です。これをプロファイルと呼びます。そして、そのスナップショットをコードベースに結びつけます。これで、コードの各行ごとのリソースの使用状況を把握することができます。プロファイリングは動的解析の一種です。コードを実行しながら測定します。プロファイリングによって、ローカルでも本番でも、コードがどのように実行されているかを正確に把握することができます。コードがデータベースや他のサービスとどのように相互作用しているかを確認することができます。プロファイリングは分散トレーシングとどう違うのか？まず、プロファイリングとトレーシングの違いについて説明します。トレーシングは、パフォーマンスを監視するために一般的に使用されるまた別のツールです。トレーシングは、リクエストの流れやタイミングを、システムを通過する際に追跡します。これは、そのシステムのパフォーマンスを理解し、ボトルネックを特定するのに役立ちます。トレースは、プログラムの実行中に発生したイベントのログです。分散型トレーシングでは、バックエンドとフロントエンドを横断して追跡するなど、分散型システムでトレースを作成します。フロントエンドからバックエンドへのリクエストをトレーシングすることで、どのサービスが関与し、どれくらいの時間がかかっているかを把握することができます。多くの場合、外部サービスやデータベースがアプリケーションの遅延を引き起こす最大の原因となっています。トレーシングは、これらの遅延を特定し測定するのに適しています。しかし、外部からの呼び出しではなく、内部的な問題でアプリケーションが遅くなっている場合、トレーシングは問題がどこにあるのかを正確には示せないことがあります。トレースから得られる情報は、コードに手動で実装したスパンと同程度の粒度しかないのです。一方、CPUプロファイラでは、関数や行レベルの詳細な情報を得ることができます。すべての関数を計測しなくても、コードのどこが遅いかを知ることができるのです。プロファイラの種類プロファイリングは非常に幅広い意味で用いられる言葉です。プロファイラは様々な方法で実装することができます。例えば、プロファイラが収集するデータには、CPU、GPU、メモリ、I/O、ネットワーキングなどの使用状況が含まれます。最近のプロファイリングツールのほとんどはCPUプロファイラで、CPU上で実行されるコードの性能を測定します。この連載では、CPUプロファイラに焦点を当てます。注意する点として、この記事で使用する例のほとんどは、フロントエンドとバックエンドの開発に関するものです。しかしながら、プロファイリングはあらゆるタイプのコードのパフォーマンスを理解するのに役立てられます。継続的プロファイリング、アドホックプロファイリング、およびトランザクションベースのプロファイリングプロファイリングには、継続的に行う方法（常に行う方法）、アドホックに行う方法（Chrome DevToolsなどのツールを使ってサイトのプロファイルを手動で収集する方法）、またはその中間があります。アドホックプロファイリングアドホックプロファイリングは、ウェブアプリケーションのプロファイルを取得する最も簡単な方法です。でも、ほとんどのアドホックプロファイリングツールは、機能が制限されています。非常に人気のあるアドホックプロファイリングツールの一つは、Chrome DevToolsのパフォーマンスパネルです。これは、ボタンを押すことで、あらゆるウェブサイトの基本的なCPUプロファイルを記録することができます。アドホックプロファイリングツールは、ウェブサイトのパフォーマンスを素早く把握するのに便利ですが、プロファイルに収集されるデータは完全ではありません。 Chrome DevToolsのプロファイルは、主にウェブサイトのフロントエンドのパフォーマンスを素早く把握するのに便利です。しかし、バックエンドのデータを正確に把握することはできません。さらに、プロファイルはあなたのマシンに固有のものであり、他のユーザーたちが体験している挙動を正確に反映しているとは限りません。最後に、これらのプロファイルの収集を自動化する簡単な方法もありません。パフォーマンスデータを見るには、毎回手動でプロファイルを作成する必要があります。各プロファイルがユーザーエクスペリエンスを正確に表しているかどうかは定かではないのです。継続的プロファイリング継続的プロファイリングは、包括的なプロファイルデータの定石です。継続的プロファイリングは、長時間実行されるプロファイルです。このプロファイルは、アプリケーションの実行時間全体、またはユーザーセッション全体にわたって自動的に収集されます。アドホックプロファイリングとは対照的に、連続的プロファイリングは、すべてのユーザーセッションで自動的に実行されます。これにより、いつでも実際のユーザーエクスペリエンスを明確に把握することができます。これを実現するために、ウォールタイム（通話が完了するまでにかかる現実世界の時間）のような計算されたメトリクスを使用することができます。継続的プロファイリングには、デメリットもあります。継続的プロファイリングは時間を長く擁することもあり、そのため必要な情報を見つけるのが難しくなることがあります。大量のデータ処理を要する場合もあります。トランザクションベースのプロファイリングトランザクションベースのプロファイリングは、アプリ内でトランザクションが発生している間にプロファイルを自動的に収集するプロファイリング手法です。トランザクションはトレーシングから生じた概念です。トランザクションとは、アプリケーション内部で呼び出されるサービスの単一インスタンスのことです。例えば、ページロード、ナビゲーション、非同期タスクなどです。これらのトランザクションの集合が1つのトレースを構成します。トランザクションベースのプロファイリングでは、自動プロファイリングの利点を享受でき、複数のユーザーのマシンで実際に起きていることを把握することが可能となります。しかし、継続的プロファイリングほど多くのデータを収集することはできません。トランザクションベースのプロファイリングでは、プロファイルが自動的に収集されるのは、トランザクションが発生している間だけです。これにより、トランザクションと一対一でプロファイルを収集することが可能になります（例えば、トランザクションをキャプチャする毎にプロファイルもキャプチャされます）。また、トランザクションに対してプロファイルの収集をアンダーサンプリングすることも可能です。つまり、各プロファイルはトランザクションに関連付けられますが、すべてのトランザクションがプロファイルを持つわけではありません。プロファイルの収集はトランザクションよりも多くのリソースを使用するため、アンダーサンプリングによってプロファイリングツールが引き起こすアプリケーションのパフォーマンス悪化を防止できます。さらに、プロファイルをトランザクションにリンクさせることで、トランザクションとプロファイルからパフォーマンスデータを探索し理解するためのわかりやすいメンタルモデルを得られます。アドホックプロファイリング、継続的プロファイリング、トランザクションベースプロファイリングの違いをまとめた表がこちらです。アドホックプロファイリング継続的プロファイリングトランザクションベースのプロファイリングプロファイルの作られ方手動自動 […]

Archives: Sentry