食べログ on Kubernetes ~ 運用15年以上の大規模レガシーシステムを Kubernetesに乗せていく~

© Kakaku.com Inc. All Rights Reserved. 1
⾷べログ on Kubernetes
株式会社カカクコム
⾷べログシステム本部
技術部 SREチーム下國峰昌
2022年11⽉30⽇（⽔）
運⽤15年以上の⼤規模レガシーシステムを
Kubernetesに乗せていく

View Slide

下國峰昌(しもくにみねまさ)
SREチーム技術専⾨職
2019年中途⼊社。⾷べログではSRE⼀本でやってきました
最近の活動
• ⾷べログオーダーインフラ、CI/CD、モニタリング構築
• Google Dataflow + Big Queryでアクセス解析システムを刷新
• OpsGenieクライアントRuby gemの作成
• ⾷べログ既存システムのKubernetes化

View Slide

本⽇お持ち帰り頂きたいこと
• システムをKubernetes化する動機
• オンプレKubernetesかマネージドKubernetesかの選択基準
• オンプレKubernetesのいいところとつらいところ

View Slide

⽬次 1. ⾷べログのシステム構成の紹介
2. なぜK8s化するのか
3. 何からK8s化に着⼿するのか
4. どうやってK8s化していくのか
5. まとめ

View Slide

1. ⾷べログのシステム構成の紹介

View Slide

⾷べログのシステム構成の紹介
⽇本最⼤級のレストラン検索・予約サイト
• 約9,000万MAU（2022年9⽉）
• レストランの⼝コミ・写真
• レストランのネット予約
• 飲⾷店DX(予約台帳、⾷べログオーダー、⾷べログ仕⼊れ)
• お取り寄せEC(⾷べログモール)

View Slide

インフラ⽬線から⾒ると？

View Slide

• この構成になって15年⽬
• ほぼオンプレのVM ⼀部ECSやGKEあり
• リクエスト数 80億req/⽉
• オンプレサーバ台数数百台
• ハイスペックマシン多め
• 12core 32GBmemなど

View Slide

2. なぜK8s化するのか

View Slide

なぜK8s化するのか
こいつをなんとかしたい。

View Slide

このMonorepoが抱える課題
• デプロイ/ロールバックに時間がかかる。MTTRが⻑い
• ⼤量のサーバに対するインフラ作業がトイル
• 無数の歴史的負債があるが、それに⼿を⼊れるのが怖い

View Slide


View Slide

デプロイ/ロールバックに時間がかかる。MTTRが⻑い
Monorepoのデプロイ回数: 4回/⽇
1⽇4回、エンジニアがデプロイ作業に拘束される

View Slide

7min.

View Slide

サーバが増え続ける中、これ以上デプロイを
⾼速にするのは、今のアーキテクチャでは厳しい。
エンジニアがデプロイに捧げる時間を減らし、
開発作業に集中できるようにしたい。
デプロイ時間が縮まれば、デプロイ頻度も上げられる。
また、デプロイ起因で障害が発⽣した際には、
即座にロールバックできるようにしたい。

View Slide

Kubernetes化すると、
Argo CDなどのKubernetes⽤ GitOps CDツールを
使えば、デプロイ担当者は、GitHub上の
プルリクエストをマージするだけで完了！
ロールバックは、マージしたプルリクエストを
リバートするだけ！
3sec.

View Slide


View Slide

⼤量のサーバに対するインフラ作業がトイル
https://www.tenable.com/cve/CVE-2019-19952
システムを運⽤していると、ある⽇突然こんなのがぽんと降ってくる。

View Slide

サーバ数百台の依存コンポーネントバージョンアップ作業
しかも緊急。下⼿すると3時間作業
⼯数/精神的負担が、突発的に発⽣し、
SRE本来の業務へ割く⼒を奪っていた。

View Slide

ここを⼤幅に削減できる。
Dockerfileを書き換えてビルドし、applyするのみ(数秒)
※イメージです。現在のバージョンとは異なります
• Ansibleを流す時間(下⼿すると3時間)
• その間のシステムモニタリング

View Slide


View Slide

無数の歴史的負債があるが、それに⼿を⼊れるのが怖い

View Slide

このNW
経路いる？
このDB
接続いる？
これデッド
コードっぽ
いから消し
たいな
これ機能ご
と別システ
ムに切り出
したいな
このシステ
ムだけES6
使えないん
だけど

View Slide

このNW
経路いる？
このDB
接続いる？
これデッド
コードっぽ
いから消し
たいな
これ機能ご
と別システ
ムに切り出
したいな
このシステ
ムだけES6
使えないん
だけど
でもそれを検証するのに
⼯数かかるし、えいやで出して
障害起こしてもロールバックに
時間かかるし触らんとこ。。。

View Slide

• リグレッションテストをきちんと⾏える環境がない
• ステージング環境はあるけど、本番と微妙に違う
• カナリアリリース/ブルーグリーンデプロイメントの仕組みがない
• いきなり改修したコードに100%トラフィックが流れてしまう
• コードの本番リリース後のロールバック機能がない
• ミュータブルなVMへの構成変更はロールバック不可
ために、歴史的負債の返済に⼿を出しづらい。

View Slide

• 本番環境とほぼ同じステージング環境が⼿に⼊る
• マニフェストで宣⾔的にインフラを定義できる
• カナリアリリース等の仕組みが導⼊しやすい
• 試しに1%だけ改修したコードへトラフィックを流せる
• コードリリースを⼀瞬でロールバックできる
• インフラがイミュータブルになり、変更がロールバック可能に
なるため、負債返済のための攻めのリリースができる
※リグレッションテスト環境も構築を進めています！
⾷べログのソフトウェアテスト⾃動化デザインパターン

View Slide

まとめ
を、解消したい。
その⼿段として、Kubernetesを選びました。

View Slide

3.何からK8s化に着⼿するのか

View Slide

何からK8s化に着⼿するのか
Kubernetes導⼊前の懸念
難しいんでしょ？

View Slide

Kubernetes導⼊前の懸念
難しいんでしょ？ => やってみなわからんわな
新規サービスでお試し。
⾷べログテイクアウトを、Google Kubernetes Engineで構築。
インフラ担当2⼈、3ヶ⽉でサービスインできた。
⼩さく始め、⼿応えを掴むところから始めた
※Googleの顧客事例にも取り上げられました
https://cloud.google.com/blog/ja/topics/customers/kakaku-com-gke/

View Slide

Kubernetes オンプレでいくかクラウドで⾏くか
クラウドの魅⼒
• 運⽤に必要なものが⼀通り揃っている
• 採⽤事例が多く、情報が多い
• ノードの管理がほぼ不要
• これがしんどい
• ECS + Fargateなどのマネージドサービス使え
ばもっと楽
オンプレの魅⼒
• カカクコム社として統⼀的なプラット
フォーム
• ハイスペックなマシンを⼤量に並べる
となると圧倒的に安い
• 80億req/⽉のネットワーキング料⾦と
なると圧倒的に安い
=> 原則オンプレでいくことに

View Slide

Kubernetes化進めていくぜ
早くKubernetesに乗せたいのはメインサービスのMonorepo。
でも、オンプレKubernetesの運⽤ノウハウがなかった
そこで、事故っても影響が⼩さく、簡素なシステムからKubernetes化していった。
1. 社内ツール
2. データベースを持たないステートレスなシステム
3. 他システムから参照されない独⽴したDBを⼀つだけ持つシステム

View Slide

新規サービスはもう全部Kubernetesで
オンプレKubernetesの運⽤ノウハウがたまってきた
=> 新規サービスは全部オンプレKubernetesでいこう！
=> Next.jsやGraphQL(NestJS)のKubernetes化の知⾒もゲット

View Slide

満を持してMonorepoのKubernetes化へ
⼀旦、Monorepo上のアプリケーションすべてをKubernetes上で稼働させてしまう
その後、ドメイン単位でVMからKubernetesへ切り替えていく
=>影響範囲を局所化しつつ切り替え可能に
INSERVICE INSERVICE
MAINTENANCE
MAINTENANCE
Monorepo

View Slide

4. どうやってK8s化していくのか

View Slide

どうやってK8s化していくのか
⼤前提は、リフト & シフト
⾷べログは、運⽤15年を過ぎた歴史あるシステム。
Kubernetes移⾏にあたってシステム全体を⾒回したとき、
つい直したくなる地雷も多く埋まっている。
しかし、いま⼤規模改修をしてもMTTRが⻑いまま。
まずはMTTRを短くするためにKubernetesに乗せる。
地雷を撤去していくのはそのあと。
この⽬的を⾒失わずにやっていきます。

View Slide

• モニタリングどうすんの
• ロギングどうすんの
• ノード運⽤どうすんの
オンプレ特有の悩み

View Slide


View Slide

モニタリングどうすんの
VM時代のホストベース監視ツールは使えない
Kubernetes上ではPodが次々に⽣まれ変わるため
サービスディスカバリ機能を備えた監視ツールが必要
ÞPrometheusを採⽤
サーバAにはこの監
視を、サーバBには
この監視を……
Pod AもPod Bも
もういない？！
Pod Cは何を監視
すれば？

View Slide

Prometheusは、デフォルトでは15⽇でデータが揮発する
Þremote write機能を使い、NewRelicへデータを永続化
メインはオンプレでも、任せられるものはSaaSに任せたほうがいいよね。

View Slide

監視の分断を避ける
Kubernetesで障害が起きると、当然AP層でも障害になる
このとき、監視の⽬が分断していると、原因に気付くのが難しい
Kubernetesは⼤量の複雑なコンポーネントが相互作⽤して稼働しているため

View Slide

監視の分断を避ける
Kubernetesシステム全体を俯瞰できるダッシュボードが必要
全てのデータをNewRelicへ集約し、システム全体状況を把握できるように
• MW以上/OS: Prometheus & NewRelicへのremote write
• Kubernetes層: NewRelic Kubernetes Integration

View Slide


View Slide

ロギングどうすんの
コンテナのログは標準出⼒に出⼒するのが基本です。
ノードにfluentdなどを仕込み、ノードレベルでログを回収しましょう。
とは⾏かないのが運⽤15年⽬のシステム。
⼀つのRailsアプリケーションから、10種類を超える種類のログファイル
を出⼒していることもある
⽤途が違う10種類のログを、ごちゃっと⼀つの標準出⼒に出⼒するよう
作り変えるのは⾟い

View Slide

Fluent-bitを各Podのサイドカーに配置し、Cloud Loggingへ送信
ログルーター機能を利⽤し、条件に応じて、テーブルやバケットを分けて
Big QueryやGCSへも保管
分析⽤
⻑期
保管⽤
短期
閲覧⽤

View Slide

個⼈情報を含むログは、クラウドには置きたくない
=>オンプレのNFSボリュームへ保管。別サーバにもマウントし、閲覧可能に

View Slide


View Slide

ノード運⽤どうすんの
これがかなりきつい。
何か障害が起きていることはわかる。でも何が原因かわからないことが多い。
• 事例1: 謎のノードメモリ使⽤量⾼騰
• dockerdのメモリリークが原因。Podたちは悪くなかった
• 定期的にノードをdrainし、dockerdを再起動する運⽤
• 事例2: 謎の⼤量Pending Podの出現
• CRI経由でのdockerdへのリクエストの遅延が原因。Kubernetesは悪くなかった
• なぜ遅延していたかまでは未だ不明
• dockerdのレイテンシを監視 & 再起動する運⽤
• 最終的にコンテナランタイムをdockerdからcontainerdへ変更した
障害から学び、監視 & 運⽤を⽇々ブラッシュアップしていく覚悟が必要

View Slide


View Slide

逆に⾔うと、
ここまでをあまり気にしなくても
なんとなく使えるのが
マネージドKubernetesのいいところ

View Slide

⾷べログ固有のつらみ
• ⼤規模MonorepoのCI/CDどうする
• ⼤規模アセットどうする

View Slide


View Slide

⼤規模MonorepoのCI/CDどうする
Monorepoにあるコンテナイメージの数は14種
デプロイ頻度(=ビルド頻度)もそこそこ多い
ビルドをSaaSで⾏うと、費⽤がとんでもないことになる

View Slide

⼤規模MonorepoのCI/CDどうする
イメージビルド基盤を内製
SaaSを使えば楽だが、⻑期的コストを鑑みた

View Slide


View Slide

⼤規模アセットどうする
Monorepoには、image/js/css、pdfなどの
静的コンテンツが1GBある
従来、Webサーバで配布していたこれら静的コンテンツを、
Webサーバのイメージ内に含めてしまうと、
コンテナのビルドサイズが巨⼤になり、ノードのディスクは
おろか、イメージプルでネットワーク帯域を⾷いつぶしてし
まう

View Slide

⼤規模アセットどうする
CD時に静的コンテンツをNFSへ配置し、
WebサーバはNFSからサーブする
苦⾁の策だが、リフト & シフトを⽅針に容易な⽅法をとった

View Slide

5.まとめ

View Slide

まとめ
• ⾷べログでは、⻑い歴史を持つMonorepoのつらみを
解消するために、Kubernetes化を始めた
• Kubernetesは複雑。⼩さく初めて徐々に広げていく
• オンプレKubernetesはつらみも多いが、システム規
模によってはコスト⾯で⼤きなメリットを得られる
• ⾷べログではリフト&シフトでKubernetes化を進めて
いる。気になる課題も多いが、その先にあるメリット
を早く享受したいため

View Slide

ご清聴ありがとうございました

View Slide

WE ARE HIRING!
https://hrmos.co/pages/kakakucom/jobs/1011020
⾷べログTech Blogはじめました！
https://tech-blog.tabelog.com/

View Slide

食べログ on Kubernetes ~ 運用15年以上の大規模レガシーシステムを Kubernetesに乗せていく~

食べログ on Kubernetes ~ 運用15年以上の大規模レガシーシステムを Kubernetesに乗せていく~

Shimokuni Minemasa

Other Decks in Technology

Featured

Transcript