InnovatorLiveJapan 【現場の本音】でお話ししてきました

2022/02に入社してから１年半くらいインフラっぽいことを網羅的にやってます。坂本です。 Developer Productivity Engineering (DPE)チームに所属しています。

インフラのお仕事をしてる関係でGoogleさんにお声かけていただき、 GoogleさんのオンラインイベントInnovatorLiveJapanに参加させていただき少しお話ししてきました。

資料はこちら。docswellさんに置かせてもらっております。

https://www.docswell.com/s/5798552758/ZGXQYQ-2023-07-08-082923

概要

資料のあらすじです。

前提
- 創業時に作ったシステムは2020年当時大きな二つの問題を抱えていた
  - Python2系であること(GCPの温情でサポートしてくれてはいるが...いつ切れるかわからない)
  - GAEで動いておりデグレを起こしやすい状態のコードだった
- 問題を解決するべくGAE standardからCloudRunへの移行を進めています
  - インフラ担当を 引き継ぎ 対応を進めています
- Python2系のEOLに伴う今後の進め方の軌道修正などが発生したため一旦振り返ってみた
結論
- 以下の結論はあくまで引き継いだ第三者視点であり、自分が計画立案する立場だった時に今から出す結論を発想できていたかは甚だ怪しい。
  - 二つある問題(Python2系であること、GAE一つでデグレを起こしやすい)を一気に片付けるのではなく、普段のリリースと同じくリリース単位をなるべく小さくする考え方を採用するべきだった。
    - SRE プラクティスを促進させるための 4 つのステップ | Google Cloud 公式ブログにある通り、「小さく初めて繰り返す」
  - 「Python2系であること」と「GAEの1インスタンスでデグレを起こしやすい」ことの解決を混ぜてはいけなかった。
    - 優先するべきは「Python2系であること」の解決。

以下詳細

移行前の状態

GAE standard 一つで管理画面・ユーザ向け画面二つのすべてをサービス提供していた。
- 開発時のデグレがあった
- 使っていたPythonのバージョンが2.7系だった

これをなんとかするためにリニューアルの話が持ち上がった。

移行後の第一段階のゴール

管理画面・ユーザ向け画面にそれぞれCloudRunのインスタンスを一つずつ割り当てる。(DBの分割は後)

進めてみた結果

社内の都合で開発チームが分かれているので、進め方に関しては各チームに一任という形になった。(着手のタイミング・人数構成の違いなど)

	チームA	チームB	チームC
事情	人数が少ない	機能が複雑で移行対象も多い	社外ユーザが触るので修正しやすくしたい
アプローチ	アーキテクチャそのまま移行	リファクタリングが必要な部分はしながら移行	アーキテクチャーを一新
アプローチ	Python の version up
苦労した部分	Pythonの version upはそこまでではなかったサービス分割による呼び出し方法変更によるコスト増	粛々と移行中リファクタリングする場合はそれなりに時間がかかっている	ゼロからの構築のため時間がかかる Python2.7 のEOLによるサポート停止発表(移行スケジュールの見直し)
苦労した部分	サービス間連携の認証の仕組み CloudRun idleからactive復旧時のtimeoutの対応 Network Endpoint Group の timeout が30秒だった当時の設定を引きずり、CloudRun の timeout も30秒にしてしまってた立ち上がりに30秒近くかかる作りだったので timeout 多発立ち上がりのチューニングが難しく、CloudRun の min/max instance を適切に設定することで対応 Network Endpoint Group の timeout が60分に変わっていることを認識し、 CloudRun の timeout も60分に変えて無事安定

GAEからCloudRun に移行・分割してよかったこと

すべて同じ設定でインスタンスが起動していた状態からサービス特性毎にチューニングが可能になった。
- 例
  - サービス
    - 外向き : AlwaysCPU
    - 内向き : 通常(業務時間外はidle)
  - 負荷の違い
    - 高負荷のものはCPU/memory を潤沢に <=> 低負荷のものは最低限に

CloudRun 移行による変化

分割によるデグレードの抑制
負荷の違いを考慮してサービス毎に CloudRun を複数持つようにした
- 設定・deploy時間の高速化など改善余地あり
  - 同一のイメージを使う・統合できるCloudRunは統合する
- 分割したことによりアーキテクチャに変更がかかり移行作業が増えてしまった
  - 元々1インスタンスだったので画面とAPIでモジュールの共有を前提とした作りになっていたが、その前提が崩れてしまったところもあった

CloudRunの移行と分割についての整理

メリット
- チーム毎の都合の良いタイミングで着手できる
- 先行チームのノウハウを後続チームが活かせる(terraform の設定を流用することもできた)
デメリット
- Python2.7 のEOLによるGAEのサポート停止の影響で移行プランの再検討が必要になった
- 分割により移行作業が想定より複雑になった

分割したこと得られたメリットも大きかったがそれ以上にデメリットの方が大きくなってしまったように思える。

どうすればよかったのか？

SRE プラクティスを促進させるための 4 つのステップ | Google Cloud 公式ブログにある通り、「小さく初めて繰り返す」必要があったかもしれない。具体的にいうと、以下のようにサービスにより影響の大きい「GAEからの脱却」を優先し、分割せずにGAEに移行するのがよかったのではないかと思われる。(分割するのはその後。)

※GAEからの脱却の方が影響が大きい理由は、サポート期限が来たらリリース自体が手軽にできなくなるため。

ランタイムライフサイクル | Google App Engine スタンダード環境のドキュメント | Google Cloud

ランタイムサポートのスケジュール | Google App Engine スタンダード環境のドキュメント | Google Cloud

振り返りししてみて気がついたこと

スケジュール通りに行くのが一番良いが、計画当時考慮できていないために軌道修正が必要になるケースはあり得る。
- 大きいプロジェクトでは特にそうだが、問題があると思った時にゴールをぶらさないように立ち止まって軌道修正をきちんとするべき & 大事になる前に相談。
- 小さく始める時に、どう小さくするか(文脈の違うものを同時リリースしない話と、影響範囲を小さくする話の二軸がある)が大事。
こういう違和感を気がついた人が発言できるように自主性を育てることや、発言しても大丈夫(取り込んでくれる)というチームづくり(雰囲気づくり)が大事。
- それを自分ができているのか、については気をつけているつもりだが至らないところも多いと思うので常に気を付けていきたい。

VisasQ Dev Blog

ビザスク開発ブログ