Cloud Run: đưa dịch vụ container lên Google Cloud của khách mà không cần dựng cụm

Thử hình dung: khách cấp cho bạn một project Google Cloud, một service account và hai tuần để chạy pilot. Không ai trong đội của họ muốn vận hành thêm một cụm Kubernetes. Trong tình huống này, Cloud Run thường là đường ngắn nhất, nhưng bạn chỉ nên chọn nó khi đã biết nó có thể hỏng ở đâu.

Google mô tả Cloud Run là nền tảng ứng dụng được quản lý hoàn toàn, chạy được code, function hoặc container. Với FDE, điểm đáng giá nhất là tài liệu khẳng định bạn không cần tạo cụm hay quản lý hạ tầng mà vẫn làm được việc.

Khi làm việc tại chỗ khách, mỗi ngày không phải đi xin quyền dựng hạ tầng là thêm một ngày dành cho bài toán thật.

Service chờ request, job chạy tới khi xong

Service đứng chờ request gửi tới. Job dành cho các tác vụ song song hoá được, chạy thủ công hoặc theo lịch cho tới khi xong.

Một bài blog năm 2019 của Google coi Cloud Run là nơi lý tưởng cho microservice container không trạng thái, tức loại không cần các tính năng Kubernetes như namespace hay quản lý node. Bài đã cũ nên chi tiết sản phẩm có thể đã khác. Dù vậy, “dịch vụ này có giữ trạng thái không?” vẫn là câu nên hỏi đầu tiên.

Một pilot cụ thể, đi từng bước

Thử hình dung khách là một công ty bảo hiểm cần trích xuất thông tin từ hồ sơ bồi thường. Bạn có hai phần: một API nhận file từ hệ thống nội bộ, và một tác vụ ban đêm xử lý lại toàn bộ hồ sơ tồn đọng. API là một Cloud Run service, còn tác vụ ban đêm là một Cloud Run job chạy theo lịch.

Image của bạn nên nằm ở đâu? Google khuyến nghị Artifact Registry và nói chỉ nên dùng Docker Hub cho các image phổ biến. Image do bạn tự build cho khách không thuộc nhóm đó, nên hãy đẩy nó vào Artifact Registry ngay trong project của khách.

Một chi tiết nhỏ nhưng hữu ích: Cloud Run nhập image vào lúc deploy và không kéo lại từ registry mỗi khi khởi động instance mới. Nhờ vậy, nếu registry gặp trục trặc đúng lúc dịch vụ cần scale lên thì việc scale cũng không bị ảnh hưởng. Đây là điều nên ghi vào runbook bàn giao cho đội vận hành của khách.

Khách muốn dịch vụ nằm trong mạng nội bộ

Công ty bảo hiểm nào cũng sẽ hỏi: hồ sơ khách hàng có đi qua internet không? Câu trả lời nằm ở cài đặt ingress. Ở chế độ All, mọi request đều được nhận, kể cả request từ internet gọi thẳng tới URL run.app.

Ở chế độ Internal, request từ các nguồn khác, kể cả internet, không tới được dịch vụ qua URL run.app, URL tùy chỉnh hay domain tùy chỉnh.

Vì vậy, ngay buổi họp đầu tiên, hãy hỏi khách hệ thống nào sẽ gọi API của bạn và nó nằm ở đâu trong mạng của họ. Sau đó đối chiếu câu trả lời với định nghĩa nguồn internal trong tài liệu ingress, đừng đợi tới ngày go-live mới làm.

Co về 0: tiết kiệm, nhưng phải trả bằng cold start

Khi service không có request nào, Cloud Run gỡ luôn cả instance cuối cùng. Vì thế request mới tới sẽ cần một instance mới, và tài liệu Google xác nhận có lúc request phải chờ instance khởi động xong mới được xử lý. Một bài blog năm 2020 của Google cũng thừa nhận các nền tảng serverless từ lâu chấp nhận đánh đổi độ trễ của phản hồi đầu tiên.

Theo tài liệu, request có thể phải chờ tối đa 3,5 lần thời gian khởi động trung bình của instance, hoặc 10 giây, tùy giá trị nào lớn hơn. Ví dụ, nếu container của bạn khởi động trung bình mất 2 giây thì 3,5 lần là 7 giây.

Con số này nhỏ hơn 10, nên request có thể phải chờ tới 10 giây. Nếu buổi demo sáng thứ Hai là request đầu tiên sau cả cuối tuần, người phải chờ chính là khách.

Một lịch gọi “làm ấm” chạy trước giờ demo cũng không đủ chắc chắn, vì nếu sau lần gọi đó không còn request nào thì instance cuối cùng vẫn có thể bị gỡ.

Cách Google khuyến nghị để giảm cold start là đặt minimum instances. Một hướng dẫn độc lập trên blog của OneUptime nhắc đến cái giá: các instance chờ sẵn không xử lý request được tính tiền ở mức thấp hơn, nhưng không miễn phí.

Với buổi demo quan trọng, bạn đang đổi một ít chi phí lấy độ trễ, và nên nói rõ khoản đánh đổi này với người duyệt ngân sách của khách.

Khi nào nên dừng lại và chọn GKE

Kiến trúc tham chiếu của Google so sánh Cloud Run với GKE Autopilot và ghi rõ một đánh đổi: Cloud Run không hỗ trợ Kubernetes. Nếu ứng dụng của khách cần namespace hay quản lý node, đừng cố ép nó lên Cloud Run.

Những lỗi dễ mắc ở pilot đầu tiên

Phần lớn rắc rối với Cloud Run không nằm ở bản thân công cụ mà ở những câu hỏi không được đặt ra đủ sớm.

Lỗi	Vì sao gây hại	Làm gì thay
Dùng service cho tác vụ batch	Việc chạy tới khi xong là phần của job	Tách việc xử lý hàng loạt thành job, chạy thủ công hoặc theo lịch
Hỏi muộn xem ai sẽ gọi dịch vụ	Với ingress Internal, internet không gọi được URL run.app	Hỏi ngay buổi họp đầu và kiểm tra trước go-live
Tin vào lịch “làm ấm” mà không thử	Instance vẫn có thể bị gỡ khi không còn request	Cân nhắc min instances, diễn tập và đo request đầu tiên
Để image riêng trên Docker Hub	Google chỉ khuyên dùng Docker Hub cho image phổ biến	Dùng Artifact Registry
Ép ứng dụng cần Kubernetes lên Cloud Run	Cloud Run không hỗ trợ Kubernetes	Xem GKE Autopilot cho phần đó

Học gì trước

Hãy bắt đầu từ container: viết Dockerfile gọn, chạy được ở máy local và giữ dịch vụ không trạng thái. Sau đó nắm cho chắc sự khác nhau giữa service và job, rồi tới ingress, vì đó là chỗ đội bảo mật của khách sẽ soi kỹ nhất. Cuối cùng, tự đo cold start trên dịch vụ của chính bạn.

Trong CV, đừng chỉ ghi “Google Cloud”. Hãy viết một dòng cụ thể, chẳng hạn: deploy API trích xuất tài liệu lên Cloud Run với ingress Internal, kèm một job xử lý hàng đêm, đặt min instances để giảm cold start trong giờ demo.

Khi đọc mô tả công việc thấy yêu cầu triển khai trên GCP của khách, đó chính là câu chuyện bạn nên chuẩn bị sẵn để kể.

Cloud Run không làm thay bạn phần khó nhất của nghề, tức là hiểu mạng và quy trình của khách. Nhưng nó gánh bớt phần hạ tầng, để bạn có thêm thời gian cho phần khó đó.