Aurora PostgreSQL Blue/Green 전환이 실패하는 원인: DDL·Replication Slot·장기 트랜잭션 점검

2026년 8월 24일 읽는 시간 약 14분

aurora postgresql blue green switchover 1787466573

Aurora PostgreSQL Blue/Green Deployment는 운영 중인 Blue 환경을 복제해 Green 환경을 만들고, 엔진 업그레이드나 파라미터 변경을 검증한 뒤 짧은 중단 시간으로 전환하는 기능이다. 그러나 콘솔에서 Green 클러스터가 정상으로 표시된다고 해서 반드시 전환까지 성공하는 것은 아니다.

Aurora PostgreSQL의 Blue/Green 복제는 논리적 복제 방식을 사용하기 때문에 DDL 변경, Replication Slot 지연, 장기 트랜잭션 같은 요소에 민감하다. 특히 배포 생성 후 운영 DB에서 스키마를 변경했거나 대량 트랜잭션이 끝나지 않은 상태라면 복제 지연 또는 Replication degraded 상태가 발생할 수 있다.

실제 운영 환경에서 전환 실패를 점검할 때는 단순히 재시도하기보다 DDL 실행 이력, Replication Slot의 LSN 차이, 장기 실행 세션을 순서대로 확인하는 것이 효과적이다.

Aurora PostgreSQL Blue/Green 전환 과정 이해하기

Blue 환경은 현재 애플리케이션이 사용하는 운영 클러스터이며 Green 환경은 변경 사항을 검증할 대상 클러스터다. 전환을 시작하면 AWS는 두 환경의 상태와 복제 지연을 검사하고, 신규 쓰기를 차단한 다음 기존 연결을 종료한다. 이후 Green 환경이 Blue 환경의 마지막 변경 사항까지 반영하면 엔드포인트와 리소스 이름을 전환한다.

이 과정에서는 다음과 같은 사전 점검이 수행된다.

Green 환경의 복제 지연이 허용 범위 안에 있는지 확인
Green 클러스터에 예상하지 않은 쓰기가 발생했는지 확인
Blue 클러스터에 장기 실행 쓰기와 DDL이 있는지 확인
지원하지 않는 DDL 또는 Large Object 변경이 발생했는지 확인
Blue 클러스터가 외부 논리 복제의 Publisher 또는 Subscriber인지 확인

AWS는 전환 중 두 환경의 신규 쓰기를 중지하고 연결을 끊은 후 Green 환경이 따라잡을 때까지 기다린다. 따라서 평소에는 몇 초 수준이던 Replication Slot 지연도 쓰기량이 많은 시간에는 전환 제한 시간을 초과할 수 있다. 기본 전환 제한 시간은 300초이며 늘릴 수 있지만, 원인을 제거하지 않고 제한 시간만 늘리는 방식은 근본적인 해결책이 아니다. AWS Blue/Green 전환 안내

DDL 변경이 전환 실패로 이어지는 이유

Aurora PostgreSQL Blue/Green 환경을 생성한 이후에는 Blue 환경에서 실행하는 DDL에 특히 주의해야 한다. 논리적 복제는 테이블의 데이터 변경을 전달하지만 CREATE TABLE, ALTER TABLE, CREATE SCHEMA와 같은 DDL을 Green 환경으로 자동 복제하지 않는다.

예를 들어 Blue 환경에 신규 테이블을 만든 뒤 해당 테이블에 데이터가 입력되면 Green 환경에는 대상 테이블이 없기 때문에 변경 사항을 정상적으로 적용할 수 없다. 운영자가 Blue와 Green 양쪽에 동일한 DDL을 수동 실행하는 방법도 일반적인 해결 절차로 권장하기 어렵다. Blue/Green 서비스가 DDL 변경을 감지하면 Green 데이터베이스를 Replication degraded 상태로 변경하고 전환을 차단할 수 있기 때문이다.

신규 파티션 생성도 같은 문제를 일으킨다. 일 단위 파티션을 자동 생성하는 환경이라면 Blue/Green 배포 기간에 pg_partman이나 배치 작업이 CREATE TABLE을 실행하지 않는지 확인해야 한다. REFRESH MATERIALIZED VIEW와 Large Object 생성·변경 역시 복제를 중단시키는 원인이 될 수 있다.

배포 생성 이후 지원되지 않는 DDL이나 Large Object 변경으로 Replication degraded 상태가 되었다면, 단순 재시도로 정상화하기 어렵다. AWS에서 안내하는 일반적인 복구 방법은 기존 Blue/Green 배포와 Green 데이터베이스를 삭제한 뒤 다시 생성하는 것이다. Aurora PostgreSQL Blue/Green 제한 사항

DDL 실행 여부를 점검할 때는 현재 실행 중인 쿼리부터 확인한다.

SELECT pid,
       usename,
       datname,
       state,
       now() - query_start AS query_duration,
       wait_event_type,
       wait_event,
       query
FROM pg_stat_activity
WHERE query ~* 'create|alter|drop|truncate|grant|revoke|refresh'
  AND pid <> pg_backend_pid()
ORDER BY query_start;

하지만 pg_stat_activity는 현재 세션만 보여주므로 이미 완료된 DDL까지 확인할 수는 없다. 운영 환경에서는 PostgreSQL 로그, pgaudit, 애플리케이션 배포 기록, Flyway 또는 Liquibase 이력도 함께 확인해야 한다. 개인적으로는 Blue/Green 생성 시점부터 전환 완료 시점까지 DDL 변경을 금지하는 운영 절차를 두는 것이 가장 안전했다. 긴 점검 기간을 잡는 것보다 DDL 동결 시간을 짧고 명확하게 관리하는 편이 장애 가능성을 줄이는 데 효과적이었다.

Replication Slot과 복제 지연 점검하기

Aurora PostgreSQL Blue/Green Deployment는 데이터베이스별로 논리 Replication Slot을 사용한다. 클러스터 안에 데이터베이스가 많으면 Slot 수도 증가하며, 각 Slot은 WAL을 소비하고 Green 환경에 변경 사항을 전달해야 한다.

Replication Slot의 진행 상태는 Blue 환경에서 다음 쿼리로 확인할 수 있다.

SELECT slot_name,
       database,
       active,
       restart_lsn,
       confirmed_flush_lsn,
       pg_current_wal_lsn() AS current_lsn,
       pg_size_pretty(
         pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)
       ) AS replication_lag
FROM pg_replication_slots
WHERE slot_type = 'logical'
ORDER BY pg_wal_lsn_diff(
           pg_current_wal_lsn(),
           confirmed_flush_lsn
         ) DESC NULLS LAST;

confirmed_flush_lsn은 소비자가 반영했다고 확인한 위치이며 pg_current_wal_lsn()은 현재 WAL 위치다. 두 값의 차이가 계속 증가한다면 Green 환경이 Blue 환경의 쓰기 속도를 따라가지 못하고 있다는 뜻이다.

CloudWatch에서는 Blue 환경의 OldestReplicationSlotLag를 우선 확인하는 것이 좋다. ReplicationSlotDiskUsage, FreeableMemory, DBLoad, DatabaseConnections도 함께 보면 지연 원인을 구분하는 데 도움이 된다. 장기 트랜잭션이 메모리 범위를 초과해 디스크에 기록되는 상황에서는 ReplicationSlotDiskUsage가 증가할 수 있다.

Aurora PostgreSQL의 Green 환경에서 논리 복제를 적용하는 프로세스는 단일 스레드로 동작한다. 따라서 Blue 환경에서 지속적으로 높은 쓰기 부하가 발생하면 Green 환경이 따라잡지 못할 수 있다. 이때는 전환 직전 대량 배치와 데이터 적재를 중단하고 쓰기량이 적은 시간대를 선택해야 한다. 데이터베이스 수가 많거나 인스턴스 용량이 작은 환경이라면 Green 또는 관련 인스턴스 용량을 임시로 상향하는 방안도 검토할 수 있다.

사용자가 직접 만든 외부 논리 Replication Slot이나 Subscription이 존재하는지도 확인해야 한다. Blue 환경이 별도의 Publisher 또는 Subscriber로 사용되고 있으면 전환 가드레일에 걸릴 수 있다. AWS는 필요한 경우 모든 데이터베이스에서 자체 관리 Slot과 Subscription을 제거한 뒤 전환하고, 완료 후 다시 구성하도록 안내한다. 다만 업무상 사용하는 Slot을 확인 없이 삭제하면 외부 복제가 중단되므로 반드시 용도와 소비자를 파악한 뒤 작업해야 한다.

장기 트랜잭션과 전환 제한 시간 점검하기

장기 트랜잭션은 Blue/Green 전환 실패에서 자주 놓치는 원인이다. 쿼리가 실행 중인 세션뿐 아니라 idle in transaction 상태로 연결만 유지하는 세션도 확인해야 한다. 애플리케이션이 트랜잭션을 시작한 뒤 Commit이나 Rollback을 수행하지 않으면 해당 트랜잭션이 오랫동안 유지될 수 있다.

SELECT pid,
       usename,
       application_name,
       client_addr,
       state,
       xact_start,
       now() - xact_start AS transaction_duration,
       wait_event_type,
       wait_event,
       query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
  AND pid <> pg_backend_pid()
ORDER BY xact_start;

10분 또는 30분 이상 실행된 세션만 확인하려면 조건을 추가할 수 있다.

SELECT pid,
       usename,
       application_name,
       state,
       now() - xact_start AS transaction_duration,
       query
FROM pg_stat_activity
WHERE xact_start < now() - interval '10 minutes'
  AND pid <> pg_backend_pid()
ORDER BY xact_start;

장기 트랜잭션이 발견됐다고 해서 즉시 pg_terminate_backend()를 실행하는 것은 위험하다. 정상적인 배치나 정산 작업일 수 있으며 세션 종료 시 전체 트랜잭션이 롤백되어 추가 부하가 발생할 수 있다. 먼저 애플리케이션 담당자에게 업무 영향과 재처리 가능 여부를 확인하고, 신규 유입을 차단한 다음 안전하게 Commit 또는 Rollback하도록 유도하는 것이 좋다.

Blue/Green 전환 직전에는 배치 작업, 대량 INSERT·UPDATE, 파티션 생성, 스키마 배포를 중단하고 커넥션 풀의 연결 수도 줄이는 것이 유리하다. 또한 애플리케이션과 JVM의 DNS 캐시 TTL이 지나치게 길면 전환 후에도 이전 Blue 엔드포인트로 연결을 시도할 수 있으므로 DNS 캐시 설정도 함께 확인해야 한다.

실제 트러블슈팅에서는 전환 버튼을 반복해서 누르기보다 다음 순서가 효과적이었다.

Blue/Green 상태와 RDS 이벤트에서 Replication degraded 여부 확인
배포 생성 이후 DDL·DCL·Large Object 변경 이력 확인
OldestReplicationSlotLag와 Slot별 LSN 차이 확인
장기 트랜잭션과 idle in transaction 세션 확인
배치 및 대량 쓰기를 중단하고 복제 지연이 감소하는지 관찰
Green 환경에서 통계 수집과 애플리케이션 연결 테스트 수행
부하가 낮은 시간에 최종 전환 진행

전환 전에 Green 환경의 각 데이터베이스에서 ANALYZE를 실행해 옵티마이저 통계를 갱신하는 것도 중요하다. 특히 메이저 버전 업그레이드에서는 통계가 그대로 이전되지 않을 수 있어, 전환에는 성공했지만 직후 실행 계획이 바뀌면서 성능이 저하되는 문제가 발생할 수 있다. Aurora PostgreSQL Blue/Green 모범 사례

마치며

Aurora PostgreSQL Blue/Green 전환 실패는 대부분 전환 버튼을 누른 순간 갑자기 발생한 문제가 아니다. 배포 생성 이후 실행된 DDL, 누적된 Replication Slot 지연, 종료되지 않은 장기 트랜잭션이 전환 시점의 가드레일 검사에서 드러나는 경우가 많다.

가장 중요한 운영 원칙은 Blue/Green 배포 기간에 스키마 변경을 통제하고, Replication Slot의 LSN 차이와 장기 트랜잭션을 지속적으로 관찰하는 것이다. Replication degraded 상태가 DDL이나 Large Object 변경 때문에 발생했다면 무리하게 복구를 시도하기보다 Green 환경을 재생성하는 편이 안전하다.

전환 당일에만 상태를 확인하는 방식보다는 배포 생성 직후부터 DDL 동결, 복제 지연 알림, 장기 트랜잭션 점검, 배치 중단 계획을 체크리스트로 관리하는 것이 좋다. 이 절차를 갖추면 전환 실패 가능성을 낮출 수 있을 뿐 아니라 실제 서비스 중단 시간도 예측 가능한 범위로 관리할 수 있다.