Google Cloud Run으로 저렴하고 쉽게 스프링부트 서버 운영하기

많은 분들이 소규모 사이드 프로젝트에서 Spring Boot와 AWS EC2를 사용하여 백엔드 애플리케이션을 배포하시곤 합니다. EC2는 프리티어 스펙인 t2.micro를 사용한다는 가정하에 프리티어 기간이 끝나면 매 달 약 25,000 원을 지불해야하는 서비스로, 가난한 학생 개발자들이 쓰기에는 부담 될 금액입니다.

Google Cloud Platform에는 이러한 비용 문제를 해결할 수 있는 서비스가 존재합니다. Google Cloud Run은 서버리스 컴퓨팅 인스턴스를 제공해주는 서비스로, 쉽고 빠르게 애플리케이션을 구축하고 배포할 수 있도록 도와줍니다. 

GCR은 Pay-as-you-go (사용한 만큼 지불) 과금 방식을 갖습니다. 배포 이후 서버에 요청이 들어온다면, 그제서야 부랴부랴 서버 인스턴스를 생성하고, 일정기간 요청이 없었다면 인스턴스를 자동으로 종료합니다. 이를 통해 정말로 사용하는 시간에 대해서만 인스턴스 비용을 지불할 수 있게 되어 EC2와 같은 서비스에 비해 저렴하게 운영할 수 있습니다. 또한 로컬 개발 환경으로부터 하나의 명령어만 수행하면 배포가 완료되며, 별도의 https 설정이나 도메인 구입을 할 필요도 없다는 장점도 존재합니다.

Google Cloud Run으로 스프링부트 배포하기

이 섹션에서는 GCR을 사용하여 스프링부트를 배포하는 절차를 단계적으로 설명합니다.

1. Google Cloud Project 생성

Cloud 관리 콘솔 | Google Cloud

콘솔에서 데이터 분석, VM, 데이터 스토어, 데이터베이스, 네트워킹, 개발자 서비스 등 클라우드 애플리케이션의 모든 것을 관리하세요.

https://cloud.google.com/cloud-console?hl=ko

내 콘솔로 이동 ->  새 프로젝트 버튼을 눌러 프로젝트 이름과 결제 정보를 기입하여 프로젝트를 생성합니다.

2. 로컬에 gcloud cli 설치 및 기본 세팅

gcloud CLI 설치  |  Google Cloud CLI Documentation

https://cloud.google.com/sdk/docs/install?hl=ko

위 문서를 참고하여 로컬 컴퓨터에 gcloud cli를 설치합니다. 

설치가 완료됐다면, Cloud Run 서비스를 사용할 기본 프로젝트를 설정해줍니다.

프로젝트 ID는 콘솔에서 확인할 수 있습니다.

이후 Cloud Run Admin API 와 Cloud Build API에 대한 사용 설정을 진행해줍니다. 터미널에 다음 명령어를 입력합니다.

3. 스프링부트 프로젝트 생성

Spring Initializr 혹은 cli를 통해 스프링 프로젝트를 생성해줍니다.

4. project.toml 생성

스프링 애플리케이션의 루트 디렉터리에 project.toml 이라는 이름의 파일을 만들어 아래 내용을 작성해줍니다.

name =  "GOOGLE_RUNTIME_VERSION"
value = "21" <-- 스프링 프로젝트 생성 시 설정한 자바 버전을 기입

5. 배포!

애플리케이션의 루트 디렉터리에서 다음 명령어를 사용하여 애플리케이션을 배포합니다. app-name에는 배포될 컨테이너의 이름을, region에는 인스턴스를 위치시킬 지역을 지정해줄 수 있습니다.

6. 완료 및 테스트

컨테이너 빌드 및 배포가 끝나면, 터미널에 url 하나가 뜹니다. 해당 링크가 gcp에서 자동으로 생성한 애플리케이션의 배포 링크로, 해당 링크를 통해 접속하여 잘 동작하나 확인해볼 수 있습니다. 배포된 컨테이너에 대한 로그 및 자세한 정보는 Cloud Run 콘솔에 접속하여 확인할 수 있습니다.

There is No Silver Bullet

비용을 아끼는 만큼 몇가지 고려해야할 점이 생깁니다.

1. 인메모리 공간 사용의 어려움

기본적으로 15분 동안 요청이 오지 않는다면 인스턴스가 종료되므로, 애플리케이션의 메모리에 유지하고 있던 값은 모두 휘발됩니다. 따라서 로직의 동작이 인메모리의 상태에 의존하지 않게 해야 합니다. 또한 인메모리 캐시 역시 비효율적으로 작동할 것입니다.

2. 초기 응답시간 

인스턴스가 종료된 상태에서 요청이 들어온다면, 해당 요청을 처리하기 위해서는 새 인스턴스가 할당된 이후 스프링부트가 초기화되는데 까지의 시간이 필요합니다. 따라서 장기간 미사용된 경우 최초 요청에 대한 응답시간이 튀는 현상이 발생합니다.

3. 악의적 공격

디도스와 같은 과도한 트래픽을 유발하는 악성 공격이 발생한 경우, 자동 스케일링이 동작하여 굉장히 많은 개수의 인스턴스가 생성되므로 비용 폭탄을 야기할 수 있습니다. 이는 max-instance 를 세팅하는 방법으로 해결할 수 있습니다.

4. 스케쥴러 사용 불가능

서버가 사용되지 않을 때에는 인스턴스가 종료되어 있기 때문에 @Scheduled 와 같은 스케쥴링 기반 코드 트리거 방식은 사용될 수 없습니다. 이를 지원하는 별도의 서비스인 Cloud Scheduler를 사용하여 Cloud Run으로 배포된 애플리케이션의 엔드포인트를 호출하는 방식으로 구현해야 합니다.

배포가 안된다면..

MAC OS를 쓰는 제 PC에서는 위 절차 그대로 수행했을 때 문제 없이 동작했으나, 윈도우 환경에서는 빌드 과정에서 에러가 발생하는 경우도 있었던 것 같습니다. 이 때에는 빌드 시 발생하는 문제를 잘 해결하거나, 정 안된다면 Cloud Shell 에서 배포 명령어를 사용하는 방식으로도 가능하니 참고해주시면 좋을 것 같습니다.