[GCP]Serverless 서비스인 Cloud Run 알아보기 9부 — 잘 안 알려졌지만 주목할만한 2022년 업데이트 정리

Published in

google-cloud-apac

15 min readApr 11, 2023

안녕하세요 이정운 입니다.

Google Cloud 에서 제공하는 컨테이너 기반의 Serverless 솔루션인 Cloud Run 에 대해서 살펴보고 실제 테스트해보면서 써볼 수 있는 시간을 가져보는 시리즈를 하단과 같이 진행하고 있습니다.

이번 이야기는 Serverless 서비스인 Cloud Run 알아보기 시리즈의 마지막으로 “잘 안 알려졌지만 주목할만한 2022년 업데이트 정리” 를 이야기 해볼까 합니다. 제목 그대로 2022년에는 Cloud Run 관련된 많은 업데이트가 있었습니다. 예를 들어 작년부터 Cloud Run 서비스에 최대 8 CPU, 32 GiB 메모리를 할당할 수 있게 되었으며 2세대 실행환경을 지원하면서 전반적인 성능과 Linux 호환성 향상을 제공할 수 있게 되었습니다. 또한, 배치성 업무 처리를 위한 Cloud Run Jobs 라는 서비스도 GA 되었습니다. 그러나, 이런 굵직 굵직한 업데이트들은 이미 잘 알고 계실듯 하며 이번에는 어떻게 보면 소소한 업데이트 일수 있지만 실제 운영환경에서 많은 도움이 될 만한 2022년 업데이트를 살펴 볼 수 있는 시간을 가져보면 어떨까하는 생각에 이번 이야기를 준비했습니다.

그럼 제 나름대로(?) 생각해 본 잘 안 알려졌지만 주목할 만한 2022년 업데이트에 대한 이야기를 나눠보는 시간을 가져보도록 하겠습니다.

#1) Serverless VPC Access connector 업데이트(머신타입과 Min/Max 설정가능)

Connect to a VPC network
https://cloud.google.com/run/docs/configuring/connecting-vpc#update-connector

처음 살펴볼 Cloud Run 의 잘 안 알려졌지만 주목할만한 2022년 업데이트는 Serverless VPC Access connector 에 대한 업데이트 기능입니다. Serverless VPC Access 는 Cloud Run 이나 Cloud Functions 와 같은 서버리스 환경에서 connector 를 통해서 Google cloud 내의 Virtual Private Cloud(VPC) 네트워크에 직접 연결을 지원하는 기능입니다. 이러한 연결 방식의 장점은 VPC 네트워크로 전송된 요청은 인터넷에 노출되지 않기 때문에 안전하다는 것이며 추가적으로 인터넷을 타는 경우보다 대기 시간이 짧을 수 있습니다. Serverless VPC Access connector 의 전반적인 구조에 대해서는 하단의 첨부된 그림을 보시면 쉽게 이해가 가능하지 않을까 합니다.

https://cloud.google.com/vpc/docs/serverless-vpc-access#example_2

그림을 보시면 아시겠지만 Cloud Run 은 사용자 VPC network 에 만들어지지 않으며 Google cloud 내의 regional 서비스 형태로 구성되며 사용자 VPC Network 에 접근하기 위해서는 기 언급했던 Serverless VPC Access connector 구성이 꼭 필요합니다. 이때 Serverless VPC Access connector 는 내부적으로 GCE 로 구성되어 있으며 이전까지는 throughput 을 직접 설정하는 형태였다면(최대 1000 Mbps 까지) 이제는 머신타입과 minimum, maximum 인스턴스 사이즈를 설정할 수 있는 형태로 업그레이드 되었습니다. 이때, 해당 설정은 최소값인 minimum 은 2부터 시작해서 최대값인 maximum 는 10까지 설정 가능합니다.

그리고 이러한 머신타입과 minimum, maximum 인스턴스 사이즈는 Serverless VPC Access connector 가 제공 가능한 throughput 과 연동됩니다.

https://cloud.google.com/vpc/docs/serverless-vpc-access#scaling

예를 들어 머신타입을 e2-standard-4 를 선택해서 최소 값을 2로하고 최대 값을 10으로 했다면 부하에 따라 동적으로 해당 인스턴스 개수는 변경되며 최소값인 2인 경우 3200 Mbps 의 throughput 을 지원할 수 있으며 최대값인 10인 경우 16000 Mbps 의 throughput 을 지원할 수 있습니다.(기존 대비 10배 이상 증가) 따라서, Cloud Run 에서 사용자 VPC Network 에 접속할때 어느정도의 throughput 이 필요하냐에 따라서 원하시는 데로 설정하실 수 있으며 필요시 해당 설정은 업데이트 가능합니다.

Serverless VPC Access 내용 포함해서 Cloud Run 의 네트워크 관련해서는 하단의 동영상에서 아주 친절하게 잘 설명되어 있으므로 조금 더 자세한 내용이 알고 싶으신 분들은 동영상을 참고하시기 바라겠습니다.

Cloud Run: Concepts of Networking
https://www.youtube.com/watch?v=rmQovUuR5O4

#2) Healthcheck probes 정식 사용 가능

Healthcheck probes are now at general availability (GA)
https://cloud.google.com/run/docs/configuring/healthchecks

다음으로는 Healthcheck probes 정식 사용에 대한 업데이트 입니다. 이제 Serverless 서비스인 Cloud Run 환경에서도 YAML 설정을 통하여 HTTP, TCP 그리고 gRPC 에 대한 startup health check probe 를 사용 가능하며, startup probe 뿐만 아니라 liveness probe 도 사용 가능해졌습니다. 여기서 probe 는 kubernetes 에서 제공 되는 기능으로, 컨테이너의 상태를 주기적으로 확인하는 진단 작업 입니다.

Startup probe 는 컨테이너가 트래픽을 받을 준비가 되었는지를 확인합니다. 예를 들어 startup brobe 가 설정되면 Cloud Run 은 HTTP get 요청을 service healthcheck endpoint(예를 들어 ‘/ready’) 로 보내고 200이나 400 응답이 나오면 success 로 판단하고 그 외에는 전부다 failure 로 판단합니다. Startup probe 가 일정 시간 이상(failureThreshold * periodSeconds, 240 초를 넘을 수 없음) 응답이 없다면 컨테이너는 shut down 되는 구조를 가지고 있습니다.

Liveness probe 는 컨테이너가 요청을 계속 처리할 수 있는지 확인합니다. 다시 말해서 컨테이너는 정상적인 Running 상태이지만, 애플리케이션에 문제가 생겨서 접속이 안되는 경우를 감지합니다. (메모리 오버플로우 등) Liveness probe 에 실패한다면 kubelet 은 컨테이너를 죽이고, 해당 컨테이너는 재시작 정책의 대상이 됩니다.

https://www.youtube.com/watch?v=Vcu76ZTnZ0Q

영상의 설명을 보시면 아시겠지만 Startup probe, Liveness probe 모두 안정적인 Cloud Run 서비스 운영에 필수 적으로 필요할듯 하며 다양한 유즈케이스에 대해서 사용될 수 있는 기능입니다.

추신 #1) 추가적으로 Cloud Monitoring 의 Uptime checks 가 이제 공식적으로 Cloud Run 을 지원합니다. 이를 추가 활용하시면 좀 더 안정적인 시스템 모니터링 환경을 구성 가능하오니 참고하시기 바라겠습니다.

Verify Cloud Run service availability with new dedicated uptime checks
https://cloud.google.com/blog/products/management-tools/monitor-cloud-run-service-availability-with-uptime-checks

#3) Startup CPU boost 기능

Startup CPU boost for revisions is now available to provide additional CPU during container instance startup time.
https://cloud.google.com/run/docs/configuring/cpu#startup-boost

Cloud Run 에서 다음으로 살펴볼 ‘잘 안 알려졌지만 주목할만한 2022년 업데이트’ 는 Startup CPU Boost 기능입니다. 개인 적으로 해당 기능은 되게 재밌게 생각하고 있으며 클라우드의 이점을 충분히 활용한 효율적인 기능이다라는 생각이 있습니다. Startup CPU boost 기능은 이름 그대로 컨테이너 인스턴스 시작시간에만 더 높은 성능을 내기 위해서 추가적인 CPU 를 임시적으로 할당해서 부스트 하는 기능을 의미합니다.

https://cloud.google.com/run/docs/configuring/cpu#startup-boost

예를 들어, 2 CPU 를 할당한 상태에서 해당 기능을 사용하면 컨테이너 시작 시간동안만 4 CPU 가 임시적으로 할당되어 부스트되고 시작이 완료되면 다시 원래 설정한 2 CPU 로 동작하게 됩니다. 이를 통해서 컨테이너 시작시 좀 더 많은 CPU 를 활용하여 빠르게 컨테이너 시작 작업을 완료할 수 있도록 지원합니다. 이러한 Startup CPU boost 기능은 Cloud Run 생성시에 필요하다면 메뉴에 체크만으로 손 쉽게 사용할 수 있습니다.

#4) Session affinity 지원

Session affinity is now available for Cloud Run service revisions.
https://cloud.google.com/run/docs/configuring/session-affinity

다음으로 Session affinity 기능이 Cloud Run 에 추가되었습니다. 현재 기본적으로는 이전과 동일하게 session affinity 기능은 enable 되어 있지 않고 있습니다. 그렇기 때문에 하단의 그림과 같이 client A 가 여러 요청을 보내게 되면 백엔드에 있는 Cloud Run 서비스의 instance 가 여러개인 경우라도 affinity 없이 처리되게 됩니다.

그러나 2022년에 다양한 업데이트 중에 Session affinity 지원 기능이 추가되었고 Cloud Run 설정에서 간단하게 enable 할 수 있게 되었습니다.

Session affinity 를 설정하게 되면 client A 가 요청을 보내서 Cloud Run 서비스의 특정 백엔드 인스턴스에서 처리가 되었다면 그 뒤에 보내진 client A 요청도 동일하게 해당 인스턴스에서 처리가 될 수 있습니다. 이러한 방식을 일반적으로 Session affinity 라고 합니다.
(참고로 session affinity cookie 를 사용하는 형태로 동작하며 기본 TTL 30 days 로 되어 있습니다.)

다만, Cloud Run 의 자동 확장 동작으로 인해서 Session affinity 는 best effort affinity 성향을 가집니다. 다시 말씀드려 인스턴스가 다시 시작, 종료, 오버로드되거나 인스턴스 축소의 결과로 사용할 수 없게 되면 Session affinity 가 끊어지고 추가 요청이 다른 인스턴스로 라우팅됩니다.

#5) 1 CPU 보다 작은 사이즈의 CPU 지원

Cloud Run now supports using less than one CPU. Refer to CPU limits for details. (Available in public preview.)
https://cloud.google.com/run/docs/configuring/cpu

마지막으로 살펴볼 ‘안 알려졌지만 주목할만한 2022년 업데이트’ 는 1 CPU 보다 작은 CPU 지원 기능입니다. 아마도 많은 분들이 알게 모르게 그냥 가장 작은 최소 단위를 1 CPU 로 생각하고 계실 수 있을텐데 Cloud Run 은 0.1 과 같이 1 보다 작은 CPU 설정을 사용 가능합니다. 즉, 하단과 같이 설정의 CPU 항목에서 ‘<1’ 을 선택하시고 0.5 처럼 1보다 작은 수를 입력하여 1 보다 작은 사이즈의 CPU 를 사용해서 컨테이너를 운영하는 것이 가능합니다. (0.08 에서 1까지 0.01 단위로)

다만, 1보다 적은 CPU 를 사용할 경우 하단의 요구사항들이 강제되는 제약은 고려해야 됩니다.

비록 제약이 있긴 하지만 아주 단순한 업무를 위해서 Cloud Run 이 필요하다거나 개발용으로 작은 머신이 필요한 경우라면 1 보다 작은 사이즈의 CPU 를 설정하는게 비용적으로 더 효율적으로 구성할 수 있는 방안이 되지 않을까합니다.

지금까지 Serverless 서비스인 Cloud Run 알아보기 시리즈의 마지막으로 “안 알려졌지만 주목할만한 2022년 업데이트 정리” 를 해봤고 소소하지만 도움이 될만한 업데이트들을 살펴보는 시간을 가졌습니다.

#1) Serverless VPC Access connector 업데이트(머신타입과 Min/Max 설정가능)
#2) Healthcheck probes 정식 사용 가능
#3) Startup CPU boost 기능
#4) Session affinity 지원
#5) 1 CPU 보다 작은 사이즈의 CPU 지원

기 언급했지만 주요한 업데이트들은 많이 알고 계실거 같아서 나름 제목 그대로 2022년에 안 알려졌지만 주목할만한 업데이트를 정리해봤는데 도움이 되는 시간이 되었기를 바래봅니다.

그럼 여기까지해서 Serverless 서비스인 Cloud Run 알아보기 시리즈는 마무리를 하고 다음에 다시 더 좋은 주제로 돌아오도록 하겠습니다. ^^&

Disclaimer: 본 글의 작성자는 Google 직원이지만 Google cloud 를 공부하는 한 개인으로서 작성된 글입니다. 본 글의 내용, 입장은 Google 을 대변하지 않으며 Google 이 해당 콘텐츠를 보장하지 않습니다.

참고 자료 #1

Update a connector
https://cloud.google.com/run/docs/configuring/connecting-vpc#update-connector