Mở rộng PostgreSQL để phục vụ 800 triệu người dùng ChatGPT

 (openai.com)
2 điểm bởi GN⁺ 2026-01-24 | 1 bình luận | Chia sẻ qua WhatsApp
  • OpenAI đã mở rộng hạ tầng PostgreSQL ở quy mô lớn để đáp ứng lưu lượng ChatGPT và API tăng vọt, xử lý hàng triệu QPS bằng một máy chủ Azure PostgreSQL Flexible Server duy nhất cùng khoảng 50 bản sao đọc
  • Vẫn duy trì kiến trúc tối ưu cho workload thiên về đọc, đồng thời di chuyển một phần workload sang Azure Cosmos DB để giảm tải ghi
  • Cải thiện độ ổn định và độ trễ bằng nhiều tối ưu hóa như pooling kết nối với PgBouncer, khóa bộ nhớ đệm, rate limiting, cô lập workload
  • Để vượt qua giới hạn của kiến trúc một primary duy nhất, họ đồng thời triển khai cấu hình HA, hot standby và thử nghiệm cascading replication
  • Với cách tiếp cận này, hệ thống đạt độ sẵn sàng 99,999% và độ trễ p99 ở mức hàng chục mili giây, đồng thời mở ra khả năng mở rộng sau này sang PostgreSQL sharding hoặc các hệ thống phân tán

Tổng quan về mở rộng PostgreSQL

  • PostgreSQL là hệ thống dữ liệu cốt lõi của ChatGPT và OpenAI API, với tải tăng hơn 10 lần trong 1 năm qua
    • Xử lý yêu cầu từ 800 triệu người dùng bằng một instance primary duy nhất và khoảng 50 bản sao đọc phân tán toàn cầu
  • Trong khi vẫn duy trì kiến trúc thiên về đọc, một phần workload đã được chuyển sang Azure Cosmos DB để giảm tải ghi
  • Không cho phép thêm bảng mới, và các workload mới về cơ bản được đặt trên hệ thống sharding

Thách thức của kiến trúc một primary duy nhất và cách ứng phó

  • Kiến trúc một writer duy nhất có giới hạn mở rộng ghi và vấn đề điểm lỗi đơn (SPOF)
    • Lưu lượng đọc được phân tán sang các bản sao, còn lưu lượng ghi được chuyển sang Cosmos DB đối với các workload có thể sharding
    • Cấu hình HA với hot standby hỗ trợ thăng cấp nhanh khi xảy ra sự cố (failover)
  • Khi tải đọc tăng đột biến, đã phát sinh hiện tượng CPU bão hòa do cache miss tăng mạnh
    • Đã đưa vào cơ chế khóa bộ nhớ đệm để ngăn truy vấn trùng lặp trên cùng một khóa

Tối ưu truy vấn và tài nguyên

  • Các truy vấn đa JOIN phức tạp chiếm dụng CPU quá mức và gây chậm dịch vụ
    • Rà soát SQL kém hiệu quả do ORM tạo ra, và chuyển logic JOIN phức tạp lên tầng ứng dụng
    • Dùng thiết lập idle_in_transaction_session_timeout để ngăn các truy vấn nhàn rỗi kéo dài
  • Để giải quyết vấn đề "noisy neighbor", lưu lượng được tách sang các instance theo mức ưu tiên
    • Cô lập để các yêu cầu ưu tiên thấp không ảnh hưởng đến dịch vụ ưu tiên cao

Quản lý kết nối và kiểm soát tải

  • Để giải quyết giới hạn 5.000 kết nối của Azure PostgreSQL, OpenAI đã đưa PgBouncer vào làm tầng proxy
    • Nhờ tái sử dụng kết nối, thời gian kết nối trung bình giảm từ 50ms → 5ms
    • Để giảm độ trễ mạng liên vùng, proxy, client và replica được đặt trong cùng một region
  • Rate limiting được áp dụng ở cấp ứng dụng, proxy và truy vấn để ngăn các đợt tăng lưu lượng đột ngột
    • Tầng ORM cũng được cải tiến để có thể chặn các query digest cụ thể

Quản lý replication và thay đổi schema

  • Vì primary phải stream WAL log tới mọi replica, tải mạng tăng lên khi số lượng replica tăng
    • OpenAI đang thử nghiệm cascading replication cùng với đội ngũ Azure
    • Replica trung gian sẽ chuyển tiếp WAL xuống các replica bên dưới, mở ra khả năng mở rộng lên hơn 100 replica
  • Các thay đổi schema gây ra full table rewrite bị cấm
    • Chỉ cho phép các thay đổi nhẹ trong giới hạn timeout 5 giây; việc tạo và xóa index có thể thực hiện đồng thời
    • Ngay cả khi backfill cũng áp dụng giới hạn tốc độ nghiêm ngặt

Kết quả và kế hoạch tiếp theo

  • PostgreSQL đang xử lý hàng triệu QPS, đạt độ trễ p99 ở mức hàng chục mili giây và độ sẵn sàng 99,999%
    • Trong 12 tháng qua chỉ có đúng một sự cố SEV-0, xảy ra khi ra mắt ChatGPT ImageGen
  • Các workload còn lại thiên về ghi cũng đang dần được chuyển sang Cosmos DB
  • Sau khi hoàn thiện cascading replication, hệ thống sẽ tiếp tục được tăng cường về khả năng mở rộng replica và độ ổn định
  • Trong tương lai, OpenAI đang xem xét khả năng áp dụng PostgreSQL sharding hoặc các hệ thống phân tán thay thế

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-01-24
Ý kiến trên Hacker News

  • Trong PostgreSQL, các truy vấn idle chạy lâu thường gây ra vấn đề
    Trong codebase của công ty chúng tôi có rất nhiều mẫu “connect → bắt đầu transaction → làm việc → commit nếu thành công”
    Cách này khiến slot kết nối tiếp tục bị chiếm dụng ngay cả khi thực tế không dùng tới DB, cuối cùng buộc phải tăng số lượng kết nối của Postgres lên tới hàng nghìn
    Vì vậy, chúng tôi đã thêm kiểm tra ở thời điểm biên dịch trong code Rust, để nếu gọi .await trong khi vẫn đang giữ kết nối bên trong hàm async thì compiler sẽ cảnh báo ngay
    Đã phải sửa hơn 100 chỗ, nhưng nhờ đó giờ đây chạy kiểm thử tải với pool 32 kết nối thay vì 10.000 kết nối cũng không còn bị chậm
    Chỉ giảm idle timeout cũng là một cách, nhưng kiểm tra tĩnh là giải pháp chắc chắn hơn nhiều

    • Có đề xuất rằng sẽ tốt hơn nếu đổi thứ tự thành “thực hiện công việc trước → lấy kết nối từ pool và bắt đầu transaction khi thành công → commit rồi trả lại”
    • Có người hỏi liệu kiểm tra tĩnh đó là một quy tắc lint hay là cách triển khai dựa trên type system

  • Bài viết quá hời hợt và chỉ lặp lại các từ khóa kiểu “chúng tôi đã sharding!”
    Hầu như không có chi tiết gì, cảm giác giống như câu chữ phục vụ SEO

    • Trông cũng giống quảng cáo cho đối tác hạ tầng
    • Cả caching, connection pooling, tối ưu hóa join... cũng chỉ được giải thích theo cách quá chung chung

  • Ý chính của bài là “single writer không thể scale, nên chúng tôi giảm ghi và tách đọc ra”
    Gần như không có gì mới, chỉ nhắc đến các cách quen thuộc như tối ưu truy vấn, sharding, read replica

  • Lý do tôi thích Postgres là vì chỉ cần tăng CPU và đĩa thôi cũng có thể chịu tải tới quy mô khá lớn
    Đến thời điểm đó thì cũng đã đủ khả năng thuê chuyên gia sharding

    • Thực ra PostgreSQL đã hỗ trợ sharding cơ bản bằng FDW và partitioning
      Vì vậy, câu “muốn sharding thì phải rời bỏ Postgres” nghe hơi lạ
    • Tuy vậy, có người nghi ngờ câu “sẽ đủ tiền để thuê chuyên gia”
      Ví dụ, OpenAI hiện giờ vẫn đang lỗ rất lớn, và còn có tin tức rằng chưa chắc họ trụ được tới năm 2027

  • Về thay đổi schema và timeout, không chỉ đơn giản là đặt timeout
    nếu chạy song song script tự động kết thúc các transaction xung đột trong lúc rollout schema thì sẽ hiệu quả hơn nhiều
    Sẽ rất tốt nếu Postgres hỗ trợ sẵn tính năng này — vì thay vì để chờ với lock nặng, đôi khi hủy một số transaction còn hợp lý hơn

    • Nhưng cũng có ý kiến phản biện rằng Postgres vốn đã hỗ trợ thay đổi schema dựa trên transaction, nên không nhất thiết phải giết các tác vụ

  • Đây là bài đầu tiên trên blog Engineering của OpenAI nên khá thú vị
    Mong rằng sau này sẽ có thêm nhiều trường hợp thực tế hơn

    • Cũng có phản hồi đùa rằng trên thực tế chắc họ sống sót nhờ downtime thường xuyên và các bản vá khẩn cấp lúc 2 giờ sáng

  • Có người tò mò về cấu hình replication
    Họ nói rằng dù có 50 read replica thì độ trễ replication gần như không có,
    nhưng trên thực tế rất dễ có replica bị chậm do spike CPU hoặc bộ nhớ
    Khi đó primary cũng có thể chậm lại vì phải chờ gửi WAL

    • Nhưng cũng có ý kiến cho rằng primary không bị chậm vì chờ TCP ACK, mà chỉ là lượng WAL segment cần lưu giữ tăng lên mà thôi

  • Có đoạn nói rằng “nếu tính năng mới cần thêm bảng thì sẽ đưa vào Azure CosmosDB thay vì PostgreSQL”
    Tức là họ giữ nguyên hệ thống cũ và chỉ chuyển các tính năng mới sang DB khác

    • Tuy nhiên, CosmosDB rất đắt, nên nếu không phải công ty dư dả như OpenAI thì khó mà dùng được

  • Có nói rằng họ “đã tăng kích thước instance”, nhưng mọi người tò mò mức đó là tới đâu
    Muốn biết họ dùng CPU·RAM thế nào, là instance giống người dùng thông thường hay phần cứng tùy biến

    • Các cloud lớn đều cung cấp SKU gán trọn một máy chủ hai socket cho một VM
      Ví dụ: Azure Standard_E192ibds_v6 (96 core, 1.8TB RAM, 10TB SSD, 3M IOPS)
      Loại lớn hơn còn có các mẫu dành cho SAP HANA như Standard_M896ixds_24_v3 với 896 core, 32TB bộ nhớ, mạng 185Gbps
      Những loại này có giá khoảng 175.000 USD mỗi tháng, nhưng OpenAI có lẽ đã được giảm giá rất mạnh
      Cá nhân tôi thích dùng VM HX176rs cho máy chủ DB hơn
      Nhờ bộ nhớ đệm HBM, băng thông bộ nhớ cao hơn hẳn, và hiệu năng tốt hơn nhiều so với VM thông thường cùng tầm giá

  • Dùng cả Azure PostgreSQL lẫn CosmosDB chắc chắn sẽ tốn kém khủng khiếp
    Dù vậy, bài viết lần này vẫn là một trong những ví dụ “mở rộng PostgreSQL trong thực tế” đáng tin nhất
    Cách tiếp cận vận hành trong môi trường cloud tiêu chuẩn, không sửa kernel hay hack mã nguồn, khiến nhiều người thấy đồng cảm