エンジニアが推進した、食べログ多言語版のアクセス速度改善プロジェクトの道のり

はじめに

こんにちは、食べログ開発本部ウェブ開発２部の米谷です。普段はチームリーダとして食べログのレストラン検索やインバウンドユーザ向けの画面の開発などを行っています。今回は、インバウンドユーザのアクセス速度改善プロジェクトについて、エンジニアが提案し、実現するまでのプロセスを共有させていただきます。本記事は、エンジニアリングマネージャーやプロジェクトマネージャー、また同様のインフラ改善プロジェクトを検討しているエンジニアの方々に向けた記事となっています。技術的な詳細と、組織内での合意形成プロセスの両面から、プロジェクトの進め方について具体的な事例として参考にしていただければと思います。

なお、本記事で言及する「インバウンドページ」とは、海外からのアクセスを想定した多言語対応のウェブページを指します。食べログが、海外居住者や訪日外国人向けに、英語や中国語など複数の言語で提供しているサービスです。

背景

2024年以前、食べログでは主に国内のユーザに向けてサービスを提供しており、インフラも国内のオンプレミス環境を前提として運用していました。そのため、インバウンドユーザのアクセス速度については、あまり考慮されていませんでした。その後、インバウンド需要の高まりを受け、2024年にインバウンドページをリニューアルしました。しかし、このリニューアル後もインフラ構成は国内向けのまま運用が続いており、海外からのアクセスについては最適化されていない状況が課題として残っていました。

そんな中、インバウンドページのリニューアル後、UI/UXの改善を進める中で速度改善の議題が上がり、エンジニアの提案から他部署と協力しながら速度改善のプロジェクトを進めていきました。組織内での提案プロセスや他部署との協働についても、具体的な事例として参考にしていただければと思います。

課題の発見と提案の準備

2024年7月ごろ、Adobe Analyticsのデータ分析担当者からインバウンドユーザのローディング時間は5〜6秒かかっており、ウェブサイトとしては非常に遅い状態という連絡を受けました。国内のページでは広告配信やトラッキングなどの追加リソースの読み込みが発生しますが、インバウンドページではそれらがほぼないため、本来であれば高速にアクセスできるはずでした。あまりに遅いとユーザは関心を失ってしまうことから、この問題はインバウンドユーザの体験に大きな影響を与えている可能性が高いと判断しました。

また、国内からインバウンドページにアクセスした時のローディング時間は特に遅くなかったことから、ローディングにかかる時間が遅くなっている理由が物理的なサーバの距離によるものと推測できました。

提案のための準備

この課題に対して、Amazon CloudFrontの導入を検討しました。Amazon CloudFrontを導入することで、ネットワーク上最適な経路でコンテンツを配信できると考えたからです。食べログでは、動的コンテンツはオリジンサーバから直接配信し、静的コンテンツ（JS、CSS、画像ファイルなど）はCDNを経由して配信する構成をとっています。そこで、このアーキテクチャを踏襲し、インバウンドページにおいてもまずは静的コンテンツのみをCloudFrontの対象とすることにしました。静的コンテンツは、そのファイルサイズの大きさやリクエスト数の多さから、CDNによるキャッシュ配信の恩恵を特に受けやすいため、改善効果が大きいと考えられます。このように効果の大きい静的コンテンツから着手することで、リスクを最小限に抑えつつ、最大の効果を得ることを目指しました。

提案するにあたって以下の準備をしました。

海外アクセスのレスポンスタイムの計測方法の検討
導入によるユーザ体験の改善度
費用対効果の試算

計測時の構成

提案した改善策の効果を事前に検証するため、USリージョンからステージング環境にアクセスし、ブラウザのローディング時間を計測しました。Adobe Analyticsは実際のインバウンドユーザの状況を示しますが、事前検証では施策単体の影響を明確にするため、この方法を採用しました。Adobe Analyticsは本番リリース後の効果測定に活用しました。

具体的な計測方法として、実際に海外の拠点からテストするのは難しいため、海外リージョンにサーバを立てて測定することにしました。AWS EC2インスタンスを使用するとAWSネットワーク内の閉じたアクセスになる可能性を考慮し、より一般的なインターネット環境に近い状況を再現するため、Google Cloud上に検証用サーバを構築し、そこからアクセスする方法を採用しました。このアプローチにより、インバウンドユーザが実際に体験する状況に近い形でのブラウザローディング時間を計測することを目指しました。

ステージング環境でこの方法を用いて検証した結果、CloudFrontのあり/なしでページ全体のローディング時間が約50%改善し、日本国内からのアクセス時とほぼ同等の速度となることが確認できました。この結果から、CloudFrontの導入によってインバウンドユーザの体験が大幅に改善されると期待できました。

また、月額費用に関しては既存のCDNへのアクセス量から費用を試算しました。

提案から合意形成までの道のり

企画部への提案

企画部に対してはデータに基づく説明を心がけました。

現状の課題と改善後の期待効果を具体的に提示
月額費用の試算と費用対効果の分析結果を提示

企画部も課題を認識していたため、ユーザ体験の向上が見込めることと、費用対効果として十分な価値があることを共有できました。ただし、初期はアクセスの多い国（具体的にはアメリカ）に絞って適用したいとの要望があり、それに応じた計画を立てることにしました。

他部署との調整

各部署との調整では、以下のような取り組みを行いました。

SRE、システムプラットフォーム部との調整

SRE、システムプラットフォーム部とは以下について依頼や相談をしました。

既存インフラへの影響調査
本番リリースの方法の調査
本番環境の運用・管理についての相談

効果測定などはサービス開発エンジニアの方でできるものの、実際に本番リリースをするにあたってインフラ周りはSRE、システムプラットフォーム部で管理・運用していることから適用に向けた相談をする必要がありました。特に企画部との会話から、最初は海外の中でも特にアクセスの多い国であるアメリカに絞る対応としたかったため、DNS周りの設定方法をどうするかの調査などをお願いすることになりました。調査にあたって、AWS側に質問したい項目などもあったため、AWSの営業の方との橋渡しも行い、よりスムーズに調査が進むよう心がけました。

また、SRE、システムプラットフォーム部からは当初、「そもそもこれをやる必要があるのか？」という素朴な疑問が投げかけられました。食べログという大きなサービスでの通信経路変更は、インフラ観点で大きなリスクがあります。現状の課題と、どの程度のユーザ体験の改善ができるかを具体的な数値で示すことで、リスクがあってもやる価値があるという認識を合わせられました。

その後は本番リリースに向けたステージング環境での動作確認、リリース時の監視体制からリリース後の運用についても滞りなく進めることができました。

法務部・情報セキュリティ部門との調整

法務部や情報セキュリティ部門とは以下の流れで相談しました。

Amazon CloudFrontを使うことによる既存データの取り扱いに関する差分の説明
データの取り扱いが変更になることによる規約への影響

特に食べログでは個人が投稿するプロフィール画像や口コミ情報を扱うため、海外サーバにキャッシュされることが規約上問題ないか事前に確認しておく必要がありました。また、食べログで初めて利用するサービスだったため、情報セキュリティ的に念の為問題ないかのチェックも社内ルール上必要でした。

法務部には下記の説明をし、規約上問題が起きないかのチェックをしてもらいました。

今までオンプレのCDNサーバにキャッシュされていたものが海外のキャッシュサーバにも配置されること
TTLの設定でどのくらいの期間キャッシュを保持するかはこちらで制御できること

法務部で確認してもらった結果、規約上問題ないことも確認できたため、法務の観点ではクリアになりました。

情報セキュリティ部門に関しても同様に説明し、以下の観点で情報セキュリティ的に問題がないか確認してもらいました。

Amazon CloudFrontを利用することによるセキュリティリスクがないこと
ユーザが投稿した画像に対してアクセスがあると最低でもTTLの間キャッシュサーバにキャッシュされることによるセキュリティリスクがないこと

Amazon CloudFront自体が世界的にも利用されているサービスなので、この辺り特にこちらでも問題はないと考えていたものの、念の為チェックしてもらい、特に問題がないことを確認できました。また、情報セキュリティ部門からはキャッシュされることにより「最新化されない」リスクがないかは予め調査しておくよう指摘を受けました。

実装と展開

技術的な実装

以下のAmazon CloudFrontの設定については、SREやAWSの営業の方と相談しながら進めました。

キャッシュ戦略の最適化
- 静的コンテンツの効率的なキャッシュ
セキュリティ設定
- WAFの設定
- セキュリティ対策の実装
- ファイルの更新管理

キャッシュ戦略については、食べログの主要なコンテンツである口コミ画像やユーザプロフィール画像の特性を考慮し、適切なTTLを設定しました。また、情報セキュリティ部門から指摘を受けていた「最新化されない」リスクに対しては、既存の食べログのCDNと同様のバージョニング方法を導入し、常に最新のコンテンツが配信できるようにしました。

また、セキュリティ対策として、攻撃検知の仕組みをSRE側と相談して決め、運用方法についても固めていきました。

段階的なロールアウト

Amazon CloudFront導入は食べログとして初めての試みでした。また、オリジンサーバへの負荷も考慮していましたが、実際の影響は運用してみないと分からない部分がありました。そこで、以下のように段階的なロールアウトを実施しました。

最初の週はアメリカからのアクセスのうち10%だけ適用
次の週は50%、最後の週で100%適用

段階的なロールアウト中は１ページ内でCDNにアクセスするファイルのうちの10%〜50%がAmazon CloudFront経由になり、残りは国内のCDNにアクセスするため、ユーザ体験の向上度合いを正確に把握することは困難でした。そのため、この期間は主にサービス全体の安定稼働とオリジンサーバへの負荷状況の監視に注力しました。

最終的には特に問題なく100%の本番リリースを終えて、アメリカからのアクセスに関して静的コンテンツの配信はAmazon CloudFront経由となりました。

成果と効果測定

技術的な成果について

検証の時と同様にGoogle Cloudでサーバを立てて効果測定をしました。インバウンドサイトのトップ画面のローディング時間は50%の改善が見られ、店舗検索画面や店舗詳細画面についても各ページのローディング時間が20~40%の改善が見られました。

キャッシュヒット率については、TTLを1日に設定したことと、海外アクセスが国内と比較して少ないことから、期待したほど高いヒット率は得られませんでした。これは、食べログの店舗検索画面では様々な画像を表示する特性があり、全体としてキャッシュヒット率が低くなる傾向にあるためと考えられます。

ビジネスインパクトについて

まだ本番リリース後２ヶ月程度なこともあり、現時点ではビジネスインパクトの詳細な分析はこれからの状況です。インバウンドサイトに対して注力していることもあって、この２ヶ月でも細かい施策を打っているため、Amazon CloudFrontの効果なのか施策の効果なのか完全に判断できないことや、季節性のトレンドもあって中々効果が分析し辛い状況です。ビジネスインパクトは今後の継続的な計測と分析により明らかにしていく予定です。

プロジェクトから得られた学び

このプロジェクトを通じて、エンジニアとして提案を実現するために重要な要素を学ぶことができました。 Amazon CloudFrontのような外部のCDN導入は多言語対応のウェブページであれば一般的なアプローチだったため、技術的な問題は少なかったです。プロジェクトの進行において、他部署とのコミュニケーションの方が難しかったです。今回プロジェクトを進行するにあたって気をつけたことは以下のことでした。

具体的な検証データに基づく提案
各部署の懸念点を事前に確認し、それに対する回答を準備すること
技術的な内容を非技術者にも理解しやすい形で説明すること

例えば、SREやシステムプラットフォーム部との調整では、当初「そもそもこれをやる必要があるのか？」という素朴な疑問がありました。そこで、具体的な数値と改善効果を示すことで、同じ方向性で進めることができました。また、法務部や情報セキュリティ部門との調整では、技術的な内容を彼らの視点で理解しやすい形に変換して説明することで、スムーズな承認を得ることができました。

また、一般的なアプローチとはいえ、食べログという大きなサービスで通信経路を変更するというのは大きなリスクがあるため、細心の注意を払う必要がありました。リスクを最小限に抑えるため、SRE、システムプラットフォーム部と相談しながら下記の対応をしました。

事前にステージング環境で本番同様の構成で問題ないことを確認
オリジンサーバーへの負荷のリスクをを最小限に抑えるための段階的なロールアウト

アメリカからのアクセスに対する段階的なロールアウトでは、10%→50%→100%という段階を設けることで、問題が発生した場合の影響を最小限に抑えることができました。また、各段階でのモニタリングにより、予期せぬ問題を早期に発見し、対応できました。

今後の課題と展望

このプロジェクトを通じて得られた学びは、今後のプロジェクトにも活かしていきたいと考えています。記事に細かい部分は書ききれませんが、事前検証で不足していた部分があり、そのせいで関係部署には色々無理を言ったりして調整してもらったりもしたため、今後は特に以下の点に注力していきたいと思います。

より早期のステークホルダーとの共有
事前検証内容のステークホルダーとの確認
コミュニケーションのタイミングの最適化

また、今回のプロジェクトで得られた知見を、組織内で共有することで、同様の課題に直面する他のチームの参考になればと考えています。

今回の取り組みは、まずアクセスの多かったアメリカを対象としましたが、将来的にはさらに多くの国や地域へ展開し、全世界のインバウンドユーザの体験を向上させていくことを目指しています。その第一歩として、2025年5月には香港、シンガポール、タイ、カナダ、オーストラリア、イギリスの6カ国にも適用範囲を拡大しました。今後も継続的に効果を測定し、さらなる改善を進めていく予定です。