Cloud Run (r1)

Cloud Run의 핵심은 서버리스 방식으로 컨테이너를 실행하는 것이다. 사용자는 Docker 컨테이너 이미지를 패키징하여 배포하기만 하면 되며, 서버나 인프라스트럭처를 직접 프로비저닝하거나 관리할 필요가 없다. 이는 전통적인 가상 머신 기반 배포나 셀프 매니지드 쿠버네티스 클러스터 운영과는 차별화되는 접근 방식이다.

이 서비스는 완전 관리형 환경을 제공한다. 사용자가 업로드한 컨테이너 이미지를 기반으로 구글 클라우드 플랫폼이 모든 실행 환경, 네트워킹, 보안 패치, 운영 체제 관리를 자동으로 처리한다. 개발자는 애플리케이션 코드와 Dockerfile에만 집중할 수 있어 개발 생산성을 크게 높일 수 있다.

Cloud Run은 HTTP 요청을 처리하는 스테이트리스(stateless) 컨테이너의 실행에 최적화되어 있다. 컨테이너는 각 요청을 독립적으로 처리하도록 설계되어야 하며, 요청이 없을 때는 자원이 0으로 스케일 다운될 수 있다. 이러한 특성은 마이크로서비스 아키텍처나 이벤트 기반 애플리케이션 프로그래밍 인터페이스를 구현하는 데 매우 적합하다.

Cloud Run의 자동 확장 기능은 개발자가 인프라 용량을 직접 관리할 필요 없이 애플리케이션의 수요에 따라 리소스를 동적으로 조정할 수 있게 해준다. 이는 서버리스 컴퓨팅의 핵심 원칙을 구현한 것으로, 사용자는 실제로 처리한 요청과 리소스 소비량에 대해서만 비용을 지불한다.

이 서비스는 수신되는 HTTP 요청의 양에 따라 컨테이너 인스턴스의 수를 자동으로 늘리거나 줄인다. 요청이 없을 때는 인스턴스 수가 0으로 축소되어 비용이 발생하지 않으며, 트래픽이 급증하면 필요한 만큼의 인스턴스를 빠르게 생성하여 수요를 처리한다. 이러한 요청 기반 확장은 예측할 수 없는 트래픽 패턴을 가진 웹 애플리케이션이나 API에 특히 유용하다.

확장 정책은 최소 및 최대 인스턴스 수를 설정하여 제어할 수 있으며, 각 인스턴스가 동시에 처리할 수 있는 요청의 수(동시성)도 구성 가능하다. 이는 애플리케이션의 성능 요구사항과 비용 효율성을 균형 있게 맞추는 데 도움을 준다. 또한, 로드 밸런싱은 자동으로 처리되어 트래픽이 모든 활성 인스턴스에 고르게 분배된다.

이러한 자동화된 스케일링 관리 덕분에 개발자는 인프라스트럭처 프로비저닝이나 클러스터 관리와 같은 운영 부담에서 벗어나 애플리케이션 코드 개발에 집중할 수 있다. Cloud Run은 구글 클라우드 플랫폼의 다른 서비스와 통합되어 확장 이벤트에 대한 세부적인 모니터링과 로깅도 제공한다.

Cloud Run은 모든 서비스에 자동으로 전역 HTTPS 엔드포인트를 제공한다. 이는 구글이 관리하는 SSL/TLS 인증서를 통해 구현되며, 개발자가 별도로 인증서를 프로비저닝하거나 갱신할 필요가 없다. 각 서비스는 *.run.app 도메인을 기반으로 한 고유한 URL을 부여받으며, 이 URL은 기본적으로 HTTPS 프로토콜을 통해서만 접근할 수 있다.

사용자는 자신이 소유한 커스텀 도메인을 Cloud Run 서비스에 매핑할 수 있다. 이 과정에서도 구글 클라우드 플랫폼이 자동으로 DNS 검증과 SSL/TLS 인증서 발급 및 관리 작업을 처리한다. 이를 통해 사용자는 복잡한 인증서 관리 부담 없이도 자신의 브랜드 도메인으로 보안된 서비스를 제공할 수 있다.

이 HTTPS 엔드포인트는 로드 밸런싱과 글로벌 CDN인 Google Cloud CDN과의 통합을 지원한다. 이를 통해 전 세계 사용자에게 낮은 지연 시간으로 트래픽을 분산하고 안전하게 전달할 수 있다. 또한, IP 허용 목록이나 클라우드 아머를 통한 보안 정책을 쉽게 적용할 수 있어, API 게이트웨이 패턴 구현이나 내부 서비스 보호에 유용하게 활용된다.

Cloud Run은 애플리케이션의 상태를 파악하고 문제를 진단하는 데 필수적인 로깅과 모니터링 기능을 구글 클라우드 플랫폼의 핵심 서비스와 통합하여 제공한다. 배포된 서비스의 모든 표준 출력과 표준 오류 로그는 자동으로 Cloud Logging으로 전송되어 중앙 집중식으로 수집, 저장 및 분석된다. 이를 통해 개발자는 명령줄 인터페이스나 웹 콘솔을 통해 실시간으로 로그를 검색하고 필터링하여 애플리케이션 동작을 추적할 수 있다.

성능 및 운영 상태 모니터링은 Cloud Monitoring을 통해 이루어진다. Cloud Run 서비스는 자동으로 트래픽, 지연 시간, HTTP 응답 코드, 컨테이너 인스턴스 수, CPU 및 메모리 사용량과 같은 핵심 지표를 생성한다. 이러한 지표를 바탕으로 사용자는 대시보드를 구성하거나 특정 임계값을 초과할 때 알림을 받는 경보 정책을 설정하여 애플리케이션의 건강 상태를 사전에 관리할 수 있다.

이러한 통합 관리는 마이크로서비스 아키텍처 환경에서 특히 유용하다. 여러 개의 Cloud Run 서비스와 다른 구글 클라우드 제품(예: Cloud Storage, Pub/Sub)을 함께 사용하는 경우에도 모든 로그와 지표가 통합된 플랫폼에서 확인 가능하므로, 분산 시스템의 전반적인 흐름과 성능을 종합적으로 파악하는 데 도움이 된다.

Cloud Run은 컨테이너화된 애플리케이션을 배포하고 실행하기 위해 도커 호환 컨테이너 이미지를 사용한다. 사용자는 자신의 애플리케이션 코드와 종속성을 도커 파일을 통해 표준 OCI 이미지로 패키징한 후, 구글 클라우드 플랫폼의 컨테이너 레지스트리나 다른 공개 레지스트리에 이미지를 업로드한다. Cloud Run 서비스는 이 이미지를 가져와서 완전 관리형 환경에서 실행한다.

배포 과정은 구글 클라우드 SDK의 명령줄 도구나 구글 클라우드 콘솔 웹 인터페이스를 통해 수행된다. 사용자는 단일 명령어로 이미지 URL을 지정하여 서비스를 배포할 수 있으며, Cloud Run은 자동으로 이미지를 풀(pull)하고, 새로운 리비전을 생성하며, 트래픽을 해당 리비전으로 라우팅한다. 이 방식은 지속적 통합 및 지속적 배포 파이프라인과 쉽게 통합될 수 있다.

컨테이너 이미지는 애플리케이션의 실행 환경을 완벽하게 정의하므로, 개발자는 로컬에서 실행하는 환경과 클라우드 프로덕션 환경 사이의 차이를 걱정할 필요가 없다. Cloud Run은 HTTP 요청을 수신하는 웹 서버를 컨테이너 내에서 실행해야 하며, 이 서버는 지정된 포트(기본값 8080)에서 수신 대기(listen)하도록 구성되어야 한다.

Cloud Run의 요청 기반 확장은 서버리스 컴퓨팅의 핵심 원칙을 구현한 기능이다. 이는 애플리케이션이 수신하는 HTTP 요청의 양에 따라 인스턴스의 수가 동적으로 조절되는 것을 의미한다. 사용자 트래픽이 증가하면 플랫폼이 자동으로 새로운 컨테이너 인스턴스를 생성하여 부하를 분산시키고, 트래픽이 감소하면 사용하지 않는 인스턴스를 정리하여 리소스를 절약한다. 이 과정은 완전히 자동화되어 있어 개발자가 인프라 용량을 미리 프로비저닝하거나 스케일링 정책을 수동으로 구성할 필요가 없다.

확장 메커니즘은 제로 스케일링과 수평 확장을 포함한다. 요청이 전혀 없는 기간에는 서비스가 활성 인스턴스 없이도 실행 가능한 상태로 유지되며, 새로운 요청이 들어오면 플랫폼이 매우 빠르게 새 인스턴스를 시작한다. 동시에 많은 요청이 유입되면 여러 인스턴스에 걸쳐 부하를 분산시키는 수평 확장이 이루어진다. 확장의 상한은 구성 가능하며, 동시에 실행될 수 있는 최대 인스턴스 수를 설정할 수 있다.

이러한 요청 기반의 자동 확장 모델은 예측하기 어려운 트래픽 패턴을 가진 애플리케이션에 특히 유리하다. 예를 들어, 이벤트성 마케팅 캠페나나 특정 시간대에 집중되는 사용을 하는 웹 애플리케이션에서 유용하다. 사용자는 실제로 처리된 요청 수와 리소스 소비 시간에 대해서만 비용을 지불하므로, 유휴 상태의 인스턴스에 대한 비용이 발생하지 않아 경제적이다.

요청 기반 확장은 마이크로서비스 아키텍처와도 잘 맞는다. 각 서비스가 독립적으로 배포되고 확장될 수 있어, 특정 기능에 트래픽이 집중되더라도 해당 서비스만 확장하면 되므로 전체 시스템의 리소스 효율성을 높일 수 있다. 이는 구글 클라우드 플랫폼의 통합 로깅 및 모니터링 도구와 결합되어 애플리케이션의 성능과 확장 동작을 실시간으로 관찰하는 데 도움을 준다.

리비전 관리는 구글 클라우드 런에서 애플리케이션의 배포 단위를 관리하는 핵심 기능이다. 새로운 컨테이너 이미지를 배포할 때마다 새로운 리비전이 생성되며, 각 리비전은 고유한 URL을 가진 불변의 스냅샷이다. 이를 통해 사용자는 애플리케이션의 특정 버전을 독립적으로 실행하고 테스트할 수 있다.

이 시스템은 롤링 업데이트와 트래픽 분할을 지원한다. 사용자는 새 리비전으로 트래픽을 점진적으로 전환하거나, 특정 비율로 트래픽을 여러 리비전에 분배하여 카나리 배포를 수행할 수 있다. 또한 이전 리비전으로의 빠른 롤백이 가능하여 배포 실패 시 안전하게 복구할 수 있다.

리비전은 자동으로 관리되며, 사용자는 최대 1000개의 이전 리비전을 보존하도록 설정할 수 있다. 오래된 리비전은 자동으로 정리되어 불필요한 리소스 사용을 방지한다. 이러한 리비전 관리 체계는 지속적 배포와 데브옵스 워크플로우를 구현하는 데 필수적인 요소로 작동한다.

Cloud Run은 웹 애플리케이션과 API를 배포하고 실행하는 데 매우 적합한 플랫폼이다. 개발자는 Docker 컨테이너 이미지로 패키징된 애플리케이션 코드를 업로드하기만 하면, Cloud Run이 모든 인프라 관리, 네트워크 구성, 트래픽 라우팅을 자동으로 처리한다. 이를 통해 개발자는 서버 프로비저닝, 운영 체제 패치, 로드 밸런서 설정과 같은 운영 부담 없이 비즈니스 로직 개발에 집중할 수 있다.

이 플랫폼은 HTTP 요청을 직접 처리할 수 있는 모든 언어나 프레임워크로 작성된 애플리케이션을 지원한다. 예를 들어, Python의 Flask나 Django, Node.js의 Express, Java의 Spring Boot, Go 언어로 작성된 서버 등이 모두 호환된다. 애플리케이션은 표준 포트(기본값 8080)에서 수신 대기하기만 하면, Cloud Run이 자동으로 HTTPS 엔드포인트를 제공하고 도메인 이름 시스템과 연동하여 안전한 접근을 보장한다.

웹 애플리케이션과 API의 트래픽 패턴은 종종 변동성이 크다. Cloud Run의 핵심 장점은 이러한 변동에 완벽하게 대응하는 자동 확장 능력에 있다. 수신 요청이 없을 때는 인스턴스가 제로(0)으로 축소되어 비용이 발생하지 않으며, 요청이 들어오는 즉시 새로운 인스턴스를 빠르게 시작하여 응답한다. 트래픽이 급증하면 필요한 만큼의 인스턴스를 수평적으로 확장하여 성능을 유지하고, 트래픽이 줄어들면 다시 인스턴스를 정리한다.

이러한 특성은 프로토타입, 마케팅 캠페인용 랜딩 페이지, 주기적인 트래픽 피크를 보이는 이커머스 서비스, 또는 사용 빈도가 낮은 내부 관리 도구와 같은 다양한 웹 서비스에 이상적이다. 또한, 마이크로서비스 아키텍처에서 각 개별 서비스를 독립적으로 배포하고 관리하는 데에도 효과적으로 활용될 수 있다.

Cloud Run은 마이크로서비스 아키텍처를 구현하고 운영하는 데 적합한 플랫폼이다. 각 마이크로서비스를 독립적인 컨테이너 이미지로 패키징하여 Cloud Run에 배포할 수 있으며, 서비스 간의 통신은 HTTP 또는 gRPC 프로토콜을 통해 이루어진다. 이는 개발 팀이 서로 다른 언어와 프레임워크(예: Node.js, Python, Go)로 작성된 서비스를 독립적으로 개발, 배포, 확장할 수 있게 해준다.

Cloud Run의 핵심 장점은 서버리스 특성으로, 각 마이크로서비스의 인프라 관리와 스케일링이 완전히 자동화된다는 점이다. 트래픽이 증가하면 각 서비스 인스턴스가 개별적으로 확장되고, 요청이 없을 때는 0으로 축소되어 비용을 최적화한다. 이를 통해 복잡한 마이크로서비스 오케스트레이션 도구 없이도 각 서비스의 수명 주기를 쉽게 관리할 수 있다.

또한, Cloud Run은 구글 클라우드 플랫폼의 다른 서비스와의 긴밀한 통합을 제공한다. 마이크로서비스는 Cloud Pub/Sub을 통해 비동기 메시지를 교환하거나, Cloud SQL에 데이터를 저장하며, Cloud Endpoints를 통해 API 게이트웨이로 관리될 수 있다. 이러한 통합은 분산 시스템을 구성하는 데 필요한 보안, 관찰 가능성, 네트워킹 기능을 간소화한다.

결과적으로, Cloud Run은 빠른 개발 주기와 효율적인 리소스 활용이 요구되는 현대적인 마이크로서비스 기반 애플리케이션을 구축하기 위한 경량화된 대안을 제공한다. 특히, 쿠버네티스의 복잡성을 피하면서 컨테이너의 이점을 누리고자 하는 팀에게 유용하다.

Cloud Run은 웹 애플리케이션이나 API 서버 외에도, 일회성 또는 주기적으로 실행되는 배치 작업을 실행하는 데에도 적합한 플랫폼이다. 서버리스 특성상 사용자는 인프라스트럭처 관리 없이 컨테이너로 패키징된 작업 코드를 업로드하기만 하면 된다. 작업은 HTTP 요청을 통해 수동으로 트리거하거나, 구글 클라우드 스케줄러와 같은 서비스를 이용해 특정 시간이나 주기로 자동 실행되도록 설정할 수 있다. 작업이 완료되면 사용한 컴퓨팅 리소스에 대해서만 비용이 청구된다.

배치 작업의 실행 방식은 장시간 실행되는 웹 서비스와 다르다. Cloud Run은 작업을 실행할 컨테이너 인스턴스를 생성하고, 컨테이너 내의 정의된 진입점(Entrypoint)을 실행한다. 작업이 종료되면 해당 인스턴스도 자동으로 종료되어 리소스가 회수된다. 이는 데이터 처리, 이미지 변환, 보고서 생성, 데이터베이스 정리와 같은 백그라운드 태스크에 이상적이다.

이러한 배치 작업을 구성할 때는 작업 완료 또는 실패를 명확히 알리는 종료 코드를 반환하도록 애플리케이션을 설계하는 것이 중요하다. 또한, 타임아웃 설정을 통해 작업의 최대 실행 시간을 제한할 수 있으며, 작업 로그는 구글 클라우드 로깅에 자동으로 통합되어 실행 이력과 문제를 추적하는 데 활용된다.

구글 앱 엔진은 구글이 제공하는 완전 관리형 서버리스 플랫폼이다. 이 서비스는 개발자가 웹 애플리케이션이나 API를 배포하고 실행할 때 서버 인프라를 프로비저닝하거나 관리할 필요 없이 코드에만 집중할 수 있도록 설계되었다. 개발자는 표준 런타임 환경을 사용하거나 컨테이너 이미지를 제공하여 애플리케이션을 배포한다. 구글 앱 엔진은 트래픽에 따라 애플리케이션 인스턴스를 자동으로 확장하거나 축소하여 운영 부담을 줄이고 효율성을 높인다.

구글 앱 엔진은 주로 웹 애플리케이션 및 API 백엔드, 마이크로서비스 아키텍처 구현에 널리 사용된다. 또한 배치 작업이나 데이터 처리 파이프라인을 실행하는 데에도 활용할 수 있다. 이 서비스는 구글 클라우드 플랫폼의 다른 서비스인 클라우드 스토리지, 클라우드 SQL, 파이어스토어 등과의 긴밀한 통합을 제공하여 애플리케이션 개발을 단순화한다.

구글 클라우드 플랫폼 내에서 구글 앱 엔진은 구글 쿠버네티스 엔진 및 클라우드 런과 함께 컨테이너화된 애플리케이션을 실행하는 주요 옵션 중 하나로 자리 잡고 있다. 각 서비스는 관리 수준과 유연성 측면에서 차이를 보인다. 구글 앱 엔진은 높은 수준의 추상화와 자동 관리를 제공하는 반면, 구글 쿠버네티스 엔진은 더 많은 제어권과 유연성을, 클라우드 런은 순수한 서버리스 컨테이너 실행 환경을 중점적으로 제공한다.

Google Kubernetes Engine은 구글 클라우드 플랫폼에서 제공하는 완전 관리형 쿠버네티스 서비스이다. 이 서비스는 사용자가 컨테이너화된 애플리케이션을 쉽게 배포, 관리 및 확장할 수 있도록 쿠버네티스 클러스터의 운영 부담을 대신 처리한다. 사용자는 구글의 인프라를 활용하여 마스터 노드와 클러스터 운영을 자동화할 수 있으며, 애플리케이션 개발과 운영에 집중할 수 있다.

Google Kubernetes Engine의 주요 기능은 컨테이너 오케스트레이션이다. 서비스는 사용자가 정의한 YAML 또는 JSON 매니페스트 파일을 통해 애플리케이션의 배포, 서비스 디스커버리, 로드 밸런싱, 스토리지 볼륨 마운트, 보안 설정 등을 자동으로 관리한다. 또한 노드 풀을 구성하여 워커 노드의 머신 타입과 수를 지정할 수 있으며, 클러스터 오토스케일러를 활성화하여 워크로드 변화에 따라 노드 수를 자동으로 조정할 수 있다.

Google Kubernetes Engine은 Cloud Run과 비교할 때 더 많은 제어권과 유연성을 제공한다. Cloud Run이 완전한 서버리스 환경에서 단일 컨테이너 이미지를 실행하는 데 초점을 맞춘다면, Google Kubernetes Engine은 복잡한 다중 컨테이너 애플리케이션, StatefulSet, 사용자 정의 네트워크 정책, 특정 노드 선택 요구사항과 같은 고급 쿠버네티스 기능을 필요로 하는 워크로드에 적합하다. 이는 마이크로서비스 아키텍처를 구현하거나 기존 온프레미스 쿠버네티스 환경을 클라우드로 마이그레이션하는 경우에 특히 유용하다.

이 서비스는 구글 클라우드 플랫폼의 다른 서비스와 긴밀하게 통합되어 있다. 예를 들어, Cloud Load Balancing을 위한 Ingress 컨트롤러, Cloud Monitoring 및 Cloud Logging을 통한 관찰 가능성, 그리고 Cloud Build를 활용한 지속적 통합/지속적 배포 파이프라인 구축이 가능하다. 또한 Istio를 기반으로 한 Anthos Service Mesh와의 통합을 통해 서비스 메시 기능을 구현할 수 있다.

AWS Fargate는 아마존 웹 서비스가 제공하는 서버리스 컴퓨트 엔진으로, 컨테이너를 실행하기 위한 인프라를 직접 관리할 필요 없이 애플리케이션을 배포하고 확장할 수 있게 해준다. 사용자는 애플리케이션을 도커 컨테이너로 패키징하기만 하면 되며, 서버 프로비저닝, 패치 관리, 용량 계획 등 기본적인 인프라 관리 작업은 Fargate가 자동으로 처리한다. 이는 AWS의 컨테이너 오케스트레이션 서비스인 Amazon ECS 또는 Amazon EKS와 함께 사용된다.

Fargate의 핵심 특징은 진정한 서버리스 경험을 제공한다는 점이다. 사용자는 실행할 컨테이너에 필요한 CPU와 메모리 용량만 지정하면 되며, 이를 기반으로 Fargate가 적절한 컴퓨팅 리소스를 할당한다. 이는 Google Cloud Run이 HTTP 요청을 기반으로 컨테이너 인스턴스를 자동으로 확장하는 방식과는 차이가 있다. Fargate는 장기 실행되는 백엔드 서비스나 마이크로서비스와 같이 지속적으로 실행되어야 하는 워크로드에 더 적합한 모델이다.

Fargate의 작동 방식은 사용자가 태스크 정의를 통해 컨테이너 이미지, 리소스 요구사항, 네트워크 구성을 명시하는 것이다. 이후 Amazon ECS나 Amazon EKS를 통해 이 태스크를 실행하면, Fargate가 이를 수용할 격리된 환경을 자동으로 프로비저닝하고 관리한다. 사용자는 가상 머신이나 클러스터의 상태를 모니터링할 필요 없이 애플리케이션 로직 자체에만 집중할 수 있다.

주요 사용 사례로는 웹 애플리케이션, API 서버, 데이터 처리 배치 작업, 마이크로서비스 아키텍처 등이 있다. 특히 인프라 관리 부담을 줄이면서도 컨테이너의 이점과 AWS의 광범위한 서비스 생태계를 활용하고자 하는 조직들에게 유용한 서비스이다.

Cloud Run을 사용하기 위해서는 몇 가지 필수 조건을 충족해야 한다. 먼저, 구글 클라우드 플랫폼 계정이 필요하며, 이 계정을 통해 프로젝트를 생성하고 빌링을 설정해야 한다. Cloud Run은 사용량에 따라 요금이 부과되는 서비스이기 때문이다.

애플리케이션을 컨테이너 이미지로 패키징할 수 있어야 한다. 이를 위해서는 Dockerfile을 작성하고, Docker를 사용하여 로컬에서 이미지를 빌드하고 테스트하는 것이 일반적인 첫 단계이다. 애플리케이션 코드와 함께 이 Dockerfile이 Cloud Run에 서비스를 배포하는 데 필요한 핵심 요소가 된다.

또한, 명령줄에서 작업을 수행하기 위해 구글 클라우드 SDK를 설치하고 초기화해야 한다. 특히 gcloud 명령어 도구와 gcloud run deploy 명령어를 사용하게 된다. 대안으로 구글 클라우드 콘솔 웹 인터페이스를 통해 시각적으로 서비스를 배포할 수도 있다.

마지막으로, 애플리케이션이 HTTP 요청을 수신 대기하도록 구성되어 있어야 한다. Cloud Run은 요청을 수신하면 컨테이너 인스턴스를 시작하고, 정의된 포트(기본값 8080)로 들어오는 트래픽을 애플리케이션에 전달하는 방식으로 동작한다.

첫 번째 서비스를 배포하는 과정은 구글 클라우드 SDK의 gcloud 명령줄 도구를 사용하거나 구글 클라우드 콘솔의 웹 인터페이스를 통해 진행할 수 있다. 기본적인 절차는 먼저 컨테이너 이미지를 빌드하고 구글 컨테이너 레지스트리에 푸시한 후, Cloud Run에 해당 이미지를 배포하는 것이다. 개발자는 Dockerfile을 작성하여 애플리케이션을 컨테이너화하고, gcloud builds submit 명령으로 이미지를 빌드 및 업로드할 수 있다.

이미지가 준비되면 gcloud run deploy 명령을 실행하여 서비스를 배포한다. 이 명령을 실행할 때 서비스 이름, 리전, 그리고 트래픽을 새 리비전으로 전환할지 여부 등을 지정할 수 있다. 배포가 성공적으로 완료되면 Cloud Run은 자동으로 서비스에 대한 고유하고 보안된 HTTPS 엔드포인트 URL을 제공한다. 이 URL을 통해 배포된 애플리케이션에 즉시 접근할 수 있다.

초기 배포 시에는 기본 구성으로 충분할 수 있으며, 필요에 따라 환경 변수, 메모리 할당량, 동시성 설정, 최대 인스턴스 수 등을 나중에 조정할 수 있다. 또한 소스 코드 저장소와의 연동을 통해 지속적 배포 파이프라인을 구성하여, 코드 변경 사항이 자동으로 빌드되고 Cloud Run에 배포되도록 설정하는 것도 가능하다.