Khi triển khai một API hoặc ứng dụng web lên Google Cloud, nhiều người thường nghĩ ngay đến Kubernetes hoặc Virtual Machine. Tuy nhiên, không phải ứng dụng nào cũng cần một hạ tầng phức tạp như vậy.

Với Cloud Run, bạn chỉ cần cung cấp một container image, còn việc triển khai, mở rộng và vận hành sẽ được Google Cloud tự động xử lý.

Nhưng phía sau sự đơn giản đó, Cloud Run thực sự hoạt động như thế nào?Với những ứng dụng như REST API, backend service hay webhook, đôi khi chúng ta chỉ cần chạy một container và để nền tảng lo phần còn lại.

Bạn chỉ cần cung cấp container image, còn việc chạy container và quản lý hạ tầng sẽ do Google Cloud đảm nhiệm.

Nhưng phía sau sự đơn giản đó, Cloud Run phải liên tục đưa ra nhiều quyết định để đảm bảo ứng dụng luôn sẵn sàng và tối ưu chi phí.

Trong bài viết này, chúng ta sẽ cùng tìm hiểu:

• 🚀 Khi nào Cloud Run khởi động container?

• 📈 Khi nào Cloud Run scale out để xử lý tải?

• 💰 Vì sao Cloud Run có thể Scale to Zero và giúp tiết kiệm chi phí?

Cloud Run là gì?

Cloud Run là dịch vụ Serverless Container của Google Cloud cho phép chạy container mà không cần quản lý Virtual Machine hay Kubernetes Cluster.

Build Container → Push Image → Deploy lên Cloud Run.

Sau khi triển khai, Cloud Run sẽ tự động quản lý môi trường chạy ứng dụng (runtime), bao gồm:

• HTTPS Endpoint

• Request Routing

• Container Runtime

• Autoscaling

• Scale to Zero

• Monitoring & Logging

Bạn chỉ cần tập trung phát triển và triển khai ứng dụng.

Hành trình của một Request

Điều thú vị nhất của Cloud Run bắt đầu từ chính request đầu tiên.

Client → Google Load Balancer → Cloud Run → Warm Instance hoặc Cold Start.

Ngay sau khi request đến, Cloud Run sẽ kiểm tra:

Đã có container nào sẵn sàng xử lý request này chưa?

Nếu câu trả lời là Có, request sẽ được chuyển ngay tới instance đang hoạt động.

Nếu câu trả lời là Không, Cloud Run phải khởi động một container mới trước khi ứng dụng có thể xử lý request.

Chính quyết định này tạo nên khái niệm Cold Start.

Cold Start — Khi Cloud Run phải tạo Instance mới

Nếu dịch vụ vừa được deploy hoặc đã không có traffic trong một khoảng thời gian, Cloud Run có thể đã Scale to Zero.

Điều đó có nghĩa là hiện tại không còn container nào đang chạy.

Request đầu tiên sẽ kích hoạt toàn bộ quá trình khởi động.

Trong suốt quá trình này, request sẽ được giữ lại.

Cloud Run chỉ chuyển request vào container khi ứng dụng đã thực sự lắng nghe trên cổng (PORT) được cấu hình.

Thời gian Cold Start phụ thuộc vào nhiều yếu tố:

• Kích thước container image

• Thời gian khởi động ứng dụng

• CPU và Memory được cấp

• Ngôn ngữ và framework sử dụng

Nếu ứng dụng yêu cầu phản hồi nhanh ngay từ request đầu tiên, bạn có thể:

• Giữ Minimum Instances = 1

• Tối ưu startup time

• Hoặc sử dụng Instance-based Billing

Một Instance xử lý được bao nhiêu Request?

Cloud Run cho phép nhiều request được xử lý đồng thời trên cùng một instance.

Khái niệm này được gọi là Concurrency.

Nhiều request cùng đi vào một container và được xử lý song song.

Autoscaling — Cloud Run quyết định khi nào cần thêm Instance

Một trong những điểm mạnh nhất của Cloud Run là khả năng tự động mở rộng.

Khi Concurrency tăng lên và các instance hiện tại đã đạt giới hạn concurrency, Cloud Run sẽ Scale Out bằng cách tạo thêm instance mới.

Traffic tăng → Scale Out , Traffic giảm → Scale In

Bạn tự cấu hình con số này tùy theo đặc điểm ứng dụng. Instance mới chỉ được tạo khi số request vượt ngưỡng đã set — nếu set concurrency = 80, request thứ 81 mới kích hoạt scale out.

Concurrency set trên Cloud Run không phản ánh số request mà ứng dụng thực sự xử lý được cùng lúc — con số đó phụ thuộc vào số worker bên trong ứng dụng.

Lấy ví dụ Laravel + PHP-FPM với cấu hình:

Cloud Run Concurrency = 80   ← Cloud Run sẵn sàng gửi 80 request vào instance
pm.max_children       = 20   ← PHP-FPM chỉ có 20 worker để xử lý

Khi 80 request đổ vào cùng lúc, điều xảy ra bên trong là:

• 20 request được PHP-FPM worker nhận và xử lý ngay

• 60 request xếp hàng bên trong container, chờ worker rảnh

• Cloud Run nhìn vào thấy instance đang nhận đúng 80 request — vẫn trong ngưỡng, không có gì bất thường, không tạo thêm instance

• Nếu API xử lý đủ nhanh, worker giải phóng liên tục, 60 request kia được tiêu hoá kịp thời và người dùng không cảm nhận được sự chờ đợi. Vấn đề chỉ xuất hiện khi API chậm — worker bị chiếm lâu, queue tích lũy, latency tăng dần — trong khi Cloud Run vẫn không tạo thêm instance vì ngưỡng concurrency chưa bị vượt.

Không có con số concurrency nào đúng cho mọi hệ thống. Hãy cân nhắc dựa trên đặc điểm ứng dụng, số worker thực tế và response time trung bình để set concurrency phù hợp cho từng service.

Cloud Run tính phí như thế nào?

Cloud Run hiện hỗ trợ hai chế độ billing.

Request-based Billing (mặc định)

Cloud Run tính phí dựa trên ba thành phần:

• vCPU-second

• GiB-second (RAM)

• Số lượng request

Thời gian sử dụng vCPU và RAM được tính theo 100 ms, làm tròn lên cho mỗi khoảng thời gian tính phí.

Trong chế độ này, vCPU và RAM chỉ được tính phí khi instance đang xử lý request. Khi instance ở trạng thái idle, Cloud Run không tính phí CPU và chỉ tính RAM nếu bạn bật minimum instances (nếu không có minimum instances thì instance có thể scale về 0 và không phát sinh chi phí).

Khi Cloud Run scale out, mỗi instance mới xử lý một phần request và được tính phí độc lập. Tổng chi phí tăng theo lượng tài nguyên thực tế được sử dụng và số request được phục vụ.

Instance-based Billing

Cloud Run tính phí vCPU và RAM trong toàn bộ thời gian instance tồn tại, bao gồm cả lúc đang xử lý request và lúc idle.

Khi Cloud Run scale out, tất cả các instance đều được tính phí liên tục cho đến khi bị dừng. Đổi lại, đơn giá vCPU và RAM thường thấp hơn so với Request-based Billing và không tính phí theo số lượng request.

Với request-based, scale out không lo chi phí idle. Với instance-based, mỗi instance thêm là chi phí cố định phát sinh ngay — phù hợp khi traffic đều và ổn định.

Lời kết

Cloud Run mang đến trải nghiệm triển khai container rất đơn giản, nhưng phía sau mỗi request là cả một quy trình tự động được Google Cloud quản lý.

Từ việc kiểm tra instance, khởi động container khi cần, xử lý đồng thời nhiều request trên cùng một instance cho đến tự động mở rộng hoặc thu hẹp theo lưu lượng — tất cả đều diễn ra mà bạn không cần quản lý máy chủ hay Kubernetes.

Hiểu được vòng đời của một request sẽ giúp bạn lý giải những hiện tượng thường gặp như Cold Start, biết khi nào nên cấu hình Minimum Instances, điều chỉnh Concurrency hợp lý và lựa chọn chế độ Billing phù hợp với ứng dụng.

Đó cũng chính là chìa khóa để xây dựng các dịch vụ serverless vừa có hiệu năng tốt, vừa tối ưu chi phí trên Google Cloud.