Neon의 레이크베이스 아키텍처 내부 들여다보기: 무상태 컴퓨팅과 셀 격리가 AWS 장애에서 살아남는 법

AWS의 프로비저닝 장애 상황에서 이 특징이 갖는 실질적인 이점은 상당합니다. Neon은 죽어버린 컴퓨팅 노드를 교체하기 위해 부하를 받고 있는 EC2 API를 호출할 필요가 없습니다. 미리 준비된 풀(Pool)에서 이미 실행 중인 인스턴스를 꺼내 기존 스토리지 상태에 붙이기만 하면 됩니다. 클라우드 사업자의 제어 영역 장애는 데이터 가용성을 위협하는 비상사태가 아니라, 단순한 운영상의 불편으로 격하됩니다.

셀 기반 격리: 하나의 리전이 하나의 장애 도메인이 아니다

Neon의 리전 배포는 단일체(Monolithic) 구조가 아닙니다. 각 리전은 하나 이상의 동일한 형태의 '셀'들로 구성되며, 하나의 셀은 자체적인 쿠버네티스 제어 영역, 컴퓨팅 풀, 스토리지 자원을 하나의 묶음으로 포함합니다 . 이러한 구획화 덕분에 클라우드 사업자 장애, 소프트웨어 버그, 혹은 자원 고갈 때문에 특정 셀 하나에 장애가 발생해도, 같은 리전 내 다른 셀로 그 장애가 전파되지 않습니다.

2026년 5월 us-east-1에서 발생한 AWS 장애 당시, 클라우드 사업자는 새로운 인스턴스를 프로비저닝하고 IP를 할당하는 기능이 특정적으로 망가졌습니다 . 만약 단일 셀 아키텍처였다면 이는 리전 전체의 서비스 장애가 되었을 것입니다. 그러나 Neon의 셀 기반 설계 덕분에, 미리 프로비저닝된 컴퓨팅 버퍼를 모두 소진한 셀들만 영향을 받았습니다. 이미 충분한 버퍼를 가진 다른 셀들은 아무런 중단 없이 운영을 계속했습니다 .

이 결과는 의도된 설계 선택을 반영합니다. 단일 셀의 자원 한계가 리전 전체의 병목이 되지 않도록 셀의 크기가 정해져 있다는 뜻이죠. 이러한 사고방식은 앞선 아키텍처 경험을 통해 강화되었습니다. 셀 기반 격리로 옮기기 전, Neon은 리전당 하나의 쿠버네티스 클러스터만 운영했습니다. 그런데 테스트 결과, EKS etcd의 메모리 한계(8GB 상한), 네트워크 설정 제약(us-east-1 기준 약 12,000개의 동시 데이터베이스), 그리고 쿠버네티스 API 요청 제한 등으로 인해 10,000개 이상의 동시 데이터베이스가 가동될 때 서비스 품질이 저하되는 것이 확인되었습니다 . 셀 기반 아키텍처는 이 단일 클러스터의 천장을 완전히 제거하고, 부하를 상호작용하지 않는 독립적인 셀들로 분산시킵니다.

사전 프로비저닝과 자체 가상화로 클라우드 의존성 줄이기

Neon과 기반 클라우드 사업자와의 관계는 의도적으로 느슨하게 유지됩니다. 데이터베이스가 시작될 때마다 그때그때 EC2 API를 호출하는 대신, Neon은 대규모(종종 베어메탈) 인스턴스 풀을 미리 할당해두고 프로비저닝 장애를 흡수할 버퍼 용량을 유지합니다 . 이 버퍼는 VIP 고객만을 위한 작은 웜 풀이 아니라, 시스템이 컴퓨팅을 스케줄링하는 방식 그 자체를 구성하는 구조적 요소입니다.

이렇게 사전에 확보된 인스턴스 위에서, Neon은 자체 개발한 수직 자동 확장(Vertically Autoscaling) 가상화 계층을 실행하여 하나의 물리적 호스트에 여러 Postgres 인스턴스를 밀집시킵니다. 이는 VM 프로비저닝 API(이미 인스턴스가 실행 중임)와 블록 스토리지 연결 경로(Neon의 컴퓨팅 노드는 클라우드 블록 볼륨을 사용하지 않음)라는 두 가지 클라우드 의존성을 동시에 우회하는 기술입니다 .

데이터 내구성 역시 같은 패턴을 따릅니다. 모든 데이터베이스 콘텐츠는 클라우드 사업자의 블록 디바이스가 아닌, Amazon S3나 Azure Blob Storage 같은 오브젝트 저장소를 기반으로 한 Neon 자체의 영역 복원력이 있는 스토리지 서비스에 상주합니다 . 오브젝트 스토리지 API는 VM 프로비저닝 API와 장애 양상이 다르며, 실제로 리전 제어 영역 장애 상황에서 오브젝트 스토리지의 내구성은 훨씬 더 강력한 것으로 입증되었습니다. 페이지서버나 세이프키퍼 노드에 장애가 발생하더라도 내구성 상태가 손실되지 않으며, 다른 노드가 WAL과 오브젝트 스토리지로부터 필요한 페이지를 재구성할 수 있습니다 .

영역 중복 스토리지는 선택 사항 아닌 기본 사항

많은 관리형 데이터베이스 서비스에서 다중 AZ 스토리지 복제는 별도 설정이 필요한 유료 기능입니다. 반면 Neon에서는 무료든 유료든 모든 요금제의 데이터베이스가 분산된, 영역 중복 오브젝트 스토리지와 여러 가용 영역에 분산된 NVMe SSD 캐시를 기반으로 운영됩니다 . 이는 물리적인 영역 간 복제를 별도의 관심사로 둘 필요가 없다는 뜻이며, 스토리지 계층 자체가 본질적으로 복제되어 있기 때문입니다.

WAL 복제 설계는 구체적인 내구성 보장을 제공합니다. 쓰기 작업은 쿼럼 요건(Quorum Requirement)과 함께 세이프키퍼에 동기식으로 복제됩니다. 공개된 한 구성은 6중 복제와 6개 중 4개의 쓰기 쿼럼을 사용하는데, 이는 가용 영역 하나 전체와 추가 복제본 하나가 동시에 사라져도 데이터 유실이 없음을 의미합니다 . 이는 이론적인 탄력성이 아니라, 클라이언트에 트랜잭션이 승인되기 전에 반드시 충족되어야 하는 쓰기 경로 상의 속성입니다.

특히 컴퓨팅 가용성 측면에서, 이 공유 스토리지 모델은 기존 주-복제본(Primary-Replica) 아키텍처가 따라잡을 수 없는 강점을 제공합니다. 모든 컴퓨팅 인스턴스가 동일한 내구성 있는 스토리지 기록을 공유하기 때문에, 교체될 컴퓨팅이 물리적 복제를 통해 따라잡을(Catch up) 필요가 없습니다. 단지 기존 기록에 접속하기만 하면, 워크로드와 캐시된 워킹 셋의 크기에 따라 몇 초에서 길어야 몇 분 안에 쿼리 서비스를 시작합니다 .

가용성 목표와 데이터가 말해주는 것

Neon의 레이크베이스 아키텍처를 위한 공개된 가용성 SLI는 약 99.93%에서 99.96% 사이로 보고됩니다 . 이 수치는 컴퓨팅 장애를 유휴 핫 스탠바이로 장애 조치하는 대신 무상태 노드 교체로 복구하고, 스토리지 내구성을 동기식 디스크 미러링 대신 오브젝트 저장소 기반 복제로 달성하는 설계를 반영합니다.

Neon의 자체 장애 기록은 이 목표치를 현실적으로 가늠할 수 있는 좋은 사례를 제공합니다. 2025년 5월 us-east-1에서 발생한 사건은 두 차례에 걸쳐 총 5.5시간 동안 데이터베이스 시작 및 생성 작업이 불가능했지만, 이미 실행 중인 활성 데이터베이스들은 아무 영향을 받지 않았습니다 . 근본 원인은 제어 영역 과부하와 AWS CNI 설정 오류로 인해 쿠버네티스 서브넷의 IP 주소가 고갈된 것이었으며, 이는 이후 셀 기반 아키텍처가 예방하도록 설계된 확장성 한계를 드러낸 사건이었습니다 . 그보다 앞선 2024년 8월, us-east-1에서 EC2 인스턴스 장애로 인한 페이지서버 중단은 최대 2시간 동안 전체 고객 프로젝트의 약 0.4%에 영향을 주었습니다. 페이지서버가 S3 기반의 로컬 디스크 캐시 역할을 하기 때문에, 페이지서버 장애는 영구적인 데이터 유실이 아닌 일시적인 가용성 저하로 이어졌습니다 .

이 사건들은 무상태 컴퓨팅과 공유 스토리지가 장애의 심각도를 낮추긴 하지만, 완전히 제거하지는 못한다는 사실을 분명히 보여줍니다. 컴퓨팅 장애로 인한 데이터 유실 제로, 재접속을 통한 자동 복구, 셀로 제한된 피해 범위와 같은 아키텍처의 회복 탄력성 속성은 실제 장애 상황에서 그 효용을 입증했습니다. 하지만 이 시스템도 소프트웨어 결함, 자원 고갈, 혹은 아직 완전히 분리되지 않은 클라우드 사업자 의존성(예: IP 주소 할당)으로부터 자유롭지는 않습니다.

회복 탄력성 테스트: 설계를 어떻게 검증하는가

Neon의 엔지니어링 블로그에 따르면, 이 시스템은 클라우드 사업자의 프로비저닝 장애 및 전체 가용 영역 연결 두절 시뮬레이션과 같은 현실적인 장애 시나리오에 대해 테스트됩니다 . 이러한 테스트는 피해 범위를 제한하기 위해 설계된 사전 프로비저닝 인스턴스 버퍼와 셀 격리 경계를 검증합니다. Neon이 설명하는 카오스 엔지니어링의 일반적인 형태는 확립된 관행을 반영합니다. 즉, 시스템이 장애 상황에서 어떻게 작동해야 하는지에 대한 '정상 상태 가설(Steady-State Hypothesis)'을 수립하고, 통제된 결함(예: AZ 전체 연결 해제 또는 컴퓨팅 버퍼 고갈)을 주입한 후, 그 가설이 유지되는지 관찰하며, 유지되지 않을 경우 아키텍처를 수정해 나가는 방식입니다 .

Neon이 아키텍처 블로그 개요 외에 상세한 카오스 엔지니어링 방법론이나 구체적인 실험 결과를 공개하지는 않았지만, 가용한 증거는 그들의 테스트가 이 시스템의 가장 독보적인 회복 탄력성 주장을 직접 겨냥하고 있음을 보여줍니다. Neon이 설명하는 테스트들, 즉 프로비저닝 장애 및 AZ 장애 시뮬레이션은 바로 무상태 컴퓨팅과 셀 격리가 전통적인 관리형 데이터베이스 아키텍처보다 가장 큰 이점을 제공해야 하는 시나리오입니다. 2026년 5월 AWS 장애는 사실상 동일한 메커니즘에 대한 계획되지 않은 대규모 검증이었으며, 제한된 피해 범위라는 결과는 사전 프로비저닝과 셀 격리가 설계된 목적과 정확히 일치하는 것이었습니다.

서버리스 Postgres를 평가하는 팀에게 주는 시사점

Neon의 아키텍처는 컴퓨팅을 일회용품처럼 취급하여 빠르게 교체하고, 스토리지 내구성과 장애 도메인 격리에 막대한 투자를 함으로써 특정한 회복 탄력성 트레이드오프를 제공합니다. 1분 미만의 간헐적인 쿼리 중단이 허용되고 주된 관심사가 데이터 안전인 워크로드에게, 이 모델은 핫 스탠바이를 유지하는 비용과 복잡성을 제거해 줍니다. 중단 없는 지속적인 쿼리 가용성이 요구되는 워크로드를 위해서는 추가적인 다중 컴퓨팅 구성이 가능하지만, 더 높은 비용이 수반됩니다.

이 아키텍처는 또한 클라우드 의존성에 대한 정직한 회계를 요구합니다. 어떤 데이터베이스 서비스도 기반 클라우드 사업자로부터 진정으로 독립적일 수는 없지만, 그 결합의 정도는 천차만별입니다. 용량을 사전 프로비저닝하고, 자체 가상화 계층을 사용하며, 블록 볼륨 대신 오브젝트 스토리지에 데이터를 저장하기로 한 Neon의 결정은 데이터베이스 계층이 작동하기 위해 반드시 가용해야 하는 클라우드 사업자 API의 표면적을 극적으로 줄입니다. 이 축소된 의존성 표면적은 2026년 5월 AWS 장애 당시 빛을 발했습니다. 사전 프로비저닝 버퍼가 충분했던 셀들은 더 긴밀하게 결합된 아키텍처였다면 리전 전체로 번졌을 장애 속에서도 중단 없이 계속 운영되었으니까요.

서버리스 인프라를 구축하는 팀들에게, Neon의 접근 방식은 피해 범위 억제가 단순한 사후 고려 사항이 아님을 보여줍니다. 이는 실제 장애가 훨씬 이전에, 스토리지-컴퓨트 경계와 장애 도메인 구조라는 아키텍처 결정으로부터 만들어진 산물인 것입니다.