Lakebase의 제로 다운타임 패치 파트 1: 사전 워밍

Lakebase에서 고객 데이터베이스를 항상 사용할 수 있도록 보장하는 것은 우리가 하는 가장 중요한 일 중 하나입니다. 우리는 시스템을 모든 수준에서 이중화하여 설계했으며, 하드웨어 또는 소프트웨어 장애 발생 시 데이터베이스를 자동으로 장애 조치하고 복구합니다.

대규모 시스템에서는 이러한 예기치 않은 장애가 통계적으로 예상되지만, 개별 데이터베이스의 경우 빈도가 그렇게 높지는 않습니다. 개별 데이터베이스의 경우, 계획된 유지보수가 더 많은 워크로드 중단을 유발하는 경향이 있습니다. 결국, 일반적인 데이터베이스는 하드웨어 장애보다 더 자주 패치됩니다.

오늘날 거의 모든 데이터베이스 제공업체는 유지보수 기간을 운영합니다. 이 기간 동안 데이터베이스는 모든 활성 연결을 끊고 몇 초에서 몇 분까지 걸릴 수 있는 프로세스를 통해 업데이트 및 다시 시작됩니다. Lakebase를 사용하면 최적의 시간에 업데이트를 예약할 수 있지만, 여전히 발생 시 잠시 중단됩니다.

우리는 더 나은 방법을 찾을 수 있다고 생각합니다. 이 블로그 게시물은 Lakebase 아키텍처를 활용하여 계획된 유지보수의 영향을 완전히 제거하는 방법에 대한 시리즈의 첫 번째 게시물입니다. 우리의 목표는 버전 업데이트 및 보안 패치를 완전히 눈에 띄지 않게 만드는 것입니다.

이 게시물에서는 데이터베이스 다시 시작 후 발생하는 성능 저하를 방지하는 기술인 사전 워밍에 대해 다룹니다. 향후 게시물에서는 장애 조치 프로세스 자체의 개선 사항과 진정한 제로 다운타임 패치에 더 가까이 다가가는 추가 최적화에 대해 논의할 것입니다.

콜드 재시작의 문제점

PostgreSQL을 다시 시작할 때의 문제는 인메모리 캐시(특히 버퍼 캐시 및 로컬 파일 캐시)가 손실된다는 것입니다. 데이터베이스가 매우 빠르게 온라인 상태로 돌아오더라도(P99에서 1초), 다시 시작 후 몇 분 동안 워크로드는 성능 저하를 겪을 수 있습니다. 이는 데이터가 스토리지에서 다시 읽히고 캐시가 워밍업되는 동안 낮은 캐시 적중률 때문입니다. 이는 성능 문제처럼 보일 수 있지만, 지연 시간이 너무 심각하여 데이터베이스가 워크로드를 따라가지 못하고 타임아웃이 발생하는 경우 가용성 문제가 될 수 있습니다.

이를 해결하기 위한 기술은 Postgres에 존재합니다. pg_prewarm을 사용하여 버퍼 캐시를 워밍업할 수 있습니다. 그러나 이는 워크로드가 이미 영향을 받은 후에 다시 시작될 때 실행됩니다. 스트리밍 복제를 사용하여 복제본을 설정할 수 있으며, 이를 장애 조치하기 전에 사전 워밍할 수 있습니다(주로 승격). 그러나 이를 위해서는 전체 복제본을 생성하고 장애 조치 전에 사전 워밍을 신중하게 조정해야 합니다.

Lakebase 아키텍처에서의 사전 워밍

Lakebase 아키텍처에서 우리는 상태 비저장, 탄력적인 컴퓨팅 노드와 분리된 공유 스토리지를 결합합니다. 컴퓨팅 노드는 서버리스 속성을 희생하지 않고 최대 성능을 제공하기 위해 로컬 캐시를 사용합니다. 캐시는 위에서 설명한 동일한 콜드 스타트 문제를 겪지만, Lakebase 아키텍처를 사용하면 더 많은 옵션을 사용할 수 있습니다.

Lakebase의 Postgres 컴퓨팅 복제본은 상태 비저장이므로 필요에 따라 켜고 끌 수 있습니다. 우리는 이를 활용하고 계획된 다시 시작 시 자동 사전 워밍과 결합하여 워크로드에 대한 성능 영향을 최소화합니다. 작동 방식은 다음과 같습니다.

1. Lakebase의 Postgres 컴퓨팅 이미지의 새 버전을 사용할 수 있게 됩니다. 알림을 받고 사용자에게 편리한 시간에 다시 시작을 예약할 수 있습니다.
2. 예약된 시간 직전에 제어 플레인이 백그라운드에서 새 Postgres 컴퓨팅을 시작합니다. 사용자는 이를 볼 수 없으며 비용도 청구되지 않습니다. 현재 주 복제본의 워크로드에는 영향을 미치지 않습니다.
3. 현재 주 복제본의 캐시에 있는 페이지 목록이 새 컴퓨팅으로 전송됩니다. 새 컴퓨팅은 공유 스토리지 계층에서 해당 페이지를 로드하며, 이는 주 복제본에 영향을 주지 않습니다.
4. 새 컴퓨팅은 WAL(쓰기 전 로그)을 구독하여 캐시를 최신 상태로 유지합니다. 효율성을 위해 일반 Postgres 복제본과 달리 캐시에 영향을 미치지 않는 모든 WAL 레코드를 무시할 수 있습니다. WAL은 Safekeepers에서 가져오므로 주 컴퓨팅에 추가 부하를 주지 않습니다.
5. 사전 워밍이 완료되면 이전 주 복제본을 빠르게 종료하고 새 컴퓨팅을 주 복제본으로 승격하여 전환합니다. 승격은 OSS Postgres의 표준 pg_promote를 사용하며 데이터베이스 서버를 다시 시작하지 않습니다.

이전:

이후:

Lakebase 아키텍처를 사용하면 추가 복제본에 대한 비용을 지불하지 않고도 추가 비용 없이 이를 얻을 수 있습니다. 오늘부터 읽기/쓰기 엔드포인트의 모든 계획된 다시 시작은 사용자가 아무것도 할 필요 없이 이러한 방식으로 수행됩니다. 곧 읽기 전용 엔드포인트로도 확장할 예정입니다.

결과

콜드 캐시의 영향을 측정하기 위해 데이터베이스를 다시 시작하는 동안 10GB pgbench(스케일 팩터 670)를 실행했습니다. 먼저 사전 워밍이 활성화된 상태로, 다음으로 사전 워밍 없이 실행했습니다. 첫 번째 차트는 읽기 전용 워크로드(pgbench “select only”)를 보여주고, 두 번째 차트는 읽기-쓰기 워크로드(pgbench “simple update”)를 보여줍니다.

두 경우 모두 사전 워밍을 사용하면 처리량이 거의 즉시 복구되는 것을 볼 수 있습니다. 사전 워밍 없이는 콜드 캐시가 워밍업되는 동안 복구가 훨씬 느립니다. 사전 워밍이 캐시 적중률을 개선하여 쓰기보다 읽기에 비례적으로 더 도움이 되기 때문에 읽기 전용 워크로드의 경우 차이가 가장 두드러집니다.

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