Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the acf domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/staging_ichizoku.demowpsites2.com/wp-includes/functions.php on line 6121
プロファイリング入門101:プロファイリングとは何か? – Ichizoku

Ichizoku is an official partner of Arize in Japan

プロファイリング入門101:プロファイリングとは何か?

アプリケーションの性能は重要です。パフォーマンスの高いアプリケーションは、優れたユーザーエクスペリエンスを保証し、大切な顧客を維持します。開発者は、パフォーマンス目標を達成するための適切なツールを使う必要があります。顧客から不満が出る前に、適切なツールを用意していなければならないのです。

良好なパフォーマンスを確保するための開発者のツールボックスの中で最も優れたツールの一つがプロファイリングです。本番のコードがどこで遅くなるかを正確に予測するのは非常に困難です。プロファイリングツールを使えば、コードの中で遅くなっている行を正確に示すことができます。また、特定の最適化を行い、テストすることも可能です。

この三回シリーズでは、プロファイリングとは何か、なぜ本番環境でコードをプロファイリングする必要があるのか、プロファイリングのための人気のツールを紹介します。

プロファイリングとは何か?

プロファイリングツールは何十年も前からありますす。 新しいものではありません。プロファイリングとは、プログラムのリソース使用状況のスナップショットを取得する方法です。これをプロファイルと呼びます。そして、そのスナップショットをコードベースに結びつけます。これで、コードの各行ごとのリソースの使用状況を把握することができます。

プロファイリングは動的解析の一種です。コードを実行しながら測定します。プロファイリングによって、ローカルでも本番でも、コードがどのように実行されているかを正確に把握することができます。コードがデータベースや他のサービスとどのように相互作用しているかを確認することができます。

プロファイリングは分散トレーシングとどう違うのか?

まず、プロファイリングとトレーシングの違いについて説明します。

トレーシングは、パフォーマンスを監視するために一般的に使用されるまた別のツールです。トレーシングは、リクエストの流れやタイミングを、システムを通過する際に追跡します。これは、そのシステムのパフォーマンスを理解し、ボトルネックを特定するのに役立ちます。トレースは、プログラムの実行中に発生したイベントのログです。分散型トレーシングでは、バックエンドとフロントエンドを横断して追跡するなど、分散型システムでトレースを作成します。

フロントエンドからバックエンドへのリクエストをトレーシングすることで、どのサービスが関与し、どれくらいの時間がかかっているかを把握することができます。多くの場合、外部サービスやデータベースがアプリケーションの遅延を引き起こす最大の原因となっています。 トレーシングは、これらの遅延を特定し測定するのに適しています。

しかし、外部からの呼び出しではなく、内部的な問題でアプリケーションが遅くなっている場合、トレーシングは問題がどこにあるのかを正確には示せないことがあります。トレースから得られる情報は、コードに手動で実装したスパンと同程度の粒度しかないのです。一方、CPUプロファイラでは、関数や行レベルの詳細な情報を得ることができます。すべての関数を計測しなくても、コードのどこが遅いかを知ることができるのです。

プロファイラの種類

プロファイリングは非常に幅広い意味で用いられる言葉です。 プロファイラは様々な方法で実装することができます。例えば、プロファイラが収集するデータには、CPU、GPU、メモリ、I/O、ネットワーキングなどの使用状況が含まれます。 最近のプロファイリングツールのほとんどはCPUプロファイラで、CPU上で実行されるコードの性能を測定します。 この連載では、CPUプロファイラに焦点を当てます。

注意する点として、この記事で使用する例のほとんどは、フロントエンドとバックエンドの開発に関するものです。しかしながら、プロファイリングはあらゆるタイプのコードのパフォーマンスを理解するのに役立てられます。

継続的プロファイリング、アドホックプロファイリング、およびトランザクションベースのプロファイリング

プロファイリングには、継続的に行う方法(常に行う方法)、アドホックに行う方法(Chrome DevToolsなどのツールを使ってサイトのプロファイルを手動で収集する方法)、またはその中間があります。

アドホックプロファイリング

アドホックプロファイリングは、ウェブアプリケーションのプロファイルを取得する最も簡単な方法です。でも、ほとんどのアドホックプロファイリングツールは、機能が制限されています。

非常に人気のあるアドホックプロファイリングツールの一つは、Chrome DevToolsのパフォーマンスパネルです。これは、ボタンを押すことで、あらゆるウェブサイトの基本的なCPUプロファイルを記録することができます。アドホックプロファイリングツールは、ウェブサイトのパフォーマンスを素早く把握するのに便利ですが、プロファイルに収集されるデータは完全ではありません。

Chrome DevToolsのプロファイルは、主にウェブサイトのフロントエンドのパフォーマンスを素早く把握するのに便利です。しかし、バックエンドのデータを正確に把握することはできません。さらに、プロファイルはあなたのマシンに固有のものであり、他のユーザーたちが体験している挙動を正確に反映しているとは限りません。

最後に、これらのプロファイルの収集を自動化する簡単な方法もありません。パフォーマンスデータを見るには、毎回手動でプロファイルを作成する必要があります。 各プロファイルがユーザーエクスペリエンスを正確に表しているかどうかは定かではないのです。

継続的プロファイリング

継続的プロファイリングは、包括的なプロファイルデータの定石です。継続的プロファイリングは、長時間実行されるプロファイルです。このプロファイルは、アプリケーションの実行時間全体、またはユーザーセッション全体にわたって自動的に収集されます。

アドホックプロファイリングとは対照的に、連続的プロファイリングは、すべてのユーザーセッションで自動的に実行されます。これにより、いつでも実際のユーザーエクスペリエンスを明確に把握することができます。 これを実現するために、ウォールタイム(通話が完了するまでにかかる現実世界の時間)のような計算されたメトリクスを使用することができます。

継続的プロファイリングには、デメリットもあります。継続的プロファイリングは時間を長く擁することもあり、そのため必要な情報を見つけるのが難しくなることがあります。大量のデータ処理を要する場合もあります。

トランザクションベースのプロファイリング

トランザクションベースのプロファイリングは、アプリ内でトランザクションが発生している間にプロファイルを自動的に収集するプロファイリング手法です。

トランザクションはトレーシングから生じた概念です。トランザクションとは、アプリケーション内部で呼び出されるサービスの単一インスタンスのことです。 例えば、ページロード、ナビゲーション、非同期タスクなどです。これらのトランザクションの集合が1つのトレースを構成します。

プロジェクト横断的な視認性

トランザクションベースのプロファイリングでは、自動プロファイリングの利点を享受でき、複数のユーザーのマシンで実際に起きていることを把握することが可能となります。しかし、継続的プロファイリングほど多くのデータを収集することはできません。トランザクションベースのプロファイリングでは、プロファイルが自動的に収集されるのは、トランザクションが発生している間だけです。

これにより、トランザクションと一対一でプロファイルを収集することが可能になります(例えば、トランザクションをキャプチャする毎にプロファイルもキャプチャされます)。また、トランザクションに対してプロファイルの収集をアンダーサンプリングすることも可能です。つまり、各プロファイルはトランザクションに関連付けられますが、すべてのトランザクションがプロファイルを持つわけではありません。

プロファイルの収集はトランザクションよりも多くのリソースを使用するため、アンダーサンプリングによってプロファイリングツールが引き起こすアプリケーションのパフォーマンス悪化を防止できます。

さらに、プロファイルをトランザクションにリンクさせることで、トランザクションとプロファイルからパフォーマンスデータを探索し理解するためのわかりやすいメンタルモデルを得られます。

アドホックプロファイリング、継続的プロファイリング、トランザクションベースプロファイリングの違いをまとめた表がこちらです。

アドホックプロファイリング 継続的プロファイリング トランザクションベースの

プロファイリング

プロファイルの作られ方 手動 自動 自動
プロファイルが作られる

タイミング

必要時のみ 常時 トランザクション発生中
コードへの実装の必要 コード変更不要 あり 自動実装が利用不可の際
利用に適した環境 開発環境 本番環境 本番環境

決定論的プロファイラとサンプリング型のプロファイラの比較

プロファイリングツールの実装には様々な方法があります。CPUプロファイラは通常、決定論的なものとサンプリング型のものの2つのカテゴリーに分類されます。 これは、プロファイルがどのように収集されるかに依存します。

決定論的プロファイラ

決定論的プロファイルは、トレーシングプロファイラとも呼ばれます。パフォーマンスよりも正確さを優先し、関数の呼び出し、関数の戻り値、例外のイベントをすべて捕捉します。また、これらのイベント間の間隔を正確に記録します。

サンプリング型プロファイラ

サンプリング型プロファイラ(またの名を統計的プロファイラ)は、優先順位を付け、パフォーマンスに負荷を与える追加作業を実施しません。一定時間ごとにコールスタックを取得し、各スレッドからサンプルを収集します。 また、統計的な手法で関数の継続時間を計算します。

例えば、コールスタックキャプチャで、関数Aが関数Bを呼び出し、その関数Bが関数Cを呼び出しているとします(A→B→C)。10ms後の次のキャプチャは、Cのない A → Bを示しています。ここから、 最初のサンプルではCがスタックに存在し、二番目のサンプルでは存在しなかったため、Cの機能持続時間は約10msであると想定できます。

サンプリン型グプロファイラで計算すると、関数Cの継続時間は約10msとなります。

決定論的プロファイラとサンプリング型のプロファイラの比較

どのプロファイラでも、プロファイルの収集に決定論的アプローチまたはサンプリングアプローチのいずれかを使用することができます。しかし、本番環境で自動的に実行される継続的プロファイリングやトランザクションベースのプロファイリングツールでは、この区別はより重要な意味を持ちます。プロファイリングツールが追加するパフォーマンスの追加負荷は、エンドユーザーの体験に直接影響します。

決定論的プロファイラでは、本番環境でのすべての関数呼び出しを測定することで、何が起きているのかの全体像を把握できます。しかし、これにはアプリに高いパフォーマンスの追加負荷が発生します。これに対して統計的プロファイラでは、関数呼び出しの回数に関する追加負荷が固定されています。

統計的プロファイラを使用すると、プロダクションでのパフォーマンスのオーバーヘッドをより低く、より一貫したものにすることができます。このため、実運用で使用されるプロファイラのほとんどは、サンプリング型プロファイラです。

アプリのプロファイリングはパフォーマンスに影響するか?

前述の決定論的プロファイラとサンプリング型プロファイラの違いについて読めば、プロファイリングが本番のコードに実際にどれだけの追加負荷を加えるのか、知りたいと思うことでしょう。

プロファイラが収集するデータが多ければ多いほど、また収集する頻度が高ければ高いほど、プロファイラがパフォーマンスに与える影響は大きくなります。前述のように、サンプリング型プロファイラの方が決定論的プロファイラよりも追加負荷が小さいことがほとんどです。

Sentryは、Android、iOS、Node、および Python 用のトランザクションベースのサンプリングプロファイラを作成します。プロファイリングされるプラットフォーム、ハードウェア、アプリケーションによって追加負荷は異なりますが、Sentryのプロファイリング製品はすべて、CPU 時間の追加負荷が10%未満となることを目標としています。

もちろん、アドホックプロファイラの場合、コードのプロファイルを収集しても、パフォーマンスに影響があるのは、そのアドホックプロファイルが収集されている間だけです。

結論

プロファイリングを始めるのは難しく感じるかもしれません。「プロファイラ」という言葉は、ツールによってさまざまな意味を持ち得ます。Sentryのプロファイリングを試してみる準備はできましたか?Sentryは、PythonとNode(アルファ版)、AndroidとiOS(ベータ版)用のトランザクションベースのプロファイラを備えています。 CPU使用率の急上昇やレイテンシーの問題を引き起こしているコード行がどこなのかを正確に見つけるお手伝いをします。

まずはもっと詳細を知りたいですか?「プロファイリング101 パート2: なぜプロファイリングなのか?」をご覧ください。また、profiling@sentry.ioに意見や質問を書いたり、Discord に参加して#profiling チャンネルに参加したりすることもできます。

Sentryは、アプリケーションコードの健全性を監視するために不可欠なツールです。エラー追跡からパフォーマンス監視まで、開発者たちは、フロントエンドからバックエンドまで、アプリケーションをより明確に把握し、より迅速に解決し、継続的に学習することができます。Sentryは、世界中の350万人以上の開発者と85,000以上の組織に愛され、Disney、Peloton、Cloudflare、Eventbrite、Slack、Supercell、Rockstar Gamesといった世界で最も有名な企業の多くにコードレベルの観察機能を提供しています。

毎月、インターネット上で最も人気のある製品から数十億の例外処理を実施しています。

 


IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。

シェアする

Recent Posts