はじめに
SREの大橋です。Assuredでは、開発プロセスの効率化を目的としてPull Requestごとに利用できるPreview環境を導入しました。そのインフラ選定にあたり、既に利用しているGKEを拡張する案と、サーバーレスのCloud Runを採用する案が挙がり、最終的にCloud Runを選択しました。
そもそもPreview環境とは？
Preview環境とは、Pull Requestごとに動的に生成される独立したアプリケーションの実行環境で、コード変更を即座に確認できるため開発スピードの向上に繋がります。PRレビュー時に実際のアプリケーションを動作させながら確認できるため、QAエンジニアやデザイナー、プロダクトマネージャーなどエンジニア以外のメンバーも動作を確認しやすいので、様々な観点でのレビューが効率化できる利点もあります。特にAssuredにおいては、クラウドサービス利用企業様、クラウドサービス提供企業様など複数のお客様に対応するモジュールが存在するため、個別に環境をセットアップすることで検証コストを下げられる他、スクラム開発における受け入れ条件を検証する上でも効率化が期待できます。
GKE案におけるコストの非効率性
まず、既存のGKEクラスタを拡張してPreview環境を構築する案を検討しましたが、コスト面の課題が大きな障壁となりました。例えばGKEのノード（e2-standard-4）を追加する場合では、月額で約$127.97の固定費が発生します(執筆時点での試算)。
Preview環境はレビューやQAなど一時的に使われることが多く、稼働しない時間帯も少なくありません。そのため、リソースを常時確保し続けるGKEの課金モデルだと非効率であると判断しました。
Cloud Runでネットワーク疎通とセキュリティの担保
これに対し、Cloud RunでPreview環境を運用すればコストを非常に低く抑えることができます。しかし、GKEを前提としたシステム構成をそのままCloud Runに適用するためには、ネットワークをどう設計するかという問題があります。
セキュリティ観点から、Cloud SQLを始めとしたインフラリソースは基本的にVPCの内部にあり、外部ネットワークからは遮断されています。GKEはVPCに配置できるため、難なくインフラリソースを利用できますが、サーバーレスであるCloud Runは事情が異なります。
しかし、Cloud Runには外向きの通信(egress)にVPCを設定できる機能が提供されているため、難なく既存のインフラリソースと接続することができました。また、Cloud Runへのアクセスも内部ALB(アプリケーションロードバランサ)に限定できるため、Cloud Armorのポリシーと紐づけて特定のIPアドレス範囲に制限することができます。
これらの設定により、VPC内部のリソースに接続しつつ、外部からのアクセスを制限することができました。
GitHub Actionsによる自動化
Cloud Runでも問題なくシステムを構築できると判断できたので、プロビジョニングと破棄のフローをGitHub Actionsで自動化しました。
具体的なフローは以下の通りです。
起動
開発者がPull Requestを作成し、特定のラベルを付与すると、GitHub Actionsのワークフローがトリガーされます。Cloud Run上にサービスがデプロイされ、環境固有のURLが払い出されます 。
停止
Pull Requestがマージまたはクローズされると、別のワークフローがトリガーされ、デプロイされたCloud Runサービスと関連リソースを自動的に削除します 。
導入してどうなったか？
前述した通り、開発のスピードおよびレビューの効率が大きく向上しました！直近QA体制を構築していたり、スクラム開発が加速していたりする中で、エンジニア以外でも手軽に成果物を確認できる状態となり、利便性が大きく上がりました。
また、フロントエンドライブラリのアップデートや画面のリファクタリングなど、画面の確認が都度必要となるケースでも並列して作業を進めやすくなりました。
まとめ
Preview環境を構築するにあたり、GKEとCloud Runを比較検討した結果、技術的な課題をクリアしたことで、コストと運用効率のメリットを享受できるようになりました。同様の技術選定を行うプロジェクトの参考になれば幸いです。
