はじめに

本記事では私が約３年程携わっているシステムをGKEからCloud Runへ移行した際の話をまとめたものになります

Cloud Runについて

公式によると Cloud Run は、サーバーレスのコンテナ化されたマイクロサービスをデプロイしてスケールするためのフルマネージドコンピューティング環境です。 とのことです
https://cloud.google.com/blog/ja/topics/developers-practitioners/cloud-run-story-serverless-containers

ここではCloud Runの導入に至った動機、背景を書き記しました

兎にも角にも やってみたかった これに尽きます
勿論これは仕事なのでそれだけでなく後述する理由やメリットを揃えた上で進めました

ここではCloud Runが適していると考えられる事柄を揃えました

ここではCloud Runにすることで得られるメリットを揃えました

コストダウン
休憩時間が長いので従量課金制と相性が良いはず
kubernetesからの卒業
deploymentなどお約束的に用意していた定義ファイル達から卒業
kubernetes clusterのアップデートによる影響を受けない->これが一大イベントになることがある
セキュリティの向上
2021年春先にCodecovでの不正アクセスの問題があったこともあり(我々のチームは使用しておりませんでした)セキュリティ向上の機運が盛り上がったのでこの際に放置していたコンポーネントにも手を入れようと

ここではセキュリティについて心がけた事、やった事について書き記しました

トリガーにて認証が必要をチェックすることでクライアントがコンテキストにrun.invokerを有したサービスアカウントにて発行したトークンをセットして送らないとエラーとなります
本システムではコンポーネント間の通信は全てgRPCを用いているので以下を参考に実装しております
https://cloud.google.com/run/docs/triggering/grpc?hl=ja#request-auth
https://cloud.google.com/run/docs/triggering/grpc?hl=ja#connect

ここではGKEで動かしているサービスたちをCloud Runに切り替えていった際の手順を書き記しました

service-a、service-b、service-cがGKE上に存在しています
これらをservice-c、service-b、service-aの順にCloud Runへ移行していきます

service-cをCloud Runに移行します
service-a、service-cはservice-aに対するrun.invokerを与え、gRPCクライアントのコネクション、認証付きリクエストの修正をします

service-bをCloud Runに移行します
service-aはservice-bに対するrun.invokerを与え、gRPCクライアントのコネクション、認証付きリクエストの修正をします

service-aをCloud Runに移行します

GKEからCloud Runへの置き換えを進めた結果、システムコスト(Compute Engine部分)が**51.81%**の削減を実現しました

人柱になれた
サービス全体をサーバーレスで組むというのはまだやっていなかったことなのでこのような事例を作ることができたので今後の選択肢を増やせたので良かったです
リプレイスならその効果を計るための計測方法を用意する
このCloudRun導入にはコスト削減の狙いもあったのでその成果をアピールよできるよう導入前後でその効果を測るための計測方法を用意しておくべきでした
特に導入前はそれを進めてしまうと戻すこともできない場合があるので以前の状態を机上で算出することになるので細かい内訳等下調べは重要です
ビジネスサイドへの説明は定量的な数字に落とせないと伝わり難いのでここを意識して行くよう心掛けます
一人で出来るとしても周りを巻き込んだ方が良い
このCloudRun導入は一人で細々と進めていたこともあり周りには詳細な事は共有せずにおりました
そのような状態ですと詰まった時、悩んだ時、意見を求めたい時に今までの経緯から説明しなければならなく相談相手として機能する状態にするまでに手間と時間が掛かってしまいました
なので多少なりと良い意味で周りを巻き込んでいくことは大事だと思います