레이크하우스 아키텍처가 클라우드 장애에 복원력을 유지하는 방법

지난해 에이전트는 새로운 사용 패턴으로 클라우드 인프라의 한계를 시험했습니다.

• 컨트롤 플레인 작업의 높은 처리량: 에이전트는 사람이 하는 것보다 훨씬 높은 속도로 데이터베이스, 스토리지, 컴퓨팅 및 기타 인프라 구성 요소를 프로그래밍 방식으로 생성하고 관리합니다. Databricks Lakebase에서는 에이전트가 사람이 만드는 것보다 4배 더 많은 데이터베이스를 생성합니다.
• 주문형 수요 증가: 서버리스, 자동 확장 및 자동 중지 인프라가 새로운 표준이 되었습니다. 에이전트가 절전 모드로 들어가면 프로비저닝된 인프라에 비용을 지불할 이유가 없습니다.
• 용량 부족: 컴퓨팅, GPU 및 클라우드 인프라에 대한 수요가 증가하고 있습니다. 클라우드의 “무한한” 용량이라는 개념에 균열이 보이기 시작했습니다.

이는 플랫폼 빌더와 클라우드 제공업체 모두에게 어려운 문제입니다. 컨트롤 플레인은 인프라를 생성, 관리 및 확장하기 위한 요청 볼륨이 크게 증가하여 안정성에 부담을 주고 있습니다. 새로운 클라우드 용량을 할당하는 것이 항상 성공하지는 않을 것입니다. 동시에 에이전트 워크로드는 운영 흐름의 일부로 핵심 컨트롤 플레인 작업에 대한 데이터 플레인 수준의 안정성을 요구합니다. 지난 몇 달 동안 에이전트는 데이터베이스 시작 횟수의 기하급수적인 증가를 주도했으며, 이제 매일 수천만 개의 데이터베이스를 시작하고 있습니다.

결과적으로 클라우드 서비스에서 발생한 수많은 실패와 사고는 안정성 로드맵에 영향을 미치는 교훈을 주었으며, lakebase 아키텍처와 설계를 클라우드 장애에 더 탄력적으로 만드는 방법을 공유하고자 합니다. 일부 항목은 이미 프로덕션에 적용되었고, 다른 항목은 진행 중입니다.

고가용성 아키텍처

기본에는 분리된 컴퓨팅 및 스토리지 아키텍처가 있으며, 여기서 고가용성(HA)은 시스템의 핵심 설계 원칙이며 추가 기능이 아닙니다.

상태 비저장 Postgres 컴퓨팅

많은 클라우드 Postgres 데이터베이스 서비스 설정이 모놀리식이고 상태 저장 컴퓨팅을 사용하는 것과 달리, lakebase 아키텍처의 Postgres는 상태 비저장입니다. 모든 영구 데이터는 원격 스토리지 서비스에 저장되므로 컴퓨팅 프로세스는 로컬 디스크에 영구 상태를 보유하지 않습니다. Postgres 또는 해당 하드웨어가 실패하면 데이터를 핫 스탠바이에 복제하거나 일반적인 Postgres 충돌 복구를 실행하지 않고도 즉시 교체할 수 있습니다. 모놀리식 설정의 핫 스탠바이는 데이터의 전체 복사본(무료 아님)이 필요하며, 충돌 복구는 마지막 체크포인트부터 쓰기 전 로그를 다시 재생해야 합니다. 이는 충돌 시점의 쓰기 속도에 따라 확장되며 구성에 따라 10분 이상 걸릴 수 있습니다. 데이터베이스 내용은 영역 복원력 있는 스토리지 서비스에 저장되므로, Lakebase의 단일 컴퓨팅 Postgres 인스턴스는 추가 핫 스탠바이 컴퓨팅 인스턴스 비용 없이 단일 상태 저장 Postgres 인스턴스보다 가용성이 훨씬 향상되었습니다.

최고 수준의 가용성이 필요한 데이터베이스의 경우 고가용성을 구성할 수 있습니다. 이는 여러 가용 영역에 전용 컴퓨팅을 프로비저닝하여 데이터베이스가 클라우드 제공업체가 장애 이벤트 중(또는 결과로) 용량이 부족하더라도 데이터베이스를 계속 사용할 수 있도록 보장합니다. 이러한 컴퓨팅은 추가로 읽기 확장을 위해 활용될 수 있습니다.

모든 것을 위한 영역 중복 스토리지

모놀리식 Postgres 설정은 일반적으로 영역 중복성이 거의 없는 로컬 블록 장치에 의해 백업됩니다. 이는 여러 가용 영역에 걸쳐 물리적 복제와 비용이 많이 드는 핫 스탠바이 복제본을 필요로 합니다. Lakebase 및 Neon에서는 모든 데이터베이스(계층 및 구성에 관계없이)가 분산되고 영역 중복성이 있으며 고가용성인 스토리지에 의해 백업됩니다. 데이터는 내구성이 뛰어나고 영역 중복성이 있는 객체 스토리지에 저장되며, 여러 가용 영역에 걸쳐 NVMe SSD 캐시를 통해 성능이 가속화됩니다. 추가 비용은 없습니다.

컨트롤 플레인이 새로운 데이터 플레인입니다

모놀리식 클라우드 데이터베이스 서비스 아키텍처에서 데이터 플레인은 서비스의 중요한 부분입니다. 99.99% 이상의 가용성과 정적 안정성을 위해 설계되었습니다. 컨트롤 플레인은 “단지” 관리 작업에만 중요합니다. 에이전트 및 주문형 워크로드의 경우, 데이터베이스를 시작하는 컨트롤 플레인 부분이 사실상 데이터 플레인이 됩니다. 이것이 우리의 아키텍처에 대한 생각을 바꾸었습니다. 현재 컨트롤 플레인은 데이터베이스 시작부터 결제까지 모든 것을 처리합니다. 전자는 분명히 더 중요합니다. 백그라운드 유지 관리 작업이 주문형 데이터베이스 시작에 리소스를 고갈시킨 장애가 있었는데, 이는 분명히 좋지 않습니다.

현재 우리는 컨트롤 플레인의 중요한 부분을 핫 경로 작업(시작/중지)만 처리하는 데이터 플레인 컨트롤러 서비스로 분리하기 위해 노력하고 있습니다. 이 서비스는 비즈니스 로직이 적고, 엄격하고 최소한의 외부 종속성(다음 섹션 참조)을 가지며, 복원력, 점진적 성능 저하 및 심층 방어를 최우선으로 하여 처음부터 설계되었습니다.

컨트롤 플레인이 데이터베이스 트래픽에 얼마나 중요한지를 설명하기 위해 컴퓨팅 세션 수명(수신 연결로 인한 자동 재개부터 비활성으로 인한 종료까지의 시간)을 분석할 수 있습니다. Neon에서는 자동 중지 데이터베이스의 컴퓨팅 세션 중 90%가 10분 미만입니다.

클라우드 제공업체 컨트롤 플레인을 포함한 중요 경로 종속성을 신중하게 고려하십시오

에이전트 워크로드 서비스를 제공하려면 데이터베이스를 생성하고 다시 시작하는 것이 매우 안정적이어야 합니다. 안정성은 종속성 체인 및 흐름에 관련된 기계의 양과 강하게 상관관계가 있습니다. 클라우드 제공업체 VM에서 Postgres를 사용하는 기존 설정에서는 이는 데이터 플레인을 훨씬 넘어섭니다.

• VM 프로비저닝을 위한 클라우드 제공업체의 컴퓨팅 컨트롤 플레인
• 사용 가능한 VM 용량(클라우드 제공업체가 누구에게 할당할지 정책을 제어함)
• 로컬 스토리지 프로비저닝을 위한 클라우드 제공업체의 블록 스토어 컨트롤 플레인
• 새 VM에 대한 IP 할당, 방화벽 구성 및 네트워크 경로를 위한 클라우드 제공업체의 네트워킹 컨트롤 플레인
• Kubernetes(K8s)를 사용하는 경우 - K8s 시스템 서비스에 대한 추가 종속성

Lakebase에서는 데이터베이스 흐름에 관련된 컨트롤 플레인 기계의 양을 대폭 줄이는 다른 접근 방식을 취합니다.

• 클라우드 제공업체로부터 큰(종종 베어 메탈) 인스턴스 풀을 할당합니다. 클라우드 제공업체의 프로비저닝 중단을 견딜 수 있는 버퍼를 유지합니다.
• 이러한 클라우드 인스턴스에 여러 Postgres 인스턴스를 예약하는 자체 수직 자동 확장 가상화 계층을 구축했습니다.
• 클라우드 블록 스토리지 장치에 의존하는 대신, 궁극적으로 S3 또는 Azure Blob 스토리지와 같은 객체 스토어에 백업되는 자체 영역 중복 스토리지에 데이터를 저장합니다.

Databricks의 다른 많은 서비스도 동일한 안정성 문제에 직면해 있습니다. 이것이 바로 Lakebase가 Databricks의 일부인 이유입니다. Databricks는 세 가지 주요 클라우드에서 모든 제품의 안정성을 높이기 위한 공통 플랫폼 구축에 투자하고 있습니다.

구획화하고 영향 범위를 제한하십시오

단일의 거대한 지역 배포를 실행하는 대신, Lakebase는 하나 이상의 동일한 모양의 셀로 지역을 구성합니다. 셀은 Neon 및 Lakebase 스택(Kubernetes, 제어 평면, 컴퓨팅 및 스토리지)의 완전하고 독립적인 조각입니다.

이는 두 가지 방식으로 도움이 됩니다:

• 확장성: 지역을 확장하려면 셀을 추가합니다. 기존 셀이 Kubernetes 및 제어 평면의 확장성 한계에 접근하면, 새 프로젝트 생성은 새로 프로비저닝된 셀로 라우팅됩니다. 셀은 수요가 증가함에 따라 빠르게 시작됩니다.
• 영향 범위 제한: 철저한 테스트와 내장된 보호 기능에도 불구하고 프로덕션에서는 여전히 문제가 발생할 수 있습니다(Kubernetes 제어 평면/시스템 서비스 문제, 코드 또는 구성 회귀, DoS 상황 등). 셀 경계는 오류를 격리하고 상황이 확산되는 것을 방지하여 해당 지역의 다른 셀이 정상적으로 트래픽을 처리하도록 합니다.

이를 통해 저희 플랫폼은 단일 장애의 영향 범위를 제한하면서 지역을 탄력적으로 확장할 수 있습니다. 2026년 5월 8일 AWS가 us-east-1의 가용 영역에 문제를 겪었던 사고 중에, 셀 중 하나가 정상 노드로 장애 조치를 하는 데 문제가 있었습니다. 영향은 해당 셀로 제한되었습니다. 해당 지역의 나머지 일곱 개 셀은 정상적으로 장애 조치되었으므로, 사고는 해당 지역 데이터베이스의 약 13%에만 영향을 미쳤습니다. 이 경우 셀 기반 아키텍처는 영향을 약 10배 줄였습니다.

장애 시뮬레이션 및 주입

이중화 아키텍처와 원칙은 실제로 작동하지 않으면 큰 가치가 없습니다. 모든 가능한 장애 모드를 브레인스토밍할 수 있지만, 머피의 법칙은 여전히 유효하며 복잡한 시스템은 항상 예상치 못한 방식으로 작동합니다. 모든 Lakebase 릴리스는 프로덕션에 배포되기 전에 장애 주입 및 카오스 테스트를 거칩니다. 실제 클러스터에 릴리스를 배포하고, 에이전트 및 비에이전트 OLTP 및 OLAP 워크로드의 혼합을 스트레스 수준 동시성으로 구동한 다음, 하부에서 문제를 일으키기 시작합니다. 프로세스를 종료하고, 노드를 다운시키고, 네트워크 장애를 주입하고, 디스크 내용을 삭제하고, 구성 요소를 반복적으로 다시 시작하며, 이 모든 동안 워크로드는 계속 실행됩니다. 가장 나쁜 시점에 충돌하는 것과 같이 재현하기 어려운 오류를 주입하기 위해 코드에 failpoints를 광범위하게 사용합니다. 이는 단일 프로세스를 대상으로 하거나 전체 셀에 걸쳐 클러스터 전체 장애를 조정할 수 있는 내부 장애 주입 프레임워크에 의해 구동됩니다.

저희의 통과 기준은 "테스트에서 오류가 발생하지 않음"보다 엄격합니다. 저희는 Postgres의 올바른 동작을 검증하기 위해 SqlLancer 및 SqlSmith와 같은 오픈 소스 도구와 유사한 내부 도구를 사용합니다. 장애 주입이 실행되는 동안 내부 데이터 일관성, 커밋된 트랜잭션이 손실되지 않았는지, 그리고 모든 구성 요소가 자체적으로 일관된 상태로 복구되는지 확인합니다.

이제 저희는 구성 요소 수준의 혼란에서 전체 AZ 다운 시뮬레이션으로 한 단계 더 나아가고 있습니다. 워크로드가 실행 중인 실제 클러스터에서, 가용 영역의 네트워크를 클러스터의 나머지 부분과 프로그래밍 방식으로 분리하고 시스템이 어떻게 반응하는지 관찰합니다: 스토리지가 생존 복제본으로 얼마나 빨리 전환되는지, 컴퓨팅이 정상 AZ로 얼마나 빨리 장애 조치되는지, 프록시 계층이 연결을 어떻게 다시 라우팅하는지, 그리고 개별 데이터베이스가 얼마나 오래 중단을 보는지 등입니다. 저희의 목표는 어떤 워크로드도 30초 이상 다운되지 않도록 하는 것입니다.

측정, 측정, 측정

Lord Kelvin은 “측정할 수 없다면 과학이 아니다”라고 말했습니다. 저희는 이를 체화하고 가용성 및 안정성을 측정하는 것을 과학으로 만듭니다. https://neonstatus.com/에서 볼 수 있는 사용자에게 보이는 상태는 개략적인 보기입니다. 내부적으로는 서비스 수준 지표(SLI)를 측정하고 모든 시스템 구성 요소 및 주요 작업, 특히 사용자 대면 작업에 대한 목표(SLO)를 설정합니다. 예를 들어, 다음과 같은 항목을 측정합니다:

• 데이터베이스 가용성: 각 개별 데이터베이스가 사용 가능한 시간의 비율입니다. 개별 고객은 자신의 데이터베이스가 다운된 경우 전체가 좋은 가용성을 가졌는지 신경 쓰지 않기 때문에, 저희는 단순히 전체 플릿의 가용성만 측정하지 않습니다.
• 데이터베이스 시작 시간: 연결 시 일시 중지된 데이터베이스가 얼마나 빨리 사용 가능해지는지, 또는 새 데이터베이스가 얼마나 빨리 시작되는지입니다.
• 데이터베이스 전환/장애 조치: 빈도 및 지연 시간. 가능한 한 드물게, 그리고 발생 시 가능한 한 빠르게.
• 스토리지: Postgres에서 스토리지로의 페이지 읽기 및 내구성 있는 쓰기의 가용성 및 지연 시간입니다. 이는 귀하의 워크로드가 필요한 것을 얻고 있는지 알려줍니다.
• 제어 평면 API: 브랜칭과 같은 중요한 작업의 성공률 및 지연 시간입니다.

저희의 목표는 모든 데이터베이스가 매월 99.99% 이상의 가용성을 달성하는 것입니다. 저희는 달성률로 해당 목표에 얼마나 가까운지 측정합니다: 목표를 달성한 플릿 데이터베이스의 비율입니다. 아래는 2026년 월간 활성 데이터베이스에 대한 Neon의 현재까지의 가용성 달성률입니다.

운영 시스템에서 최고 수준의 안정성과 가용성은 매우 중요합니다. 저희는 귀하의 데이터베이스 서비스에 대한 신뢰를 구축하기 위해 열심히 노력하고 있습니다.

팀

위의 안정성 작업은 관계형 데이터베이스를 구축하고 운영한 경력을 가진 사람들이 주도하고 있습니다. 그중 일부는 다음과 같습니다:

• Jasraj Dange - Lakebase 엔지니어링 리더, 이전에는 Azure SQL Database 성능 및 확장성 작업을 주도했으며 Azure SQL Database를 애플리케이션을 위한 강력한 플랫폼으로 만들었습니다.
• Hans Norheim - Lakebase 가용성 및 안정성에 중점, Microsoft에서 SQL Server 및 Azure SQL Database에서 13년간 근무했으며, 다운타임 없이 SQL Server를 업데이트할 수 있는 핫 패치 기술과 Azure SQL Database를 99.995% 가동 시간 SLA로 유지하는 업그레이드 오케스트레이션을 포함합니다.
• Stas Kelvich - Neon을 공동 창립한 후 현재 Lakebase에서 근무 중입니다. Neon 이전에는 Postgres Professional에서 5년간 Postgres 내부 작업을 수행했으며, 쿼럼 커밋을 통한 내결함성 멀티 마스터 복제, 느슨하게 동기화된 클록을 사용한 노드 간 스냅샷 격리, 2단계 커밋 및 논리 복제 개선 등이 포함됩니다.
• John Spray - Lakebase 스토리지 리드. 이전에는 스토리지 및 컴퓨팅을 이끌며 샤딩과 같은 주요 확장 개선 작업을 수행했습니다. 그 전에는 Redpanda, Red Hat(Ceph), Intel에서 분산 스토리지 및 시스템 작업을 수행했습니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)