食べログのサーキットブレーカー導入を振り返って

【日経×MIXI×カカクコム】SREで築く障害耐性〜長期運用を支える復旧力〜
https://nikkei.connpass.com/event/391773/

Transcript

1. © Kakaku.com Inc. All Rights Reserved. 1 ⾷べログのサーキットブレーカー導⼊を 振り返って 2026/5/28 株式会社カカクコム ⾷べログカンパニー 開発本部 技術部 SREチーム 浅野 ⼤我
2. © Kakaku.com Inc. All Rights Reserved. 2 ⾃⼰紹介 浅野 ⼤我 (@atpons) 2025/9〜 株式会社カカクコム ⾷べログカンパニー 開発本部 技術部 SREチーム
3. © Kakaku.com Inc. All Rights Reserved. 3 ⾷べログについて ⾷体験を豊かにするレストラン検索‧予約サービス 掲載店舗数は89万店以上（※） 。（※）2026年5⽉時点 お店が発信するこだわり情報やユーザーが投稿した⼝コミ‧写真など、レストランに関する豊富 な情報から、さまざまな視点で⽬的に合ったお店が探せます。 またいつでもどこからでも、簡単に空席確認やネット予約ができます。 多⾔語版サービス 英語、中国語（簡体字/繁体字）、 韓国語 アクセス数（2026年3⽉現在） ⽉間総ページビュー 24億5,971万PV ⽉間利⽤者数 9,708万⼈
4. © Kakaku.com Inc. All Rights Reserved. 4 ⽬次 1. なぜサーキットブレーカーが必要だったのか 2. Envoyを選んだ理由 3. 導⼊とチューニング 4. まとめ
5. © Kakaku.com Inc. All Rights Reserved. 5 なぜサーキットブレーカーが必要 だったのか
6. © Kakaku.com Inc. All Rights Reserved. 6 ⾷べログのインフラ構成 Kubernetes環境 VM環境 nginx nginx Rails Rails nginx Rails Rails ロードバランサー フルK8s化へ 移行中 オンプレとプライベートクラウドをベースとした構成
7. © Kakaku.com Inc. All Rights Reserved. 7 フルKubernetes化絶賛進⾏中 詳細はテックブログで公開中 https://tech-blog.tabelog.co m/entry/tabelog-kubernetes- migration
8. © Kakaku.com Inc. All Rights Reserved. 8 ⾷べログのシステムアーキテクチャの今まで tabelog_base サブシステム1 サブシステム2 メインDB 特定機能 用DB 口コミ検索 口コミ検索 独立システム 検索エンジン 外部サービス 機能ごとに サブシステム同士で 通信 社内検索 基盤と通信 外部サービスと API連携 重複した機能
9. © Kakaku.com Inc. All Rights Reserved. 9 ⾷べログのアーキテクチャの今まで tabelog_base サブシステム1 サブシステム2 メインDB 特定機能 用DB 口コミ検索 口コミ検索 独立システム 検索エンジン 外部サービス 機能ごとに サブシステム同士で 通信 社内検索 基盤と通信 外部サービスと API連携 重複した機能
10. © Kakaku.com Inc. All Rights Reserved. 10 ⾷べログのアーキテクチャの今まで tabelog_base サブシステム1 サブシステム2 メインDB 特定機能 用DB 独立システム 検索エンジン 外部サービス kiban kiban DB 口コミ検索 主要機能が切り出され、 検索エンジンとの通信も kibanを介して、疎結合に なるはずだった
11. © Kakaku.com Inc. All Rights Reserved. 11 kibanシステム‧外部通信の課題 tabelog_base サブシステム1 サブシステム2 メインDB 特定機能 用DB 独立システム 検索エンジン 外部サービス kiban kiban DB 口コミ検索 kiban経由・外部通信のどれかが 高負荷になると、 引きずられて カスケード障害になる アクセス しづらい 高負荷
12. © Kakaku.com Inc. All Rights Reserved. 12 現状のアーキテクチャの課題 これはつらい・・・ - kibanシステム‧⾷べログの多くのシステムはVMで動作 - RailsのUnicorn上のワーカー数には上限がある - 例えば以下のようなことが起こると⾷べログ全体に波及する - 検索エンジン（Solr）側の⾼負荷状態が続くと、kibanを経由した検索が不可に - リクエストが滞留し、kibanがアクセスできなくなる - 検索以外の様々な機能が利⽤できなくなり、全体のリクエストが詰まり始める - Solrに対してはサブシステムから直接アクセスもあり、そこも詰まることがある - 主要機能が⼀箇所に集まったことで、SPOFが増えてカスケード障害が起こる原因に
13. © Kakaku.com Inc. All Rights Reserved. 13 解決策を検討 - ⼊社時点で各サブシステムでエラーが返ってくれば、そこを表⽰しないような制御は⼊りつ つあった - カスケード障害が起きていると各種システムのワーカーがレスポンスすら返せず、全体 的にリクエストが詰まる - サーキットブレーカーを導⼊して⼀定のアクセスパターンになったらすぐにエラーを返して バックエンドへの到達を⽌める必要があった まずkiban・検索エンジンをターゲットに、 サーキットブレーカーを導入することを決めた
14. © Kakaku.com Inc. All Rights Reserved. 14 Envoyを選んだ理由
15. © Kakaku.com Inc. All Rights Reserved. 15 サーキットブレーカーを実現する⽅法を検討 - バックエンドのアプリケーションレベルで実現する - ⼀定のエラーがでたら⼀時的にリクエストを⽌める - プロキシを導⼊する（採⽤） - バックエンドに対してプロキシを導⼊して、そこでアクセスのパターンにより サーキットブレーカーを有効にする 今回は検索エンジンなど、全社組織で管理しているサービスへの適用もあったことからア プリケーションレベルではなく、プロキシを導入して実現した
16. © Kakaku.com Inc. All Rights Reserved. 16 Envoyを選定した理由 - プロキシとして導⼊するデータプレーンは Envoy 導⼊⼀択だった - 他の選択肢はあまりなかった - コントロールプレーンとして Istio をさらに導⼊していくかは検討した - Istio など xDS サーバがあると設定の注⼊などがやり易い - ⼀⽅、⾷べログのシステムは Kubernetes と VM が現状混在している状態 - Istio は VM にも展開可能なので、Kubernetes と VM を同じ Istio で管理するなども出来 そうだった
17. © Kakaku.com Inc. All Rights Reserved. 17 EnvoyをVMに展開して動作させることになった tabelog_base サブシステム1 サブシステム2 メインDB 特定機能 用DB 検索エンジン kiban kiban DB 口コミ検索 EnvoyをVMに展開して リバースプロキシさせることで サーキットブレーカーなどを 有効にした Envoy Envoy
18. © Kakaku.com Inc. All Rights Reserved. 18 Envoy を⾮コンテナ環境と共存させる構成 - ⾷べログでは現在 Kubernetes 化を進めており、⼀部のサブシステムは Kubernetes ではなく VM 上で動いているものがある 🔗 ⾷べログ on Kubernetes ~ 運⽤15年以上の⼤規模レガシーシステムを Kubernetesに乗せ ていく~ - K8s化進⾏中なものの‧‧‧ - VM環境がまだ残っており、ロードバランサーアプライアンスとの組み合わせで正しく動 くかが未知数だった - ⾷べログで実績の多い VM 環境で Envoy をインストールして動作させることにした
19. © Kakaku.com Inc. All Rights Reserved. 19 Envoy を VM で動作させる⼤変さ 1. 設定の再読み込みを⾏いたい時が⼤変 - Envoy は同じプロセス内で静的な設定を再読み込みすることが難しい - 基本的には xDS サーバなどを⽤意して設定を配布するしかない - 動的に設定などを再読み込みするためには Hot Restart を⾏う必要があり、新旧プロセスを⼊れ 替えるための通信を⾏う必要がある - 今回は公式で⽤意されている Python スクリプトをベースに Hot Restart を⾏い、systemd で Envoy ⾃体を管理するような仕組みにした 2. Envoy のバイナリをビルドするのが⼤変 - Envoy のバイナリが利⽤している Linux ディストリビューションでうまく動作しないことがわ かった - Bazel でビルドされているため、そこからパッケージを作成して配布するロジックを作成した
20. © Kakaku.com Inc. All Rights Reserved. 20 導⼊とチューニング
21. © Kakaku.com Inc. All Rights Reserved. 21 導⼊について - 今回は、検索エンジンとkibanシステムに導⼊することにした - 閾値について - 今回のサーキットブレーカーは同時接続数✖接続保留数の閾値が溢れると遮断 - 検索エンジンについては、これまでの負荷動向に少し余裕を持たせたキャパシティに設定 - kibanシステムについては、あらゆるシステムから繋がるため保守的なキャパシティに設定 - 導⼊にあたっては、フィーチャートグルで Envoy か直接接続を選べるようにした - 無停⽌かつ無障害でリリースすることが出来た 一定期間モニタリング後、負荷に合ったキャパシティに設定しなおして運用を継続
22. © Kakaku.com Inc. All Rights Reserved. 22 導⼊後の成果とチューニングについて - サーキットブレーカーの動作閾値などについてはダッシュボードで観測‧監視 - 同時接続が絞られたことで⼀気にバックエンドにリクエストが流れないようになり、負荷が平準化 されているため、サーキットブレーカーが実際に発動することは少ない
23. © Kakaku.com Inc. All Rights Reserved. 23 まとめ - Envoyを使って、サーキットブレーカーによるトラフィック制御を実現した - VM環境でもEnvoyを段階導⼊し、無停⽌‧無障害でリリースできた - 同時接続数などの指標を観測できるようになり、負荷状況に応じたチューニングが可能になった - Kubernetes化の進展に合わせて、今後はEnvoyの管理⽅式（VM→K8s、Istio）を⾒直していく
24. © Kakaku.com Inc. All Rights Reserved. 24 ありがとうございました