Bên Trong Kiến Trúc 'Lakebase' Của Neon: Cách Máy Tính Không Trạng Thái Và Cách Ly Tế Bào Sống Sót Qua Các Sự Cố AWS

Khi một nhà cung cấp đám mây lớn gặp sự cố ở tầng kiểm soát (control-plane) trong khu vực, hậu quả thường thấy với các dịch vụ cơ sở dữ liệu được quản lý là sự gián đoạn trên diện rộng: không thể khởi tạo máy ảo mới, không thể cấp phát địa chỉ IP, và cơ chế chuyển đổi dự phòng (failover) cũng tê liệt vì phụ thuộc vào chính các API đang gặp sự cố. Kiến trúc "lakebase" của Neon được thiết kế rõ ràng để né chuỗi phụ thuộc này. Thay vì coi nhà cung cấp đám mây như một bộ điều phối tài nguyên thời gian thực, Neon phân bổ trước dung lượng và cô lập các vùng lỗi, để một sự cố khu vực của AWS không tự động trở thành một sự cố khu vực của Neon .

Bài viết này sẽ mổ xẻ các cơ chế kiến trúc cụ thể—máy tính không trạng thái, cách ly dựa trên tế bào, lưu trữ dự phòng đa vùng, và giảm thiểu phụ thuộc vào tầng kiểm soát—mà Neon sử dụng để kiểm soát phạm vi ảnh hưởng. Nó dựa trên các báo cáo sự cố, tài liệu kiến trúc đã công bố của Neon và các phân tích từ bên thứ ba để cho thấy các chiến lược này đã hoạt động như thế nào trong sự cố AWS tháng 5 năm 2026 tại us-east-1, và điều đó cho chúng ta biết gì về khả năng phục hồi thực tế của thiết kế.

Cốt lõi: Tách độ bền dữ liệu khỏi tính sẵn sàng của máy tính

Kiến trúc của Neon bắt đầu từ một nguyên tắc rất dễ phát biểu nhưng khó thực thi một cách an toàn: không có trạng thái bền vững nào nên tồn tại trên nút máy tính đang chạy Postgres. Trong các hệ thống Postgres được quản lý truyền thống, tiến trình cơ sở dữ liệu ghi dữ liệu vào một ổ đĩa khối (block volume) gắn cục bộ. Nếu máy chủ hoặc phần cứng bên dưới gặp sự cố, việc khôi phục đòi hỏi phải có một máy chủ dự phòng nóng (hot standby) với trạng thái được sao chép hoặc một quy trình khôi phục sự cố (crash recovery) phát lại WAL từ ổ đĩa của nút bị lỗi. Cả hai hướng đều phụ thuộc vào khả năng của nhà cung cấp đám mây trong việc khởi tạo máy chủ thay thế và gắn ổ đĩa—chính là khả năng mà các sự cố khu vực có thể làm suy giảm .

Neon loại bỏ sự phụ thuộc này bằng cách chuyển tất cả trạng thái bền vững sang một tầng lưu trữ riêng biệt, có khả năng chịu lỗi đa vùng sẵn sàng. Các nút máy tính Postgres trong Neon không giữ dữ liệu trên đĩa cục bộ; chúng xử lý các truy vấn và truyền trực tiếp các bản ghi WAL (Write-Ahead Log) đến một cụm các nút safekeeper và pageserver, nơi lưu trữ bền vững mọi thay đổi . Điều này có nghĩa là khi một nút máy tính bị lỗi, quá trình xử lý truy vấn tạm dừng trong chốc lát, nhưng không có dữ liệu nào bị mất. Một máy tính mới có thể được gắn vào cùng lịch sử lưu trữ và tiếp tục công việc tại điểm máy cũ dừng lại, mà không cần chờ gắn lại ổ đĩa hay khôi phục sự cố .

Hệ quả thực tế trong một sự cố gián đoạn khởi tạo của AWS là rất đáng kể: Neon không cần gọi đến API EC2 dưới áp lực sự cố để thay thế các nút máy tính đã chết. Nó có thể lấy một nút thay thế từ một nhóm các máy chủ đã được "hâm nóng" sẵn và gắn nó vào trạng thái lưu trữ hiện có. Sự suy yếu ở tầng kiểm soát của nhà cung cấp đám mây trở thành một sự bất tiện trong vận hành thay vì một tình huống khẩn cấp về tính sẵn sàng của dữ liệu.

Cách ly tế bào: Một khu vực không có nghĩa là một vùng lỗi duy nhất

Các triển khai khu vực của Neon không phải là nguyên khối. Mỗi khu vực bao gồm một hoặc nhiều "tế bào" có hình dạng giống hệt nhau, trong đó một tế bào đóng gói control plane Kubernetes, nhóm máy tính và tài nguyên lưu trữ của riêng nó . Sự phân vùng này có nghĩa là một lỗi trong một tế bào—dù là do sự cố nhà cung cấp đám mây, lỗi phần mềm, hay cạn kiệt tài nguyên—sẽ không lan sang các tế bào khác trong cùng khu vực.

Trong sự cố AWS tháng 5 năm 2026 tại us-east-1, lỗi của nhà cung cấp đám mây đặc biệt ảnh hưởng đến khả năng khởi tạo máy chủ mới và cấp phát địa chỉ IP . Đối với một kiến trúc đơn tế bào, đó có thể đã là một sự cố toàn khu vực. Trong thiết kế dựa trên tế bào của Neon, chỉ những tế bào nào cạn kiệt bộ đệm máy tính được phân bổ trước mới bị ảnh hưởng. Các tế bào khác, với đủ bộ đệm máy chủ đã được cấp phát, tiếp tục hoạt động không bị gián đoạn .

Kết quả này phản ánh một lựa chọn thiết kế có chủ ý: các tế bào được định cỡ để giới hạn tài nguyên của không một tế bào đơn lẻ nào có thể trở thành nút thắt cổ chai của toàn khu vực. Các bài học kiến trúc trước đó đã củng cố suy nghĩ này. Trước khi chuyển sang cách ly dựa trên tế bào, Neon vận hành một cụm Kubernetes duy nhất cho mỗi khu vực, và các thử nghiệm cho thấy sự suy giảm dịch vụ khi vượt quá 10.000 cơ sở dữ liệu đồng thời do giới hạn bộ nhớ etcd của EKS, ràng buộc cấu hình mạng và giới hạn tốc độ API của Kubernetes . Kiến trúc dựa trên tế bào loại bỏ hoàn toàn các trần giới hạn của cụm đơn bằng cách phân chia tải qua các tế bào độc lập, không tương tác lẫn nhau.

Giảm phụ thuộc vào nhà cung cấp đám mây thông qua phân bổ trước và ảo hóa tùy chỉnh

Mối quan hệ của Neon với nhà cung cấp đám mây bên dưới được cố ý giữ ở mức "một cánh tay". Thay vì gọi API EC2 theo yêu cầu mỗi khi một cơ sở dữ liệu cần khởi động, Neon phân bổ trước các nhóm máy chủ lớn—thường là máy chủ bare-metal—và duy trì dung lượng đệm để hấp thụ các sự cố gián đoạn khởi tạo . Bộ đệm này không phải là một nhóm khởi động nhỏ dành cho khách hàng ưu tiên; nó là một thành phần cấu trúc trong cách hệ thống lên lịch cho tài nguyên máy tính.

Trên nền các máy chủ được phân bổ trước này, Neon chạy một lớp ảo hóa tự động mở rộng theo chiều dọc (vertical autoscaling) của riêng mình, đóng gói nhiều phiên bản Postgres vào một máy chủ vật lý duy nhất. Điều này cùng lúc vô hiệu hóa hai phụ thuộc vào nhà cung cấp đám mây: API khởi tạo máy ảo (vì máy chủ đã chạy sẵn) và đường dẫn gắn ổ đĩa khối (các nút máy tính của Neon không sử dụng ổ đĩa khối của đám mây) .

Độ bền dữ liệu cũng theo cùng một mô hình. Tất cả nội dung cơ sở dữ liệu nằm trong dịch vụ lưu trữ có khả năng phục hồi đa vùng của riêng Neon, được hậu thuẫn bởi các kho lưu trữ đối tượng như Amazon S3 hoặc Azure Blob Storage, chứ không phải trên các thiết bị khối của nhà cung cấp đám mây . API lưu trữ đối tượng có các chế độ lỗi khác với API khởi tạo máy ảo, và trên thực tế, độ bền của kho đối tượng trong các sự cố tầng kiểm soát khu vực đã chứng minh là có khả năng phục hồi tốt hơn đáng kể. Khi một nút pageserver hoặc safekeeper bị lỗi, không có trạng thái bền vững nào bị mất—một nút khác có thể tái tạo các trang cần thiết từ WAL và lưu trữ đối tượng .

Lưu trữ đa vùng sẵn sàng là nền tảng, không phải là tiện ích cao cấp

Trong nhiều dịch vụ cơ sở dữ liệu được quản lý, sao chép lưu trữ đa vùng sẵn sàng (multi-AZ) là một tính năng trả phí yêu cầu cấu hình rõ ràng. Trong Neon, mọi cơ sở dữ liệu—bất kể gói giá—đều được hậu thuẫn bởi lưu trữ đối tượng phân tán, đa vùng sẵn sàng với bộ nhớ đệm SSD NVMe trải rộng trên nhiều vùng sẵn sàng (AZ) . Điều này loại bỏ việc sao chép vật lý qua các vùng như một mối quan tâm riêng biệt, bởi vì bản thân tầng lưu trữ đã được sao chép một cách vốn có.

Thiết kế sao chép WAL cung cấp các đảm bảo về độ bền cụ thể: các thao tác ghi được sao chép đồng bộ đến các safekeeper với yêu cầu số đại biểu (quorum) (một cấu hình đã được công bố là sao chép sáu chiều với số đại biểu ghi là bốn trên sáu), có nghĩa là toàn bộ một vùng sẵn sàng cộng thêm một bản sao nữa có thể bị hỏng mà không mất dữ liệu . Đây không phải là khả năng phục hồi trên lý thuyết; nó là một thuộc tính của đường dẫn ghi phải được thỏa mãn trước khi giao dịch được xác nhận (acknowledge) cho máy khách.

Riêng về tính sẵn sàng của máy tính, mô hình lưu trữ chia sẻ mang lại một lợi thế mà các kiến trúc chính-phụ (primary-replica) truyền thống không thể sánh được: vì tất cả các máy tính chia sẻ cùng lịch sử lưu trữ bền vững, một máy tính thay thế không cần phải "bắt kịp" thông qua sao chép vật lý. Nó gắn vào lịch sử hiện có và bắt đầu phục vụ truy vấn trong vòng vài giây đến vài phút, tùy thuộc vào khối lượng công việc và kích thước của tập làm việc được lưu trong bộ nhớ đệm .

Mục tiêu về tính sẵn sàng và những gì dữ liệu thể hiện

Các SLI (Service Level Indicator) về tính sẵn sàng đã công bố cho kiến trúc lakebase của Neon nằm trong khoảng xấp xỉ 99.93% đến 99.96% . Những con số này phản ánh một thiết kế nơi các lỗi máy tính được khắc phục bằng cách thay thế các nút không trạng thái thay vì chuyển đổi dự phòng sang các máy dự phòng nóng (hot standby) nhàn rỗi, và nơi độ bền lưu trữ đạt được thông qua sao chép dựa trên kho đối tượng thay vì đồng bộ hóa đĩa.

Hồ sơ sự cố của chính Neon cung cấp một sự hiệu chuẩn hữu ích cho các mục tiêu này. Một sự cố vào tháng 5 năm 2025 tại us-east-1 đã gây ra 5.5 giờ gián đoạn cho các hoạt động khởi động và tạo cơ sở dữ liệu qua hai sự kiện riêng biệt, mặc dù các cơ sở dữ liệu đang hoạt động vẫn không bị ảnh hưởng . Nguyên nhân gốc rễ—cạn kiệt địa chỉ IP trong các subnet Kubernetes do quá tải control plane và cấu hình sai AWS CNI—đã phơi bày một giới hạn mở rộng mà kiến trúc tế bào sau đó được thiết kế để ngăn chặn . Trước đó, vào tháng 8 năm 2024, một sự cố pageserver ở us-east-1 đã ảnh hưởng đến khoảng 0.4% dự án của khách hàng trong tối đa hai giờ sau khi một máy chủ EC2 bị lỗi; vì pageserver hoạt động như một bộ nhớ đệm đĩa cục bộ được hậu thuẫn bởi S3, việc mất pageserver đồng nghĩa với sự gián đoạn tạm thời hơn là mất dữ liệu vĩnh viễn .

Những sự cố này nhấn mạnh rằng máy tính không trạng thái và lưu trữ chia sẻ làm giảm mức độ nghiêm trọng của lỗi nhưng không loại bỏ chúng hoàn toàn. Các thuộc tính phục hồi của kiến trúc—không mất dữ liệu từ lỗi máy tính, tự động khôi phục thông qua gắn lại, phạm vi ảnh hưởng giới hạn trong tế bào—vẫn đứng vững trong các điều kiện lỗi thực tế, nhưng hệ thống không miễn nhiễm với các lỗi phần mềm, cạn kiệt tài nguyên, hoặc các phụ thuộc vào nhà cung cấp đám mây chưa được tách rời hoàn toàn (chẳng hạn như cấp phát địa chỉ IP).

Kiểm tra khả năng phục hồi: Neon xác nhận thiết kế như thế nào

Blog kỹ thuật của Neon cho biết hệ thống được kiểm tra dựa trên các kịch bản lỗi thực tế, bao gồm sự cố gián đoạn khởi tạo của nhà cung cấp đám mây và mô phỏng ngắt kết nối toàn bộ vùng sẵn sàng . Các bài kiểm tra này thực hành trên các bộ đệm máy chủ được phân bổ trước và ranh giới cách ly tế bào, vốn được cho là để giới hạn phạm vi ảnh hưởng. Hình thức chung của kỹ thuật hỗn loạn (chaos engineering) mà Neon mô tả phản chiếu các thông lệ đã được thiết lập: xác định một giả thuyết trạng thái ổn định về cách hệ thống nên hành xử khi gặp lỗi, tiêm một lỗi có kiểm soát (chẳng hạn như ngắt kết nối toàn bộ một AZ hoặc làm cạn kiệt bộ đệm máy tính), quan sát xem giả thuyết có đúng không, và lặp lại trên kiến trúc khi nó không đúng .

Mặc dù Neon chưa công bố một phương pháp luận kỹ thuật hỗn loạn chi tiết hoặc các kết quả thí nghiệm cụ thể ngoài tổng quan blog kiến trúc, bằng chứng hiện có cho thấy việc kiểm tra nhắm trực tiếp vào các tuyên bố về khả năng phục hồi đặc trưng của hệ thống. Các bài kiểm tra mà Neon mô tả—mô phỏng sự cố gián đoạn khởi tạo và lỗi AZ—chính là các kịch bản mà máy tính không trạng thái và cách ly tế bào sẽ mang lại lợi thế lớn nhất so với các kiến trúc cơ sở dữ liệu được quản lý truyền thống. Sự cố AWS tháng 5 năm 2026 về cơ bản đã phục vụ như một sự xác nhận ngoài kế hoạch cho các cơ chế tương tự, và kết quả phạm vi ảnh hưởng được kiểm soát là nhất quán với những gì mà việc phân bổ trước và cách ly tế bào được thiết kế để tạo ra.

Điều này có ý nghĩa gì với các đội ngũ đang đánh giá Postgres phi máy chủ (serverless)

Kiến trúc của Neon đưa ra một sự đánh đổi cụ thể về khả năng phục hồi: nó chấp nhận rằng máy tính là phù du (ephemeral) và thay thế nó nhanh chóng thay vì cố gắng giữ cho nó chạy bằng mọi giá, đồng thời đầu tư mạnh mẽ vào độ bền lưu trữ và cách ly vùng lỗi. Đối với các khối lượng công việc mà việc gián đoạn truy vấn thỉnh thoảng dưới một phút là có thể chấp nhận được và mối quan tâm chính là an toàn dữ liệu, mô hình này loại bỏ chi phí và sự phức tạp của việc duy trì các máy dự phòng nóng (hot standby). Đối với các khối lượng công việc yêu cầu tính sẵn sàng truy vấn liên tục với không gián đoạn, các cấu hình đa máy tính bổ sung có sẵn nhưng đi kèm với chi phí cao hơn.

Kiến trúc này cũng buộc phải có một sự hạch toán trung thực về sự phụ thuộc vào đám mây. Không có dịch vụ cơ sở dữ liệu nào thực sự độc lập với nhà cung cấp đám mây bên dưới, nhưng mức độ liên kết thay đổi rất lớn. Quyết định của Neon trong việc phân bổ trước dung lượng, sử dụng lớp ảo hóa của riêng mình, và lưu trữ dữ liệu trong kho đối tượng thay vì ổ đĩa khối đã thu hẹp bề mặt của các API nhà cung cấp đám mây phải sẵn sàng để tầng cơ sở dữ liệu hoạt động. Bề mặt phụ thuộc hẹp hơn đó đã được đền đáp trong sự cố AWS tháng 5 năm 2026, khi các tế bào có đủ bộ đệm được phân bổ trước tiếp tục hoạt động xuyên suốt một lỗi mà lẽ ra đã là trên toàn khu vực đối với một kiến trúc được liên kết chặt chẽ hơn.

Đối với các đội ngũ đang xây dựng trên hạ tầng phi máy chủ, cách tiếp cận của Neon chứng minh rằng việc kiểm soát phạm vi ảnh hưởng không phải là một suy nghĩ muộn màng—nó là sản phẩm của các quyết định kiến trúc được đưa ra tại ranh giới lưu trữ-máy tính và cấu trúc vùng lỗi từ rất lâu trước khi một sự cố xảy ra.