Upstash bắt đầu hành trình với sứ mệnh trở thành lựa chọn cơ sở dữ liệu tốt nhất cho AWS Lambda functions. Trong khi đó, chúng tôi phát hiện một lựa chọn tuyệt vời khác để xây dựng serverless functions: Cloudflare Workers. Đây là sản phẩm thú vị vì hứa hẹn độ trễ tốt hơn khắp thế giới với chi phí thấp hơn và không cold starts. Nhưng nó có nhiều hạn chế khi so sánh với AWS Lambda. Những hạn chế bổ sung làm danh sách các lựa chọn cơ sở dữ liệu ngắn lại. Chúng tôi thấy đây là cơ hội để định vị Upstash như giải pháp tuyệt vời cho câu hỏi: CF Workers là stateless. Nên lưu dữ liệu ở đâu?
Thách thức
Khả năng truy cập
Cloudflare Workers là môi trường khép kín hơn. Không giống AWS. Bạn không thể tự thiết lập cơ sở dữ liệu vào cùng region và truy cập qua VPC. Vì vậy cần truy cập cơ sở dữ liệu từ hàm Workers. Cloudflare Workers dùng V8 Isolates làm runtime. Nó không cho phép kết nối TCP. Vì vậy cơ sở dữ liệu phải truy cập được qua HTTP.
Sao chép Toàn cầu
Workers có lợi thế triển khai khắp nơi. Trong khi hàm của bạn truy cập được với độ trễ thấp từ khắp thế giới; bạn không nên mất hàng trăm mili giây để truy cập cơ sở dữ liệu. Cơ sở dữ liệu nên gần nơi hàm thực thi. Điều này có thể bằng cách sao chép dữ liệu sang nhiều region và châu lục.
Độ trễ thấp
Nhà phát triển thích giải pháp edge computing vì cung cấp độ trễ thấp khắp nơi. Cơ sở dữ liệu không nên là bottleneck. Cơ sở dữ liệu trong bộ nhớ như Redis cung cấp độ trễ dưới mili giây.
Hành trình của Upstash
REST API
Chúng tôi ra mắt Upstash với hỗ trợ Redis API gốc. Tất cả Redis client đều được hỗ trợ, hoàn hảo cho ứng dụng Redis kế thừa. Nhưng sớm chúng tôi thấy người dùng gặp vấn đề kết nối trên serverless functions. Cũng không truy cập được từ Cloudflare Workers. Vì vậy trước tiên triển khai GraphQL API. Nhưng không hài lòng vì chi phí hiệu suất do lớp proxy. GraphQL cũng không phải cách dễ nhất chạy lệnh Redis. Chúng tôi quyết định xây dựng REST server bên trong database engine để giảm thiểu chi phí hiệu suất. Chúng tôi nghĩ REST phù hợp hơn cho Redis. Chúng tôi ra mắt REST API và thấy nó khá phổ biến בקרב nhà phát triển muốn truy cập Redis từ Cloudflare Workers và Webassembly.
Edge Caching
Nhờ REST API, Upstash truy cập được từ Workers nhưng độ trễ chưa lý tưởng. Một số nhà phát triển thử dùng caching của Cloudflare để cache phản hồi Redis. Nhưng đó là giải pháp phức tạp. Redis đã rất nhanh, nên không cảm thấy tốt khi cache Redis ở nơi khác. Đó là lý do chúng tôi quyết định xây dựng edge caching nơi cache phản hồi Redis REST tại tất cả vị trí edge. Chúng tôi dùng nhà cung cấp CDN cache phản hồi Redis. Đây là cải thiện đáng kể độ trễ edge, lên tới 80% tăng hiệu suất.
Global Database
Edge caching giải quyết tốt vấn đề độ trễ toàn cầu nhưng có nhược điểm cho một số trường hợp. Thứ nhất, không hỗ trợ cache invalidation (xóa cache). Nếu thời gian hết hạn cache là 30 giây; có cửa sổ 30 giây client có thể đọc dữ liệu cũ. Nhiều trường hợp web chấp nhận được nhưng không phải tất cả. Thứ hai, edge caching chỉ hỗ trợ REST API. Redis client không tận dụng được edge caching. Vì vậy quyết định thiết kế loại database mới sao chép dữ liệu sang nhiều region. Thiết kế nó high available và consistent đủ rất thách thức. Hiện Upstash có global database sao chép dữ liệu sang 5 region AWS khác nhau (Đông và Tây Bắc Mỹ, Châu Âu, Châu Á, Nam Mỹ). Global database không phải cache nên không có vấn đề cache-invalidation. Ghi được sao chép tức thì sang tất cả replica. Vì hiệu suất và sẵn sàng, Global database thiết kế eventually consistent.
Edge Caching vs Global Database (hoặc cả hai)
Nếu chỉ cần cache cho giải pháp edge thì Edge caching là lựa chọn tốt. Nhưng nếu cần ghi vô hiệu hóa cache ngay lập tức, nên ưu tiên Global database. Ngoài caching, Global database dùng được như datastore toàn cầu high available. Cũng nhớ Edge caching chỉ dùng cho REST calls. Nếu dùng Redis client, Global database là lựa chọn duy nhất độ trễ thấp tại edge.
Cả Edge caching và Global database đều thiết kế giảm thiểu độ trễ đọc. Nếu trường hợp dùng 90% ghi thì thiết lập single region hợp lý hơn. Ghi có độ trễ giống nhau cho cả multi và single region, nhưng đắt gấp 5 lần trong Global setup.
Khi edge caching bật, Upstash lấy request đầu từ origin sau đó cache tại edge. Nếu origin không gần, độ trễ cao. Nếu muốn độ trễ tốt nhất mọi trường hợp; dùng cả hai bằng cách bật Edge Caching trên Global Database.
Xem ứng dụng benchmark so sánh độ trễ edge caching và global database.
Tiếp theo?
Một vài điều chúng tôi có thể làm để cải thiện Upstash tại Edge:
- Độ trễ thấp cho ghi: Hiện Global database thiết kế tối ưu độ trễ đọc với kiến trúc single leader. Chúng tôi nghĩ này bao phủ đa số trường hợp. Nhưng tùy phản hồi và use case mới có thể làm kiến trúc cho độ trễ thấp cả ghi lẫn đọc.
- Hỗ trợ Kafka: Chúng tôi dự định ra mắt Kafka bổ sung Redis trong tuần tới. Kafka sẽ cho phép use case mới tại edge như phân tích clickstream hoặc đẩy log đến kafka từ serverless/edge functions.
Chúng tôi tiếp tục cải thiện và phát triển Upstash theo phản hồi của bạn. Cho chúng tôi biết suy nghĩ trên Twitter hoặc Discord.