この記事は 食べログ Advent Calendar 2025 の6日目の記事です🎅🎄
はじめに
こんにちは！食べログ開発本部技術部SREチームの浅野 @atponsです。
Web系企業2社でスマートフォンのゲームバックエンド開発やプラットフォームエンジニアリングを経験しました。その後、2025年9月、食べログにSREとして入社しました。
入社してから3ヶ月が経ったので、食べログのSREとして実際に働いてみて感じたことを記事にしようと思います。食べログのSREとしての関わり方について興味を持っていただけたら幸いです。
目次
食べログのSREを選んだ理由
いくつかの企業と面接をする中で、食べログのSREを選んだ理由は以下の点でした。
大規模サービスをさらに進化させていくチャレンジングな環境
食べログは20周年を迎えた歴史のあるサービスです。単純なモノリスなアプリケーションではなく、関連サービスも多く、大規模なサービスと言えます。
そして、20年の歴史を持つサービスだからこそ、インフラは単純なクラウドネイティブな環境とは異なります。こちらの記事のようにKubernetes移行を進めていますが、その過渡期として、既存のオンプレミスのVM環境とKubernetes環境が協調して動作するハイブリッド構成となっています。
この大規模かつハイブリッドな環境の信頼性を担保しながら、さらに進化させていくというフェーズに、SREとして強く惹かれました。
AI活用に関して理解があり積極的に取り組んでいること
食べログではAIを幅広く活用しており、SRE内でもGitHub Copilot、CursorやClaude Codeなどを利用している文化が浸透しています。
自身も前職までにAIを活用してきたので、そのような文化があることは入社の大きな動機になりました。単にツールが導入されているだけでなく、実際にSREの業務にも生かされています。気になる方はこちらの記事もご覧ください。
入社してみて感じたこと
入社をしてから、食べログのエンジニア組織について感じたことを紹介します。
他部署との協業が多い環境
食べログは複数のサービスや部署が連携して動いており、SREが他の部署と協業する場面は非常に多いです。
プロダクトだけではなく、セキュリティやインフラにも全社組織があります。オンプレミスの基盤についても全社組織で管理している部分が多く、関係部署との密な連携が必要です。そのため、リリースや改善を進める上での計画が重要になります。
一方で、入社して間もない段階から、次の章で述べるように、食べログのシステムアーキテクチャに関わる難易度の高いタスクに取り組めています。なので、歴史ある大規模サービスでありながら、メンバーが持つ裁量も大きいと感じています。
コミュニケーションの機会が多い
エンジニア間での協業が必須なので、漠然と不安がありました。しかし、食べログにはコミュニケーションの機会が多くあったので心配は不要でした。
隔週で行われているTabelog Tech MTGという取り組みがあります。ここでは食べログエンジニアの活動が紹介され、リリース内容やノウハウが共有されます。面白いと思ったポイントや質問をコメントでやりとりでき、自分の学びにもなります。
新規メンバーが自己紹介する機会もあります。そのため、新しい人ともコミュニケーションしやすい環境になっています。
現時点における自分の取り組み
私は現在、食べログのサービス間トラフィックをコントロールするため、Envoyをベースとしたプロキシの導入を進めています。
現在の課題と選択したソリューション
食べログのインフラは、前述の通り既存のオンプレミスVM群とKubernetes環境が共存するハイブリッド構成です。この環境下で、サービス間通信の可視化やトラフィック制御（サーキットブレーカー等）を統一的に行うことが課題でした。
完全なクラウドネイティブな環境であればIstioのようなサービスメッシュ導入が一般的です。しかし、VMとKubernetesが混在し既存システムも大規模な環境であるため、最初からフルスタックなサービスメッシュを導入すると構築期間の長期化や複雑性の増大が懸念されました。
そこで、スピード感を持って課題を解決するため、まずはデータプレーンであるEnvoyのみを導入する方針を選択しました。最小構成でトラフィック制御を実現し、今ある課題を解決する基盤を構築しています。将来的にはIstioへの移行も視野に入れつつ、現時点では実用的な仕組みを早く提供することを優先しています。
難しさと工夫
この取り組みの最大の難しさは、VM・Kubernetes両環境に跨るプロキシ配置と、既存サービスへの影響を最小限に抑えた段階的な導入です。
Kubernetes環境ではサイドカーパターンでの導入が比較的容易ですが、VM環境では既存のデプロイフローやネットワーク構成を尊重しながら、慎重に進める必要があります。また、20年の歴史を持つ大規模サービスであるため、サービス間の依存関係や通信パターンも複雑です。
そのため、まず特定のサービス間通信から試験的に導入し、影響がないことを確認した上で段階的に適用範囲を広げています。また、既存のドキュメントやコードを読み解きながら、ネットワーク構成や依存関係を把握し、事前に影響範囲を見極めることもしています。
こうした取り組みを通じて、食べログの安定稼働を維持しながら、将来的なインフラ進化の基盤を構築しており、SREとして貴重な経験を積んでいます。
もちろん、歴史があるサービスであるため、設計思想の理解には時間を要します。しかし、ドキュメントやコードの積み重ねがあるため、キャッチアップがしやすかったです。
こうした複雑なシステムを理解する上でも、AIとの伴走が役立っています。例えば、今回のプロキシ導入にあたり、既存コードから障害点となり得る特定のエンドポイントをリストアップする作業にAIを活用し、調査の初動を大幅に効率化しました。
これにより、本来時間を割くべき構築方法の検討など、より本質的な作業にすぐ取り掛かることができました。それでもわからないことがあれば、メンバーに聞いて解決したりすることも出来る環境で非常に恵まれています。
今後は、日々SREに寄せられる問い合わせ業務の自動化などにもAIを活用できないか、業務を通して知見を収集しているところです。
まとめ
食べログのSREとして働いてみてみると、大規模かつ歴史あるサービスを安定的に動かしながら、さらにアップデートしていくという、技術的にチャレンジングな課題に取り組める面白さを実感しています。
普段の業務においても、入社直後からスムーズに業務に入れる仕組みが整っています。そのため、慣れるための不安は特に感じることなく仕事できています。
今後は、現在進めているタスクを完了させるとともに、SREとしての文化や活動を食べログのサービス信頼性向上にさらに貢献し、アウトプットができればと思っています。
この記事が、大規模なサービスのSREとして入社した後の働き方や、具体的にどのような業務から関わっていくのかについて知りたい方の参考になれば幸いです。
明日は @weakboson さん、@massaaaaan さんの「食べログにおけるDevinブラウザテストの実現に向けた取り組み」です。お楽しみに!
食べログでは、20年の歴史を未来へ繋いでいく仲間を募集しています！
ご興味のある方は、ぜひこちらもチェックしてみてください。
