Webパフォーマンスチューニングのためのオブザーバビリティ

なぜWebサービスはパフォーマンス改善が求められるのか

パフォーマンスを改善し”高速化”することは、現代のWebサービスにおける強力な武器です。現代のWebサービスを是非を担う重要な要素 = ユーザー体験はビジネスの成功を左右します。Googleでは、Web上で優れたユーザー体験を実現するための重要な指標として Core Web Vitalsを策定し、ユーザー体験の最適化へ取り組むことがサイトの長期的な成功の秘訣として語られています。そして、2021年５月より、Google 検索へのページ エクスペリエンスの導入され、SEO対策としてこのCore Web Vitalsが関係します。かつ、その中には読み込み時間(Largest Contentful Paint)が重要指標として評価されます。現代のWebサービスにおけるパフォーマンス改善、つまり高速化は、SEO対策になると同時にユーザー体験の向上につながる、企業の競争力に直結する必須の要件です。

 Webパフォーマンス改善のためのオブザーバビリティ

New Relicが提供するオブザーバビリティは、データに基づいたWebパフォーマンス改善を強力に推進します。New Relicはありとあらゆるところからフルスタックでデータを計測することで、勘に頼ることなくパフォーマンスを客観的に可視化し改善できるプラットフォームです。これは古くからソフトウェア業界に伝わる格言「推測するな、計測せよ」を手軽に実現するプラットフォームでもあります。今日のWebサービスに求められるパフォーマンスやレイテンシ、スループット、もちろんCore Web Vitalsも可視化し、改善可能にします。次章では、可視化されたパフォーマンスがどのように見えるのか、その実際を見ていきましょう！

New Relic APMでパフォーマンスを追跡する

従来、パフォーマンス情報を読み解くには負荷試験による外部からの補足を行うか、ログに記録して読み解く手段しかありませんでした。前者は負荷試自体の準備に時間や工数を要し手軽にできるものではなく、またネットワークの遅延などその他の要因も絡むためユーザーサイドの視点から計測するなら良いものの、間接的にアプリケーションの性能を評価することになります。またログでパフォーマンス確認する方法もありますが、ログの取集、保存、分析が必要なため、同様に工数や時間が浪費されます。加えて、もし複数台に渡ってアプリケーションログを取集するとなると、比例して手間がかかります。しかし、New RelicのAPMを利用すれば、アプリケーションの純粋なパフォーマンスを内部から直接計測し、一目で状態を見渡すことができます。さまざまなデータからサービスの健全性を確認し、ボトルネックの特定、遅延の発見、エラーの補足を通じてパフォーマンスが非常に手軽に可視化されます。下記New Relic APMの画面をご覧ください。

この画面は、New Relic Relic APMが計測したデータを自動で可視化してくれます。不要な手間なしに直ちにパフォーマンスをリアルタイムで確認できます。グラフからどのようにデータを読み取れるかを下記に解説します。

1. Web transaction time
   • レスポンスタイムを示しています。これによりレイテンシーの発生を簡単に発見することができます。
   • 画像にある時間軸「Jul 21 11:00 am」あたりに遅延が発生していることがグラフから一目で見抜けます。
2. Throughput
   • 1分あたりに捌いたリクエスト数が表示されます。スループットは同時並行処理に関わる指標でパフォーマンス改善の一環で着目される指標です。高速化を実現してく中で、ある瞬間に捌いているリクエスト数がどれくらいかを可視化しています。
   • 画像では、どの時間帯でも平均的なスループットに優位差は無く、比較的安定的に捌けているというアプリケーションの健全性が読み取れます。
3. Error rate
   • 発生したエラーの件数をエラー率として示しています。エラーがどれくらいの頻度で発生しているのか、今までのエラーログ解析に比べれば、遥かに簡単で、リアルタイムに把握することができます。
4. Apdex score
   • Apdexはレスポンスタイムについて、ユーザー満足度を計測するための業界標準です。apdexは、満足、許容、不満足の３つの評価でエンドユーザーのアプリに対する全体的な満足度を示します。

いかがでしょうか。New Relic APMは非常に手軽にパフォーマンスを確認し、ボトルネックの特定に役立つことができます。また、トランザクション単位でより詳細な分析も可能です。

New Relic Browserでウェブページパフォーマンスとユーザー体験を追跡する

New Relic  はAPMのようなバックエンドアプリケーションのみならず、ブラウザアプリケーションも得意としております。そしてNew Relic Browser Monitoring はGoogle の Core Web Vitalsがデフォルトで備わっているため、不要な追加作業なしに、重要なメトリクスを一発で確認することができます。「なぜWebサービスはパフォーマンス改善が求められるのか」に記述した通りGoogle Core Web Vitals は業界標準のメトリクスであり、ブラウザアプリケーションのロードパフォーマンスや応答性、レイアウトの安定性を可視化することで、SEO対策、ユーザー体験の把握ができます。

1. Core Web Vitals
   • ユーザー体験の指標であるCore Web Vitalsがデフォルトで計測されます。
   • LCP: 最大の満足のいくペイント, FID: 最初の入力遅延, CLS: 累積レイアウトシフトを意味しますが、特にLCPはバックエンドのレイテンシに加えてブラウザの処理時間も含めて計測されるため、パフォーマンスに関わる指標と言えます。また、「Webサービスの顧客満足度を把握するための Core Web Vitals を理解しよう」は緻密かつ実践な解説がございませすのでぜひ一読いただければ幸いです。
2. Front end vs. back end
   • フロントエンドとバックエンドのどちらに処理時間を要したのか、比較によって明らかになります。これによりパフォーマンスや問題がフロントエンドとバックエンドのどちらにあるのか切り分けに使えるグラフです。
3. その他
   • ユーザーの滞在時間（User time on the site)などその他さまざまなリアルユーザーモニタリングに重要な指標を可視化します。

分散トレーシングで一気通貫でパフォーマンスを追跡する

最後の仕上げとして、分散トレーシングによるフロントからバックエンドまでの一気通貫のパフォーマンスを見ていきましょう。ここまで、バックエンドアプリケーション(APM)とブラウザアプリケーション(Browser)を単体で見てきました。もちろん単体でも有効にご活用いただけますが、ここではさらに踏み込んでバックエンドアプリケーション(APM)とブラウザアプリケーション(Browser)を同時に１つのものとして観測し、それぞれを関連づけて分析することで、パフォーマンスに関する深いインサイトを得てみましょう。下記の画面をご覧ください。

サービスマップに代表されるように、ブラウザからバックエンドにまたがる１つのリクエストが全体を通して可視化されています。この例では、ブラウザからバックエンド１へ、そこからさらにバックエンド２へ通過するリクエストをトレースし、可視化されています。一般的にこのような１つのリクエストがブラウザから、バックエンド１、バックエンド２へまたがって処理される場合、たった１つのアプリケーションに着目して観測するだけでは全体的なパフォーマンスやエラーを補足することができません。ゆえに分散トレーシングのような一気通貫でパフォーマンスを補足できる技術が最も有効に活用できるシーンであります。

1. Average duration
   • トレース全体の経過時間になります。この場合ブラウザから、バックエンド１、バックエンド２にまたがって処理にかかった時間が算出されます。
2. Throughput
   • 1分あたりに全体に跨いで捌かれたクエスト数が表示されます。
3. Error Details
   • トレース全体に跨いで補足されたエラーが表示されます。自動でエラーを収集するため、ログ分析なしにアプリケーションのエラーを迅速に特定できます。
4. スパン
   • 全体に跨いで処理されたリクエストがどのアプリケーションのどの部分に処理時間を要したのか、全体からボトルネックを特定できるようになります。また、通常より遅延が発生しているレスポンスなどはNew Relicが自動的に異常検知し、さらに容易にボトルネックを発見できます。

New Relic は計測することで、速度改善のためパフォーマンスデータをきっちりと可視化してくれます。APMやBrowserなど単体で各アプリケーションを計測、可視化し、ご活用いただけるだけではなく、分散トレーシングによってリクエスト全体を分析できるツールを提供しております。速度改善したいエンジニアが”高速化”によってパフォーマンスとユーザー体験に貢献できるような取り組みをNew Relicは支援します。