Cách Nango chạy mã không tin cậy của khách hàng ở quy mô lớn: Từ Sandbox đến AWS Lambda

Phần mềm09 tháng 6, 2026·5 phút đọc

Nango xử lý hơn 150 triệu hàm mỗi tháng từ mã khách hàng không tin cậy, đòi hỏi kiến trúc bảo mật nghiêm ngặt. Bài viết chia sẻ hành trình chuyển đổi từ sandbox trong quy trình sang AWS Lambda để đảm bảo cách ly an toàn, cùng những đánh đổi về hiệu suất và bài học kinh nghiệm quý báu.

Cách Nango chạy mã không tin cậy của khách hàng ở quy mô lớn: Từ Sandbox đến AWS Lambda

Nango là nền tảng tích hợp API cho phép khách hàng kết nối ứng dụng với hàng trăm dịch vụ như Salesforce, Google Calendar hay Slack. Tuy nhiên, thách thức lớn nhất của họ không phải là kết nối, mà là chạy mã do khách hàng viết — một loại mã hoàn toàn "không tin cậy" có thể cố tình phá vỡ hệ thống, rò rỉ dữ liệu hoặc tiêu tốn tài nguyên. Mỗi tháng, Nango thực thi hơn 150 triệu hàm như vậy.

Hạ tầng công nghệHạ tầng công nghệ

Yêu cầu khắt khe cho môi trường chạy mã

Nango phải xử lý ba loại khối lượng công việc rất khác nhau: các cuộc gọi theo yêu cầu (Actions) cần tốc độ nhanh, các tác vụ chạy dài (Syncs) đồng bộ dữ liệu trong hàng giờ, và các sự kiện webhook đến bất ngờ. Đặc biệt, việc chạy mã không tin cậy đặt ra các yêu cầu bảo mật nghiêm ngặt:

  • Cách ly khỏi hệ thống: Mã khách hàng không được phép chạm vào cơ sở dữ liệu, bí mật hoặc mạng nội bộ của Nango.
  • Cách ly giữa các khách hàng: Mã của khách hàng này không được ảnh hưởng đến khách hàng khác.
  • Chi phí và tính đàn hồi: Hệ thống phải tự động mở rộng quy mô mà không tốn chi phí cho tài nguyên nhàn rỗi.

Bài học từ vm2: Sandbox không phải là biên giới bảo mật

Trong những năm đầu, Nango sử dụng vm2, một sandbox Node.js chạy trong cùng một tiến trình với worker. Cách tiếp cận này đơn giản và hiệu quả về mặt hiệu suất, nhưng đến năm 2023, vm2 bị khai thác bởi các lỗ hổng "sandbox escape". Điều này cho thấy một bài học đắt giá: sandbox trong cùng một tiến trình không phải là biên giới bảo mật thực sự. Chia sẻ tiến trình với mã không tin cậy đồng nghĩa với việc bạn chỉ cách một bước chân khỏi thảm họa bảo mật.

Chuyển sang kiến trúc Runner riêng biệt

Để khắc phục, Nango tách hệ thống thành hai phần: Dispatcher (phân phối) và Runner (thực thi). Mỗi khách hàng có runner riêng, chạy trên dịch vụ đám mây Render. Runner không có quyền truy cập trực tiếp vào cơ sở dữ liệu; mọi thao tác lưu trữ phải đi qua một dịch vụ persist riêng biệt qua mạng.

Mặc dù cải thiện bảo mật, mô hình runner gặp vấn đề về sự công bằng tài nguyên. Một tác vụ nặng có thể chiếm dụng tài nguyên và làm "đói" các tác vụ khác của cùng một khách hàng, đồng thời gây khó khăn trong việc quan sát và debug lỗi.

Điện toán đám mây và bảo mậtĐiện toán đám mây và bảo mật

Giải pháp cuối cùng: AWS Lambda và cách ly thuê bao

Cuối năm 2025, Nango chuyển sang AWS Lambda. Mỗi lần thực thi chạy trong một microVM ảo hóa phần cứng riêng biệt, cung cấp cách ly mạnh mẽ hơn nhiều so với việc chia sẻ tiến trình. Điều này giúp giải quyết vấn đề quan sát tài nguyên và ngăn chặn một hàm lỗi ảnh hưởng đến các hàm khác.

Tuy nhiên, AWS Lambda có giới hạn thời gian chạy tối đa 15 phút, trong khi các tác vụ đồng bộ của Nango có thể kéo dài hàng giờ. Giải pháp của họ là giới hạn mỗi lần chạy 10 phút và sử dụng tính năng "checkpoint" để tác vụ có thể tiếp tục từ điểm dừng thay vì chạy một mạch dài.

Thách thức về khởi động nguội (Cold Starts)

Lambda tái sử dụng môi trường để duy trì tốc độ (warm start), nhưng đối với mã không tin cậy, việc tái sử dụng môi trường giữa các khách hàng khác nhau tạo ra rủi ro bảo mật. Nếu mã của khách hàng A thoát ra được sandbox, nó có thể truy cập vào thông tin của khách hàng B tiếp theo.

Nango giải quyết bằng cách "ghim" (pin) hàm Lambda cho từng khách hàng. Môi trường ấm chỉ được tái sử dụng cho cùng một khách hàng. Đánh đổi của phương án này là tỷ lệ khởi động nguội tăng từ dưới 1% lên khoảng 9%. Để giảm thiểu tác động, họ giữ các hàm của khách hàng trả phí ở trạng thái ấm bằng cách gửi các yêu cầu no-op định kỳ.

Lập trình và kiến trúc hệ thốngLập trình và kiến trúc hệ thống

Bài học kinh nghiệm

Hành trình của Nango mang lại nhiều bài học quý giá cho các kỹ sư xây dựng hệ thống xử lý mã không tin cậy:

  • Hiểu rõ biên giới bảo mật: Đừng tin tưởng vào sandbox trong quy trình; chúng có thể bị phá vỡ.
  • Vẽ đường ranh giới dựa trên nhu cầu sản phẩm: Xác định rõ đâu là điểm không được vượt qua (ví dụ: mã khách hàng không được chạm vào hệ thống nội bộ).
  • Ưu tiên công việc có thể tiếp tục: Thay vì cố gắng chạy một tác vụ dài 24 giờ, hãy chia nhỏ nó thành các đoạn có thể khôi phục. Điều này tốt hơn cho việc xử lý giới hạn tốc độ và khả năng chịu lỗi.

Chạy mã của người khác một cách an toàn là một công việc chưa bao giờ kết thúc. Nango hiện đang tìm cách tăng cường cách ly xuống cấp độ từng hàm mã lệnh để đảm bảo an toàn tuyệt đối ngay cả khi xảy ra sự cố.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗