INTRO
PostgreSQL Blue/Green 배포란?
PostgreSQL(오픈소스 객체 관계형 데이터베이스 관리 시스템) 서버를 운영할 때, 버전 업그레이드나 파라미터 수정 등으로 인해 재시작이 필요한 상황이 발생합니다. 이때, PostgreSQL의 Blue/Green 배포란 운영 중인 Production Cluster(Blue)와 전환을 위한 Staging Cluster(Green)를 준비한 뒤, Switchover(시스템에서 다른 시스템으로 자원에 대한 액세스를 수동 교환하는 경우 발생하는 것) 명령으로 Blue와 Green을 전환하는 과정을 말합니다. 이 방법을 통해 운영 환경의 변경 작업을 더욱 원활하게 진행할 수 있습니다.
AWS는 Green Cluster의 구성부터 Blue/Green Deployment 사전 검사, Switchover에 이르는 모든 과정을 완전 관리형으로 제공합니다. 이 기능을 사용하면 Production PostgreSQL 서버의 서비스 중단 시간을 최소화하고 Green Cluster로 쉽게 전환할 수 있습니다. 즉, 운영 효율성을 크게 개선하는 중요한 기능인 것입니다.
PostgreSQL Blue/Green 서비스는 2023년 10월에 정식 출시된 후 Amazon Aurora와 RDS(Amazon Relational Database Service, 클라우드에서 간편하게 데이터베이스를 설치, 운영 및 조정할 수 있는 관리형 서비스 모음)에서 지원되는 PostgreSQL에서 사용할 수 있습니다. 이를 통해 다양한 운영 환경에서 안정적이고 효율적인 데이터베이스 관리가 가능해졌습니다.
PostgreSQL Blue/Green 복제 방식
RDS PostgreSQL에서는 Blue/Green Deployment 데이터 복제를 위해 Logical Replication을 사용합니다. 이는 WAL(Write-Ahead Log, 로그 선행 기입, 데이터베이스 시스템에서 ACID 특성 가운데 원자성과 내구성을 제공하는 기술의 한 계열)에 기반해 작동하고, WAL은 데이터베이스 변경사항을 Log Record로 기록한 후 디스크에 적용합니다. 이때, 생성된 Log Record를 대상 서버로 전송하고 Replay를 수행하며 같은 변경사항을 적용할 수 있습니다.
Logical Replication에 의한 WAL 전송은 파일이 아닌 WAL Record 단위로 이뤄지며, Logical Decoding을 통해 읽을 수 있는 형식으로 변환한 후에 전송됩니다.
WAL Record의 전송은 Publish & Subscribe 패턴을 따르고 Blue Cluster에서 발생한 변경 사항들은 WAL 파일에 기록됩니다. 변경 사항들은 WAL Record로 분류돼 저장되고 WAL Record가 생성되면, Logical Decoder를 거쳐 Subscriber인 Green Cluster로 전달됩니다.
Logical Replication은 Replication ID(주로 Primary Key)를 기반으로 데이터 객체와 변경 사항을 기록하며 복제합니다. 이 때문에 Source DB의 모든 테이블에는 Primary Key(기본 키, SQL 데이터베이스에서 특정 레코드를 유일하게 식별하기 위해 사용되는 필드 또는 필드의 집합)가 필요합니다. Logical Replication은 스키마(Schema, 데이터베이스를 구성하는 개체, 속성, 관계, 데이터 조작 시 데이터 값의 제약 조건을 전반적으로 정의한 것)와 DDL(Data Definition Language, 데이터 정의어, 데이터베이스의 테이블을 생성하고, 수정, 삭제하는 언어)을 복제하지 않기 때문에 Blue Cluster에서 새로운 테이블이 생성되거나 변경이 발생하면 Green Cluster에서도 같은 작업을 수행해야 합니다. 만약 Blue/Green 배포를 계획 중이라면, DDL 변경은 배포가 완료된 후에 진행하는 것이 바람직합니다.
PostgreSQL Blue/Green Deployment 작업 순서
PostgreSQL Blue/Green Deployment의 작업 순서는 아래와 같습니다.
1. 작업 대상 및 일정 수립
2. RDS PostgreSQL의 Blue/Green 배포 주의사항 확인 및 조치
3. Green Cluster 생성
4. switchover 실행
5. Blue Cluster 데이터 확인 및 애플리케이션 상태 확인
6. Green Cluster 제거
• 지원되는 PostgreSQL 버전 확인
이 여섯 가지 단계를 거치기 위한 준비 작업으로 지원되는 PostgreSQL 버전을 확인해야 합니다. 또한, 현재 사용중인 Aurora(완전 관리형 관계형 데이터베이스 엔진) 또는 RDS PostgreSQL의 버전이 Blue/Green Deployment를 지원하는지 확인해야 합니다. 버전이 낮을 경우 in-place version 업그레이드를 수행해야 합니다.
• 16.1 and higher
• 15.4 and higher
• 14.9 and higher
• 13.12 and higher
• 12.16 and higher12.16 and higher12.16 and higher
• 11.21 and higher
• 파라미터(Parameter) 조정
Logical Replication을 활성화하기 위해선 파라미터를 변경하고, 복제 성능을 개선하기 위한 설정을 환경에 맞게 조정해야 합니다. 파라미터를 변경한 후에는 데이터베이스를 재시작해야 합니다.
• rds.logical_replication
• max_replication_slots
• max_wal_sender
• max_logical_replication_worker
• max_worker_processes
• Green Cluster 생성
RDS 콘솔 화면에서 Blue Cluster를 선택한 다음 ‘Action > Create Blue/Green Deployment’를 클릭해 Green Cluster를 생성합니다. 이 과정에서 엔진 버전, DB 클러스터 파라미터 그룹, DB 파라미터 그룹을 변경할 수 있습니다. 또한 AWS RDS CLI(Command Line Interface, 명령줄 인터페이스, 키보드를 이용해 운영 체제와 상호 작용하는 소프트웨어 메커니즘) 명령어를 사용해 생성 작업을 수행할 수도 있습니다.
• Switchover 실행
Switchover는 Blue/Green Cluster를 전환하는 과정으로, ‘Actions > Choose Switch over’ 메뉴를 통해 진행할 수 있습니다. Switchover 프로세스가 시작되면, 사전 검사 단계와 전환 단계가 실행됩니다. 이때, 지원되지 않는 PostgreSQL 변경사항이 감지되면 복제가 중단되고, 사용자에게 알림이 전송됩니다.
Switchover 단계에서는 제한 시간(Timeout)을 설정할 수 있습니다. 기본 제한 시간은 300초(5분)로 설정돼 있으며, 이 시간은 30초에서 3,600초(1시간) 사이로 지정할 수 있습니다. 설정된 시간을 초과할 경우, 모든 변경사항은 롤백돼 양쪽 환경에 아무런 변화를 끼치지 않습니다. 게다가 Blue/Green 배포 전환 이후에도 클러스터 엔드포인트(컴퓨터 네트워크에 연결되는 모든 장치)가 변경되지 않으므로 별도의 애플리케이션 변경없이 사용할 수 있습니다.
Switchover 사전 검사 실행 단계는 아래와 같습니다.
1. 사전 검사 실행
1) Green Cluster 확인 단계
● Replication health : 인스턴스 상태 확인
● Replication lag : Blue Cluster와 Green Cluster 간에 복제가 동기화되었는지 확인
● Active writes : green cluster에서 write 진행 중인 것이 있는지 확인
2) Blue Cluster 확인 단계
● External replication : DB 인스턴스가 외부 binlog(바이너리로그, DML(데이터 조작어) 실행 시 시간과 함께 기록되는 로그) replica가 있는지 확인
● Long-running active writes & DDL statements : 장기 실행중인 쓰기 또는 장기 실행 중인 DDL이 있는지 확인
● Unsupported PostgreSQL changes : DDL 변경이나 Large Object의 추가 또는 수정이 있는지 확인
2. 전환
1) Blue 및 Green Cluster에 대한 쓰기를 중지한 뒤, 두 Cluster의 연결을 모두 끊고 Blue Cluster에서 Green Cluster가 완전히 동기화 되도록 합니다.
2) Blue Cluster의 Sequence 값과 일치하도록 Green Cluster의 Sequence 값을 증가시킵니다. Green Cluster가 새 기본 Cluster로 승격됩니다.
3) Blue Cluster 이름의 suffix에 -old{n}를 붙이고, Green Cluster의 이름은 기존 Blue Cluster의 이름으로 변경합니다.
다양한 제한사항
PostgreSQL Extension 제한 사항
아래의 PostgreSQL Extension(PostgreSQL의 기능을 확장해 주는 역할을 수행)들은 Blue/Green Deployment 수행 시 복제를 중단하는 작업이 발생할 수 있어 비활성화 해야 합니다.
• pg_partman
• pg_cron
• apg_plan_mgmt
• apg_plan_mgmt.capture_plan_baselines
• apg_plan_mgmt.capture_plan_baselines
• pglogical
• pg_active
Logical Replication 제한 사항
• DDL 복제 불가
• Sequence Nextval(시퀀스의 다음 값을 리턴하는 함수) 작업에 대한 동기화 불가 : Switchover시 green 환경의 sequence 값을 증가시켜 동기화 하며, Sequence 대상이 많아질 경우 전환 시간이 길어집니다.
• pg_largeobject 복제 불가
• primary key 없는 테이블의 업데이트와 삭제 불가
PostgreSQL Blue/Green Deployment Testing
PostgreSQL Blue/Green 배포 테스트
PostgreSQL Blue/Green 배포를 테스트를 진행하며 애플리케이션이 어떻게 동작하는지 확인했습니다. 또한 Blue/Green 테스트가 가능한 환경을 마련하고, 지속적인 부하를 발생시키는 스크립트를 작성 및 실행했습니다. 이때 Application은 Spring Boot를 기반으로 hikaricp를 사용했고 DB connection pool을 관리하도록 구성했습니다. Switchover 제한시간(Timeout)은 60초로 설정해 테스트를 진행했습니다. 테스트 결과, PostgreSQL Blue/Green 배포 후 약 60초간 에러가 반복 발생한 것을 확인할 수 있었습니다.
PostgreSQL Blue/Green Deployment 배포 테스트 에러 유형
PostgreSQL Blue/Green 배포 과정에서 발생한 주요 에러 유형을 분석해보겠습니다. 먼저, 가장 흔하게 발생한 문제는 ‘Connection is not available’ 오류였습니다. 이는 데이터베이스가 10초간 응답하지 않아 오류 응답이 반환되는 문제입니다. 하지만 Green Cluster 전환 작업이 성공적으로 완료된 이후에는 지연 상태의 요청들이 정상적으로 처리돼 성공적인 응답을 받았습니다.
• Connection is not available, request times out after 10000ms
• cannot execute INSERT in a read-only transaction
• cannot execute UPDATE in a read-only transaction
• terminating connection due to administrator command
• Application exception overridden by rollback exception
DB Connections
RDS database_connections 지표는 Blue/Green 배포가 진행될 때, DB Connection 횟수가 일시적으로 감소한 후 다시 정상으로 돌아오는 현상을 보였습니다. 이는 1분 단위로 측정되는 평균값이기 때문에 일정한 오차 범위가 존재할 수 있습니다.
JAVA Thread
Request 처리량이 많지 않은 시스템이었기 때문에 초기 Thread Count는 낮게 유지되고 있었습니다. 하지만 Blue/Green 배포가 되는 순간 DB Connection이 되지 않아 Request에 대한 Response를 줄 수 없는 상태가 되고, 이 상태로 10초 동안 기다렸다가 connection Timeout 에러 Response를 보내게 됩니다. 이후 Request가 누적되면서 Thread Count는 증가하는 모습을 보였습니다. Request 양이 많아진다면 Thread Count는 더욱 많이 증가해 max thread count까지 증가할 수 있습니다.
하지만 Thread의 수가 증가하면서 Thread가 사용하는 메모리의 양이 애플리케이션에 문제를 일으킬 수 있습니다. 예를 들어, 대량의 엑셀 파일을 업로드하고 파싱하는 상황이라고 가정했을 때, 파싱한 데이터는 객체에 저장한 후 DB에 insert를 시도하게 됩니다. DB Connection이 되지 않은 상황에서는 객체에 담긴 많은 양의 데이터가 메모리를 점유하면서 Timeout이 될 때까지 메모리를 해제하지 않게 됩니다. 이와 같은 요청이 누락되면 결국 OOM(Out Of Memory, 시스템이 더 이상 메모리를 할당할 수 없을 때 발생하는 오류나 상태) 오류가 발생할 위험이 있습니다.
Outro
1. RDS PostgreSQL의 Blue/Green 배포를 적용하려면 파라미터 변경이 필수적이며, 이과정에서 데이터베이스의 재시작이 요구됩니다.
2. RDS PostgreSQL Blue/Green 배포는 일반적으로 다운타임(시스템을 이용할 수 없는 시간)이 짧지만, 다운타임이 완전히 없을 수는 없습니다. 이때, 다운타임시 DB Connection Timeout 에러가 지속적으로 발생하지 않도록 잠재적인 문제를 미리 파악하고 대응하는 것이 필요합니다.
3. 다운타임 중에는 애플리케이션의 Thread가 급증하기 때문에, 애플리케이션의 CPU와 메모리 사용량을 모니터링하는 것은 필수입니다. 이는 부하를 효과적으로 관리하고, 예기치 않은 성능 저하나 애플리케이션 종료를 예방하는 데 도움이 됩니다.
