目次
はじめに
食べログカンパニー 開発本部 技術部 SREチームの乾です。食べログには2018年から参画しています。
この記事では、10年以上続いた手作業によるcronの運用に対して、生成AIを活用することで、わずか4日間の開発で「作業時間0分」にすることができたシステム改善の事例をご紹介します。
AIとの対話による設計プロセス、実装の高速化、そしてレガシー改善に潜む心理的なハードルをいかにして乗り越えたか。私たちの実践的な知見が、同様の課題を抱える皆さんの助けとなれば幸いです。
SREチームにおける「cron登録作業」とは
私の所属するSREチームは、食べログのミドルウェアやオーケストレーションの管理、CI/CDの運用、モニタリングなどを担うチームです。 食べログは複数のシステムから構成されていますが、SREチームはそのほぼすべてを横断的に管理しています。
食べログでは、長年にわたり追加されてきた多数のバッチ処理が稼働しており、その一部はVMに設定しているcronで実行されています。SREチームはcronの登録・管理を担当しており、開発チームから設定内容の変更依頼を受け付け、取りまとめて作業しています。具体的な作業フローは以下の通りです。
- 設定ファイルの管理: cronの設定内容は、IaC（Infrastructure as Code）の考え方に基づき、GitHub上でファイルとして管理しています。
- デプロイ: 各VMへは、10年以上前に作成された秘伝のデプロイスクリプトを用いて設定を反映させています。
- 手動オペレーション: デプロイ作業時には、作業者がスクリプトに対してsudoパスワードを数回入力する必要があります。
この運用は年間約100回発生し、1回あたりの作業時間は10分程度です。1回1回は軽微な作業ということもあり、「改善コストと効果が見合わない」という判断で、この運用方法が長年続いていました。
しかし、この作業のためだけにsudoパスワードを手元に準備しておく必要がありました。ほかにも、デプロイにどのサーバを使い、そこでどのようなコマンドを実施するのか、といった作業に必要な知識が多く存在する運用でした。
このようなレガシーな繰り返し作業を放置することは、エンジニアが本来向き合うべき創造的な業務への集中を阻害します。 私たちは、この現状を打破すべく、cron運用改善の第一歩を踏み出すことにしました。
改善を始めた経緯
長年課題と認識しつつも、なかなか着手できずにいたこの問題ですが、今回改善に踏み切ったのには、ある個人的なきっかけがありました。
それは、私の育児休業からの復帰です。長期間現場を離れていたため、これまで当たり前のようにこなしていたcron登録作業も、頭の中がリセットされたまっさらな状態で向き合うことになりました。いざ作業してみると、「なぜこんなに何度もパスワードを？」「この手順、毎回ドキュメントを見ないと不安になるな…」といった、かつては慣れで見過ごしていた数々の手間に、改めて気づかされたのです。
この体験は、"慣れ"がいかに作業の非効率さを見えなくさせていたかを浮き彫りにしました。
そして、これまで「コストに見合わない」と判断していた改善についても、考え直すきっかけがありました。 生成AIの活用です。生成AIに設計案を出してもらい、実装コードもほとんど生成できます。自分でゼロから考えるよりも低コストで改善を実現できるということです。
システム設計と技術的アーキテクチャ
詳細なシステム構成図
今回構築した新しいcron管理システムの全体像は、図の通りです。GitOpsの考え方をベースに、KubernetesとArgo CDを中核技術として採用しました。
開発者がcronの設定ファイルをGitHubのmasterブランチにプッシュすると、その変更をArgo CDが自動で検知し、Kubernetesクラスタ上のConfigMapとして同期します。その後、ConfigMapの更新をトリガーとしてKubernetes Jobが実行され、最終的にターゲットとなるVM上のcronが更新される仕組みです。
このアーキテクチャで特に工夫した点は、ターゲットとなるVMの構成を一切変更していないことです。長年安定稼働しているVM環境に手を加えることは、予期せぬトラブルを招くリスクを伴います。そこで、cronを更新するための処理はすべてKubernetesクラスタ側で実行し、VMへはSSH経由で更新コマンドを送信するだけに留めました。
この設計により、既存環境への影響を最小限に抑えつつ、Gitへのプッシュを起点としたモダンで宣言的なワークフローを実現しています。
技術スタックの選定理由
今回のシステムを構築するにあたり、重視したのは「食べログのドメイン知識がゼロのエンジニアでも、安全かつ迷わずcron登録作業を実施できること」でした。この実現のために、GitOpsというアプローチを採用しました。
GitOps化を目指す上で、その中核となるツールとしてArgo CDを選定しました。これは、食べログの既存のKubernetes基盤上で、すでに安定稼働の実績があったためです。 下記の過去記事にもある通り、いくつかのシステムをオンプレのKubernetes上で動かしています。Argo CDを使ってGitHub上のコード変更検知もすでに実践しています。
新たなツールを導入する学習コストや検証コストをかけることなく、使い慣れた環境と技術スタックで迅速に開発を進められました。
今回の技術選定の背景は「誰でも負担ゼロで作業できる」運用を目指しています。 そのために、既存の技術資産を最大限に活用して改善コストを抑えつつ、GitOpsの思想を取り入れました。
セキュリティ考慮事項
今回のシステム改善は、セキュリティの向上にも大きく貢献しました。
従来の運用では、cronのデプロイを実行するために、作業者が特権ユーザのsudoパスワードを把握している必要がありました。これは、パスワード管理の観点から、セキュリティ上のリスクを内包している状態でした。
新しいシステムでは、このパスワードをBitnami Sealed Secretsで暗号化し、Kubernetesクラスタ内での安全な管理に変更しました。これにより、作業者はデプロイサーバにSSHでログインする必要も、特権パスワードを知っておく必要もなくなりました。
今までcronのデプロイ作業者も、細心の注意を払ってパスワードを管理し、デプロイ作業をしていました。今回の改善で、そういった心理的な負担もなくなりました。 作業者の負担を軽減し、かつシステム全体として、よりセキュアな状態を実現できました。
GitOpsでのリリースフロー
「誰でも負担ゼロで作業できる」というと、管理が行き届かない無法地帯のような状態を想像されるかもしれません。しかし、もちろんそんなことはありません。今回の新しいフローでは、食べログの標準的な開発プロセスに則った、適切なガバナンスが確保されています。
cronの設定変更は、すべてGitHubのPull Request（PR）を通じて行われます。そして、そのPRは必ずチームリーダーの承認（レビュー）を経てからでなければ、masterブランチにマージできません。これにより、変更内容の意図や妥当性が第三者によってチェックされる体制が担保されています。
従来のcron登録は、このPRマージ後に、デプロイサーバに入って作業をしてスクリプトを叩く...という手順でした。この手順もリリース作業の一環であり、テキストに起こしてレビューの対象となっていました。今回のシステム変更で、テキストに起こしたりレビューしたりといった手順の削減にも繋がっています。
また、デプロイの実行状況や結果は、Argo CDのGUIからリアルタイムで確認できます。もし何らかの問題が発生した場合でも、Sync状態や実行ログから迅速に原因を追跡できます。このように、作業の属人性を排除しつつも、トレーサビリティと統制がしっかりと効いたリリースフローを実現しています。
食べログのシステム規模ならではの考慮事項
食べログシステムでは非常に多数のサーバが稼働しています。 特に今回注意を払ったのが、cron登録対象となるVMの多さです。多数のVMに対して同時にSSH接続とコマンド実行する処理では、ネットワークの瞬断などによる接続エラーの可能性を考慮しなければなりません。また、設定ミスで大量のVMへ意図しないSSH接続が繰り返し実行され、SSH接続要求が集中してしまう事態も避けなければなりません。
このようなリスクを回避し、大規模環境でも安定して稼働させるために、以下の点を考慮して設計しました。
- 障害耐性の確保: cronのデプロイ処理は、ある1台のVMへのデプロイが失敗しても、その影響が他のVMに波及することなく、正常なVMへのデプロイは継続されます。
- 容易なリトライ: Argo CD上で管理されているため、GUI上から簡単にSync（再実行）をかけられます。
- 安全な実行タイミング: VMへのSSH接続を必要なタイミングのみに抑えてあり、変更が必要なときのみJobが起動します。
これらの設計により、大規模環境であっても、安全かつ安定的に変更を適用できる仕組みを実現しました。
実装プロセスと生成AI活用の詳細
今回のプロジェクトは、設計から実装、デバッグに至るまで、生成AIを相棒として全面的に活用したことが大きな特徴です。ここでは、その具体的なプロセスと、AIとの協業における発見についてご紹介します。
生成AIとの対話による設計と実装
設計の初期段階では、生成AIを壁打ち相手として活用しました。まだ本気で改善に着手するつもりはなく、たまたま開いていたCursor上で、エンジニア仲間と雑談するような軽い気持ちで話しかけたのが始まりです。
私： 「既存のcron運用にはこんな問題があるんだけど、何か良い方法ない？いま面倒すぎるんだよね」
この漠然とした問いかけに対し、AIはまず一般的なベストプラクティスをいくつか提示してくれました。
AI： 「AWS Lambda、Kubernetes CronWorkflow、GitHub Actionsなどの利用が考えられます」
これを受けて、私たちは食べログならではの制約条件や、すでに利用可能な技術資産を伝えていきました。
私： 「あ、うちはオンプレ環境が前提なんだ。でも、既存のKubernetesクラスタなら使えるよ」
AI： 「なるほど。では、ConfigMapの利用やCronWorkflowでの変更検知はいかがでしょう？」
私： 「いいね！ConfigMapなら
configMapGeneratorを使った実績もある。変更検知は、既に導入済みのArgo CDを使えばもっと簡単にできそうだ！」
このようにAIとの対話のキャッチボールを繰り返すことで、机上の空論ではない、実現可能で効果的な設計案へと徐々に具体化させていきました。
実装とデバッグの高速化
「これなら本当に実現できそうだ」と確信が持てたところで、実装フェーズに移行しました。ここでもAIは強力なサポーターです。Kubernetesのマニフェストファイルやコンテナで実行するシェルスクリプトなど、実装に必要なコードのほとんどをAIが生成してくれました。
もちろん、生成されたコードがそのまま動かないこともあります。しかし、発生したエラーを伝えればすぐにデバッグをサポートしてくれます。
また、開発・デバッグ作業を効率化するために、Docker Composeを使ったローカルでの動作確認環境の構築もAIに依頼しました。Secretや環境変数の扱い方について、「自分以外も触るから、わかりやすさと保守性を重視して」といった設計思想を伝えるだけで、最適な方法を提案・実装してくれました。
チェックスクリプトによる安全なリリース
安全なリリースの確立にもAIを活用しました。10年以上続いた運用を新しくするため、問題なく新システムの運用を始められることを確認する必要がありました。 cronファイルが今までと変わらずにデプロイ出来ているか、意図せぬ変更を生んでいないか。それらの観点をチェックするためのスクリプト作成をAIに依頼し、多数あるcron実行サーバ全てにチェックを実施しました。これにより、ヒューマンエラーのリスクを低減できました。
生成AIの限界と人間の専門知識の重要性
しかし、生成AIは万能ではありません。今回のプロジェクトでも、最終的な意思決定には人間のエンジニアによる専門知識が不可欠でした。
例えば、AIが最初に提案してきたのは、更新処理をDeploymentやCronJobで管理するという案でした。configMapGeneratorでcronファイルのConfigMapを生成して管理し、Deploymentでは起動時にcronデプロイ処理を実行するPodをひとつだけ構成しておきます。そのPodにはConfigMapをマウントしておけば、cronファイルを更新するとPodの再生成が実施され、cronデプロイされる...という設計です。これは一見妥当に見えました。SREチームの技術専門職である下國に設計レビューを頼んだところ、「簡単に出来そうで良いですね。ただ今回の用途なら、一度きりの処理を実行するJobリソースを使う方が、よりシンプルで無駄がないと思います」という的確なアドバイスをもらいました。こうしたシステム特性を深く理解した上での判断は、まさに人間の専門家ならではの価値です。
また、AIが廃止済みの古いkustomizeの機能（configMapGeneratorでディレクトリ以下をワイルドカードで指定）を提案してくる場面もありました。最初は提案通りに実装し動作確認していましたが、何度やってもkustomize buildが通りませんでした。AIに聞いても書き方がダメだなどを指摘されましたが、自分で調べたところ廃止されていたことがわかりました。AIの知識は必ずしも最新・正確ではないため、その提案を鵜呑みにせず、公式ドキュメントなどでファクトチェックを行う重要性を改めて認識させられました。
実践から得たトラブルシューティングの知見
開発の最終段階では、実践的なトラブルシューティングも経験しました。当初、処理が完了したJobリソースを自動でクリーンアップする設定にしていたところ、Jobの実行ログも一緒に削除されてしまい、失敗した際に原因を追うことができないという問題に直面しました。 なお、基本的にはKubernetesのノードレベルでのロギングが推奨されていますが、食べログではアプリケーションのログはサイドカーパターンで収集しています。食べログのKubernetesロギングについては下記の記事でも語られています。
AIに相談すると、もちろんノードレベルのロギングを提案されました。しかし現状の制約を改めて伝えたところ、 Argo CD Notificationsの利用やログ収集コンテナを追加する案などを提案されました。
必要なManifestの雛形も生成してくれたため、Argo CD Notificationsをサクッと試してみたものの、コンテナのログの内容を通知するようなものではないことがわかりました。それに気づいてからAIに問うと、「確かに今回の目的では適していなかったかもしれません」と。
他の案も検討しましたが、ひとまずファーストリリース段階ではJobを自動で消さないようにする、というシンプルな方法を採用しました。実行ログ自体も「〜〜〜サーバに配布完了」のような簡素な出力だけだったため、平常時ではログを見に行くケースは少ないだろうという判断もあります。
このように、生成AIは常に完璧な答えを提示するわけではありません。しかし、多様な選択肢を示し、試行錯誤のハードルを劇的に下げてくれることで、私たちの問題解決能力を拡張してくれる。そんな「優秀なアシスタント」であることは間違いないでしょう。
成果と効果の検証
今回の取り組みで、開発プロセスと日々の運用の両面で、大きな成果を得ることができました。
開発工数の大幅な削減：10人日から4人日へ
まず特筆すべきは、生成AIの活用による開発工数の大幅な削減です。
もし今回、生成AIを一切使わずにゼロから設計・実装していた場合、およそ10人日程度の工数を見込んでいました。しかし、実際には4人日で開発を完了できました。
これは、設計の初期段階でAIが多様な選択肢を提示してくれたこと、そして実装段階でコードの雛形を素早く生成してくれたことが大きく貢献しています。従来であれば、調査や試行錯誤に多くの時間を費やしていたであろう部分を、AIとの対話で高速に、かつ納得感を持ちながら進められました。
レガシー改善の心理的ハードルを越えて
10年以上続いた運用を新しい仕組みに切り替える作業には、技術的な難しさだけでなく、「本当に安全に移行できるのか」という心理的なプレッシャーが伴います。
この点においても、生成AIは大きな助けとなりました。新旧のcron設定に差分がないか、意図せぬ変更が加わっていないかを確認するためのチェックスクリプト作成をAIに依頼しました。これにより、移行作業の安全性を客観的に担保でき、私たちは自信を持ってリリースに臨めました。
「何から手をつければいいか分からない」「失敗が怖い」といった、レガシー改善にありがちな心理的ハードルを、AIが取り払ってくれたと言えるでしょう。
cron登録作業の抜本的な改善
そしてもちろん、本来の目的であったcron登録の運用も劇的に改善されました。
上の図が示すように、従来のフローではデプロイスクリプトの実行やパスワードの準備など、複数の手動作業が必要でした。一方、新しいフローでは、開発者がGitHubに設定ファイルをプッシュするだけで、残りのプロセスはすべて自動で実行されます。
これにより、以下のような効果が生まれています。
- 定量的な改善効果: 1回あたり約10分かかっていた作業が、実質0分になりました。
- 定性的な改善効果: 事前のパスワード準備や、手順書を見ながらの作業といった手間が一切なくなり、誰でも、気兼ねなくcronの登録・変更ができるようになりました。
横展開への広がり
この新しいcron登録システムは、SREチーム内だけでなく、他チームのエンジニアからも「ぜひ使いたい」という声が上がっています。一部のチームではすでに関心を持ってくれており、今後の全社的な生産性向上にも繋がる、大きな可能性を秘めた成果となりました。
今後の展望
今回の成功体験を通じて、私たちは「生成AIを活用すれば、これまでコスト対効果が見合わないと後回しにしてきたレガシーな繰り返し作業も、少ない工数で改善できる」という確信を得ることができました。
SREチームが抱える同様の課題は、まだ他にも存在します。今後は、今回のプロジェクトで得た知見と勢いを活かし、それらの改善にも積極的に取り組んでいきたいと考えています。
生成AIという強力な相棒と共に、私たちはこれからも食べログのサービス信頼性向上と、エンジニアの生産性向上に貢献していきます。
Kubernetesリソースのアイコンは、Apache License Version 2.0に基づいて使用しています。 Kubernetesの名称およびロゴは、米国およびその他の国における The Linux Foundation の商標です。 Argo CDの名称およびロゴは、米国およびその他の国における The Linux Foundation の商標です。 GitHubおよびGitHubのロゴは、GitHub, Inc.の商標です。
