テクノロジー本部の布川です。
私の所属するチームではこれまで、ユーザ体験向上のためにLIFULL HOME'Sの高速化に取り組んできました。 本記事では、上記プロジェクトの一環として実施した、一度チューニングを行ったページの性能を将来に渡って維持するための仕組みづくりについて紹介したいと思います。
背景と目的
性能改善後の再劣化の検知
本プロジェクトにおいては、LIFULL HOME'S内の各ページのパフォーマンスを一覧で閲覧できるような仕組みを用意して、優先的に改善対応を行うべき箇所の特定や、施策の評価などに活用していました。
Webページのパフォーマンスは、一度改善の対応を行っても、その後さまざまなリリースが積み重なることによって再び劣化してしまうものです。再劣化を検知したタイミングですぐに原因を特定して対応できれば、改善されたパフォーマンスを長く維持することにつながります。
しかし、従来はその変化に気付くためには日常的にダッシュボードを確認する必要があり、パフォーマンス維持に向けた取り組みが効率的な形で行われているとは言えない状況でした。 そこで、高速化チームやリリースを行ったチームが早い段階で問題に気付き、必要に応じて対応できるようにするため、パフォーマンスの劣化を検知して通知する仕組みを用意することにしました。
課題
この仕組みを作るにあたっては、劣化の検知に限られた時間範囲のデータしか使えないことが課題となっていました。
現状のメトリクス収集基盤
現行のサイト監視の仕組みにおいて取得した計測データは、データ収集ツールであるPrometheusに集積されます。 これには、LIFULLのKEELチームが運用するPrometheus, Thanos, AlertManager, Grafanaといった基盤をそのまま使っています。
PrometheusとGrafanaで追求する、より良いアプリケーションの可観測性 | ドクセル
ここでは、メトリクスの収集先であるPrometheusに向けてこのようなpromqlを叩くことで、収集したメトリクスを任意の方法で可視化したり、比較することができます。
avg by (category)(wpt_score{uri="https://www.homes.co.jp/"})
アラート生成にまつわる問題
ここで、Grafanaなどでメトリクスにアクセスする際はPrometheusの永続化層であるThanosのデータにもアクセスできますが、アラートはその前段のPrometheus上のストレージのみを元に生成します。
ページパフォーマンスが劣化したという事象について信頼性を担保するには長期間のメトリクスをもとにアラートを生成することが望ましいですが、永続化前段では3時間分のデータしか保持しないため、この点について対処する必要がありました。
Thanos Rulerを通して長期間のメトリクスをもとにアラートを生成することはできますが、信頼性に関していくつかのトレードオフがあり信頼性を担保したい今回のユースケースには適さないと判断しています。
解決策
新たなメトリクスの生成
それぞれのページの各バイタル（パフォーマンス計測ツールであるLighthouseの評価指標をもとに定義しています）について「一定の値を連続で上回った回数」という新たなメトリクスを導入し、既存のメトリクスとは別途で取得するようにしました。
上図中のWebpagetest Exporterにて、テスト結果を取得する度にこのメトリクスを更新し、ほかのメトリクスと一緒にPrometheusへ登録するようなイメージです。
- Prometheusでのデータ保持を24時間程度に増やしてもらう
- lambdaやcronjobを用意して、定期的にThanosにクエリを行いアラートを生成する
などといった手段も考えられましたが、
- 追加のリソースコストをかけたくない
- 共通の基盤に対して、一部でしか使われないような特殊な機能を組み込むことは避けたい
といった理由から、これらの手段は選択しませんでした。
閾値の設定
バイタルの劣化をカウントする基準となる値は、以下のようにして設定しました。 これらの値は、バイタルの揺れの幅や頻度、絶対値の大きさといった要素を考慮しつつ、暫定的に設定したものになります。
- LCP, FCP, SI, TTFB: ある特定の1週間の90パーセンタイル × 1.2 [ms]
- TBT: ある特定の1週間の90パーセンタイル + 300 [ms]
- CLS: ある特定の1週間の90パーセンタイル + 0.05
これらの値を連続して所定の回数上回った際にそのバイタルがテスト対象のページにおいて劣化したと判断することで、揺れによる誤検知を防ぎ、アラートの精度を上げることを狙っています。
以上の設定を元に、今まで取得していたバイタルの実測値やそのスコアと同様に、それらが一定の値を連続で上回った回数もメトリクスとして記録されるようにしました。
たとえばLCPの閾値が2680msのページだと、新たに追加したメトリクスは次のような形で時系列に記録されます。
バイタルの実測値（既に存在していたメトリクス）
一定の値を連続で上回った回数（新たに追加したメトリクス）
新たなメトリクスを元に劣化アラートを生成
これをもとに、それぞれのページの各バイタルについて一定の値を連続で上回った回数が閾値に達すると、以下のようなpromqlをベースに指定したslackチャンネルへ通知が行われるようになりました。
avg by (uri, target_group)(wpt_overrun_count{id="CLS"}) >= 7
以上の対応によって、アラート生成の際により長い時間範囲のメトリクスを参照できるようになり、信頼性の高いパフォーマンスの劣化アラートを出すことができるようになりました。
まとめ
ここまで、LIFULL HOME'Sのページ性能を維持するための劣化アラートの仕組みづくりについてお話ししてきました。 対応につながるような有意なアラートを実装することを目指して、ページパフォーマンスが継続的に劣化していることを信頼性高く示すためにアラート生成の際に参照できるメトリクスの時間範囲を拡張しました。
実装の際には新しいストレージやツールを用意することなく、今既にある仕組みを拡張する形で問題を解決できたことも良かったと思います。本質的な問題を見極めてから、それを解決する手段として最善なものを選ぶということを継続して行きたいと感じました。
LIFULLでは、今回のようなプラットフォームの効率化にも積極的に取り組んでいます。これらの取り組みに興味を持った方がいらっしゃいましたら、ぜひ以下のリンクからお問い合わせください。
