[GCP]Serverless 서비스인 Cloud Run 알아보기 3부 — 업데이트 및 트래픽 조정
안녕하세요 이정운 입니다.
지난번 이야기까지 Google Cloud 에서 제공하는 컨테이너 기반의 Serverless 솔루션인 Cloud Run 에 대해서 개략적으로 살펴보기도 했으며, 로컬에서 VS Code 에 Cloud Code 플러그인을 설치해서 개발 및 테스트하고 실제 Google Cloud 환경에 배포하는 테스트도 수행해 봤습니다.
[GCP]Serverless 서비스인 Cloud Run 알아보기 1부 — Cloud Run 개요
[GCP]Serverless 서비스인 Cloud Run 알아보기 2부 — 로컬에서 개발하기(Cloud Code)
이번 이야기 에서는 애플리케이션 변경을 배포하는 과정에 대해서 조금 더 자세히 살펴볼 예정입니다. Cloud Run 은 개념적으로 살펴보면 실제 서비스를 수행하는 기본 단위인 서비스와 서비스에 배포되는 버전(Revision) 으로 구분되며 실제 요청이 들어올때 버전이 컨테이너 인스턴스에 매핑되어 실제로 서비스가 이루어지는 형태입니다.
리소스 모델
https://cloud.google.com/run/docs/resource-model
예를 들면, 컨테이너 이미지를 Cloud Run 에 배포할때 입력한 이름에 따라 서비스가 생성이 되면서(예:서비스 A) 버전v1도 기본적으로 같이 생성됩니다. 그리고 실제 서비스를 호출하게되면 해당 버전에 매핑된 컨테이너 인스턴스들이 동적으로 시작되어서 서비스 처리를 수행하게 됩니다. 이 상태에서 애플리케이션을 변경하고 새롭게 컨테이너 이미지를 업데이트해서 동일한 서비스 A 에 배포하면 기존 버전이 있으므로 버전v2가 새로 생성이 됩니다. 실제 서비스를 수행할 때 버전v1 과 버전v2 의 트래픽 비율을 조정할 수 있으며 버전v2 로 100% 트래픽 설정을 하고 URL 호출을 해보면 업데이트 된 내용을 브라우저에서 직접 확인 가능합니다.
Cloud Run adds support for gradual rollouts and rollbacks
https://cloud.google.com/blog/products/serverless/cloud-run-now-supports-gradual-rollouts-and-rollbacks
간단한 설명을 드렸지만 설명만으로는 이해가 어려울 수 있으므로 이제 실제 테스트를 직접 해보면서 Cloud Run 의 업데이트 및 트래픽 조정등에 대해서 살펴보는 시간을 가져보도록 하겠습니다.
#1) 새로운 애플리케이션 변경 사항 배포하기
Deploying container images
https://cloud.google.com/run/docs/deploying
새로운 애플리케이션 변경 사항을 배포해보는 테스트를 해보기 위해서 우선 기존에 설치된 서비스를 확인해 봅니다.(hello-world-1) “GCP 관리콘솔 > Cloud Run > 버전” 메뉴로 가서 확인해보면 앞에서 설명드린 것처럼 기본적으로 하나의 버전이 설치되고 100% 트래픽을 받는 형태로 서비스가 되고 있는 것을 확인 가능합니다.
또한, URL 을 통해서 정상적으로 서비스 결과가 나오는 것을 확인합니다.
이제 기본 확인이 되었으니 지난 이야기에서 작성된 VS Code 의 애플리케이션을 변경합니다.(예:텍스트에 ‘Version02’ 추가)
변경을 저장하고 ‘Deploy to Cloud Run’ 메뉴를 선택하여 기존 배포된 서비스와 환경에 지금 변경된 애플리케이션을 배포합니다.
정상적으로 해당 작업이 완료되면 Output 창에 하단과 같이 성공 메시지를 확인할 수 있습니다.
다시 서비스 URL 을 호출해보면 하단과 같이 변경된 내용이 즉시 반영된 것을 확인하실 수 있습니다.
또한, GCP 관리콘솔에 접속해 보면 하단과 같이 새로운 버전v2 가 추가되어 있고 해당 버전이 100% 트래픽을 보내도록 매핑되어있는 것을 확인 가능합니다.
#2) 배포 버전간의 트래픽 조정 및 케이션 변경 사항 배포하기
Rollbacks, gradual rollouts, and traffic migration
https://cloud.google.com/run/docs/rollouts-rollbacks-traffic-migration
Managing Revisions
https://cloud.google.com/run/docs/managing/revisions
이전 파트에서는 애플리케이션을 수정해서 업데이트 형태로 배포하는 것을 확인해봤습니다. 해당 방식의 경우에는 배포하자마자 새로운 버전의 애플리케이션으로 모든 트래픽이 변경되서 들어가는 형태였습니다. 그러한 방식의 경우에는 개발시에 빠르고 쉽게 배포한 이점이 있을 수 있지만 운영환경이라고 가정한다면 한번에 모든 트래픽을 변경하는 작업에는 리스크가 있을 수 있습니다. 따라서, 실제적으로 많은 기업환경의 운영환경에서는 카나리 배포방식이라 이름 불리는 트래픽 조정 업그레이드 방식을 선호합니다.
이를 조금 더 쉽게 설명하면 버전v1 에 100% 서비스 중이였다면 버전v2 를 업데이트해서 배포했을 때 일부(약 10% 정도) 서비스만 테스트 형태로 처리하도록 해서 검증 작업을 거칠 수 있는 배포 방식입니다. 일부 서비스를 통해서 운영 환경의 서비스를 검증해보고 이상이 없는 경우 점차 새로운 버전v2 로 트래픽 비중을 높여서 나중에는 v2 가 100% 서비스 처리를 수행하도록 하는 방식을 의미합니다.
방금 설명드린 내용에 대해서 테스트 해보기 위해서 다시한번 VSCode 에서 애플리케이션을 변경하고 저장합니다.(예:텍스트에 ‘Version003’ 변경)
이번에는 VSCode 에서 바로 배포하지 않고 제어하기 위해서 해당 소스를 docker 를 통해서 컨테이너 이미지로 빌드합니다.
참고로 이전에 VSCode 에서 직접 Google Cloud 의 Cloud Run 으로 컨테이너 이미지를 배포했을 때 내부적으로는 자동으로 Google Container Registry(GCR — https://cloud.google.com/container-registry) 로 푸시해서 저장하고 그 이미지를 사용해서 Cloud Run 으로 배포작업을 수행했습니다. 따라서, “GCP 관리콘솔 > Container Registry” 메뉴에 가면 저장된 컨테이너 이미지 와 경로(gcr.io/jwlee-myproject-01/hello-world-1)를 확인할 수 있습니다.
확인된 GCR 의 경로에 컨테이너 이미지를 업데이트 해서 배포 후에 사용할 예정이므로 GCR 경로를 사용해서 컨테이너 이미지를 빌드합니다.
docker build -t gcr.io/jwlee-myproject-01/hello-world-1빌드된 컨테이너 이미지를 확인해보고 해당 이미지를 기존 컨테이너 이미지가 배포된 GCR 경로로 푸시합니다.
docker image list
docker push gcr.io/jwlee-myproject-01/hello-world-1정상적으로 푸시가 완료되면 “GCP 관리콘솔 > Container Registry > 이미지” 메뉴에서 hello-world-1 이미지가 새롭게 업데이트 되었음을 확인 가능합니다.
GCR 에 배포할 이미지가 준비되었으면 이제 실제 배포 작업을 진행하도록 하겠습니다. 배포하고자 하는 Cloud Run 서비스로 가서 ‘새 버전 수정 및 배포’ 메뉴를 클릭합니다.
새 버전 배포 마법사의 항목을 살펴보고 변경이 필요없다면 ‘이 버전을 즉시 제공’ 메뉴의 체크를 해제한 후에 배포를 클릭하여 실제 배포를 수행합니다.
(참고적으로 컨테이너 이미지 URL 이 실제 배포하고자 하는 컨테이너 이미지의 주소를 의미하며 기존과 동일하게 둡니다. 예: gcr.io/jwlee-myproject-01/hello-world-1)
배포가 완료되어 서비스 URL 을 호출해보면 하단과 같이 실제 업데이트가 되지 않고 이전 버전의 결과가 나오는 것을 확인할 수 있습니다.
그 이유는 “GCP 관리콘솔 > Cloud Run > 버전” 메뉴를 보면 이해가 바로 가능합니다. 보시면 아시겠지만 새롭게 배포된 애플리케이션은 ‘이 버전을 즉시 제공’ 메뉴의 체크를 해지했기 때문에 배포는 되지만 실제로 트래픽은 전달 안되게 0% 설정되어 배포된 것을 확인하실 수 있습니다.
그러면 이제 새롭게 배포된 애플리케이션으로 트래픽의 일부를 조정해보도록 하겠습니다. 해당 버전의 애플리케이션의 작업에 있는 햄버거 아이콘을 클릭하여 트래픽 관리 버튼을 클릭합니다.
트래픽 관리 메뉴가 나오면 새로운 서비스로 조정할 트래픽 비율을 조정합니다. (이번 이야기에서는 효과를 바로 보기 위해서 50% 를 선택했는데 5% 나 10% 등 원하시는 형태로 조정 가능합니다.)
트래픽 조정이 완료되면 하단과 같이 변경이 완료된 내역을 확인 가능합니다.
이제 서비스 URL 로 호출해보면 새롭게 배포한 애플리케이션을 확인할 수 있습니다. 특히, 50% 비율로 2개의 버전이 서비스되도록 트래픽 조정을 수행했기 때문에 대략 50% 의 확율로 이전 버전과 새로운 버전이 번갈아 가면서 결과가 나오는 것을 확인 가능합니다.
당연히 서비스에 문제가 없는 것을 확인했다면 하단과 같이 새롭게 배포한 애플리케이션 쪽으로 트래픽을 100% 조정하여 업그레이드 작업을 쉽게 마무리 할 수 있습니다.
참고로 해당 부분은 GCP 관리콘솔 뿐만 아니라 VSCode 에서도 확인 가능합니다.
추신 #1) 트래픽 조정 방식 이외에 버전 URL(태그)를 추가하게 되면 하단과 같이 특정 버전에 대한 태그를 URL 로 할당 가능하여 트래픽 조정전에 특정 버전의 태그가 추가된 URL 을 통해서 직접 호출 가능하게 설정도 가능합니다.
지금까지 VS Code 에서 애플리케이션을 수정하여 새로운 버전의 애플리케이션을 Cloud Run 으로 배포하는 작업을 수행해 봤습니다. 직접 배포해서 바로 서비스 수행도 해봤으며 카나리 배포방식을 활용하여 배포하자 마자 서비스를 수행하는 것이 아니라 적은량의 트래픽을 먼저 분산해서 검증해볼 수 있는 트래픽 조정 업그레이드 방식도 테스트 해봤습니다. 보시면 아시겠지만 Cloud Run 은 별도의 추가 작업없이도 이미 트래픽 조정과 같은 기능이 포함되어 있으므로 운영환경에서도 좀 더 안정적으로 서비스를 운영하고 업그레이드 할 수 있는 쉬운 방법을 제공 가능합니다. 그럼 이번 포스팅은 여기서 마무리하고 다음에 다른 포스팅으로 다시 돌아오겠습니다.
Disclaimer: 본 글의 작성자는 Google 직원이지만 Google cloud 를 공부하는 한 개인으로서 작성된 글입니다. 본 글의 내용, 입장은 Google 을 대변하지 않으며 Google 이 해당 콘텐츠를 보장하지 않습니다.
참고 자료 #1
Cloud Run adds support for gradual rollouts and rollbacks
https://cloud.google.com/blog/products/serverless/cloud-run-now-supports-gradual-rollouts-and-rollbacks
리소스 모델
https://cloud.google.com/run/docs/resource-model
Deploying container images
https://cloud.google.com/run/docs/deploying
Rollbacks, gradual rollouts, and traffic migration
https://cloud.google.com/run/docs/rollouts-rollbacks-traffic-migration
