Figma tự xây dựng proxy Redis nội bộ FigCache để đạt độ ổn định 99,9999%

Figma tự xây dựng proxy Redis nội bộ FigCache để đạt độ ổn định 99,9999%

Figma mới đây đã công bố chi tiết về cách họ xây dựng một dịch vụ proxy Redis nội bộ gọi là FigCache, nhằm thay thế cho hệ thống caching phân tán đã trở thành gánh nặng đối với tính sẵn sàng của trang web. Được mô tả trong một bài đăng bởi kỹ sư phần mềm Kevin Lin, hệ thống này đã được đưa vào vận hành sản phẩm từ nửa cuối năm 2025 và đạt được những kết quả ấn tượng.

Figma Redis Proxy

Theo Kevin Lin, các lỗ hổng về khả năng mở rộng và độ tin cậy trong nền tảng Redis của Figma trước đây đang trở thành mối đe dọa ngày càng lớn đối với tính sẵn sàng của toàn bộ hệ thống. Việc ra mắt FigCache là bước tái cấu trúc lưu trữ lớn thứ hai của Figma, sau khi họ hoàn thành việc chia nhỏ (sharding) ngăn xếp Postgres vào năm 2024 với một proxy tùy chỉnh tên là DBProxy.

Bối cảnh và Thách thức

Những vấn đề mà Figma gặp phải khá phổ biến đối với bất kỳ ai vận hành Redis ở quy mô lớn. Lượng kết nối đang tiến tới giới hạn cứng, và việc mở rộng quy mô nhanh chóng của các dịch vụ khách hàng đã tạo ra những "đàn bão" (thundering herds) yêu cầu kết nối mới, làm bão hòa I/O của Redis và làm giảm tính sẵn sàng.

Ngoài ra, sự tồn tại của nhiều thư viện khách hàng độc lập với nhau theo thời gian, mỗi cái có hành vi quan sát (observability) riêng, đã khiến việc chẩn đoán sự cố trở nên khó khăn. Đội ngũ kỹ thuật ban đầu đã xây dựng các giải pháp tạm thời cho từng dịch vụ, bao gồm cả một lớp kết nối (connection pooling) phía khách hàng, nhưng kết luận rằng các giải pháp này chỉ đang cô lập sự cố Redis khỏi tính sẵn sàng của trang web cấp cao hơn chứ không giải quyết được các vấn đề cấu trúc gốc rễ.

"Các lỗ hổng về khả năng mở rộng và độ tin cậy trong nền tảng Redis của chúng tôi là một mối đe dọa ngày càng tăng đối với tính sẵn sàng của trang web Figma." — Kevin Lin, Kỹ sư phần mềm tại Figma

Tại sao tự xây dựng thay vì dùng giải pháp có sẵn?

Quyết định tự xây dựng thay vì sử dụng các proxy mã nguồn mở có sẵn xuất phát từ những hạn chế của các giải pháp hiện tại. Kevin Lin lưu ý rằng các giải pháp hiện tại đi kèm với các máy chủ RPC "nguyên thủy" không có khả năng trích xuất các đối số đầy đủ và có chú thích từ các lệnh Redis tùy ý đến.

Nếu không có sự nhận biết ngữ nghĩa đó, Figma không thể triển khai các hàng rào bảo vệ thời gian chạy (runtime guardrails) cần thiết, cũng như không thể định nghĩa các lệnh tùy chỉnh mà proxy có thể chặn và xử lý. Hơn nữa, họ cần hỗ trợ một cơ sở khách hàng hiện tại bị phân mảnh: một số dịch vụ nhận biết Redis Cluster, một số sử dụng TLS, và một số không dùng cái nào. Một lớp độc quyền cho phép đội ngũ xây dựng các "shims" xử lý tất cả các biến thể này một cách minh bạch.

Kiến trúc và Tính năng của FigCache

FigCache là một dịch vụ không trạng thái (stateless) được xây dựng trên ResPC, một thư viện Go mà đội ngũ viết để cung cấp khung RPC trên Giao thức tuần tự hóa Redis (RESP). Proxy nằm giữa các ứng dụng khách hàng và một đội máy các cụm Redis trên AWS ElastiCache.

Kiến trúc của nó tách biệt lớp giao diện người dùng (frontend), xử lý quản lý kết nối và phân tích cú pháp lệnh nhận thức giao thức, khỏi lớp backend quản lý đa路 hóa kết nối và thực thi lệnh đối với các cụm thượng nguồn. Sự tách biệt này làm cho hệ thống có thể mở rộng: các hành vi mới có thể được giới thiệu ở một trong hai lớp mà không làm gián đoạn lớp kia.

Một trong những lựa chọn thiết kế thú vị là cách cấu hình backend của FigCache. Thay vì sử dụng các tệp cấu hình tĩnh, cây động cơ điều phối cách các lệnh được định tuyến và xử lý được biểu diễn dưới dạng chương trình Starlark, được đánh giá tại thời gian chạy trong máy ảo. Điều này cho phép các nhà vận hành thay đổi logic định tuyến, các quy tắc từ chối dựa trên tiền tố khóa và phân chia loại lệnh hoàn toàn thông qua cấu hình, mà không cần triển khai lại mã máy chủ.

Proxy cũng xử lý một lớp vấn đề mà Redis Cluster thường hiển thị cho khách hàng dưới dạng lỗi: lỗi CROSSSLOT. FigCache bao gồm một động cơ lọc fan-out chặn các đường ống (pipeline) hoặc giao dịch đa shard phù hợp và thực thi chúng nội bộ dưới dạng thao tác phân tán và tổng hợp song song (scatter-gather), gửi các lệnh riêng lẻ và tổng hợp phản hồi trước khi trả về cho khách hàng.

Chiến lược Di chuyển và Kết quả

Các thư viện khách hàng chính thức (first-party) trong Go, Ruby và TypeScript đi kèm với proxy. Đây là các trình bao bọc (wrappers) trên các thư viện mã nguồn mở hiện có, nghĩa là việc di chuyển một dịch vụ sang FigCache, trong trường hợp đơn giản nhất, chỉ là thay đổi cấu hình một dòng.

Chiến lược di chuyển được thiết kế để có thể hoàn tác ở mọi giai đoạn. Lưu lượng được chuyển dịch dịch vụ này sang dịch vụ khác, với các cờ tính năng cho phép hoàn tác ngay lập tức mà không cần thay đổi mã hay triển khai nhị phân. Đối với các khối lượng công việc lớn như dịch vụ API chính của Figma, lưu lượng được chuyển dịch tăng dần trên các miền độc lập.

Kết quả là FigCache đã loại bỏ các lỗi kết nối do "đàn bão" từng góp phần vào nhiều sự cố nghiêm trọng. Các thao tác chuyển đổi dự phòng (failover) shard, mở rộng cụm, xoay vòng phần cứng và nâng cấp OS giờ đây là các hoạt động chạy trong nền với thời gian ngừng (zero-downtime). Khả năng quan sát trên toàn bộ ngăn xếp caching hiện đã được thống nhất, giúp giảm thời gian chẩn đoán sự cố từ vài giờ hoặc vài ngày xuống còn vài phút.