Conceptly
← 전체 목록
🚀

Google Cloud Run

컴퓨팅컨테이너 실행 계층

Google Cloud Run은 컨테이너를 서버리스 방식으로 실행하는 배포 계층입니다. 요청이 들어올 때만 인프라를 쓰고 싶을 때, 애플리케이션 코드를 컨테이너 단위로 올려 운영 부담을 줄이는 자리를 맡습니다. '컨테이너는 유지하되 운영은 최소화'하고 싶을 때 가장 먼저 검토되는 선택지입니다.

아키텍처 다이어그램

🔗 관계 다이어그램

점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다

왜 필요한가요?

컨테이너로 앱을 묶었는데, 이를 서비스로 띄우려면 클러스터 운영이나 VM 관리가 따라붙습니다. 서비스가 적고 트래픽도 들쑥날쑥한데 운영 비용까지 짊어질 필요는 없습니다. 특히 초기 제품 단계에서는 운영 복잡도 자체가 출시 속도를 늦춥니다.

왜 이런 방식이 등장했나요?

컨테이너가 배포의 기본 단위가 되면서, Kubernetes 없이도 프로덕션에 바로 올릴 수 있는 실행 계층이 필요해졌습니다. Cloud Run은 그 부담을 없애기 위해 만들어진 서버리스 컨테이너 모델입니다. 개발팀이 인프라보다 제품 기능에 집중할 수 있게 해 주는 흐름과 맞물려 빠르게 확산됐습니다.

내부적으로 어떻게 동작하나요?

이미지를 배포하면 Cloud Run이 HTTPS 엔드포인트와 리비전을 만들고, 요청량에 따라 인스턴스를 늘리거나 줄입니다. 컨테이너가 요청을 받는 동안만 살아 있고, 트래픽은 새 리비전으로 점진적으로 옮길 수 있습니다. 동시성·최소 인스턴스 설정을 조정하면 지연 시간과 비용을 서비스 특성에 맞게 튜닝할 수 있습니다.

경계와 구분

Cloud Run과 Compute Engine은 둘 다 서버를 대신 세워 주지만, Cloud Run은 컨테이너만 주면 런타임과 스케일을 맡아주고 Compute Engine은 OS와 프로세스를 직접 운영해야 합니다. Cloud Run과 GKE는 둘 다 컨테이너를 실행하지만, GKE는 스케줄링 정책과 서비스 메시까지 필요한 경우에 맞습니다. 즉, 제어면이 필요한지 여부가 Cloud Run과 GKE를 나누는 핵심 기준입니다.

언제 쓰나요?

HTTP API, 웹훅 처리, SSR 프론트엔드, 이벤트를 받아 짧게 일하는 작업처럼 요청 패턴이 들쑥날쑥한 컨테이너에 적합합니다. 노드 수준 튜닝이나 복잡한 오케스트레이션이 필요하면 다른 계층을 봐야 합니다. MVP, 내부 도구, BFF(Backend for Frontend) 같은 서비스도 Cloud Run에서 빠르게 운영할 수 있습니다.

웹 API 서버마이크로서비스백엔드 작업프론트엔드 SSR