PostgreSQL 복제 지연 원인과 실무 해결 방법

개요

데이터베이스 복제는 고가용성·읽기 확장을 위해 널리 사용된다. 그러나 복제 지연(replication lag)은 읽기 일관성 문제와 장애 복구 지연을 초래한다. 이 글은 replication lag postgres 원인 파악부터 실제 postgres 복제 지연 해결까지 단계별로 설명한다. 처음 접하는 운영자도 이해할 수 있도록 진단 쿼리와 설정 예시를 함께 제시한다.

복제 지연의 개념 이해

복제 지연은 primary 노드에서 발생한 변경이 standby 노드에 반영되는 시간 또는 바이트 차이를 의미한다. streaming replication lag postgres 상황에서는 WAL 기록이 전송(sending), 수신(receiving), 재생(replay) 단계 중 어디에서 지연되는지 구분하는 것이 중요하다.

주요 원인

1. WAL 생성 속도 초과

트랜잭션이 많아 WAL 생성량이 급증하면 전송 혹은 재생이 따라가지 못한다. 특히 대량 배치 작업이나 대규모 복구 시 WAL 생성이 지연의 출발점이 된다.

2. 네트워크 대역폭 및 지연

네트워크가 좁거나 지연(latency)이 높으면 WAL 전송 단계에서 병목이 발생한다. 클라우드 간 복제나 멀티리전 구성에서 자주 문제된다.

3. 디스크 I/O 병목

standby 노드의 디스크 성능 부족으로 WAL을 받아도 빠르게 쓰지 못하면 replay가 늦어진다. fsync, flush 주기와 디스크 대기 시간이 영향을 준다.

4. 체크포인트·플러시 설정

checkpoint 주기가 짧거나 checkpoint 수행 중 I/O가 몰리면 전체 성능이 하락하면서 복제 지연이 발생한다.

5. 설정·버전·리소스 경쟁

postgres 설정(wal_buffers, max_wal_size, wal_sender_timeout 등)이나 서로 다른 버전 간 동작 차이, CPU·메모리 경쟁도 지연 원인이 된다.

진단 절차

진단은 우선 지연이 발생하는 단계 확인부터 시작한다. 아래 쿼리는 primary에서 복제 상태를 확인하는 대표적 방법이다.

SELECT application_name,
       client_addr,
       state,
       sent_lsn,
       write_lsn,
       flush_lsn,
       replay_lsn,
       pg_wal_lsn_diff(sent_lsn, replay_lsn) AS byte_lag
FROM pg_stat_replication;

standby 측에서는 수신·재생 위치를 확인한다.

SELECT pg_last_wal_receive_lsn() AS recv_lsn,
       pg_last_wal_replay_lsn() AS replay_lsn,
       pg_wal_lsn_diff(pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn()) AS byte_lag;

추가로 iostat, vmstat, sar 같은 시스템 도구로 디스크·네트워크 사용량을 확인하고, 로그 파일에서 wal sender/receiver 관련 에러를 검색한다.

실무 해결 방법

1단계: 즉시 완화 조치

• 긴 배치 작업을 비업무 시간으로 이동하거나 배치 속도 제한
• 비동기 복제(asynchronous) 환경이라면 읽기 일관성 정책을 재검토
• 네트워크 우선순위 설정 또는 일시적 대역폭 확장

2단계: 설정 조정

postgresql.conf의 일부 설정을 조정하면 지연을 줄일 수 있다. 예시:

# postgresql.conf 예시
wal_buffers = 16MB
max_wal_size = 2GB
checkpoint_completion_target = 0.9
wal_compression = on

설정을 변경한 뒤에는 reload 또는 restart를 수행하고 모니터링을 지속한다.

3단계: 하드웨어·네트워크 개선

• standby 노드의 디스크를 NVMe 등으로 교체 또는 IOPS 증설
• 전용 네트워크 회선 확보 또는 네트워크 QoS 설정
• 복제 토폴로지를 재검토(다중 standby, cascading replication 등)

4단계: 아키텍처 변경

복제 지연이 지속적으로 발생하면 logical replication, pglogical, 또는 외부 큐 기반 아키텍처로 일부 트래픽을 분산하는 방안을 고려한다. 또한 읽기 전용 복제본을 캐시계층과 함께 구성하면 일관성 요구도를 낮춰 지연 영향을 줄일 수 있다.

모니터링 및 알림 설정

복제 지연은 미리 감지하는 것이 중요하다. 모니터링 항목과 권장 경보 임계값은 다음과 같다.

• byte_lag 또는 replay_lag(초): 예) 5초 또는 10MB 초과 시 경보
• WAL 전송 속도와 수신 속도 차이
• 디스크 큐 길이, fsync 지연, 네트워크 RTT

Prometheus와 pg_exporter를 사용하면 위 지표를 수집해 Grafana 대시보드와 연동 가능하다.

실제 사례와 체크리스트

일반적인 해결 순서는 다음과 같다.

• pg_stat_replication으로 지연 위치 확인
• 네트워크/디스크 사용량 동시 확인
• 단기 완화(배치 조정, 비동기 전환 등) 적용
• postgres 설정 최적화 및 재시작·모니터링
• 필요 시 인프라 업그레이드 또는 아키텍처 변경

요약

replication lag postgres 원인은 WAL 생성 과다, 네트워크 지연, 디스크 I/O 병목, 설정 부적합 등 다양하다. 진단은 pg_stat_replication과 standby의 LSN 비교로 시작하고, 해결은 즉시 완화, 설정 조정, 인프라 개선, 아키텍처 변경의 순으로 접근한다. 꾸준한 모니터링과 알림 설정으로 문제를 조기에 발견하는 습관이 가장 중요하다.