How We Built Fly Postgres

Fly.io · 2022 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Bài của một nhà cung cấp hạ tầng về sản phẩm của chính họ; nhận định ghi "theo Fly.io".

Bối cảnh

• Fly.io khởi đầu (2019) là nền tảng "edge app" không có lưu trữ bền: dữ liệu thật nằm ở us-east-1, phần chạy ở edge là cache. Khách xin database từ ngày đầu; họ từ chối hơn 300 ngày, có thử Redis dùng chung ("bị nguyền") và cân nhắc CockroachDB managed.
• Lập luận năm 2020: app không cần stateless, chỉ cần dùng DB ngoài (RDS, Crunchy, PlanetScale). Rồi họ thêm volume (LVM2) cho mọi app.
• Không muốn làm lại RDS, nên chọn: không có managed database mà có "automated database": một app Postgres thân thiện chạy trên chính nền tảng, cộng vài lệnh tiện ích. Ra mắt thử fly pg create tháng 1/2021 (cụm 2 node, metrics, health check, alert).

Kiến trúc

• Một primary, một replica gần đó qua streaming replication bất đồng bộ (WAL). Postgres không tự failover, nên dùng Stolon (Go): sentinel quyết định leader, keeper quản từng Postgres, proxy định tuyến về leader; trạng thái cụm lưu trong Consul.
• Vấn đề: Stolon "nói chuyện" với Consul rất nhiều và lặp lại request khi không tới được; một cụm chập chờn có thể làm bão hoà Consul dùng chung. Proxy của Stolon mất Consul thì đánh rơi mọi kết nối: nhiều sự cố Postgres truy về Consul sập hoặc node xa không nối được Consul.
• Sửa: thay proxy Stolon bằng HAProxy hỏi thẳng từng node "anh là leader hay replica" mỗi 2 giây qua health check HTTP (Postgres trên mỗi node tự biết vai trò của mình), nên Consul không còn nằm trên đường đi của kết nối. Thêm cụm Consul ở nhiều region, đặt gần primary của khách, vì mạng giữa Stolon và Consul càng ngắn càng ít hỏng.
• Một VM chạy keeper, sentinel, HAProxy, Postgres, health check và supervisor flypg (thử phục hồi process lỗi trước khi để VM bị lập lịch lại). Node ở region khác chỉ đọc; ghi về primary region (Fly-Replay).
• Đánh đổi của HA: cần kho trạng thái ngoài, tức thêm một kiểu hỏng. Theo Fly.io, một node đơn lẻ không có máy móc HA còn đáng tin hơn; nhưng bản "dev" một node riêng lại khó nâng lên HA, nên họ bỏ.
• Backup bằng snapshot block device của volume thay cho backup kiểu Postgres: chạy được cho mọi thứ ghi ra filesystem, sau đó tổng quát thành tính năng cho mọi volume.

Bài học cho SWE

• HA tự động đem theo một phụ thuộc mới (kho đồng thuận); đưa nó ra khỏi đường đi nóng và đặt gần dữ liệu (Độ tin cậy và multi-region).
• Nguồn sự thật về vai trò nên là chính node, không phải bản sao trạng thái ở nơi khác.
• Theo Fly.io: làm "Postgres" thực chất là làm nền tảng; mỗi tính năng (volume, snapshot, health check) phục vụ được mọi app (Nền tảng nội bộ cho service (đường ray chung)).

Liên quan

• Failover, replica và dự phòng dữ liệu
• Nền tảng nội bộ cho service (đường ray chung)
• Tự động hoá vận hành và auto-remediation