Kubernetes 환경에서 PostgreSQL을 운영할 때 가용 영역, 스토리지, 복제, 재해 복구를 고려해 선택할 수 있는 대표 아키텍처 패턴과 권장 사항을 정리한다.
2023년 9월 29일 게시 · 작성자: Gabriele Bartolini
EDB의 Cloud Native 부문 VP인 Gabriele Bartolini의 멤버 포스트
몇 달 전 Kelsey Hightower는 트위터에서 이렇게 말했습니다. “Kubernetes에서 데이터베이스를 실행할 수 있는 이유는, 근본적으로 VM에서 데이터베이스를 실행하는 것과 동일하기 때문이다.” 이는 그가 2018년에 트위터에서 했던 말, “Kubernetes는 상태 저장 워크로드를 지원한다; 하지만 나는 지지하지 않는다”(링크)와는 꽤 대조적입니다.
(원문에는 관련 트윗 스크린샷 이미지가 포함되어 있습니다.)
사실 저는 지금도, 그리고 그때도 그에게 동의합니다. 당시에는 Kubernetes의 스토리지 기능이 아직 성숙하지 않았습니다(로컬 퍼시스턴트 볼륨이 GA가 된 것은 이듬해였습니다). 또한, 그 사이 데이터베이스 같은 상태 저장 애플리케이션에 결정적으로 중요하다는 것이 입증된 오퍼레이터 패턴도 널리 받아들여지기 전이었습니다. 그리고 Data on Kubernetes Community도(2020년 하반기) 2년 이상 뒤의 일이었죠.
지금은 상황이 완전히 달라졌습니다. 지난 몇 년간 Kubernetes에 상태 저장 워크로드를 올리기 위해 열심히 노력해 온 많은 사람들도, Kelsey의 최근 강력한 발언이 대중의 인식을 되돌리고 우리의 미션을 더 쉽게 해주는 데 기여할 것이라고 저와 같은 생각을 할 거라 확신합니다. 물론 우리가 계속 잘해 나간다는 전제하에서요.
제 개인적인 의견은 더 나아갑니다. 몇 가지 요구사항만 충족된다면, Kubernetes에서 PostgreSQL을 실행하는 것이 VM에서 실행하는 것보다 더 낫습니다. PostgreSQL은 최근 전 세계에서 가장 인기 있는 DBMS로 선정되기도 했습니다.
저는 2019년부터 Kubernetes 및 클라우드 네이티브 조직에서 Postgres 사용 경험을 개선하는 데 집중해 왔습니다. 저희 팀은 Kubernetes에서 로컬 스토리지를 한계까지 밀어붙여, 수십 년간 전 세계 최대 규모 PostgreSQL 설치 환경에서 사용해 온 베어메탈/VM 솔루션과 비교해 성능이 어떤지 확인하기로 했습니다.
파일럿 프로젝트의 일환으로 2019년 말, 베어메탈 Kubernetes 클러스터에서 벤치마크를 수행해 이 이니셔티브가 가치가 있는지(실패를 빠르게 확인하는 접근법으로) 점검했습니다. 결과는 기대 이상이었고, 이후 블로그 글로 공개했습니다. 그때 우리는 Kubernetes에서 Postgres를 실행하는 것이 베어메탈이나 VM에서 실행하는 것과 동일한 스토리지 과제를 가지지만, 다음 세 가지가 반드시 필요하다는 점을 깨달았습니다.
저는 빠르게 성장하는 오픈 소스 오퍼레이터(CloudNativePG)의 메인테이너이며, 주로 PostgreSQL 배경을 가진 고객/사용자와 소통합니다. 이 글에서는 뒤의 두 가지 요구사항(PostgreSQL 지식 및 오퍼레이터)은 충족되어 있다고 가정하고, Kubernetes 측면에 집중하겠습니다.
먼저 한 가지를 분명히 해야 합니다. Kubernetes는 (적절한 비유를 하자면) 단순한 VM 프로비저닝 서비스가 아니라 가상 데이터센터라는 더 넓고 복잡한 문제를 해결하도록 도와줍니다.
물론 온프레미스에서 Kubernetes를 직접 운영(self-managed)하기로 선택한다면, 인프라 레벨에서 비즈니스 연속성(BC) 요구사항과 문제의 상당 부분을 표준적인 방식으로 아래로 내려 해결할 수 있도록 사람과 역량에 투자하는 결정을 의식적으로 내린 것입니다. 3개 이상 가용 영역(AZ)을 제공하는 퍼블릭 클라우드의 매니지드 Kubernetes 서비스를 채택하면 이 영역의 투자 부담을 확실히 줄일 수 있지만, 여전히 다학제(stream-aligned) 팀 내부 또는 여러 팀이 공유하는 플랫폼 팀(스켈턴과 파이스의 『Team Topologies』에서 정의한 형태) 내에 Kubernetes를 이해하는 T자형 인재가 필요합니다.
좋은 소식은 Kubernetes는 학습 가능하다는 점입니다. 또 다른 좋은 소식은 Kubernetes가 표준 인프라를 제공하므로, 퍼블릭 클라우드나 프라이빗 환경(요즘 고객들이 가장 자주 선택하는 두 패턴)으로 쉽게 이동할 수 있고, 이후 하이브리드/멀티클라우드 분산 전략을 점진적으로 탐색할 수 있다는 점입니다. 이는 클라우드 서비스 제공자(CSP) 벤더 락인에 대한 매우 값진 해법이자 협상력도 제공합니다.
따라서 제 조언은, 전통적인 환경에서 Kubernetes로 데이터베이스를 “리프트 앤 시프트”하려는 유혹을 피하라는 것입니다. (장기 여정에서 의식적으로 선택한 중간 단계라면 예외입니다.) 여정 초기에는 Kubernetes 역량이 매우 중요합니다. 이 단계에서 내린 결정은 나중에 바꾸기 어렵거나, 불가능할 수도 있습니다. 하지만 목표(클라우드 네이티브를 이해하는 조직) 자체가 변혁을 위한 수단이기도 하기에, 아직 보지 못하는 문제를 해결하지 못하는 일이 흔히 발생합니다.
이 글을 읽으며 Kubernetes 배경 없이 클라우드 네이티브 환경에서 Postgres를 쓰려 한다면, 제 조언은 0일차부터 인증된 서비스 제공자(KCSP)의 전문 지원을 즉시 받으라는 것입니다. 모두가 Kubernetes로 간다고 해서 그것이 당신의 조직에도 반드시 좋은 선택인 것은 아닙니다.
또한 전문 지원을 받더라도, 아키텍처 결정을 도와줄 Kubernetes 전문가들에게 이 글을 반드시 공유하세요. 그들이 Kubernetes에서는 전문가일지라도, Kubernetes 내부에서 PostgreSQL 같은 상태 저장 워크로드를 운영하는 데는 익숙하지 않을 수 있습니다.
CNCF 스토리지 TAG(Storage Technical Advisory Group)가 만든 “Cloud Native Disaster Recovery Whitepaper”에도 매우 통찰력 있는 정보가 있습니다. 이 글을 더 잘 이해하는 데 도움이 되는 기본 용어와 개념을 제공합니다.
Kubernetes는 여러 가용 영역에 걸쳐 실행되도록 설계되었고, 하나(또는 동시에 여러 개) 데이터센터 장애에 대한 복원력을 자동으로 제공하도록 설계되었습니다. 이를 위해서는 데이터센터 간 네트워크가 고대역폭, 저지연, 그리고 이중화되어 있어야 합니다. 이런 조건이 충족되면, Kubernetes 컨트롤 플레인은 서로 다른 데이터센터에 존재하는 노드들에 걸쳐 분산되고, 웹 애플리케이션이나 Postgres 데이터베이스 같은 워크로드도 마찬가지로 분산됩니다. 주요 클라우드 제공자는 모두 동일 리전 내 최소 3개 가용 영역에 걸친 Kubernetes 서비스를 제공합니다.
일부 벤더는 이를 “스트레치드(stretched)” Kubernetes 클러스터라고 부릅니다. 예를 들어 Red Hat은 스트레치드 OpenShift 클러스터를 서로 다른 위치의 노드 간 왕복 지연(RTT)이 5ms를 넘지 않고, 최대 RTT가 10ms일 때만 권장합니다.
(원문에는 데이터센터 간 저지연 네트워크 연결을 보여주는 다이어그램 이미지가 포함되어 있습니다.)
하지만 온프레미스 설치를 가진 고객과 대화해 보면, 데이터센터가 같은 도시/수도권에 있어도(종종 길 건너 다른 건물에 있는 경우도 있습니다) 가용 영역/데이터센터와 Kubernetes 클러스터를 1:1로 매핑하는 경우를 여전히 많이 봅니다. 즉:
이런 현상은 아마 다음 두 가지 이유로 설명될 겁니다.
첫 번째 경우는 이해하지만, 온프레미스에서 Kubernetes를 운영하려는 전 세계 조직들이 최소 3개 이상의 데이터센터를 리전 내에 계획하고, 클라우드 제공자들이 10년 넘게 해 온 방식을 모방하도록 더 밀어붙일 필요가 있다고 생각합니다. 2개에서 3개 이상 데이터센터로의 전환은 하루아침에 되지 않지만, 지금부터 계획을 시작하는 것이 중요합니다.
두 번째 경우에서, 우리가 다루는 애플리케이션은 PostgreSQL이라는 점을 고려해야 합니다. PostgreSQL은 15년 이상 버전이 올라갈 때마다 물리/논리 복제에 대한 기본 지원과 성능을 꾸준히 강화해 왔습니다. 물리 복제는 다음 두 가지의 기반입니다.
이 기능들은 모두 Postgres가 기본으로 제공하며, CloudNativePG 오퍼레이터가 네이티브로 지원합니다.
따라서 Kubernetes에서 Postgres를 운영할 때 제 조언은 다음과 같습니다.
아래 각 섹션에서 흔히 마주치는 사용 사례에 대해 더 구체적인 정보와 디테일을 제공합니다.
두 개 데이터센터를 넘길 수 없어서 Kubernetes 클러스터도 두 개로 분리해야 한다면, 낙담하지 마세요.
(원문에는 각 데이터센터에 각각 Kubernetes 클러스터가 있는 다이어그램 이미지가 포함되어 있습니다.)
이 경우 하나의 데이터센터를 프라이머리로, 다른 하나를 재해 복구(DR)로 취급하는, 일종의 액티브/패시브 시나리오를 받아들이는 것입니다. 또한 두 데이터센터 간 활동을 조율해야 하며(멀티 AZ 스트레치드 클러스터에서 Kubernetes가 해주는 기본 작업을 사람이 대신하는 셈), 프라이머리 데이터센터에 예기치 못한 장애가 발생하면 수동 작업이 필요할 수 있다는 점도 감수해야 합니다. 예를 들어 비즈니스 연속성/재해 복구 계획에 따라 3~6개월마다 DR 시뮬레이션을 수행한다면, 이런 수동 작업이 정기적으로 일어날 수도 있습니다.
좋은 점은, 최적은 아니더라도 각 데이터센터에서 가능한 한 단일 장애 지점(SPoF)을 제거한다면 Postgres에 대해 RPO/RTO 측면에서 매우 좋은 결과를 얻을 수 있다는 것입니다. 예를 들어 같은 데이터센터 내 Postgres 인스턴스들이 네트워크 외에는 아무것도 공유하지 않도록, 서로 다른 워커 노드 및 서로 다른 스토리지에 스케줄링하세요. 이런 권장 사항은 언제나 유효하지만, 여기서는 특히 중요합니다. 스트레치드 Kubernetes 클러스터에서처럼 여러 데이터센터에 걸친 자동 페일오버를 매끄럽게 활용할 수 없기 때문입니다.
CloudNativePG에는 “레플리카 클러스터(Replica clusters)”라는 기능이 있어 다른 데이터센터에 대칭적인 Postgres 아키텍처를 다시 만들 수 있습니다. 레플리카 클러스터는 지속적으로 복제되며, 오브젝트 스토어에서 WAL 파일만 가져오는 방식으로(활성 스트리밍 복제 연결이 없어도) 수동 승격(promote)이 가능하도록 준비된 상태를 유지합니다. 이 내용은 아래 “단일 Kubernetes 클러스터를 넘어” 섹션에서 더 자세히 다룹니다.
가용 영역은 잠시 제쳐두고 큰 그림에서 보면, Kubernetes에서 PostgreSQL을 운영하는 가장 초급 단계는 “모든 것을 공유(share everything)”하는 접근입니다. Postgres를 다른 애플리케이션과 동일하게 취급해, Kubernetes 스케줄러가 요청 리소스에 따라 가능한 곳이면 어디든 데이터베이스를 배치하게 하고, 동일한 네트워크 스토리지를 공유합니다(이는 SPoF가 될 수 있습니다).
(원문에는 워커 노드에 애플리케이션과 DB가 함께 있는 ‘공유 워크로드/공유 스토리지’ 다이어그램 이미지가 포함되어 있습니다.)
이 솔루션은 성능 예측 가능성, 특히 비즈니스 연속성(RTO/RPO)과 초당 트랜잭션 수(TPS)에 대한 예측 가능성을 기대하지 않는다면 잘 작동합니다.
다음 단계는 affinity/anti-affinity, node selector, taint 같은 Kubernetes 네이티브 스케줄링 기능을 이용해 PostgreSQL 워크로드를 다른 워크로드와 분리된 워커 노드에 배치하는 것입니다. 스토리지는 여전히 공유하지만, CPU/메모리 사용의 예측 가능성은 높아집니다.
(원문에는 애플리케이션 워커 노드와 DB 워커 노드를 분리하지만 스토리지는 공유하는 다이어그램 이미지가 포함되어 있습니다.)
조직 내에서 Postgres 사용이 늘어나면, 다음 다이어그램처럼 데이터베이스 워크로드를 위한 네트워크 스토리지를 전용으로 두는 것도 고려할 수 있습니다. 분리는 주로 논리적이지만, 핵심은 RTO/RPO/TPS에 대한 명확한 기대치와 전체 비용을 기준으로 얼마나 유연하게 구성할 수 있는지를 보여주는 것입니다.
(원문에는 애플리케이션용 공유 스토리지와 Postgres용 공유 스토리지를 논리적으로 분리한 다이어그램 이미지가 포함되어 있습니다.)
하지만 수년간의 Postgres 경험에 비추어 볼 때, 프로덕션에서는 위의 “모든 것 공유” 솔루션을 가능한 한 피하는 것을 권합니다.
로컬 스토리지를 고려하기 시작하면 DB 관점에서 훨씬 흥미로워집니다. 이는 퍼블릭 클라우드부터 전용 하드웨어(예: NVMe)가 있는 베어메탈 노드까지 모든 환경에 적용됩니다.
아래 예시는 Postgres 워크로드와 비-Postgres 워크로드를 명확히 분리하고, Postgres 전용 워커 노드에 마운트된 로컬 퍼시스턴트 볼륨을 사용합니다. 이렇게 하면 비-Postgres 워크로드(무상태/상태 저장 모두)에는 공유 스토리지를, PostgreSQL에는 로컬 스토리지를 사용해 차별화할 수 있습니다. PostgreSQL은 스토리지 레벨 복제가 필요하지 않으며(그리고 하지 말아야 합니다!).
예를 들어 프라이머리 1개와 레플리카 2개(최소 1개는 동기 복제, RPO=0)로 구성된 Postgres 클러스터를 생각해 보세요. 각 인스턴스는 로컬 스토리지가 있는 서로 다른 워커 노드에 위치합니다. Postgres 복제는 클러스터 전체 상태가 최소 다른 노드 하나 이상에 즉시 존재하도록 보장해, 데이터 손실 위험을 줄입니다. 이때 단일 장애 지점은 곧 데이터센터가 되며, 워커 노드가 저지연 네트워크로 연결된 서로 다른 가용 영역에 분산되어 있다면, 단일 장애 지점은 리전이 될 수도 있습니다. 특별히 무언가를 “구현”할 필요 없이, 설정만으로 가능한 이야기입니다.
스토리지 레벨 복제를 추가해도 비즈니스 연속성은 전혀 개선되지 않으며, 오히려 쓰기 증폭(write amplification)을 유발해 성능을 저하시킬 수 있습니다. 관심이 있다면, 제가 Ondat(현재 Akamai)의 Chris Milsted와 함께 KubeCon NA 2022 디트로이트에서 발표한 “Data On Kubernetes, Deploying And Running PostgreSQL And Patterns For Databases In a Kubernetes Cluster”를 보세요. Kubernetes에서 동기 복제 Postgres 클러스터로 18k 이상의 OLTP 유사 TPS를 달성했고, 프라이머리의 급작스러운 장애 후에도 데이터 손실이 없었으며, 스탠바이의 자동 승격이 거의 즉시 일어났다는 근거를 제시합니다.
백업/복구 관점에서는, 오브젝트 스토어로의 Postgres 네이티브 연속 백업(PITR의 경우 일반적으로 RPO=0, 리전 재해의 경우 최대 5분) 또는 Velero, Kasten 같은 Kubernetes 네이티브 백업 솔루션을 동시에 활용할 수 있습니다.
이 시나리오는 taint/toleration으로 쉽게 구현할 수 있으며, 가상/물리 노드 모두에서 특정 전용 노드에 Postgres 워크로드를 명확히 제한할 수 있습니다. 예를 들어 Kubernetes 클러스터 아키텍처가 이미 설계된 상태라면, 각 가용 영역에 최소 1개의 전용 노드를 두고(최소 3노드) 시작하는 것은 좋은 절충안입니다.
(원문에는 애플리케이션은 공유 스토리지, DB는 노드별 로컬 스토리지를 사용하는 다이어그램 이미지가 포함되어 있습니다.)
매우 크고 중요한 데이터베이스가 있어 특별히 신경 쓰고 싶다면, 아래 다이어그램처럼 해당 DB에 워커 노드 하나를 전용으로 할당할 수 있습니다.
(원문에는 특정 Postgres 인스턴스에 워커 노드가 전용으로 배정된 다이어그램 이미지가 포함되어 있습니다.)
Postgres 마니아로서, 이것이 단연 제가 가장 좋아하는 시나리오입니다. 이 글의 시작에서 언급했듯, 우리가 초기 파일럿 프로젝트에서 검증하고자 했던 정확한 사용 사례이기도 합니다. 데이터베이스가 요구하는 ‘완전한 제어’와 Kubernetes가 요구하는 ‘완전한 자동화’를 결합한 완벽한 예입니다. 분산 DBMS에서는 이 아키텍처를 ‘공유 없음(shared nothing)’ 아키텍처라고 부르기도 합니다.
단일 Kubernetes 클러스터 안에서 3개 가용 영역에 걸쳐, 각 Postgres 인스턴스가 전용 워커 노드와 함께 배치되고 최소 1개의 동기 레플리카를 갖는 구조(아래 다이어그램)는, 제 15년 이상의 커리어에서 0일차부터 2일차 운영까지 포함해 제가 경험한 최고의 Postgres 운영 경험이었습니다.
(원문에는 AZ #1에서 #3까지 분산된 Postgres 구성 다이어그램 이미지가 포함되어 있습니다.)
단일 Kubernetes 클러스터에서 채택한 동일한 아키텍처를, 하나 이상의 리전에 복제할 수 있습니다. 아래 다이어그램은 왼쪽에 프라이머리 1개와 스탠바이 2개(그중 1개는 동기)를 가진 PostgreSQL 클러스터를 보여줍니다. 연속 백업이 구성되어 있으며, 프라이머리는 최소 5분마다 같은 리전의 오브젝트 스토어에 WAL 파일을 아카이빙하고, 물리 베이스 백업도 주기적으로(필요에 따라 하루 1회 또는 주 1회 등) 저장합니다. 오브젝트 스토어는 퍼블릭 클라우드일 수도 있고 클러스터 내부일 수도 있으며, 선택한 오브젝트 스토어 기능을 활용해 장기 보관을 위해 퍼블릭 서비스나 원격지로 릴레이할 수도 있습니다.
오른쪽의 Postgres 클러스터는 CloudNativePG 용어로 ‘레플리카 클러스터’입니다. 보시다시피 대칭 구조이며, 로컬 레플리카들은 네이티브 스트리밍 복제를 통해 지정된 프라이머리(여기서는 ‘지정된 프라이머리’가 실제로는 스탠바이이며, 원 리전의 프라이머리에 장애가 발생하면 프라이머리가 될 준비가 되어 있음)와 동기화됩니다. 또한 리전별 오브젝트 스토어가 연속 백업 데이터(베이스 백업과 WAL 파일)를 받도록 구성되어 있습니다.
(원문에는 양쪽 리전 간 레플리카 클러스터 구성을 보여주는 다이어그램 이미지가 포함되어 있습니다.)
Postgres 복제에만 의존하더라도, 두 리전에 백업 오브젝트가 존재하게 됩니다.
더 나아가, 레플리카 클러스터는 원본의 오브젝트 스토어(왼쪽)의 WAL 파일만 가져오는 방식으로도 동기화를 유지할 수 있습니다(오른쪽 클러스터에 읽기 권한이 있어야 함). 이는 2006년, warm standby를 포함한 PostgreSQL 8.2가 릴리스될 때부터 제공되어 온 기능입니다. CloudNativePG에서는 기본 설정만으로도 교차 리전 DR에서 대략 최대 5분의 RPO를 제공합니다.
네트워크와 데이터베이스 워크로드에 따라, 프라이머리와 레플리카 클러스터 사이에 스트리밍 복제를 활성화하고, mTLS 및 양 엔드포인트 간 보안 채널을 사용하면, 리전 간 RPO를 거의 0에 가깝게 줄일 수도 있습니다.
필요하다면 캐스케이딩 복제로 레플리카 클러스터를 더 추가할 수 있습니다. 다음 스케치는 3개 리전(예: 아메리카, 유럽, 아시아 태평양)으로 복제되는 Postgres 클러스터 예시를 보여줍니다.
(원문에는 리전 1에서 리전 3으로 이어지는 복제 흐름 다이어그램 이미지가 포함되어 있습니다.)
앞서 언급했듯, 레플리카 클러스터는 단일 가용 영역 Kubernetes 클러스터에서 데이터센터 장애를 낮은 RTO로 견뎌낼 수 있는 유일한 옵션입니다.
이 글에서 강조한 몇 가지 시나리오는 가능한 아키텍처의 완전한 목록이 아닙니다. 제 조언은 ‘모든 것을 공유’에서 ‘공유 없음’까지 두 극단을 고려하고, 목표와 예산에 따라 선택하라는 것입니다.
이 글에서는 스토리지에 대해 간단히만 언급했습니다. 스토리지는 별도의 논의가 필요합니다. 핵심 요점은 Postgres의 경우, Kubernetes처럼 분산된 시스템에서 단일 클러스터 내부 및 그 너머까지 상태를 동기화하기 위해 데이터베이스 복제 시스템을 사용해야 한다는 점입니다.
CloudNativePG는 앞으로 Postgres 테이블스페이스에 대한 선언적 지원과, Kubernetes VolumeSnapshot API 지원을 추가해 초대형 데이터베이스(VLDB)에서 증분/차등 백업을 도입하려고 하고 있어, 저도 이 주제에 대해 별도의 글을 쓰려 합니다. 또한 2023년 11월 7일 시카고에서 열리는 KubeCon NA 2023에서 Google 및 Kubernetes 스토리지 전문가인 Michelle Au와 함께 “Disaster Recovery with Very Large Postgres Databases”에 대해 발표할 예정입니다.
0일차부터 Kubernetes에서의 Postgres 경험을 제대로 계획하면, 애플리케이션 개발자와 최종 사용자 사이에 자동화된 지속적 전달/배포 파이프라인(마이크로서비스 데이터베이스를 포함하는 GitOps)을 통해 전례 없는 ‘빠른 흐름’의 고속도로를 만들 기회를 얻게 됩니다.
Kelsey의 발언으로 돌아가 보겠습니다. 저는 “VM에서 데이터베이스를 실행하는 것과 근본적으로 동일하기 때문에” Kubernetes에서 데이터베이스를 실행할 수 있다고 생각할 뿐만 아니라, CloudNativePG 오퍼레이터를 통해 VM에서보다 더 나은 방식으로 Postgres 데이터베이스를 운영할 수 있다고 믿습니다. PostgreSQL과 Kubernetes 같은 견고한 오픈 소스 기술에 기반하고, 매우 강력하지만 종종 잊히는 표준 SQL 언어를 활용함으로써, Postgres는 모든 산업 분야의 클라우드 네이티브 애플리케이션을 위한 기반 솔루션이 될 수 있습니다.
CloudNativePG는 EDB가 처음 만든 프로젝트로, 2022년 5월 오픈 소스로 공개되었으며 현재는 벤더 중립 커뮤니티가 공개적으로 거버넌스합니다. Kubernetes에서의 Postgres 경험을 개선하는 데 관심이 있다면 cloudnative-pg.io 또는 GitHub에서 커뮤니티에 참여해 주세요.
Gabriele Bartolini는 EDB(PostgreSQL 오픈 소스 프로젝트의 가장 큰 기여자 중 하나)의 VP이며, 오랜 Postgres 팬이고, CloudNativePG의 메인테이너 중 한 명입니다. LinkedIn 또는 X(Twitter)에서 그를 팔로우할 수 있습니다.
