- Tự host Postgres không phức tạp hay rủi ro như nhiều người nghĩ, đồng thời rẻ hơn dịch vụ managed và cho phép tinh chỉnh hiệu năng linh hoạt hơn
- Phần lớn dịch vụ cơ sở dữ liệu đám mây vận hành trên Postgres mã nguồn mở với một số chỉnh sửa nhỏ, khác biệt thực chất nằm ở mức độ tự động hóa vận hành
- Trong các trường hợp vận hành thực tế, Postgres tự host có thể xử lý ổn định hàng nghìn người dùng và hàng chục triệu truy vấn, trong khi thời gian bảo trì rất ít
- Do giá của các dịch vụ managed như AWS RDS tăng lên, nay có thể tự vận hành máy chủ cấu hình cao hơn rất nhiều với cùng chi phí
- Với các đội ngũ quy mô trung bình không có hạ tầng quá phức tạp, tự host là một phương án thay thế thực tế về cả chi phí lẫn hiệu năng
Sự thay đổi của câu chuyện lấy đám mây làm trung tâm
- Trước đây, phần lớn doanh nghiệp tự vận hành cơ sở dữ liệu trên máy chủ riêng, một kiến trúc nhanh hơn do độ trễ mạng thấp
- Trong giai đoạn 1980~2000, máy chủ ứng dụng và máy chủ cơ sở dữ liệu thường nằm trên cùng thiết bị vật lý
- Sự ra mắt của Amazon RDS (2009) được đón nhận như một đề xuất hấp dẫn khi tự động hóa sao lưu, vá lỗi và giám sát
- Ban đầu, chi phí gần tương đương máy chủ chuyên dụng nhưng giúp giảm gánh nặng vận hành
- Sau năm 2015, khi việc áp dụng đám mây tăng tốc, nhận thức rằng tự quản lý hạ tầng là không hiệu quả bắt đầu lan rộng
- Mô hình AWS quản lý hạ tầng thay, còn nhà phát triển tập trung vào logic ứng dụng, đã trở thành tiêu chuẩn
- Tính đến năm 2025, giá RDS đã tăng mạnh, tạo ra tình huống có thể thuê máy chủ chuyên dụng cấu hình cao hơn rất nhiều với cùng ngân sách
- Ví dụ: instance
db.r6g.xlarge (4 vCPU, 32GB RAM) có giá $328/tháng, trong khi có thể thuê máy chủ 32 lõi · 256GB RAM
Cấu thành thực tế của dịch vụ managed
- AWS RDS về cơ bản là Postgres tiêu chuẩn được bổ sung hệ thống giám sát và sao lưu riêng của AWS
- Bao gồm sao lưu dựa trên snapshot EBS, quản lý cấu hình qua Chef/Puppet/Ansible, connection pooling bằng PgBouncer, giám sát CloudWatch và script failover tự động
- Về mặt kỹ thuật, cấu hình này không quá phức tạp; giá trị cốt lõi nằm ở tự động hóa vận hành và sự tiện lợi khi triển khai ban đầu
- Kết quả khi migrate từ RDS sang tự host với cùng cấu hình máy chủ cho thấy hiệu năng giữ nguyên hoặc thậm chí tốt hơn
- Có thể trực tiếp điều chỉnh các tham số từng bị giới hạn trên RDS để tối ưu hiệu năng
Độ phức tạp trong vận hành tự host
- Việc migrate sang máy chủ DigitalOcean 16 vCPU / 32GB RAM / 400GB đĩa mất khoảng 4 giờ, sau đó xác nhận vận hành ổn định
- Các nhóm sản phẩm yêu cầu tính sẵn sàng cao cần khoảng 30 phút quản trị mỗi tháng, còn dịch vụ ít traffic có thể tự động hóa hoàn toàn
- Chu kỳ quản trị định kỳ
- Hàng tuần (10 phút) : xác minh sao lưu, rà soát slow query log, kiểm tra dung lượng đĩa
- Hàng tháng (30 phút) : cập nhật bảo mật, kiểm tra chính sách lưu giữ bản sao lưu, lập kế hoạch dung lượng
- Hàng quý (2 giờ) : cập nhật dashboard giám sát, tối ưu cấu hình, kiểm thử khôi phục
- Ứng phó sự cố là trách nhiệm trực tiếp của bạn, nhưng RDS cũng có thể gặp sự cố và cuối cùng nhà phát triển vẫn phải xử lý
- Khi tự vận hành, có thể tự quyết định thời điểm cập nhật và vùng rủi ro, từ đó dễ đảm bảo tính ổn định hơn
Khi nào tự host không phù hợp
- Khi lập trình viên giai đoạn đầu cần tạo prototype nhanh, dịch vụ managed sẽ tiện hơn
- Doanh nghiệp quy mô lớn có thể thấy hiệu quả hơn khi có kỹ sư cơ sở dữ liệu chuyên trách hoặc ủy thác cho đám mây để giảm chi phí nhân sự
- Các ngành bị quản lý chặt (PCI-DSS, HIPAA, v.v.) có thể bị yêu cầu dùng nền tảng managed đã được chứng nhận
Các điểm cấu hình quan trọng
- Cấu hình bộ nhớ: cần điều chỉnh
shared_buffers, effective_cache_size, work_mem, maintenance_work_mem theo phần cứng
- Ví dụ: đặt
shared_buffers bằng 25% RAM, effective_cache_size bằng 75%
- Quản lý kết nối: dùng
pgbouncer để thiết lập connection pooling, hoạt động hiệu quả trong môi trường Python asyncio
- Ví dụ cấu hình cơ bản:
max_connections = 200, log_connections = on
- Tinh chỉnh lưu trữ: trong môi trường NVMe SSD, điều chỉnh
random_page_cost = 1.1, effective_io_concurrency = 200
- Tốc độ đọc ngẫu nhiên được cải thiện, giúp tối ưu kế hoạch truy vấn
- Cấu hình WAL: điều chỉnh
wal_level = replica, max_wal_size = 2GB, checkpoint_completion_target = 0.9 để cân bằng độ bền và hiệu năng
Kết luận
- Không phải mọi hạ tầng đều cần tự vận hành, nhưng Postgres là một lĩnh vực mà tự host khá hợp lý
- Nếu đang chi hơn $200/tháng cho RDS, rất đáng thử chuyển một cơ sở dữ liệu không cốt lõi sang máy chủ thử nghiệm
- Trong tương lai, hạ tầng có thể phát triển theo mô hình hybrid kết hợp dịch vụ managed và tự host
- Postgres được đánh giá là ứng viên tự host có hiệu quả chi phí rất cao
4 bình luận
Vì còn được đảm bảo storage đạt 11 số 9, nên vận hành khó như khi dùng cloud thì người ta mới dùng cloud chứ haha
Trên thực tế, vận hành một cụm 3 node sẽ không hề dễ dàng đến vậy.
Ý kiến trên Hacker News
Tôi xem self-hosting là vấn đề về trách nhiệm
Tôi đang tự host vài sản phẩm SaaS, rẻ hơn AWS rất nhiều mà hiệu năng cũng tốt hơn hẳn
Tuy vậy, với các dự án khách hàng thì tôi vẫn thuyết phục họ trả tiền cho AWS, vì như vậy có thể chuyển trách nhiệm về tính sẵn sàng của phần cứng sang bên khác
Khi ngân sách hạn chế thì chi phí RDS khá nặng. Vận hành một cụm Galera 3 node trên Hetzner với vài đô rõ ràng kinh tế hơn nhiều
Nhưng ngay cả các dịch vụ được quản lý như Cloudflare hay SQS cũng vẫn thỉnh thoảng gặp sự cố. Rốt cuộc chẳng có nơi nào ổn định tuyệt đối cả
AWS Aurora Serverless
Ngược lại, cloud SQL lại có cấu trúc chi phí phức tạp, còn phần backup thì chỉ cần cấu hình một lần là xong
Tôi không đồng ý với lập luận rằng self-hosting là lựa chọn phù hợp cho đa số
Theo tôi, chỉ khi ngân sách rất eo hẹp, hoặc quy mô đủ lớn để có kỹ sư chuyên trách, thì tự host mới hợp lý
Với doanh nghiệp nhỏ thì giao cho cloud vẫn thực tế hơn. Tính ra sau khi setup xong, mỗi tháng chỉ cần 30–120 phút quản trị là đủ
PaaS như Heroku hay Render thì developer bình thường cũng dùng được, nhưng đắt hơn nhiều
Rốt cuộc nếu không tự động hóa khôi phục ứng dụng thì chuyện bị đánh thức lúc 3 giờ sáng vẫn y hệt
Nếu là công cụ nội bộ, chỉ mất 5 phút để thêm một Postgres vào Docker
Định nghĩa về ‘managed database’ đang khá mơ hồ
Với tôi, các yêu cầu cơ bản là backup tự động, tối ưu index, failover đa trung tâm dữ liệu, khôi phục theo thời điểm, phân tích slow query, dự đoán lưu trữ
Nếu có thể cung cấp những thứ đó trong phí hàng tháng thì tranh luận về self-hosting gần như không còn ý nghĩa
Cuối cùng lại phải có hai người, rồi vì công việc quá nhàn nên bắt đầu thử những cải tiến không cần thiết và có khi lãng phí mất 6 tháng
DB managed đắt hơn VPS quá nhiều
Tôi có kỳ vọng một mức premium cho sự tiện lợi, nhưng thực tế lại đắt hơn gấp nhiều lần. Vì vậy ngoài các dự án lớn ra thì tôi không dùng
Phần tính sẵn sàng cao (HA) được nhắc trong bài còn thiếu. Chỉ nói về cấu hình WAL là chưa đủ. Replication rất tốn kém
Tôi không hiểu vì sao Postgres lại được đánh giá quá cao trên HN
Không có cách dễ dàng để dựng cụm HA với failover tự động như MongoDB. Tôi tò mò trong môi trường production thì người ta giải quyết chuyện này thế nào
Thảo luận liên quan: mailing list PostgreSQL
Trên thực tế, mọi kết nối đều sẽ bị cắt, cache bị khởi tạo lại, và khi nâng cấp thì việc gián đoạn dịch vụ là bắt buộc
Chỉ Oracle RAC là ngoại lệ, còn PostgreSQL không được thiết kế như vậy. YugabyteDB là lựa chọn thay thế gần nhất
Phần lớn ứng dụng chấp nhận vài giờ downtime. Chỉ các công ty lớn mới kham nổi tự động hóa phức tạp như thế
Trong môi trường Kubernetes thì CloudNativePG cũng tốt.
pg_auto_failover thì đơn giản nhưng có giới hạn
Nhìn vào Autobase, có thể thấy nó tự động xử lý những việc cần thiết khi self-hosting
Trong 15 năm qua tôi luôn self-hosted Postgres, nhưng gần như chưa từng gặp vấn đề gì
Điều duy nhất khiến tôi phải bận tâm là khi cần migrate phiên bản PG để phù hợp với các đợt nâng cấp ORM. Chuyện đó có thể xử lý bằng quản trị hệ thống cẩn thận
Tôi từng tự chạy Postgres không được quản lý trên Fly.io, và thật sự rất khổ
Node chết thường xuyên đến mức tôi phải dùng repmgr để khôi phục thủ công, cuối cùng còn phải viết hẳn quy trình vào wiki nội bộ
Mục tiêu của cluster là tính sẵn sàng cao, nên tôi không hiểu vì sao nó không tự động xử lý primary zombie
Cuối cùng tôi chuyển sang managed Postgres, và việc để người khác xử lý khi có sự cố thực sự rất nhẹ đầu
Nhiều bình luận trong thread này đang bỏ qua các yếu tố thực tế như quy mô, workload, nhân lực, thời gian, giai đoạn kinh doanh, yêu cầu mở rộng
Self-hosting có thể đúng, cũng có thể không, nhưng cuộc thảo luận đang bị đơn giản hóa quá mức
Điều các nhà phát triển băn khoăn có lẽ là liệu khi tự host những thứ như vậy thì các yếu tố đó có được công nhận hay không. Dù chi phí cloud có cao hơn, nếu phần tiết kiệm nhờ tự host không được ghi nhận thì cứ dùng dịch vụ cloud rồi bù vào, thu hẹp phạm vi phải tự quản lý có lẽ còn nhẹ đầu hơn.