Google Cloud Customer Engineer 권신중님.
CloudRun: 완전관리형, 컨테이너 기반 애플리케이션 배포 / 운영 / 확장을 위한 서비스.
- 인프라 고민 필요없음.
CloudRun 소개
크게 두 가지 형태로 쓰임. Service / Job.
- Service: public / private한 웹사이트 또는 Endpoint
- url endpoint 제공
- autoscale 기준은 크게 두 가지 (or 조건으로 동작함)
- cpu 기준. default 60%
- request 개수 (concurrency) - default 80.
- canary deployment (traffic split) based on revision
- HTTP, WebSocket, gRPC, Event 등 다양한 조건으로 트리거
- Job: kubernetes Job과 동일. batch를 병렬로 수행할 수 있는 Container의 묶음
- 하나의 cloudrun instance (max 8Core, 32GB Mem)로 큰 작업 돌리는 것보다 여러 개 병렬처리하는 게 좋다
지원하는 Integration
- Google Cloud Redis
- custom Domain / Load balancer
- Load balancer를 붙일 수 있다? -> CDN도 붙일 수 있다는 뜻.
- Firebase hosting
Pricing
Pay-as-you-go (on-demand) 방식의 비용 설계. 비용 옵션은 크게 두 가지
- 요청 들어왔을 경우에만 cpu 할당 (option 1) - default
- 단, 서울리전 기준 option 2의 단가가 option 1보다 50% 정도 낮다.
- request pattern이 spiky / unpredictable 한 경우에 유용함.
- cpu 반드시 할당 (option 2)
- 꾸준히 traffic이 들어오는 경우에 유용함.
즉, option 1에서 option 2로 넘어갈 때 cost saving될 가능성이 있다.
최근에 cpu recommend 기능이 추가되었음.
- 일정 기간 (1개월 등) 앱이 어느 정도의 cpu 사용량을 기록했으니 recommended amount는 어느 정도인지를 추천해준다.
billable time
인스턴스는 하나 떠 있고 요청을 2개 처리하는 상황.
- cloudRun의 default concurrency 80. 즉 하나의 인스턴스가 이론적으로는 80개의 request를 처리할 수 있다. max는 1000
- overlay 구간은 비용의 double check가 되지 않는다. 즉 concurrency 수치 높일수록 비용 절감 효과.
- 단, 이 경우 사용자가 만든 앱 자체의 handling concurrency보다 높아져 버리면, 500에러 발생하고 있어도 autoscale이 동작하지 않는다
- i.e. 사용자가 springboot 앱을 만들었고, 앱 특성상 최대 50개의 요청을 동시처리할 수 있는 구조인데 concurrency를 100으로 주면 500에러 나고 있어도 autoscale을 지원하지 못한다.
- Concurrency는 사용자의 tuning point
New Features
사용자가 hello world 찍는 용도로는 더 이상 안 쓴다. 요구사항이 많아졌다.
- Sidecar Container 지원
- 더 큰 리소스 선택 가능 (8 vCPU / 32GiB RAM) - Service, Job 둘 다.
- 등등등...
여기서 소개할 내용은 크게 두 가지 - Sidecar Container, Direct VPC egress
지금까지 Cloud Run은 Single Container만 지원하고 있었음
- sidecar를 붙인다는 건, container workload 간 localhost로 통신 가능하다는 뜻.
- in-memory shared volume 활용 가능.
생각해볼 수 있는 usecase는 세 가지
- App Monitoring, Logging, Tracing
- cloudRun은 GCP의 logging / monitoring 기능을 지원하지만, 사용자는 prometheus를 원함.
- openTelemetry에서 제공하는 agent를 sidecar로 띄우는 것.
- Proxy 붙이기
- incoming request에 sidecar (i.e. nginx) - reverse proxy를 붙인다거나 / 인증, caching이 필요하다거나
- outgoing request에 sidecar (i.e. cloud sql proxy) - GCP에서 제공하는 managed DB인데, 통신 암호화라던가 ACL 지원해주는 Daemon 같은 느낌으로 proxy 사용을 권장하고 있음.
- Advanced Networking, Security, Service Mesh까지.
nginx를 sidecar로 붙이는 예시
- apiVersion을 보면 knative 스펙임.
- nginx conf 보면 loopback interface. (location 필드의 proxy_pass http://127.0.0.1:8888)
- main 컨테이너와 nginx 컨테이너의 bootup 서순 명시 - annotation의 'run.googleapis.com/container-dependencies' 필드
CloudRun으로 앱을 띄우고 외부 인터넷으로 접근 가능한 endpoint를 받았음.
- 대부분의 사용자는 GCP의 VPC 내부에 만들어둔, private IP로 접근가능한 리소스와 통신하고 싶어함
- 또는 on-prem 서버와 연동하고 싶음
지금까지는 Serverless VPC Access Connector라는 일종의 VM 머신을 발급받아서 통신해야 했음.
- egress 트래픽이 많으면 10개까지 늘어나는 VM.
중간에 있던 Access Connector (VM) 을 없앴다. VPC와 이제 직접 통신할 수 있음.
- 중간 hop에 해당하는 VM을 없앴을 때의 장점을 누릴 수 있다
- Latency 감소
- VM에 의존하던 Throughput에서 독립됨
- idle일 때도 인스턴스 발급 자체에서 발생하던 비용 없어짐
Web Console에서 활성화할 수 있다.
- subnet을 설정해야 하는데, /24 권장. (private interface를 위한 ip)
- service나 job 개수가 100을 넘어갈 것 같으면, 사용가능한 총 인스턴스 수의 4배 가량의 ip가 필요함.
Best Practices
개발자가 할 수 있는 선에서 Cold Start 줄여야 한다.
- 이미지 크기 줄이기, dependency 최소화, lazy loading...
- 그래도 안 되면 인프라의 도움을 받는다. Startup CPU boost. 문서상으로는 50% 정도 절감된다고 하는데, case by case.
- Min instance를 1로 설정하는 것도 방법.
특히 Java / .Net의 경우 cold start의 부담이 큰 편.
비용 최적화
- Concurrency 설정 잘해야 한다. App이 감당할 수 있는 concurrency를 테스트해봐야 함.
- request 늘려갈 때 500에러 뱉기 시작하는 지점이 한계치임. 그것보다 살짝 낮은 값으로 안전하게 잡으면 된다.
- cpu recommender 활용하기.
Operation/Security
- 민감한 환경변수는 Secret manager에 key-value로 넣고, IAM 활용해서 control하는 것을 권장함.