[GCP] 초보자를 위한 Cloud Run 설명회

 Cloud Run이란 구글 클라우드 플랫폼에서 제공하는 서버리스 컴퓨팅 서비스로 AWS의 Fargate에 대응됩니다.

 GCE를 통해 가상 머신을 생성하고 서버를 구성 후 코드를 빌드하여 배포하는 기존 방식(IaaS)과 달리, 어플리케이션을 컨테이너 형태로 빌드해 Cloud Run에 등록하는 간단한 과정으로 빠르고 안전하게 배포할 수 있게 돕습니다.

Cloud Run 내부에서 자동화 된 컨테이너 관리

 Cloud Run은 https나 웹소켓, gRPC 등의 요청이나 이벤트가 발생할 때 등록되어있는 컨테이너를 실행하게되며, 이러한 방식은 가상 머신의 복제보다 빠르고 운영 체제나 언어, 라이브러리 등의 제약 없이 개발과 배포 환경을 일치시킬 수 있다는 점에서 컨테이너의 장점을 활용할 수 있습니다.

 

Docker) 초보자를 위한 도커 설명회

---

완전 관리형 서비스 (Serverless)

 기존의 온프레미스나 IaaS의 한계인 인프라의 운영과 관리에 필요한 수고를 자동화해 관리함으로써 서비스와 인프라를 분리, 개발자가 서비스의 개발에 집중할 수 있게 만든 것이 서버리스 솔루션으로, 프로비저닝이나 스케일링 등의 인프라 운영을 신경쓸 필요가 없기에 서버리스라고 불립니다.

 Cloud Run 이외에도 Aws Lambda, Azure Container Apps 등 벤더에 따라 유사한 서비스가 있고, 같은 벤더 내에서도 아키텍처의 추상화 정도에 따라 Google Cloud Function 등으로 분리됩니다.

 

Cloud Run VS Cloud Function

 구글의 또 다른 서버리스 솔루션인 Cloud Function 역시 특정 이벤트가 트리거 되어 실행되지만, 추상화 정도에 차이가 있습니다.

 Aws Lambda나 Cloud Function 등의 FaaS(Function As A Service)는 컨테이너 기반의 Cloud Run보다 높은 추상화 수준으로 함수를 작성하고, 특정 이벤트에 응답하도록 설정하면 되지만, 사용 언어나 버전 등에 크게 의존성을 가지며 컨테이너 기반의 Cloud Run에 비해 낮은 이식성을 가집니다.

 반면 Cloud Run은 더 낮은 추상화 수준으로 런타임 환경, 라이브러리, 프레임워크 등의 제어권을 가질 수 있기 때문에 보다 복잡한 어플리케이션에 적합합니다.

---

Cloud Run 설정 및 배포

클라우드 런의 사용을 설명하기 위한 예시로

• 컨테이너 레지스트리는 Google Container Registry를 사용하였습니다.
• 이미지 빌드와 GCR 업로드까지의 과정은 gcloud sdk와 CLI 환경
• 클라우드 런 설정과 배포까지의 과정은 클라우드 콘솔을 통해 진행하였습니다.

프로젝트 설정

1. 구글 클라우드 프로젝트 생성

1번의 프로젝트 ID를 기억

2. Google Cloud Registry 사용 설정

API 사용 설정

해당 API 사용 설정

 

이미지 빌드

2. 실행될 서비스를 이미지로 빌드

gcr.io/프로젝트 명/이미지 이름으로 태그를 붙여 빌드해줍니다.

2. gcloud 서비스를 사용하기 위해 로그인

프로젝트의 권한을 가진 계정으로 로그인

3. 도커 클라이언트 구성

도커 클라이언트가 Container Registry와 연결될 수 있도록 구성

4. 이미지를 컨테이너 레지스트리에 Push

이미지를 레지스트리에 push

위와 같은 과정을 끝내고 push까지 마무리했다면 이미지가 제대로 업로드 되었는지 확인할 수 있습니다.

순서대로 버킷에 접근해보면

방금 올린 이미지가 정상적으로 Push 되었습니다.

리소스

이미지를 생성하고 레지스트리에 올리기까지 성공했다면 클라우드 런을 통해 배포할 수 있습니다.

 

클라우드 런 설정

클라우드 런 접속

클라우드 런에 접속해 서비스를 생성해줍니다.

 

실행에 필요한 환경 구성

1. 실행될 이미지를 선택합니다. 컨테이너 레지스트리를 확인해보면 아까 push한 이미지가 있는데, 선택해줍니다.
2. 서비스의 이름을 설정합니다
3. 인스턴스가 위치할 리전을 지정합니다.
4. 자동 확장에 필요한 인스턴스를 설정해줍니다. 인스턴스 최소 개수 pool로 상시 동작중인 인스턴스의 최소 갯수를 지정해 요청이 없으면 아무것도 실행하지 않게 할 수도 있고, 1개 이상의 인스턴스를 상시로 구동해 요청에 따른 컨테이너 실행의 오버헤드를 줄일 수 있습니다.

컨테이너, 네트워킹, 보안 탭에서 구동에 필요한 환경변수나 시크릿 등의 고급 설정을 추가로 할 수 있습니다.

 

배포 성공

배포에 성공한 모습입니다. 외부에서 접근할 수 있는 URL을 제공받습니다.

 

테스트

테스트에 사용한 이미지는 테스트용으로 만들어 둔 url 단축기입니다. 블로그 주소로 테스트 해봅니다.

 

테스트 툴은 Apache Jmeter를 사용했습니다.

새로운 블로그 url 만관부

 

200 OK

기본 유휴 컨테이너가 0이라 요청이 들어오면 컨테이너 실행 후 응답합니다. 0.8초가 걸린 모습입니다.

 

Cloud Run을 사용하는 이유 중 하나는 스케일링의 자동화인데, 부하를 걸어 동시에 요청을 보냈을 때 컨테이너가 추가로 늘어나는 모습입니다.

초당 요청수에 따라 컨테이너가 4개까지 늘어난 모습

마치며

 여기까지 구글의 서버리스 솔루션인 Cloud Run을 통해 어플리케이션을 컨테이너화하고 배포 이후 부하 테스트를 통해 자동으로 스케일링되는 모습까지 확인했습니다.

 요청 트래픽에 대한 스케일링은 처리했지만, 이러한 여러 컨테이너가 동시에 커넥션을 맺고있는 DB 등에서 다양한 문제가 발생하는데, Stateless한 서버와 달리 데이터베이스는 이렇게 분산될 시 여러 데이터베이스가 동기화 되지 않는 문제가 발생합니다.

산넘어 산

Aurora DB나 Cloud SQL 등 서버리스 DB도 존재하지만, 비용이 어마어마합니다..

다음엔 데이터 정합성 유지를 위한 분산 시스템에서의 데이터 베이스 동기화 방식을 알아보겠습니다.

 

---

블로그 URL을 바꾸었더니 접속자가 싹 사라졌습니다.

크롤러가 360도 달라진 절 찾아줄 줄 알았는데, 아니네요.

광고도 이 주소로 이전해야하는데, 어서 새로운 글을 써서 구글에게 절 알려야겠습니다.

 

질문이 있다면 댓글 적어주시면 친절히 답변드리겠습니다. 감사합니다.