GKEからCloud Runへの移行事例

参考になった

レビュー投稿日の情報になります

株式会社HRBrain / 東島史弥

メンバー / SRE / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名

最終更新日2024/09/18投稿日2024/09/18

ツールの利用規模	ツールの利用開始時期	事業形態
51名〜100名	2023年7月	B to B

ツールの利用規模	51名〜100名
ツールの利用開始時期	2023年7月
事業形態	B to B

アーキテクチャ

アーキテクチャの意図・工夫

ロードバランサーと接続するCloud Run（フロント、APIゲートウェイ）はロードバランサーと同じプロジェクトに配置し、APIゲートウェイより後ろのサーバー側はマイクロサービス単位でプロジェクトに配置しています。

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

もともと、HRBrainではアプリケーションのワークロード基盤としてKubernetes（GKE）クラスタを使用していました。しかし、定期的なクラスタアップグレードやKubernetesのマニフェスト管理など運用・管理の煩雑さに見合うだけのメリットを十分に享受できていない状況でした。

どのような状態を目指していたか

Platformチーム・エンジニア双方の開発時のオーバーヘッドを軽減し、エンジニアがよりハイスピードなマイクロサービス開発を推進できる状態を目指しました。

比較検討したサービス

GKE Autopilot

比較した軸

運用・管理のための時間を削減できること
私たちの組織でKubernetesを使ってやりたいことがあるか

選定理由

開発者が開発に集中できること
運用・管理の容易さ

導入の成果

どのような成果が得られたか

定期的なクラスタアップグレードが不要になり、クラスタ運用をしていたPlatformチームが他のことに時間が使えるようになりました。プロダクト開発に携わるエンジニアも環境変数やCPU,メモリなど関心のある項目を定義するだけで良くなり、アプリケーション開発に時間を使えるようになりました。

導入時の苦労・悩み

全てのサービスをGKEからCloud Runに移行したので移行方針や手順の作成に苦労しました。

導入に向けた社内への説明

上長・チームへの説明

Cloud Runを使用することでの費用的メリットや運用負担、移行方針や既存機能への影響などについて説明しました。また、GKEからCloud Runへの移行負担を軽減するため、可能な限り２つのプラットフォームで同一のDockerイメージを使用できるように移行方針を作成しました。

活用方法

よく使う機能

リビジョンタグ

リビジョンタグを付与することでプルリクエスト上でプレビュー環境を構築しています。

ツールの良い点

フルマネージドサービスなので管理から解放され、アプリケーション開発に集中できる
インスタンス数がゼロまでスケールインされ、コスト効率が高い
YAMLで宣言的な構成管理ができる
リビジョンにタグをつけることで、簡単にトラフィックを切り替えることができ、プレビュー環境の構築がしやすい

ツールの課題点

KubernetesのDeploymentとは異なり外部に開放されるポートは実質的に 1 つ（443 HTTPS）のみになる
push型のGitOpsが主流で、pull型のGitOpsを支援するメジャーなツールがない
Cloud Runがtraceparentに常に介入してしまうのでon/offを切り替えできるオプションが欲しい

ツールを検討されている方へ

Cloud Runは非常に使いやすく、簡単に始めることができます。一方、KubernetesのCRDとカスタムコントローラーのようなカスタマイズ性は提供していません。このため、システムに適したワークロードの選択が重要であり、Cloud Runの特性を理解し、そのメリットを最大限に活かせるようなユースケースに適用することが求められます。

また、本格的な運用フェーズに入ると、効率的な管理方法が課題となります。その時、おすすめなのが宣言的に管理できるYAMLまたはTerraform ＋ gcloudコマンドの２つの方法です。これらの方法を適切に選択することで、一貫性のある管理が可能となります。