「このページ開けないの私だけかな？」
きっかけはこの一言のslackメッセージでした。
少しすると、他のメンバーからもスレッドに返信が続きます。
「私は開けました！」「私も問題なく開けました！」
そして、しばらくしてから-----
「再び開いてみたら、開けました。ただ、さっき開いた時はとても重くて開かなかったです」
どうやら、なんらかの理由でサービスの表示速度が悪くなる時がありそうですね。
これは、、、エンジニアとして腕の見せ所かもしれません💪
軽く自己紹介
こんにちは、株式会社マイベストでDevLeadを務めているゆーだいです。
マイベストは「インターネットで、最高の選択体験を実現する」を掲げ、さまざまな商品の比較・検証を自社で行いそのデータベースを元に、「選ぶ」という領域の課題を解決するサービスを提供しています。
現在は、月間ユーザー数3000万人を超えたサービスになっています。
この記事では、私が「マネタイズミッション」のDevLeadを務めた期間（2025年4月〜9月）に取り組んだ、サービス表示速度改善のための施策を紹介します。
「なぜ」サービスの表示速度悪化が起こっているのか？
結論から言うと、主な原因は以下の2点です。
- 機能の追加やコンテンツのリッチ化（商品画像などが増えた）によるパフォーマンスの悪化
- 比較記事数の増加に伴うCDNキャッシュのヒット率低下
どのような改善を行なったか？を紹介する前にマイベストの簡単なインフラ構成や言葉の紹介を行います。
マイベストのインフラ構成（簡易版）
RailsやNext.jsで構築したアプリケーションがFargate上で動作しており、それらのコンテンツはCloudFrontを経由して配信されています。
CloudFrontでは、一部の静的コンテンツやAPIレスポンスをキャッシュすることで、配信の高速化やサーバー負荷の軽減を実現しています。
CDNキャッシュ
CDN(Content Delivery Network)キャッシュは、世界中に分散したサーバー（エッジサーバー）にコンテンツをキャッシュして、ユーザーに地理的に近いサーバーから配信する仕組みです。
エッジサーバーにコンテンツをキャッシュしておくことで、オリジンサーバー（マイベストでいう、RailsやNext.js）に毎回アクセスしなくてよくなります。
SWR(Stale-While-Revalidate)
SWRは「古いキャッシュを即座に返却しつつ、裏で新しいデータをオリジンサーバーに取りに行き、キャッシュしているコンテンツを更新する」という仕組みです。
接続中断率
「接続中断率」はこの施策内で定義した独自指標です。
弊社では全社的に「セッション数」を重要指標としており、セッション数に変動があれば敏感にキャッチし、その考察と対応が行われます。
セッション数はページの描画完了時にJSにより発火するイベントを集計することで計測されます。
マイベストでは機能追加/比較記事のリッチ化により、オリジンサーバーのレスポンス速度がかなり遅く、ページが開く前にユーザーが離脱するケースが発生していました。
いわゆる「ページが重くて開けない」という状態です。
しかも、この現象が起こっている場合は「コンテンツの描画が行われない」ため、セッション数という指標では、この問題の把握ができませんでした。
| 用語 | 説明 | 例 |
|---|---|---|
| アクセス数 | サーバーへのリクエスト数のこと。1つのアクセスに対して実際は複数のリクエストが行われている。ここでは、メインのリクエストが行われている数をアクセス数として呼ぶ。 | 例：マイベストの比較記事へのリンクをクリック後、表示が遅く離脱した場合 → 1アクセス、0PV |
| PV数 | ユーザーがマイベストの記事を見た回数のこと。 | 例：あるユーザーが「洗濯機」と「掃除機」の比較記事を見た場合 → 2PV |
| セッション数 | 同一セッション内のPVを1つにまとめたもの。 | 例：「洗濯機の比較記事を見る」→その記事内から「洗剤の比較記事を見る」場合 → 2PV、1セッション |
そのため、アクセス数の定義/見える化を行い、接続中断率を定義しました。
接続中断率 ＝ PV数 / アクセス数
※アクセス数はbotのアクセスを除外し、実際のユーザーのアクセス数に近づけて計測したりもしてます。
どのようなアプローチで「ストレスレスなUX」と「アクセスロス防止」を実現したか？
まずは結果からお見せします。
大きく4つのアプローチを行い、5%近くまで悪化していた「接続中断率」を0.5%近くで推移するところまで下げることができました🙌
①既存機能のパフォーマンス調査・チューニング
弊社では、オリジンサーバーのパフォーマンス速度に関しては、Datadogのダッシュボードに情報が整理・集約されているため、まずはそこのデータを調査しました。
すると、あるリリースをきっかけに、一部のページのパフォーマンスが大きく悪化していることを発見しました。
原因になっているリリースやその他改善できそうな部分のパフォーマンスチューニングを行いました。
②CDNキャッシュ/SWRの設定見直し・適用範囲拡大
オリジンサーバーのパフォーマンスを確認した後は、CDNキャッシュ/SWRを含めた際のパフォーマンス改善に取り組みます。
マイベストでは、洗濯機やクレジットカードなどの人気商材から、縄跳びやデジタルフォトフレームなどのニッチな商材まで幅広く取り扱っており、セッション数はパレートの法則（全体の結果の8割は全体の要素の2割が生み出しているという有名な法則）のようになっています。
ロングテールの比較記事では、頻繁にアクセスが行われるわけではないため、「キャッシュの有効時間を過ぎたタイミングでのアクセス」が多く、全体のキャッシュヒット率を下げる要因になっていました。
そこで、SWRの設定時間を長めにすることで、キャッシュヒット率を上げ、結果「接続中断率」の改善に繋げるアプローチを選択しました。
SWRの設定時間を長くすることのPros/Consを整理し、ロングテールの比較記事のアクセス頻度などを踏まえ、24時間に設定することに決めました。
| 観点 | Pros（メリット） | Cons（デメリット） |
|---|---|---|
| パフォーマンス | キャッシュの有効時間が長くなり、ヒット率が向上 | （直接的な原因ではないが）オリジンサーバーのパフォーマンスが放置されやすくなる |
| サーバー負荷 | リクエストの頻度が減り、API・DBへの負荷が軽減される | - |
| UXの安定性 | 一時的な通信エラー時もキャッシュで表示を維持できる | リリースやデータ更新の反映にラグが発生する |
| コスト | CDNキャッシュのヒット率が上がり、トラフィックコストを削減できる | キャッシュパージ時にコストが発生する |
| 開発・運用 | 短時間での集中したアクセスに耐えられる | キャッシュ管理が複雑になる |
また、このタイミングでCDNキャッシュの適用範囲を広げました。
③「SWR温め君」のリリース
②の対応で、SWRの設定時間を24時間に変更する対応を加えました。
それに合わせて「SWR温め君」というbotの作成も行いました。
SWRの設定時間を24時間にしたことで、1日に1アクセスあれば常にキャッシュが維持される状態になりました。
そこで、全記事に対して1日1回アクセスを行うbotを動かすことで、常にキャッシュヒットする状態を保つようにしました。
「SWR温め君」導入による全体的な接続中断率の改善幅はあまり大きくありませんでした。
しかし、AIなどの進化＆活用に伴い、これまで作成できなかった「よりニッチな商材」を取り扱うことが可能になります。そうした「超ロングテール」の記事群に将来的に効いてくる機能になると考えています。
④CDNキャッシュの保存戦略変更
最後に、CDNキャッシュのkey設定をチューニングしました。
マイベストでは、さまざまな経路からの流入をURLのクエリパラメータで制御しています。
分析の結果、1つの記事に対して数百パターンのURLが存在することがわかりました。
CDNキャッシュはURL文字列をもとにkeyを作成していたため、同じ記事でもURLごとに異なるキャッシュが生成され、キャッシュヒット率の低下を招いていました。
クエリパラメータによっては表示や機能に分岐が入るものも存在するため、キャッシュkeyとして無視できるパラメーターと無視できないパラメータに振り分け、以下のイメージ画像のように作成されるキャッシュが極力少なくなるようのkeyの生成方法に変更しました。
この戦略は、AWS CloudFrontのデベロッパーガイドでも紹介されていました。
⑤継続的にモニタリングできる仕組み・運用を整える
売上に直結する重要指標である「セッション数」に大きく影響を与える「接続中断率」の悪化を検知できなかった原因は、その数値が見えづらい状態だったことにありました。
弊社では基本的に、さまざまなデータをBigQueryに集約しています。
しかし、CloudFrontのアクセスログはBigQueryと連携しておらず、分析を行うには S3に保存されたログをAWS Athenaからクエリを叩いて分析する必要がありました。
そこで、CloudFrontのアクセスログをBigQueryに連携し、そのデータをもとに自動で更新されるダッシュボードを作成しました。
さらに、ダッシュボードを定期的にモニタリングする運用ルールを整備し、指標の悪化を早期に検知できる仕組みを実現しました！
※ 他にも日付/記事種別ごとのアクセス数/キャッシュヒット率/レスポンス速度などを確認できるダッシュボードも作りました。
さいごに
この記事では、CDNキャッシュ/SWRを中心に、ロード時間を改善するための5つの取り組みを紹介しました。
その結果、「ページの表示速度の大幅改善によるUX向上」 と 「月間150万以上のアクセスロス防止」 を実現できました🙌
一方で、SWRの設定時間を長くしたことで、以下のような新たな問題も見えてきました。
- 特定の時刻に表示される内容を切り替えることが難しい（最大24時間切り替わらない場合がある）
- リリース起因の障害の検知が遅れてしまう場合がある
これらについても、自動キャッシュパージの仕組みの導入などを通して、改善を進めていく予定です。
（さいごのさいごに）
途中でも触れましたが、SWRの設定時間変更のConsで以下のように記載しました。
（直接的な原因ではないが）オリジンサーバーのパフォーマンスが放置されやすくなる
CDNキャッシュという強力な仕組みを活用することで、ユーザー視点では「ほとんどの場合スムーズに動作するサービス」に見えるようになります。（これ自体は良いこと）
すると、「オリジンサーバーのパフォーマンス改善」 についての優先度が下がりやすくなります。
しかし、今後の機能追加・改善を続けていく中で必ずどこかでそれが問題になる時がきます。（ユーザーへの影響や開発効率への影響など）
そのため、リクエストの分割やUXと技術負債のバランス的にコスパの悪い機能の撤退など、要求・要件の整理から含めて改善を続け「最高の選択体験」を最速で届けられるようにサービス開発を進めていきたいです。
おわり
株式会社マイベストのテックブログです！ 採用情報はこちら > notion.so/mybestcom/mybest-information-for-Engineers-8beadd9c91ef4dc2b21171d48a4b0c49
Discussion