เจาะลึกสถาปัตยกรรม Lakebase ของ Neon: การประมวลผลไร้สถานะและการแยกส่วนแบบ Cell รอดพ้นจาก AWS ล่มได้อย่างไร

ผลลัพธ์ในทางปฏิบัติระหว่างที่ AWS ล่มนั้นชัดเจนมาก: Neon ไม่จำเป็นต้องเรียกใช้ EC2 API ท่ามกลางสภาวะกดดันเพื่อสร้างโหนดประมวลผลใหม่ทดแทนตัวที่เสียไป มันสามารถดึง Instance ใหม่จาก Pool ที่เตรียมพร้อมไว้ล่วงหน้า แล้วนำมาเชื่อมต่อกับข้อมูลใน Storage เดิมได้ทันที ความบกพร่องของ Control Plane ของคลาวด์จึงกลายเป็นเพียงปัญหาด้านปฏิบัติการที่น่ารำคาญ แทนที่จะเป็นวิกฤตต่อความพร้อมใช้งานของข้อมูล

การแยกส่วนแบบ Cell: หนึ่งภูมิภาคไม่ได้หมายถึงขอบเขตความเสียหายเดียว

การติดตั้งในแต่ละภูมิภาคของ Neon ไม่ได้เป็นการติดตั้งแบบเสาหิน (Monolithic) แต่ละภูมิภาคประกอบด้วย Cell หนึ่งหรือหลาย Cell ที่มีรูปร่างเหมือนกัน โดยแต่ละ Cell จะมี Kubernetes Control Plane, Compute Pool, และทรัพยากร Storage เป็นของตัวเอง การจัดแบ่งเป็นสัดส่วนนี้หมายความว่า ความล้มเหลวใน Cell หนึ่ง—ไม่ว่าจะเกิดจากคลาวด์ล่ม, บั๊กของซอฟต์แวร์, หรือทรัพยากรหมด—จะไม่ลุกลามไปยัง Cell อื่นในภูมิภาคเดียวกัน

ระหว่างเหตุการณ์ AWS ล่มในภูมิภาค us-east-1 เมื่อเดือนพฤษภาคม 2026 ความล้มเหลวของผู้ให้บริการคลาวด์ส่งผลต่อความสามารถในการสร้าง Instance และจัดสรร IP Address ใหม่โดยเฉพาะ หากเป็นสถาปัตยกรรมแบบ Cell เดียว เหตุการณ์นี้คงจะกลายเป็นปัญหาในระดับภูมิภาคทั้งหมด แต่ด้วยการออกแบบแบบ Cell ของ Neon มีเพียง Cell ที่ใช้ Buffer ของ Instance ที่จัดสรรไว้ล่วงหน้าจนหมดเท่านั้นที่ได้รับผลกระทบ ส่วน Cell อื่นที่มี Buffer เพียงพอยังคงทำงานต่อไปได้โดยไม่หยุดชะงัก

ผลลัพธ์นี้สะท้อนถึงการตัดสินใจออกแบบที่จงใจ: Cell ถูกกำหนดขนาดเพื่อไม่ให้ข้อจำกัดด้านทรัพยากรของ Cell หนึ่งกลายเป็นคอขวดของทั้งภูมิภาค บทเรียนทางสถาปัตยกรรมก่อนหน้านี้ยิ่งตอกย้ำแนวคิดนี้ ก่อนจะย้ายมาใช้การแยกส่วนแบบ Cell Neon เคยใช้ Kubernetes Cluster เดียวต่อภูมิภาค และการทดสอบแสดงให้เห็นถึงความเสื่อมถอยของบริการเมื่อมีฐานข้อมูลที่เปิดพร้อมกันเกิน 10,000 ฐานข้อมูล อันเนื่องมาจากข้อจำกัดของ EKS etcd memory, ข้อจำกัดการตั้งค่าเครือข่าย, และ Kubernetes API Rate Limiting สถาปัตยกรรมแบบ Cell ได้ขจัดข้อจำกัดแบบ Cluster เดียวเหล่านั้นออกไปโดยสิ้นเชิงด้วยการกระจายภาระไปยัง Cell อิสระที่ไม่ขึ้นต่อกัน

ลดการพึ่งพาผู้ให้บริการคลาวด์ด้วยการจัดสรรล่วงหน้าและ Virtualization เฉพาะทาง

ความสัมพันธ์ระหว่าง Neon กับผู้ให้บริการคลาวด์นั้นถูกออกแบบให้ห่างกันอย่างจงใจ แทนที่จะเรียกใช้ EC2 API ทุกครั้งที่ต้องการเริ่มฐานข้อมูล Neon จะจัดสรร Pool ของ Instance ขนาดใหญ่—มักเป็นแบบ Bare-Metal—ไว้ล่วงหน้าและรักษา Buffer ให้เพียงพอเพื่อรองรับภาวะที่ไม่สามารถสร้าง Instance ใหม่ได้ Buffer นี้ไม่ใช่ Pool อุ่นเครื่องเล็กๆ สำหรับผู้เช่าที่มีลำดับความสำคัญสูง แต่มันคือองค์ประกอบเชิงโครงสร้างของวิธีการที่ระบบจัดสรรทรัพยากร

ยิ่งไปกว่านั้น บน Instance ที่เตรียมไว้ล่วงหน้านี้ Neon ได้รัน Virtualization Layer ของตัวเองที่ปรับขนาดแนวตั้งอัตโนมัติ (Vertical Autoscaling) ซึ่งช่วยบรรจุ Instance Postgres หลายตัวลงบน Physical Host เพียงเครื่องเดียว ทำให้สามารถเลี่ยงการพึ่งพาผู้ให้บริการคลาวด์ถึงสองอย่างพร้อมกัน: API สำหรับสร้าง VM (เพราะ Instance พร้อมทำงานอยู่แล้ว) และขั้นตอนการต่อ Block Storage (เพราะโหนดประมวลผลของ Neon ไม่ได้ใช้ Cloud Block Volume)

ความคงทนของข้อมูลก็ใช้แนวทางเดียวกัน เนื้อหาทั้งหมดของฐานข้อมูลจะอยู่ใน Zone-Resilient Storage Service ของ Neon ซึ่งมี Object Store อย่าง Amazon S3 หรือ Azure Blob Storage หนุนหลัง แทนที่จะเป็น Block Storage ของผู้ให้บริการคลาวด์ Object Storage API มีโหมดความล้มเหลวที่ต่างจาก API สำหรับสร้าง VM และในทางปฏิบัติ Object Store ได้พิสูจน์แล้วว่ามีความยืดหยุ่นสูงกว่ามากในระหว่างที่ Control Plane ของภูมิภาคล่ม เมื่อ Pageserver หรือ Safekeeper Node ล้มเหลว จะไม่มีข้อมูลคงทนใดสูญหาย—อีก Node หนึ่งสามารถสร้าง Page ที่จำเป็นขึ้นมาใหม่จาก WAL และ Object Storage ได้

Storage สำรองข้าม Zone คือรากฐาน ไม่ใช่ฟีเจอร์เสริมราคาแพง

ในบริการฐานข้อมูลแบบจัดการหลายแห่ง การทำ Storage Replication ข้าม AZ เป็นฟีเจอร์ที่ต้องเสียเงินเพิ่มและตั้งค่าเอง แต่ใน Neon ทุกฐานข้อมูล—ไม่ว่าจะอยู่ในแพ็กเกจราคาใด—จะมีระบบจัดเก็บข้อมูลแบบกระจาย สำรองข้าม Zone (Zone-Redundant Object Storage) พร้อมด้วย NVMe SSD Caches ที่กระจายอยู่หลาย AZ สิ่งนี้ทำให้ไม่ต้องกังวลเรื่อง Physical Replication ข้าม Zone แยกต่างหาก เพราะชั้น Storage มี Replication ในตัวอยู่แล้ว

การออกแบบ WAL Replication ให้การรับประกันความคงทนของข้อมูลอย่างเป็นรูปธรรม: การเขียนข้อมูลจะถูก Replicate ไปยัง Safekeeper แบบ Synchronous ด้วยข้อกำหนด Quorum (มีการเผยแพร่การตั้งค่าหนึ่งคือการ Replicate 6 ทิศทางและต้องเขียนสำเร็จ 4 ใน 6 ตัว) ซึ่งหมายความว่าถึงแม้ Availability Zone ทั้ง Zone และ Replica อีกหนึ่งตัวจะล่มไป ข้อมูลก็ยังไม่สูญหาย นี่ไม่ใช่ความยืดหยุ่นในทางทฤษฎี แต่มันคือคุณสมบัติของเส้นทางการเขียนข้อมูลที่จะต้องสำเร็จก่อนที่ธุรกรรมจะถูกยืนยันกลับไปยัง Client

สำหรับความพร้อมใช้งานในการประมวลผลโดยเฉพาะ โมเดล Shared Storage ให้ข้อได้เปรียบที่สถาปัตยกรรม Primary-Replica แบบดั้งเดิมไม่อาจเทียบได้: เนื่องจาก Instance ประมวลผลทั้งหมดใช้ประวัติการจัดเก็บข้อมูลที่คงทนร่วมกัน Instance ใหม่ที่มาทดแทนจึงไม่ต้องไล่ตามข้อมูลให้ทันผ่าน Physical Replication มันแค่เชื่อมต่อเข้ากับประวัติเดิมและเริ่มให้บริการ Query ได้ภายในไม่กี่วินาทีถึงสองสามนาที ขึ้นอยู่กับปริมาณงานและขนาดของ Working Set ที่ถูก Cache ไว้

เป้าหมายความพร้อมใช้งานและสิ่งที่ข้อมูลแสดงให้เห็น

ตัวชี้วัด Service Level Indicator (SLI) ด้านความพร้อมใช้งานที่เผยแพร่ของสถาปัตยกรรม Lakebase ของ Neon อยู่ในช่วงประมาณ 99.93% ถึง 99.96% ตัวเลขเหล่านี้สะท้อนถึงการออกแบบที่ความล้มเหลวในการประมวลผลจะถูกกู้คืนโดยการแทนที่โหนดไร้สถานะ แทนที่จะ Failover ไปยัง Hot Standby ที่รออยู่เฉยๆ และที่ที่ความคงทนของข้อมูลเกิดขึ้นได้ผ่าน Replication ที่มี Object Store หนุนหลัง แทนที่จะเป็น Synchronous Disk Mirroring

บันทึกเหตุการณ์ของ Neon เองช่วยให้เราเทียบค่าเป้าหมายเหล่านี้ได้ดี เหตุการณ์ในเดือนพฤษภาคม 2025 ที่ us-east-1 ทำให้บริการสร้างและเริ่มฐานข้อมูลไม่พร้อมใช้งานเป็นเวลา 5.5 ชั่วโมง แม้ฐานข้อมูลที่กำลังทำงานอยู่จะไม่ได้รับผลกระทบ ต้นตอของปัญหา—IP Address ใน Kubernetes Subnet หมด ซึ่งเกิดจาก Control Plane ทำงานหนักเกินไปและ AWS CNI ตั้งค่าผิดพลาด—ได้เผยให้เห็นข้อจำกัดด้านการขยายตัวที่สถาปัตยกรรมแบบ Cell ถูกออกแบบมาเพื่อป้องกันในเวลาต่อมา ก่อนหน้านั้นในเดือนสิงหาคม 2024 เหตุการณ์ Pageserver ล่มใน us-east-1 ส่งผลกระทบต่อโปรเจกต์ของลูกค้าประมาณ 0.4% เป็นเวลานานถึงสองชั่วโมง หลังจาก EC2 Instance ที่โฮสต์บริการหนึ่งเสียไป เนื่องจาก Pageserver ทำหน้าที่เป็น Local Disk Cache ที่มี S3 หนุนหลัง การเสีย Pageserver ไปจึงหมายความถึงการไม่พร้อมใช้งานชั่วคราว ไม่ใช่การสูญหายของข้อมูลอย่างถาวร

เหตุการณ์เหล่านี้ตอกย้ำว่า แม้การประมวลผลไร้สถานะและ Shared Storage จะลดความรุนแรงของความล้มเหลว แต่ก็ไม่ได้กำจัดมันไปเสียทั้งหมด คุณสมบัติความยืดหยุ่นของสถาปัตยกรรม—การไม่สูญเสียข้อมูลจาก Compute Failure, การกู้คืนอัตโนมัติผ่านการเชื่อมต่อใหม่, ขอบเขตความเสียหายที่จำกัดอยู่ใน Cell—ยังคงยืนหยัดได้ภายใต้สภาวะความล้มเหลวจริง แต่ระบบก็ไม่ได้มีภูมิคุ้มกันต่อข้อบกพร่องของซอฟต์แวร์, ทรัพยากรหมด, หรือการพึ่งพาผู้ให้บริการคลาวด์ที่ยังไม่ได้ถูกถอดออกอย่างสมบูรณ์ (เช่น การจัดสรร IP Address)

การทดสอบความยืดหยุ่น: Neon ตรวจสอบความถูกต้องของการออกแบบอย่างไร

บล็อกด้านวิศวกรรมของ Neon ระบุว่าระบบถูกทดสอบกับสถานการณ์ความล้มเหลวในโลกจริง ซึ่งรวมถึงการจำลองการล่มของระบบการสร้าง Instance ของผู้ให้บริการคลาวด์ และการตัดการเชื่อมต่อ Availability Zone ทั้ง Zone การทดสอบเหล่านี้ได้ใช้ประโยชน์จาก Buffer ของ Instance ที่เตรียมไว้ล่วงหน้าและขอบเขตการแยกส่วนของ Cell ซึ่งถูกออกแบบมาเพื่อจำกัดวงความเสียหาย รูปแบบทั่วไปของ Chaos Engineering ที่ Neon อธิบายนั้นสะท้อนแนวปฏิบัติที่เป็นที่ยอมรับ: กำหนดสมมติฐานสภาวะคงตัว (Steady-State Hypothesis) ว่าระบบควรมีพฤติกรรมอย่างไรเมื่อเกิดความล้มเหลว, ฉีดความผิดพลาดแบบควบคุม (เช่น ตัด AZ ทั้ง Zone หรือทำให้ Compute Buffer หมด), สังเกตว่าสมมติฐานยังคงเป็นจริงหรือไม่, และปรับปรุงสถาปัตยกรรมเมื่อมันไม่เป็นไปตามนั้น

แม้ว่า Neon จะไม่ได้เผยแพร่รายละเอียดระเบียบวิธี Chaos Engineering หรือผลการทดลองที่เจาะจงเกินกว่าภาพรวมในบล็อกด้านสถาปัตยกรรม แต่หลักฐานที่มีอยู่แสดงให้เห็นว่าการทดสอบมุ่งเป้าไปที่ข้อกล่าวอ้างเรื่องความยืดหยุ่นที่เป็นจุดขายของระบบโดยตรง การทดสอบต่างๆ ที่ Neon อธิบาย—การจำลองการล่มของระบบสร้าง Instance และความล้มเหลวของ AZ—คือสถานการณ์ที่ Stateless Compute และ Cell Isolation ควรให้ข้อได้เปรียบสูงสุดเหนือสถาปัตยกรรมฐานข้อมูลแบบจัดการดั้งเดิม เหตุการณ์ AWS ล่มในเดือนพฤษภาคม 2026 จึงเท่ากับเป็นการตรวจสอบกลไกเหล่านั้นโดยไม่ได้วางแผน และผลลัพธ์ที่วงความเสียหายถูกจำกัดไว้ก็สอดคล้องกับสิ่งที่การจัดสรรทรัพยากรล่วงหน้าและ Cell Isolation ถูกออกแบบมาให้เป็น

สิ่งนี้หมายถึงอะไรสำหรับทีมที่กำลังประเมิน Serverless Postgres

สถาปัตยกรรมของ Neon นำเสนอทางเลือกที่เฉพาะเจาะจง: มันยอมรับว่า Compute เป็นสิ่งที่ไม่จีรังและแทนที่มันอย่างรวดเร็ว ดีกว่าจะพยายามรักษามันให้ทำงานต่อไปไม่ว่าจะต้องแลกด้วยอะไรก็ตาม ขณะที่ลงทุนอย่างหนักในความคงทนของข้อมูลและการแยกขอบเขตความเสียหาย สำหรับงานที่ยอมรับได้ว่า Query จะถูกขัดจังหวะเป็นพักๆ ในระดับต่ำกว่านาที และสิ่งที่กังวลหลักคือความปลอดภัยของข้อมูล โมเดลนี้จะช่วยขจัดต้นทุนและความซับซ้อนในการรักษา Hot Standby สำหรับงานที่ต้องการความพร้อมใช้งานของ Query อย่างต่อเนื่องโดยไม่มีการขัดจังหวะเลย การตั้งค่าที่มี Compute หลายตัวก็มีให้ใช้งาน แต่มาพร้อมกับต้นทุนที่สูงกว่า

สถาปัตยกรรมนี้ยังบังคับให้เราต้องประเมินการพึ่งพาคลาวด์อย่างซื่อตรง ไม่มีบริการฐานข้อมูลใดที่เป็นอิสระจากผู้ให้บริการคลาวด์เบื้องล่างอย่างแท้จริง แต่ระดับของการพึ่งพานั้นแตกต่างกันอย่างมาก การตัดสินใจของ Neon ที่จะจัดสรรทรัพยากรล่วงหน้า, ใช้ Virtualization Layer ของตัวเอง, และเก็บข้อมูลใน Object Storage แทนที่จะเป็น Block Storage ได้ลดพื้นที่ผิวของการพึ่งพา API ของผู้ให้บริการคลาวด์ที่ต้องพร้อมใช้งานเพื่อให้ระบบฐานข้อมูลทำงานได้ พื้นผิวการพึ่งพาที่แคบลงนี้ให้ผลตอบแทนในเหตุการณ์ AWS ล่มเมื่อเดือนพฤษภาคม 2026 เมื่อ Cell ที่มี Buffer เตรียมไว้ล่วงหน้าเพียงพอยังคงทำงานได้ต่อไป ท่ามกลางความล้มเหลวที่น่าจะลามไปทั่วภูมิภาคสำหรับสถาปัตยกรรมที่พึ่งพากันแนบแน่นกว่านี้

สำหรับทีมที่กำลังสร้างบนโครงสร้างพื้นฐานแบบ Serverless แนวทางของ Neon แสดงให้เห็นว่าการจำกัดวงความเสียหายไม่ใช่สิ่งที่คิดทีหลัง—มันคือผลผลิตของการตัดสินใจทางสถาปัตยกรรมที่เกิดขึ้น ณ จุดเชื่อมต่อระหว่าง Storage-Compute และโครงสร้างของขอบเขตความเสียหาย ก่อนที่เหตุการณ์ขัดข้องจะเกิดขึ้นเสียอีก