Membedah Arsitektur Lakebase Neon

Neon menghilangkan ketergantungan ini dengan memindahkan semua status durable ke lapisan penyimpanan terpisah yang redundan lintas zona. Simpul komputasi Postgres di Neon tidak menyimpan data di disk lokal; mereka memproses kueri dan mengalirkan rekaman WAL (Write-Ahead Log) ke armada simpul safekeeper dan pageserver yang menyimpan setiap perubahan secara tahan lama . Ini berarti kegagalan simpul komputasi menghentikan pemrosesan kueri sejenak, tetapi tidak ada data yang hilang. Sebuah instans komputasi baru dapat terhubung ke riwayat penyimpanan yang sama dan melanjutkan dari titik terakhir instans sebelumnya, tanpa perlu menunggu pemasangan ulang volume atau pemulihan crash .

Konsekuensi praktisnya selama gangguan provisioning AWS sangat signifikan: Neon tidak perlu memanggil API EC2 di bawah tekanan kegagalan untuk mengganti simpul komputasi yang mati. Neon dapat mengambil pengganti dari kumpulan instans yang sudah berjalan (pre-warmed pool) dan menghubungkannya ke status penyimpanan yang ada. Gangguan pada control-plane penyedia cloud menjadi ketidaknyamanan operasional, bukan darurat ketersediaan data.

Isolasi Berbasis Sel: Satu Region Bukan Berarti Satu Domain Kegagalan

Penerapan regional Neon tidak bersifat monolitik. Setiap region terdiri dari satu atau lebih sel yang identik, di mana setiap sel menggabungkan control plane Kubernetes, kumpulan komputasi, dan sumber daya penyimpanannya sendiri . Kompartmentalisasi ini berarti bahwa kegagalan di satu sel—entah karena gangguan penyedia cloud, bug perangkat lunak, atau kehabisan sumber daya—tidak akan merambat ke sel lain di region yang sama.

Selama gangguan AWS pada Mei 2026 di us-east-1, kegagalan penyedia cloud secara spesifik memengaruhi kemampuannya untuk menyediakan instans baru dan mengalokasikan alamat IP . Untuk arsitektur sel tunggal, itu akan menjadi insiden yang melumpuhkan seluruh kawasan. Dalam desain berbasis sel Neon, hanya sel yang kehabisan buffer komputasi yang telah dialokasikan sebelumnya yang terkena dampak. Sel lainnya, dengan buffer yang cukup dari instans yang sudah dialokasikan, terus beroperasi tanpa gangguan .

Hasil ini mencerminkan pilihan desain yang disengaja: sel diukur sedemikian rupa sehingga tidak ada batas sumber daya satu sel pun yang bisa menjadi hambatan regional. Pelajaran arsitektur sebelumnya memperkuat pemikiran ini. Sebelum beralih ke isolasi berbasis sel, Neon mengoperasikan satu kluster Kubernetes per region, dan pengujian menunjukkan degradasi layanan di luar 10.000 basis data bersamaan karena batasan memori EKS etcd, batasan konfigurasi jaringan, dan pembatasan laju API Kubernetes . Arsitektur berbasis sel sepenuhnya menghilangkan batasan kluster tunggal itu dengan membagi beban ke sel-sel independen yang tidak saling berinteraksi.

Mengurangi Ketergantungan pada Penyedia Cloud melalui Pra-Alokasi dan Virtualisasi Kustom

Hubungan Neon dengan penyedia cloud yang mendasarinya sengaja dibuat berjarak. Alih-alih memanggil API EC2 sesuai permintaan setiap kali database perlu dimulai, Neon mengalokasikan terlebih dahulu kumpulan instans besar—seringkali bare-metal—dan mempertahankan kapasitas buffer untuk menyerap gangguan provisioning . Buffer ini bukan kumpulan kecil hangat untuk penyewa prioritas; ini adalah komponen struktural dari bagaimana sistem menjadwalkan komputasi.

Di atas instans yang telah dialokasikan ini, Neon menjalankan lapisan virtualisasi vertically autoscaling-nya sendiri yang mengemas beberapa instans Postgres ke dalam satu host fisik. Ini melewati dua ketergantungan penyedia cloud sekaligus: API provisioning VM (instans sudah berjalan) dan jalur pemasangan penyimpanan blok (simpul komputasi Neon tidak menggunakan volume blok cloud) .

Durabilitas data mengikuti pola yang sama. Semua konten basis data berada di layanan penyimpanan tahan zona milik Neon sendiri, didukung oleh penyimpanan objek seperti Amazon S3 atau Azure Blob Storage, bukan pada perangkat blok penyedia cloud . API penyimpanan objek memiliki mode kegagalan yang berbeda dari API provisioning VM, dan dalam praktiknya, durabilitas penyimpanan objek selama gangguan control-plane regional terbukti jauh lebih tangguh. Ketika simpul pageserver atau safekeeper gagal, tidak ada status tahan lama yang hilang—simpul lain dapat merekonstruksi halaman yang diperlukan dari WAL dan penyimpanan objek .

Penyimpanan Redundan Lintas Zona adalah Fondasi, Bukan Fitur Tambahan Premium

Di banyak layanan database terkelola, replikasi penyimpanan multi-AZ adalah fitur berbayar yang memerlukan konfigurasi eksplisit. Di Neon, setiap database—terlepas dari tingkat harganya—didukung oleh penyimpanan objek terdistribusi dan redundan lintas zona dengan cache NVMe SSD yang tersebar di beberapa availability zone . Ini menghilangkan replikasi fisik lintas zona sebagai masalah terpisah, karena lapisan penyimpanan itu sendiri secara inheren direplikasi.

Desain replikasi WAL memberikan jaminan durabilitas yang konkret: penulisan direplikasi secara sinkron ke safekeeper dengan persyaratan kuorum (replikasi enam arah dengan kuorum tulis empat-dari-enam adalah satu konfigurasi yang dipublikasikan), yang berarti seluruh availability zone ditambah satu replika tambahan dapat gagal tanpa kehilangan data . Ini bukanlah ketahanan teoretis; ini adalah properti dari jalur tulis yang harus dipenuhi sebelum transaksi diakui ke klien.

Untuk ketersediaan komputasi secara spesifik, model penyimpanan bersama memberikan keuntungan yang tidak dapat ditandingi oleh arsitektur primer-replika tradisional: karena semua instans komputasi berbagi riwayat penyimpanan tahan lama yang sama, komputasi pengganti tidak perlu mengejar ketertinggalan melalui replikasi fisik. Ia terhubung ke riwayat yang ada dan mulai melayani kueri dalam hitungan detik hingga beberapa menit, tergantung pada beban kerja dan ukuran set kerja yang di-cache .

Target Ketersediaan dan Apa yang Ditunjukkan Data

SLI ketersediaan yang dipublikasikan untuk arsitektur lakebase Neon berada dalam kisaran sekitar 99,93% hingga 99,96% . Angka-angka ini mencerminkan desain di mana kegagalan komputasi dipulihkan dengan mengganti simpul stateless alih-alih melakukan failover ke hot standby yang menganggur, dan di mana durabilitas penyimpanan dicapai melalui replikasi yang didukung penyimpanan objek, bukan mirroring disk sinkron.

Catatan insiden Neon sendiri memberikan kalibrasi yang berguna untuk target-target ini. Sebuah insiden pada Mei 2025 di us-east-1 menyebabkan 5,5 jam ketidaktersediaan untuk operasi memulai dan membuat database di dua kejadian terpisah, meskipun database yang aktif tetap tidak terpengaruh . Akar masalahnya—alamat IP yang habis di subnet Kubernetes yang dipicu oleh kelebihan beban control plane dan kesalahan konfigurasi AWS CNI—mengekspos batas penskalaan yang kemudian dicegah oleh arsitektur berbasis sel . Sebelumnya, pada Agustus 2024, gangguan pageserver di us-east-1 memengaruhi sekitar 0,4% proyek pelanggan hingga dua jam setelah kegagalan instans EC2; karena pageserver bertindak sebagai cache disk lokal yang didukung oleh S3, kehilangan pageserver berarti ketidaktersediaan sementara, bukan kehilangan data permanen .

Insiden-insiden ini menegaskan bahwa komputasi stateless dan penyimpanan bersama mengurangi tingkat keparahan kegagalan tetapi tidak sepenuhnya menghilangkannya. Properti ketahanan arsitektur—tanpa kehilangan data dari kegagalan komputasi, pemulihan otomatis melalui penyambungan kembali, radius ledakan yang dibatasi sel—bertahan dalam kondisi kegagalan nyata, tetapi sistem tidak kebal terhadap cacat perangkat lunak, kehabisan sumber daya, atau ketergantungan penyedia cloud yang belum sepenuhnya dipisahkan (seperti alokasi alamat IP).

Pengujian Ketahanan: Bagaimana Neon Memvalidasi Desainnya

Blog rekayasa Neon menyatakan bahwa sistem ini diuji terhadap skenario kegagalan dunia nyata, termasuk gangguan provisioning penyedia cloud dan simulasi pemutusan seluruh availability zone . Pengujian ini melatih buffer instans yang telah dialokasikan sebelumnya dan batas-batas isolasi sel yang seharusnya membatasi radius ledakan. Bentuk umum dari chaos engineering yang digambarkan Neon mencerminkan praktik yang sudah mapan: tentukan hipotesis kondisi-mapan tentang bagaimana sistem seharusnya berperilaku di bawah kegagalan, suntikkan kesalahan terkendali (seperti memutuskan seluruh AZ atau menghabiskan buffer komputasi), amati apakah hipotesis itu bertahan, dan iterasi pada arsitektur jika tidak .

Meskipun Neon belum mempublikasikan metodologi chaos engineering yang terperinci atau hasil eksperimen spesifik di luar ikhtisar blog arsitektur, bukti yang tersedia menunjukkan bahwa pengujian tersebut secara langsung menargetkan klaim ketahanan khas sistem. Pengujian yang dijelaskan Neon—mensimulasikan gangguan provisioning dan kegagalan AZ—adalah skenario di mana komputasi stateless dan isolasi sel seharusnya memberikan keuntungan terbesar dibandingkan arsitektur database terkelola tradisional. Gangguan AWS pada Mei 2026 secara efektif berfungsi sebagai validasi tidak terencana dari mekanisme yang sama, dan hasil radius ledakan yang terbatas konsisten dengan apa yang dirancang untuk dihasilkan oleh pra-alokasi dan isolasi sel.

Apa Artinya Ini bagi Tim yang Mengevaluasi Postgres Serverless

Arsitektur Neon menawarkan pertukaran ketahanan yang spesifik: ia menerima bahwa komputasi bersifat ephemeral dan menggantinya dengan cepat daripada menjaganya tetap berjalan dengan segala cara, sambil berinvestasi besar-besaran dalam durabilitas penyimpanan dan isolasi domain kegagalan. Untuk beban kerja di mana gangguan kueri sesekali selama kurang dari satu menit dapat diterima dan perhatian utamanya adalah keamanan data, model ini menghilangkan biaya dan kerumitan memelihara hot standby. Untuk beban kerja yang memerlukan ketersediaan kueri berkelanjutan tanpa gangguan, konfigurasi multi-komputasi tambahan tersedia tetapi dengan biaya yang lebih tinggi.

Arsitektur ini juga memaksa perhitungan yang jujur tentang ketergantungan cloud. Tidak ada layanan database yang benar-benar independen dari penyedia cloud yang mendasarinya, tetapi tingkat keterkaitannya sangat bervariasi. Keputusan Neon untuk mengalokasikan kapasitas terlebih dahulu, menggunakan lapisan virtualisasi sendiri, dan menyimpan data di penyimpanan objek alih-alih volume blok mengurangi area permukaan API penyedia cloud yang harus tersedia agar database tier berfungsi. Permukaan ketergantungan yang lebih sempit itu membuahkan hasil selama gangguan AWS pada Mei 2026, ketika sel-sel dengan buffer pra-alokasi yang memadai terus beroperasi melalui kegagalan yang akan melumpuhkan seluruh kawasan untuk arsitektur yang lebih terkait erat .

Bagi tim yang membangun di atas infrastruktur serverless, pendekatan Neon menunjukkan bahwa pembatasan radius ledakan bukanlah renungan—ini adalah produk dari keputusan arsitektur yang dibuat di batas penyimpanan-komputasi dan struktur domain kegagalan jauh sebelum gangguan terjadi.