[レポート] 食べログでの Google Cloud: 新規サービスを少人数で迅速にローンチする #GoogleCloudDay

Google Cloud Day: Digital ’22 のセッション「食べログでの Google Cloud: 新規サービスを少人数で迅速にローンチする」のレポートブログです。
2022.04.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。CX事業本部MAD事業部のYui(@MayForBlue)です。

Google Cloud Day: Digital ’22」が2022年4月19日~21日に開催されました。
本ブログはイベント内のセッション「食べログでの Google Cloud: 新規サービスを少人数で迅速にローンチする」のレポートブログです。

セッション概要

概要

新規サービス「食べログ テイクアウト」はインフラも含めたバックエンドは二人という体制でありながら、迅速にローンチする必要がありました。 Google Cloud を利用することでそれをどのように実現したのかをご紹介いたします。 また、食べログでの Google Cloud の活用事例についてもお話いたします。

取り上げる主な Google Cloud 製品 / サービス

  • Kubernetes Engine (GKE)

スピーカー

株式会社カカクコム 大石 司 さま

食べログテイクアウトで Kubernetes を採用した理由

食べログテイクアウトについて

  • 食べログがはじめたテイクアウトサービス
  • 今回のセッションは2019年ローンチ当時のお話

食べログの課題

  • 食べログが Rails 化してから15年
  • 長い歴史の中でレガシーな部分が出てきたり課題が浮き彫りになった
  • 課題は無数にあるがまずはインフラを改善したかった
  • アプリケーションを安全に変更できる基盤として Kubernetes に注目した
    • コードでのインフラ管理
    • 自律的に動いてくれる安心・安全性
    • コンテナを利用することによる運用のしやすさ

採用理由

  • 食べログ自体は Kubernetes を採用したことがなかった
  • 大きなサービスで試す前に「食べログテイクアウト」に導入して試すことにした
  • ローンチまでのインフラ面での人員的なコスト削減も叶えたかった
  • GKE を採用
  • Google Cloud の他のエコシステムに乗れることもメリットだった

Google Cloud を使ってローンチするまで

  • 開発開始からローンチまでだいたい3ヶ月くらい
  • エンジニアの構成はインフラ、バックエンド、モバイルアプリが各2名、フロントエンドが4名
  • 技術的な判断をする上でのポイント
    • Kubernetes を運用する上での知見を得られるか
    • インフラ面での人的コストを削減してビジネスに注力できるか

システム構成

  • 特殊なことをせずシンプルな構成になるように意識した

Kubernetes 周りの構成

  • ログ・モニタリング周りを Google Cloud のサービスと連携して管理できたのが良かった
  • Cloud SQL , Memorystore なども含めて Google Cloud に寄せることで運用コストを下げられた

Cloud NAT の利用

  • 外部API(食べログのAPI)は認証とIPアドレス制限がかかっている
  • アクセス元のIPを固定したかった

食べログテイクアウトの構成

  • データベースについてはサービスごとに分ける検討もしたが、参照するデータがほとんど同じであること、運用コストを考慮してひとつのデータベースにした

Kubernetes の構成

  • Pod の設計はひとつの Pod にひとつのコンテナがオーソドックス
  • それぞれのサービスで必要になるコンテナをひとつの Pod におさめた
    • Kubernetes の構成要素を減らして運用を楽にしたかった
    • 関係するコンテナをひとつの Pod 内におさめることでコンテナ間の連携が楽になる
    • スケールしにくいというデメリットはある

非同期処理

  • Cloud Functions を検討
    • Ruby がサポートされていなかったのが懸念点だった
    • Kubernetes 化を見据えた中でメリットがあるか?
  • 慣れている sidekiq を採用

CI / CD パイプライン

  • CI ツールは慣れている CircleCI を採用
  • CD ツールを当初導入しなかったが今考えるとコストをかけてでも最初から導入するべきだったと考えている
    • ソフトウェアデリバリーは組織のパフォーマンスや開発生産性に大きな要因を持っている

新規サービスに Kubernetes / GKE を採用した結果

  • インフラまわりに割く人的リソースを削減できた
  • Kubernetes での運用の最初の知見を得ることができた

食べログでの Google Cloud の活用事例

  • Cloud Logging / BigQuery によるアクセスログの解析
  • Trace によるサービス間のリクエストの可視化
  • BigQuery によるデータ分析基盤の構築

まとめ

  • 短期間でのプロダクト開発で Google Cloud を利用することで大きなアドバンテージを得ることができた
  • 技術的なチャレンジをすることは組織に重要な価値をもたらすと感じた

Q&A(抜粋)

Q. 運用周りの Tips があれば教えてください
A. Google Cloud をベースに利用している中でこれまで大きなトラブルはなかった。Kubernetes に関してソフトウェアデリバリーの部分はとても重要だと感じている。

Q. SRE 周りはどのように行なっている?
A. 食べログは専門のSREチームがいる。食べログテイクアウトに関してはチーム内でアプリケーションエンジニアが行なっている。プロジェクトやチームの規模で動き方を変えている。

Q. Kubernetes のキャッチアップはどのように行なった?
A. 最初に勉強しようとすると専門用語が多くて大変だと感じる。
「Kubernetes クラスターを運用するスキル」「Kubernetes 上で動かすアプリケーションを運用するスキル」のうち後者をどうキャッチアップするかに注力した。ステップとして CKAD 取得をマイルストーンにして勉強会をチーム内で開いたりした。

Q. 短期間でのローンチに成功した秘訣は?
A. インフラ面だけではなく企画立案〜機能開発を考えたりする中でエンジニア、デザイナーを含めてひとつの目標に向かえたのは大きかった。
インフラ面がひとつの要因としてコミットしたことは確かだが、他の要素もある。安心して使える Google Cloud のマネージドサービス、プラットフォームがあったのは大きい。プロダクトとして「何をやらないか」をきちんと考えるのも重要。

Q. 内製化で気をつけていることがあれば
A. サービスを立ち上げるときに内製以外の選択肢をあまり考えていない。外部委託した場合に一旦ローンチまではできるかもしれないが、継続してサービスを提供する立場として運用面や組織内で技術をつないでいくことを考えた場合に内製が一番だと考えるため。
サービスを内製で運用し続けていくことに関しては技術や知識の伝播は継続してやっていかないといけないと考えている。

感想

Kubernetes / GKE の利用事例だけではなく、プロダクトに新しい技術を取り入れる際の姿勢や考慮するべきポイントなども学べるセッションでした。
また、技術周りに加え、少人数かつ短期間でプロダクトのローンチを成功させ、運用していくノウハウなど参考になるポイントが盛りだくさんでした。

アーカイブが公開されていますので、気になった方は視聴してみてはいかがでしょうか。

以上、CX事業本部MAD事業部のYui(@MayForBlue)でした。