Configuring Cloud Run Services

Introduction and Goal

In the previous lesson, you learned about the fundamental concepts of Google Cloud Run and its serverless model. You've also practiced deploying Cloud Run services using the gcloud run deploy command with default settings. While those services work perfectly, production workloads often require specific resource allocations and scaling configurations to optimize performance and cost. In this lesson, you'll take your service configuration skills to the next level by learning about resource allocation and scaling settings . These concepts determine how your containers utilize compute resources and respond to traffic, giving you control over cost optimization and performance. By the end of this lesson, you'll understand how to configure CPU allocation, memory limits, concurrency settings, and scaling parameters that match your application's needs. Your main goal is to create Cloud Run services with explicit resource and scaling configurations and inspect their settings using gcloud commands. This hands-on approach will help you understand how Cloud Run manages resources and prepare you to make informed decisions about container deployment strategies in real-world scenarios.

Resource Allocation in Cloud Run

When you deploy containers on Cloud Run, you must specify resource allocation settings that determine how much CPU and memory your container instances receive. Think of resource allocation as defining the compute capacity available to each container instance. The resources you allocate affect everything from cost to performance and response times. CPU allocation in Cloud Run comes in two modes: CPU is always allocated and CPU is only allocated during request processing . When CPU is always allocated, your container has continuous access to CPU resources even when not handling requests, which is ideal for background processing or applications that need to maintain state. When CPU is only allocated during request processing (the default), you only pay for CPU while actively handling requests, making it more cost-effective for request-driven workloads. Memory limits define the maximum amount of RAM available to each container instance. Cloud Run supports memory allocations from 128 MiB to 32 GiB, depending on your application's needs. Key considerations include: Application requirements : Choose memory based on your application's actual needs, including any in-memory caching or data processing. Cost efficiency : You pay for the memory you allocate, so right-sizing is important. Performance : Insufficient memory leads to container restarts and errors, while excessive allocation wastes resources. The trade-offs are clear: Higher resource allocations provide better performance and can handle more complex workloads, but increase costs. Lower allocations reduce costs but may limit your application's capabilities. Cloud Run excels at allowing you to fine-tune these settings to match your specific workload characteristics.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Concurrency and Scaling Settings

Concurrency determines how many simultaneous requests a single container instance can handle. This setting is crucial for optimizing resource utilization and cost. Cloud Run supports concurrency values from 1 to 1,000, with 80 as the default.

Setting concurrency to 1 means each container instance handles only one request at a time, which is ideal for applications that aren't thread-safe or need exclusive access to resources. Higher concurrency values allow multiple requests to be processed simultaneously by the same container instance, reducing the number of instances needed and lowering costs for applications that can safely handle concurrent requests.

It's important to consider the trade-off between throughput and latency. While a higher concurrency setting increases the number of requests a single instance can handle (improving throughput and reducing costs), it can also increase the processing time for each individual request. If an instance is overloaded, requests may queue up and eventually exceed the configured request timeout, leading to errors. Therefore, you must balance concurrency with your application's ability to process requests efficiently to avoid increased latency and timeouts.

Scaling settings control how Cloud Run automatically adjusts the number of container instances based on incoming traffic. These settings include:

Minimum instances: The number of container instances kept running even with no traffic. Setting a minimum greater than 0 reduces cold start latency but increases costs since you pay for idle instances.
Maximum instances: The upper limit on container instances, preventing runaway scaling and controlling costs. This also helps you stay within quota limits.

Cloud Run automatically scales between your minimum and maximum based on incoming request volume and the concurrency setting. If each instance can handle 80 concurrent requests and you receive 800 requests simultaneously, Cloud Run will scale up to 10 instances (assuming no minimum/maximum constraints).

Understanding the relationship between concurrency and scaling is essential: Higher concurrency means fewer instances are needed for the same traffic volume, while lower concurrency requires more instances but provides better isolation between requests.

Create a Service with Resource Configuration

Now let's create a Cloud Run service with explicit resource and scaling configuration. This approach gives you precise control over how your service utilizes compute resources and responds to traffic patterns.

Shell

gcloud run deploy my-service \
  --image gcr.io/cloudrun/hello \
  --region us-central1 \
  --cpu 1 \
  --memory 512Mi \
  --concurrency 80 \
  --min-instances 0 \
  --max-instances 10

gcloud run deploy my-service \
  --image gcr.io/cloudrun/hello \
  --region us-central1 \
  --cpu 1 \
  --memory 512Mi \
  --concurrency 80 \
  --min-instances 0 \
  --max-instances 10

This command creates a service named my-service using the gcr.io/cloudrun/hello container image. The --cpu 1 parameter allocates 1 vCPU to each container instance, while --memory 512Mi sets the memory limit to 512 MiB. The --concurrency 80 setting allows each instance to handle up to 80 simultaneous requests. The scaling parameters --min-instances 0 and --max-instances 10 configure the service to scale from zero (no idle instances) up to a maximum of 10 instances.

When you run this command, you'll see output similar to this:

text

Deploying container to Cloud Run service [my-service] in project [my-project] region [us-central1]
✓ Deploying new service... Done.
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [my-service] revision [my-service-00001-abc] has been deployed and is serving 100 percent of traffic.
Service URL: https://my-service-abc123-uc.a.run.app

Deploying container to Cloud Run service [my-service] in project [my-project] region [us-central1]
✓ Deploying new service... Done.
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [my-service] revision [my-service-00001-abc] has been deployed and is serving 100 percent of traffic.
Service URL: https://my-service-abc123-uc.a.run.app

The service is now running with your specified resource configuration. Cloud Run will automatically scale instances between 0 and 10 based on incoming traffic, with each instance capable of handling 80 concurrent requests using 1 vCPU and 512 MiB of memory.

Introduction and Goal

Resource Allocation in Cloud Run

Join the 1M+ learners on CodeSignal

Concurrency and Scaling Settings

Create a Service with Resource Configuration

Configure CPU Allocation Mode

Understanding CPU Boost

Inspect and Compare Service Configurations

Update Existing Service Configuration

Summary and What's Next