食べログのサーキットブレーカー導入を振り返って

by atpons

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© Kakaku.com Inc. All Rights Reserved. 3 ⾷べログについて⾷体験を豊かにするレストラン検索‧予約サービス掲載店舗数は89万店以上（※）。（※）2026年5⽉時点お店が発信するこだわり情報やユーザーが投稿した⼝コミ‧写真など、レストランに関する豊富な情報から、さまざまな視点で⽬的に合ったお店が探せます。またいつでもどこからでも、簡単に空席確認やネット予約ができます。多⾔語版サービス英語、中国語（簡体字/繁体字）、韓国語アクセス数（2026年3⽉現在）⽉間総ページビュー 24億5,971万PV ⽉間利⽤者数 9,708万⼈

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© Kakaku.com Inc. All Rights Reserved. 12 現状のアーキテクチャの課題これはつらい・・・ - kibanシステム‧⾷べログの多くのシステムはVMで動作 - RailsのUnicorn上のワーカー数には上限がある - 例えば以下のようなことが起こると⾷べログ全体に波及する - 検索エンジン（Solr）側の⾼負荷状態が続くと、kibanを経由した検索が不可に - リクエストが滞留し、kibanがアクセスできなくなる - 検索以外の様々な機能が利⽤できなくなり、全体のリクエストが詰まり始める - Solrに対してはサブシステムから直接アクセスもあり、そこも詰まることがある - 主要機能が⼀箇所に集まったことで、SPOFが増えてカスケード障害が起こる原因に

Slide 13

Slide 13 text

© Kakaku.com Inc. All Rights Reserved. 13 解決策を検討 - ⼊社時点で各サブシステムでエラーが返ってくれば、そこを表⽰しないような制御は⼊りつつあった - カスケード障害が起きていると各種システムのワーカーがレスポンスすら返せず、全体的にリクエストが詰まる - サーキットブレーカーを導⼊して⼀定のアクセスパターンになったらすぐにエラーを返してバックエンドへの到達を⽌める必要があったまずkiban・検索エンジンをターゲットに、サーキットブレーカーを導入することを決めた

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© Kakaku.com Inc. All Rights Reserved. 15 サーキットブレーカーを実現する⽅法を検討 - バックエンドのアプリケーションレベルで実現する - ⼀定のエラーがでたら⼀時的にリクエストを⽌める - プロキシを導⼊する（採⽤） - バックエンドに対してプロキシを導⼊して、そこでアクセスのパターンによりサーキットブレーカーを有効にする今回は検索エンジンなど、全社組織で管理しているサービスへの適用もあったことからアプリケーションレベルではなく、プロキシを導入して実現した

Slide 16

Slide 16 text

© Kakaku.com Inc. All Rights Reserved. 16 Envoyを選定した理由 - プロキシとして導⼊するデータプレーンは Envoy 導⼊⼀択だった - 他の選択肢はあまりなかった - コントロールプレーンとして Istio をさらに導⼊していくかは検討した - Istio など xDS サーバがあると設定の注⼊などがやり易い - ⼀⽅、⾷べログのシステムは Kubernetes と VM が現状混在している状態 - Istio は VM にも展開可能なので、Kubernetes と VM を同じ Istio で管理するなども出来そうだった

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© Kakaku.com Inc. All Rights Reserved. 18 Envoy を⾮コンテナ環境と共存させる構成 - ⾷べログでは現在 Kubernetes 化を進めており、⼀部のサブシステムは Kubernetes ではなく VM 上で動いているものがある 🔗 ⾷べログ on Kubernetes ~ 運⽤15年以上の⼤規模レガシーシステムを Kubernetesに乗せていく~ - K8s化進⾏中なものの‧‧‧ - VM環境がまだ残っており、ロードバランサーアプライアンスとの組み合わせで正しく動くかが未知数だった - ⾷べログで実績の多い VM 環境で Envoy をインストールして動作させることにした

Slide 19

Slide 19 text

© Kakaku.com Inc. All Rights Reserved. 19 Envoy を VM で動作させる⼤変さ 1. 設定の再読み込みを⾏いたい時が⼤変 - Envoy は同じプロセス内で静的な設定を再読み込みすることが難しい - 基本的には xDS サーバなどを⽤意して設定を配布するしかない - 動的に設定などを再読み込みするためには Hot Restart を⾏う必要があり、新旧プロセスを⼊れ替えるための通信を⾏う必要がある - 今回は公式で⽤意されている Python スクリプトをベースに Hot Restart を⾏い、systemd で Envoy ⾃体を管理するような仕組みにした 2. Envoy のバイナリをビルドするのが⼤変 - Envoy のバイナリが利⽤している Linux ディストリビューションでうまく動作しないことがわかった - Bazel でビルドされているため、そこからパッケージを作成して配布するロジックを作成した

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© Kakaku.com Inc. All Rights Reserved. 21 導⼊について - 今回は、検索エンジンとkibanシステムに導⼊することにした - 閾値について - 今回のサーキットブレーカーは同時接続数✖接続保留数の閾値が溢れると遮断 - 検索エンジンについては、これまでの負荷動向に少し余裕を持たせたキャパシティに設定 - kibanシステムについては、あらゆるシステムから繋がるため保守的なキャパシティに設定 - 導⼊にあたっては、フィーチャートグルで Envoy か直接接続を選べるようにした - 無停⽌かつ無障害でリリースすることが出来た一定期間モニタリング後、負荷に合ったキャパシティに設定しなおして運用を継続

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© Kakaku.com Inc. All Rights Reserved. 23 まとめ - Envoyを使って、サーキットブレーカーによるトラフィック制御を実現した - VM環境でもEnvoyを段階導⼊し、無停⽌‧無障害でリリースできた - 同時接続数などの指標を観測できるようになり、負荷状況に応じたチューニングが可能になった - Kubernetes化の進展に合わせて、今後はEnvoyの管理⽅式（VM→K8s、Istio）を⾒直していく