Gaudiy Tech Blog

Gaudiyの技術、開発組織、カルチャーについてお伝えするブログです

Kubernetes初学者が担当したGKE移行プロセスの全貌

はじめまして。Gaudiyでエンジニアをしているあんどう（@Andoobomber）です。

クラウドネイティブ全盛の世の波に乗り、この度 Gaudiy では Cloud Run から Google Kubernetes Engine (GKE) への移行を行いました。

この記事では、その移行プロセスの全体像を共有し、得られた教訓と今後の展望を探ってみたいと思います。

1. Before After: 移行の概観

1-1. Before

Before

以前までの構成は、

  • マイクロサービスの実行環境として Cloud Run を使用
  • 監視ツールにはGCPの Cloud Monitoring, Cloud Logging, Cloud Trace を使用
  • Pub/Sub→マイクロサービス間に API Gateway を経由
  • アプリケーションのデプロイは Github Actions が行う

といった感じでした。

1-2. After

現在の構成は、

  • マイクロサービスの実行環境としてGKEを採用。1つの Cluster 上で全てのサービスを動かしています。
  • 監視ツールにはDatadogを採用し、OpenTelemetry Collector経由でテレメトリーデータを流しています。
  • Pub/Sub→マイクロサービス間にESPv2を経由。
  • アプリケーションのデプロイはArgo CDが行い、Github Actions がArtifact Registryに push した Image を Argo CD Image Updater が Watch し、Cluster にデプロイしています。

といった感じに変わりました。

2. なぜGKE環境に移行したのか

移行に至った経緯は様々あるのですが、主に↓の3つが理由です。

  • クラウドネイティブな技術選択をしたい
    • CNCF Projectsをはじめとする、コンテナ技術の最新トレンドを採択したい
    • Kubernetes Controller で自由に機能拡張できる
  • Ops 起因で重要な目的があった
    • これが大きな理由だったのですが、機密情報に当たるので申し訳ないですが詳細は伏せさせていただきます
  • 機械学習関連でマシンリソースを選びたかった
    • Gaudiyではレコメンドエンジンなど、AIにも注力しており、通常サーバーとは異なるマシンリソースが必要になった

3. 移行のプロセス

普通なら移行計画を立ててKubernetes(k8s)に移行していくところですが、僕はk8s未経験であり前提知識も全くなかったので、k8sを学ぶことから始めていきました。

3-1. Kubernetesを学ぶ (1週間: 2023/10/01~)

Kubernetes完全ガイド 第2版を読んでサンプルアプリを作ってました。これが無かったら移行完了までのスケジュールは大きく変わっていたと思うくらい良書でした。

この時に、DeploymentやServiceなどのk8sオブジェクトを理解するとともに、ライフサイクルやエコシステムなども学んでいきました。

3-2. Dev on GKE環境作成 (2-3週間)

FanlinkのアーキテクチャはFE → Load Balancer → BFF → BE(micro services)という構成になっており、今回は Load Balancer 以降を GKE に全く同じ環境を作成して、FEの向き先を変えて移行することにしました。

GKE環境を作る際に様々な技術を使用しましたが、1つずつ書いていくと書ききれないので、以下にやったことを抜粋して記載します。詳細は割愛しますが、後に別記事としていくつか公開する予定です。

  • Cluster の作成
  • 各マイクロサービスのKubernetesオブジェクト定義
    • サービス: 27個、cronjob: 8個ほどありました。
  • External Secrets の使用
    • Secret Managerを参照するため使用。
  • OpenTelemetry Collector の使用
    • テレメトリーデータをOpenTelemetry Collectorに集約させて、まとめて Datadog にexportしています。
  • Gateway API の使用
    • つい先日GAとなったKubernetes Gateway API を使って、Load Balancerを管理しています。
  • ESPv2 の使用
    • REST から gRPC へのトランスコーディングとして、Envoy ベースの ESPv2 を使用しています。
  • Argo CD の導入
    • k8s リソース管理及びCDとして、Argo CD を採択しました。
  • etc…

3-3. Staging on GKE環境作成 (2日)

基本的には環境変数の変更で、Devで作成したyamlをStagingも同じように作っていくだけなのでそこまで難しくはありませんでした。

この時、開発チームへGKE環境に触ってもらう・受け入れテストのお願いをアナウンスしました。

3-4. Private Clusterへの移行 (1-2週間)

今まではデフォルトの設定で Cluster を作成していましたが、Private Cluster にすることでコントロールプレーンとノードに対して外部アドレスを割り当てなくする(≒よりセキュアにする)ことができると知り、Stating/Prod 環境は Private Cluster で建てることにしました。

  • GCPリソースのTerraform化
    • GKE Cluster
    • Network / Subnetwork
    • Firewall
    • etc…
  • Tailscale Operator 導入
    • Private Cluster の操作を Tailscale Network 経由で行うようにしました。
  • Private Clusterでの環境再作成
    • コントロールプレーンのパブリックエンドポイントアクセスを無効にして、よりセキュアな Clusterへと変更しました。

3-5. Prod on GKE環境作成 (2日)

こちらもStaging同様にyamlを複製し、Prod用の環境変数を割り当てる程度なのでそこまで難しくはありませんでした。

ただし、cron処理やoutbox patternが存在したので現行の環境に影響を与えないように気をつけながら作業を行っていきました。

3-6. 負荷試験・受け入れテスト (1週間)

Staging環境を作成した段階で、開発チームへのアナウンスや負荷試験をProd環境作成と並行して行っていきました。

最後の大詰めとして以下のような作業をコツコツと進めていきました。

  • バグの解消
    • 環境変数や外部サービスとの通信部分で特にバグが起きました…
  • Pod/Nodeリソース・スケール値の設定
    • Grafana k6で負荷試験をして、想定負荷に必要なリソースを計算しました。幸い、瞬間的に同時アクセスが大量に走るような複雑なサービスではないので、ある程度の負荷を余裕もって耐えれる位の設定値にしました。
    • ただ、それでも単一Podだと落ちた時が怖かったので複数Podをminimumとし、負荷試験に耐えられる位をmaxとして設定しました。

3-7. リリース(2023/12/04)

2023/12/04の深夜にCloud Run環境からGKE環境にSwitchしました。移行後から1週間くらいは異常が起きないかモニタリングを続けましたが、特段大きな問題はなくアプリケーションが稼働していたのでホッとしました。

4. 移行後の感想

4-1. 良かった点

  • おおよそ2ヶ月でk8s環境へ移行できた。
    • 経験者の知見もいただきながらですが、初学者ながらわりと順調に進めることができたと思います。
  • 最新のクラウドネイティブ技術への追従ができる。
    • CNCF Projectsに登録されているプロジェクトを見て活かせそうなツールがないかみるのが最近楽しいです。
  • リソースの調整
    • 機械学習系のマシンが使えるの嬉しい。
  • レスポンスタイム向上
    • 全体約200msほど
  • Datadogに移行したこと
    • 高機能でかなり使いやすいです。今後のSRE業務に拍車がかかりそうです。

4-2. 課題点

  • k8sの学習コストが高い
    • k8sへの完全移行は達成したものの、k8s APIやらeBPFなど学ぶことがいっぱい。まだまだこれからだなと感じています。
  • 運用コストも高い
    • 学習コストに近いですが、定期的なk8sのアップデートやCSP(クラウドサービスプロバイダ)の知識がないとアプリケーションを落としかねないので、運用は簡単とは言えなさそうです。
    • また、適切なリソース設定をしないと費用面でも無駄なコストがかかってしまいます。

5. 今後の展望

現在は最小構成のk8s環境で動いているので、様々なクラウドネイティブ技術を積極的に試していきたいと考えています。

  • Ciliumの導入
  • eBPFの調査
  • Flux (GitOps)
  • Kubernetes Custom Controller 作成
  • Config Connector

6. 結論

Kubernetes移行はかなり大変でしたが、Gaudiyのビジョンに向けたソリューションと技術的な野心を反映した、意義深い変革の一歩だったと思います。

クラウドネイティブ技術の進化に伴い、より良いサービスとソリューションを提供するために、今後もアップデートを続けていきたいと考えています。

この領域に知見のある方や、Gaudiyでのプロダクト開発に興味のある方がいたらぜひお話ししましょう！

site.gaudiy.com

site.gaudiy.com