目次
- 1章 はじめに
- 2章 食べログのKubernetes移行について
- 3章 巨大モノレポのKubernetes移行におけるチームの課題
- 4章 巨大モノレポのKubernetes移行を始める戦略
- 5章 巨大モノレポのKubernetes移行の実践
- 6章 おわりに
1章 はじめに
食べログ開発本部 技術部 SREチームの乾です。食べログには2018年から参画しています。
私の所属するSREチームは、食べログのミドルウェアやオーケストレーションの管理、CI/CDの運用、モニタリングなどを担うチームです。 食べログは複数のシステムから構成されていますが、SREチームはそのほぼすべてを横断的に管理しています。
この記事では、食べログの各システムを構成する巨大モノレポをKubernetes移行していく戦略とその実践について、チームとしての歩みや私が工夫したポイントを交えて紹介します。
2章 食べログのKubernetes移行について
Kubernetes移行の背景
食べログのメインサービスは、長らくVM環境上でシステム運用しています。SREチームでは、このシステムをKubernetes上に移行するべく、数年前から活動を続けてきました。 Kubernetes移行の動機はいろいろありますが、大きく下記の3点です。
デプロイ/ロールバックの時間短縮
食べログのアプリケーションは、オンプレミスのデータセンターへデプロイされています。食べログでは1日に複数回のデプロイを実施していますが、VMベースのシステムではこれらのプロセスに多くの時間と労力がかかっています。特に、ロールバックに時間を要するため、万一の障害時に素早く収束できないことが大きな課題となっています。Kubernetesの導入により、コンテナ技術を活用して、デプロイを自動化し、数分でのロールバックを可能にすることを目指しています。 また食べログを構成する複数のシステムのうち多くは、巨大なモノレポで管理されています。この巨大モノレポはデプロイに時間がかかるだけでなく、食べログサービスの主要なロジックを多数含んでいます。より素早く変更を適用できるようにし、リリースに問題があったときは素早くロールバックできることを目指しています。そのため、巨大モノレポもKubernetes移行していくことを目指しています。
インフラ作業を素早く実施できるように
VMベースのインフラ管理には変更が生じるたびに時間がかかります。Ansibleによる構成管理をしていますが、サーバの台数が非常に多いため適用には時間がかかります。ユーザ影響の観点から、サービスからサーバを外して作業するものもあります。Kubernetes移行によって、変更の適用を素早く出来るようにし、サービスから外す手順もより楽に出来るようにしていきたいと考えています。
変更容易性を高める
システムの変更が容易であることは、ビジネスの俊敏性に直結します。Kubernetesの柔軟な構成と管理機能により、システムの変更を迅速かつ安全に実施できるようにしたい狙いがあります。例えば新しいマイクロサービスを作成するといったこともKubernetes上であれば迅速に行えます。
このあたりについては、食べログ on Kubernetes ~ 運用15年以上の大規模レガシーシステムを Kubernetesに乗せていく~ でも説明されています。
これまでの歩み
食べログのメインサービスに手を入れる前に、食べログノートや食べログオーダーといった新規サービスをオンプレミスのKubernetes上に構築し、その運用実績を積み重ねてきました。 加えて、VMで運用していた小規模なマイクロサービスをいくつかKubernetes移行し、各サービスのスケールやデプロイをKubernetes上で管理できるようになりました。これらの経験を重ねたことで、Kubernetes上でサービス運用していくための基盤が整っていきました。いくつか取り上げると下記のようなものです。
CI/CD
継続的インテグレーションとデプロイメントのパイプラインを整備し、自動的にイメージビルドされる仕組みを構築しました。CircleCI、Tekton、ArgoCDなどを組み合わせて実現しています。これにより、開発者はGitHubのPRをマージするだけでKubernetes上にコードが反映されます。 詳しくは 食べログのCloud NativeなCI/CDパイプラインのお話 でも紹介されています。
モニタリング
モニタリングツールを導入することで、システムの可視性を高め、問題の早期検出と迅速な対応が可能になりました。 VMでもPrometheusやGrafanaを導入してモニタリングは実施しています。しかし、データの永続化を考えるとコストの問題とは切っても切り離せません。また、Kubernetes上のさまざまなコンポーネントのメトリクスを取得するのは中々大変です。食べログでは、New Relicを導入することでそれらの問題を解決しています。 詳しくは 食べログへのNewRelic導入の経緯と効果、運用効率化のための工夫 でも紹介されています。
ロギング
一般的には、シンプルなアーキテクチャで、ログの欠損が起こりにくいノードレベルでのロギングが推奨されています。しかし、食べログではアプリケーションから出力されるログの種類が多岐にわたるため、サイドカーパターンを用いてアプリケーションログを収集しています。収集したログはGoogle Cloudに送信しています。長期保管にはGCSに保管し、ログを分析したいときはBigQueryを使って集計できるようにしていたりと、Google Cloudのサービスを活用しています。
3章 巨大モノレポのKubernetes移行におけるチームの課題
現状
上記のような取り組みの成功を通して「Kubernetes上でインフラを稼働させる」手応えを掴めたこともあり、巨大モノレポのKubernetes移行を進めるいう気運がチームの中で高まっていきました。食べログの中核をなす巨大モノレポがKubernetes移行できれば、デプロイ/ロールバックの高速化といった恩恵を多くの開発者が享受できるようになります。SREチームとしてもインフラ作業が高速化されることで運用業務の負担を減らすことができます。
いよいよやっていくぞ！という気持ちの下、チーム総出で巨大モノレポのKubernetes移行に向けてKubernetesのマニフェストを書いていきました。食べログサイトのトップページを担うシステムを検証用のKubernetes上で動作させて画面表示に成功したりと、着実に部品を揃えていきました。
課題
城をイメージせずに城の部品を作っていた
リクエストを処理するためのPodやServiceなど、巨大モノレポのKubernetes移行に必要な部品は揃ってきました。しかし、課題がありました。巨大モノレポのKubernetes移行プロジェクトの全体像が不明確で、どのような状態になればVMから切り替えてもOKか、明確なゴールが決まっていなかったのです。いわば、チームで分担して城の部品を作っていたものの、城の完成イメージを描いていなかったのです。
イメージを考える人がいない
巨大モノレポに存在しているバリエーションの多い設定は、それぞれ固有の事情をたくさん抱えています。そのために、Kubernetesの専門知識と食べログシステムの深い知見を兼ね備えていないと完成イメージを描くのは困難でした。食べログ在籍歴の長いチームメンバーが退職したことも重なり、プロジェクトの全体像、完成イメージを考えられる人が不足し、プロジェクトの進行に影響を与えました。
解決: 「俺に任せろ」
これらの課題の解決方法は 「俺に任せろ」 でした。 私は食べログに参画してからSREチーム一筋でしたが、1年半ほど別チームに異動していました。チームがこの課題に直面していたタイミングで、私はSREチームに戻ってきました。 チームから異動する前とあまり変わっていないように見えるプロジェクト進捗を不思議に思い、チームメンバーに話を聞いてみました。そこで初めて、プロジェクトが置かれている状況と直面している課題を理解しました。そして、この課題は自分なら出来る...というある種の驕りのような使命感が自分の中に芽生え、プロジェクトリーダーとしてプロジェクトの立て直しを決意しました。 もっとも、SREチームが他に進めているプロジェクトとの兼ね合いなどもあり、純粋に自分のやる気の問題だけではないのですが、SREチームに戻ってきたタイミングも運命的なものを感じました。
食べログ知見はある
自分がプロジェクトをリードしていくと決意したのは、食べログシステムの知見を持っているから、ということが大きな理由の1つです。深い知見とまで言ってよいのかはわかりませんが、食べログシステムの全体像についてはそれなりに把握しているつもりだ、という自信がありました。 私は、過去に食べログのデータセンター移行プロジェクトを経験しています。その際、当時VMで稼働していた食べログシステムほぼ全てを調べ、移行の段取りや計画、必要な対応洗い出しなど進めていました。この経験が、今回の巨大モノレポのKubernetes移行の全体像を描くのにそのまま活かせると考えました。
Kubernetes運用の業務経験は無い
ただ一方で、Kubernetesの専門知識はほとんどありませんでした。書籍で軽く読んだり、簡単なHowTo程度の経験はあるものの、Kubernetes上で稼働しているシステムの運用経験はほぼありませんでした。 そのため、この足りない部分を補わないと現実的なKubernetes移行計画を立てることができません。最終的なゴールの状態、そこに至るまでの必要な要素、VMからKubernetesへと移行するにはどのような選択肢があるか、など、計画を立てるうえでKubernetesの知識は必須でした。 そこでまずは、食べログのKubernetes運用についてのキャッチアップから始めました。CircleCIやArgoCDを組み合わせたCI/CDの仕組みなどを始め、アーキテクチャの把握はしていたものの、ぼんやりとしたものでした。しかしここから自分がKubernetes移行の計画を立てていくには深く理解する必要があります。そこでチームでまとめていたドキュメントを読み込んだり、普段チームで行っている運用業務で気になったところは深掘りしてメンバーに質問したりして、理解を深めていきました。
他にも、今までチームがどういうふうに移行をしようとしていたか、何を作ったか、何を検証したかなど現状のキャッチアップを漏らさず行いました。
4章 巨大モノレポのKubernetes移行を始める戦略
このようにしてプロジェクトリーダーに立候補した私ですが、まずは巨大モノレポのKubernetes移行プロジェクトを成功させるために、どのような方針・ゴールで進めていくか、戦略を立てる必要があります。 今回このプロジェクトを進めるにあたり、私は以下の3つの戦略を立てました。
- 一度にたくさんのことをしようとしない
- リフトアンドシフト
- 切り替えは迅速かつシームレスに
以下でそれぞれについて詳しく説明します。
戦略1: 一度にたくさんのことをしようとしない
Kubernetes移行対象を分ける
まず1つ目の戦略として、巨大モノレポの中のWebサーバの部分だけを先行してKubernetes移行することを決定しました。これにより、全体を移行する際の複雑さを軽減し、初期段階での障害発生リスクを最小限に抑えることができます。もちろん、巨大モノレポ故にWebサーバだけといってもたくさんのシステムのWebサーバ設定が存在しています。 食べログの大半のシステムでは、Webサーバとアプリケーションサーバ (APサーバ) の2段構成でユーザリクエストを処理しています。このうち、前段であるWebサーバのみをまずはKubernetes移行します。複雑さ軽減だけならAPサーバから実施するという方法も考えられますが、以下の理由によりWebサーバから進めることを選択しました。
WebサーバをKubernetes移行しておけば、APサーバの切り替えが迅速にできる
Webサーバを先に移行するメリットとして、その先のAPサーバの移行が楽になる、という点が挙げられます。WebサーバからAPサーバへのプロキシ設定はAnsibleによって構成管理しているものの、サーバ台数も多いことから反映には時間がかかります。そのためWebの部分を先に移行しておけば、Kubernetesの迅速な変更が可能というメリットを享受してアプリケーションの切り替えが実施できます。 また、アプリケーションコードを動かすAPサーバは食べログシステムの要です。「APサーバのKubernetes移行は可能な限り慎重かつ安全に実施したい」ということも、まずはWebサーバだけをKubernetes移行することを選ぶ大きな理由になりました。
Webのconfig更新といった日々の運用が楽になる
Webサーバの設定はAnsibleで管理していますが、やはり台数が多いため変更を適用するのに時間がかかります。このオペレーションはSREチームで実施していますが、SREチームにとってこの運用負荷は大きいものでした。そのため巨大モノレポのWebサーバがKubernetes移行されるだけでも、大きく運用負荷が軽減されます。SREチームにとって嬉しいメリットです。
1Web:1APという構造になっていないのでWeb-APセットは難しい
システムの構造上、WebサーバとAPサーバが1:1になっていません。WebサーバがAPサーバにプロキシする経路が複数あり、複雑に絡み合っています。そのためWebサーバとAPサーバを1セットとしてKubernetes移行するアプローチは取れませんでした。これをするためには、各種WebサーバとAPサーバのネットワーク経路の見直しなど大規模なリファクタリングが必要になってしまいます。
戦略2: リフトアンドシフト
そして2つ目の戦略として、このプロジェクトではあくまでKubernetes環境への移行のみを目指すことにしました。これはすなわち「システム構成や設定をKubernetesに最適化することはしない」ということを意味します。大規模にシステムを変更する時は「作り直すならここの設定をこう変更しておきたかったからこれを期に直そう！」というふうに考えたくなりますが、巨大モノレポのKubernetes移行というだけでもボリュームのあるプロジェクトです。Webサーバだけに絞っても、複雑なWebのプロキシや設定と向き合っていく必要があります。そのため、できるだけプロジェクトでやることを小さくし、本当に重要なことだけにフォーカスすることにしました。
Webサーバ設定を可能なかぎりそのまま維持
今回移行の対象とする各Webサーバは、移行前後で可能な限り設定を維持することとしました。設定の互換性を確保することで、移行後のトラブル時の切り分けを迅速にし、素早い判断が出来るようになります。とはいえ、Ansibleで管理していたものをコンテナ化したりKubernetes用のマニフェストファイルに置き換えるのはそこまで単純な作業ではありません。「Webサーバに設定されているすべての設定値、プロキシ先などがVMとKubernetesとで一致するものが出来上がっていること」という状態をゴールとして据えました。
全経路のレスポンスヘッダの一致
Kubernetes移行後もWebサーバとしてサービス品質を維持するため、全ての経路で、VMとKubernetesとでそれぞれレスポンスヘッダが一致するように設定を確認しました。まずは巨大モノレポのWebサーバ-APサーバのネットワーク経路を全て網羅的に洗い出しました。その結果36通りの経路の存在が判明しましたが、この全ての経路でこのレスポンスヘッダ一致確認を行うこととしました。
今回、移行Readyの条件を「VMとKubernetesでWebサーバの設定は同じ」「VMとKubernetesで同じリクエストを流せば同じレスポンスが返ってくる」の両者を達成することとしました。これによってVMと同じサービス提供ができることを担保します。
戦略3: 切り替えは迅速かつシームレスに
3つ目の戦略は移行方法に関するものです。サービスを提供しているVMのWebサーバから、Kubernetes上のWebへ切り替えることになります。そのため、SREチームとしてはユーザ影響を可能な限り抑えられるよう十分に工夫・検討しておく必要があります。食べログではWebサーバの前段にロードバランサーが存在することもあり、無停止で移行することの難易度自体は高くありません。とはいえ問題が起きることもあり得る以上、それを察知したら素早く移行前の状態にロールバックできるよう準備しておく必要があります。 つまり、迅速かつユーザにとっては静かに、キビキビと切り替えていくための準備しておく必要があります。
迅速な切り替えの仕組み
まずは切り替えを迅速に行える仕組みを構築し、かつ必要に応じて迅速に切り戻せる体制を整えました。Webサーバの上位にあるLBからのヘルスチェック（メンバーの死活監視）を利用し、VMのWebサーバのサービスIN/OUT、Kubernetesクラスタ上のWeb PodのサービスIN/OUTをコントロールできるようにします。LBのメンバーから外すだけのため、急遽KubernetesクラスタのWebをサービスOUTさせても、ユーザリクエストの処理を中断するわけではありません。
VMとKubernetesで割合を変えていく
さらに、一気にVMとKubernetesとをバチンと切り替えるのではなく、徐々にKubernetesのリクエスト処理割合を増やしていく方法で切り替えることにしました。もしも何か問題があっても、ユーザ影響を可能な限り小さくなるように抑えておくためです。加えて、例えば「1%ずつ増やしていく」といった方策では慎重すぎると判断しました。最初は様子を見ていくものの、問題ないと判断したら50%->75%->100%といった勢いでKubernetesに割合を割いていくことにしました。
切り戻す基準決め
「問題が起きる」の基準も、あらかじめ決めておく必要があります。今回はWebサーバのみをKubernetes移行するため、アプリケーションでの例外発生などだけでは異常を捉えることは困難です。食べログではサービスごとに稼働率とレイテンシを計測していますので、切り戻し基準としてはこの指標を用いることとしました。
これらにより、Kubernetesクラスタ上のWebサーバで処理したリクエストだけに異変があった場合、1分以内にはロールバックして移行前の状態に戻せるように計画しました。
キャパシティ不安はちょい出ししてみる
Web Podのリソース設定はVMのWebサーバのリクエスト数/secをもとに計画し、ピーク時の流量に耐えられるかも検証を実施します。さらに念には念をいれ、処理するリクエスト数が多いサービスについては、完全に切り替える前に事前テスト投入を計画しました。これは30分から1時間程度だけKubernetesのWeb PodをサービスINさせ、予定時間経過で元に戻すというものです。解消できる不安点は少しでも解消したうえで切り替えに臨めるように、こういった工夫も移行戦略として計画しました。
切り替え後の手厚いモニタリング
システムのモニタリングについては、切り替え中および直後のモニタリングと、その後のモニタリングで分けて考えました。切り替え中とその直後はNew Relicを張り付いて見ておくぐらいに手厚く確認することとしました。その後については、1時間おきチェック、そして日次チェックと徐々に手厚さをゆるめていきました。その後は、日々のアラートチェックなどのSREチームでの通常運用フローに乗せていく、という方針です。
Kubernetes移行はプロジェクトのゴールではありますが、新たな運用のスタートでもあります。すでにKubernetes上で稼働しているシステムはあるものの、今回の移行対象としている巨大モノレポのWebのリクエスト処理規模は既存のシステムを遥かに上回るものとなります。そのためどのようなアラートが必要かも設計しておく必要があります。ここでの方針は、最低でも、VMと同等の監視とアラートを準備しておくことを目指しました。 具体的にはPod数やリソースのLimitに対する使用率、コンテナの監視などです。New Relicが自動的に収集してくれているものは何か・アラート設定はどこまで準備してあるか・自分たちでつくらなければならないものは何かなどについて、切り替え後に自分たちが日常の中で運用していくイメージを作りながら調査、検討していきました。
5章 巨大モノレポのKubernetes移行の実践
このように戦略を整えたあとは実践です。立てた戦略に対して、以前に作っていた部品がそのまま使えるのか。使えるのであればそのまま使い、足りないものは作り、設定値を変えていたりするものは直していく、といったことを行っていきます。
「Webサーバ設定を可能なかぎりそのまま維持」のためのconfigを揃える
先述の通り、私がプロジェクトへ参画する前から、すでにKubernetes移行に向けた部品、つまり各種configファイルは作成されていました。そして幸いなことに、今回の戦略に含まれる「Webサーバ設定を可能なかぎりそのまま維持」と同じ方針で作成されていたようで、新旧ファイルが等価かどうかの比較ログも見つかりました。 しかしそのログを見る限りでは、エクセルで対象を一覧化し、それを目視検査（！）で差分チェックを行っていたようであり、私がエクセルを読み始めて1時間ほどで誤りを見つけてしまいました。この方法で確認していては、自信を持って「Webサーバの設定はそのまま維持できた！」と言える日はだいぶ遠そうです。 また、比較するファイル数はざっと数えても千を超えていました。少なくとも目で検査するのは現実的でない、と判断しました（以前にこの方法でやろうとしてエクセルにリストアップしたのは凄いですが...）。
そこで、スクリプトなどを用いた機械的なチェックをしていくことにしました。しかしGitHub上で管理しているファイルを比較しようにも、Ansible用のファイルとKubernetes用ファイルでは、変数展開の仕組みを変えていることもあり、単純なdiffを取っても差分が出てしまうことはわかっていました。さらに、Ansibleではifなどの条件分岐によって記述される設定もあり、一筋縄ではいきません。 そこで私は「実際のサーバやPod上には、変数に値がセットされて配置されているはずで、それを比較すればもっと楽にdiffを取れるはず」と考えました。検証用環境で、VMのWebサーバとWeb Podそれぞれに配置された設定ファイル全てをコピーし、これらに対してdiffをとっていくことにしました。 それでも、diffを取っていくとAnsibleとKubernetesとで記述方法の差は出てきてしまいます。とはいえ、ある程度決まったパターンの差分ばかりです。このチェックを効率よく、そして正確に行うために、簡単なスクリプトを書きました。diffで差分をとり、それが決められたパターンにマッチする差分だった場合は無視する、といったスクリプトです。これを使って千をも超えるファイル全てをチェックし、設定の完全一致を検証しました。
巨大モノレポ内でWebサーバの設定は複雑に分岐しており、Webサーバごとに設定の差があります。それは実装時期の違いによる微妙な差であったり、Webサーバ固有の事情による差であったりします。スクリプトによる全ファイル検査によって、そういったわずかな設定漏れも検出できました。ただし、それが例え修正できそうなものであったとしても、今回の戦略に沿って、このタイミングでの修正は見送りました。
これで、Webの設定は完全にVMとKubernetesとで一致していると自信を持って言える状態を作り出すことができました。
ユーザ影響がわかるようにモニタリング整備
「ユーザ影響を抑えて切り替える」という戦略を実践するためには、ユーザ影響がわかるようになっていなければいけません。食べログではサービスごとに稼働率やレイテンシといったモニタリングをVMでも行っていました。Kubernetes上でも同様のモニタリングを実施できるように整えておく必要があります。 モニタリング項目や監視の詳細については、下記の過去記事をご覧ください。
ユーザ影響を確認するための内容整理
実際の切り替え作業用に、一時的な専用ダッシュボードをNew Relicに作成しました。Web PodのCPUやメモリ利用率、稼働率などを一目で確認できるように整理してあります。切り替え作業中に異変を見逃さないよう、1つのダッシュボードにアクセスすれば必要な情報が全て載っている状態にしました。これにより、少しでも異変を感じたら素早いロールバックをできるようにしました。
切り替え
そして、満を持して巨大モノレポのWebサーバをKubernetesへと切り替えていきました。
切り替え後のモニタリング
逐次ユーザ影響の有無を確認し、稼働率やレイテンシの悪化が無いか、切り替え後のパフォーマンスを詳細に監視しました。ユーザ影響は無いがWeb PodのCPU使用率が少し高めであるとか、Pod数を増やしたほうが良さそうであるとか、そういったことも見逃さないようにモニタリングしていました。食べログのサービス規模を踏まえると、問題が起きてからの対処では、対処が完了するまでにすでに大きなユーザ影響が出てしまっている、というケースが多いためです。
結果、移行中・移行後通して稼働率などのサービスレベルをほぼ維持できました。これにより、立てた戦略の有効性も実証できたと考えています。
迅速なロールバック
移行に際し、1ドメインだけIngressの設定が不足していたことが判明しました。 非常にアクセス数の少ないドメインであったこともありますが、事前に準備していたアラートやロールバックに関する計画のおかげでユーザ影響が出る前に対処できました。入念な準備が功を奏したものと考えています。
作業の体制
巨大モノレポには多数のシステムが含まれています。それらのWebサーバを打ち立てた戦略通りに切り替えるには、1人や2人の作業でなんとかなるものではありませんでした。安全には安全を重ねるため、1システムずつ分けて切り替え作業を実施。切り替えたあとのモニタリング作業もあります。 そのため作業はSREチーム全員で分担して実施しました。必ず2人以上のペアを組んで切り替え作業を実施していました。これはトラブルが発生した際にスムーズに対処するためのSREチームのノウハウです。 そして、チームの誰が実施しても同じクオリティで切り替えられるように、切り替え作業や切り戻し基準、モニタリング方法など細部にわたって手順化を徹底しました。 これにより、食べログのサービス提供には一切影響を出さずに、巨大モノレポのWebをKubernetesへと切り替えることができました。
6章 おわりに
モノレポのWebサーバ Kubernetes移行は完了、次はAPサーバ
今回のプロジェクトで得られた成果をもとに、次のステップとして巨大モノレポのAPサーバ Kubernetes移行を計画しています。Webサーバの成功がチームに自信を与え、またチームにKubernetesに関する運用ナレッジが大きく貯まりました。
Kubernetesについて深く理解しておくのが大事
今回、私がプロジェクトをリードして完成図をイメージするために、Kubernetesに関する知識のキャッチアップや調査から行いました。自分がリードしていくと決めた際の一番の不安点であったのと、振り返ってみても一番苦労したポイントでした。ただ、SREチームメンバーから のサポートがプロジェクトの成功に大きく寄与しました。
Kubernetesは非常に便利でさまざまなことが実現できますが、その裏で何が行われてどういう仕組みで実現されているのか、そこをきちんと把握しておくことが重要だと改めて感じました。例えばサイドカーコンテナにはpreStopでメインコンテナの終了を待つといった仕掛けを施してありますが、なぜそれが必要なのか。Podの終了時にはどういった流れでServiceリソースのルーティング先から外れるのか。 このような地道な理解の連続が、プロジェクトの成功へと繋がりました。プロジェクトに関わる前は「Kubernetesって詳しくはよくわからないけど、なんかすごいやつなんだろうな〜」というふわっとした印象でしたが、プロジェクトを遂行した経験を通して理解の解像度が上がり、しっかり自分たちで運用できるイメージがつきました。
Webサーバだけを移行対象にしたのはかなり良かった
巨大モノレポのWebサーバだけをまずKubernetesに移行したという戦略は、今回の成功にかなり大きく寄与したと考えています。移行作業全体を自分たちが対処できる規模感に抑えたことで、プロジェクト全体の複雑さを軽減し、考慮すべき点を見落とさずに計画できました。結果、ユーザ影響なく移行を終えられ、かつ段階を踏むことでチームにナレッジと自信が得られたと考えています。
やってよかったKubernetes移行
巨大モノレポのWebサーバだけというまだ一部ではあるものの、Kubernetes移行が進んだことは食べログにとって非常に大きな一歩となりました。 今回の戦略でWebサーバのKubernetes移行をした後、Kubernetesを活用する恩恵を多数受けました。Webサーバだけとはいえ、普段の運用業務は多岐にわたります。
- CPUやメモリといったリソース調整
- サービス成長に合わせた増台
- 収集メトリクスの設定変更
- OSやミドルウェアのアップデート
これらそれぞれが、VMでWebサーバを運用していた時代はAnsible Playbookの修正・実行などの時間を要する作業を伴っていました。それがKubernetes移行により、マニフェストファイルを数行変更するだけで、素早く変更を適用できるようになり、運用業務負荷の軽減に繋がりました。
VMからKubernetesやコンテナにシステムを移行したけど辛くなって戻した、という事例も目にします。確かに、Kubernetes上でのサービスの運用は大変だと感じます。特に、チームにナレッジが溜まっていかないと非常に辛いものになります。 ただ、今回の取り組みを通して、食べログにおいては今後のKubernetes移行も前向きに取り組めそうだ！という実感を得ることができました。巨大モノレポのAP Kubernetes移行を達成できれば、食べログの開発はさらに加速できると確信しています。
私達は、このような食べログのインフラの革新を一緒に取り組んでくれる仲間を募集しています。この記事を読んで少しでも興味を持っていただけましたら、ぜひ下記の採用情報ページをご覧ください。
