PostgreSQL 복제 지연 이해 및 감소

PostgreSQL에서의 복제 지연은 주 서버에서의 변경 사항이 복제 서버에 반영되기까지 시간이 걸리는 경우 발생합니다. 스트리밍 또는 논리적 복제를 사용하더라도, 지연은 성능, 일관성 및 시스템 가용성에 영향을 줄 수 있습니다. 이 게시물은 복제의 유형, 그들의 차이, 지연의 원인, 지연 추정을 위한 수학적 공식, 모니터링 기술, 그리고 복제 지연을 최소화하는 전략을 다룹니다.

PostgreSQL에서의 복제 유형

스트리밍 복제

스트리밍 복제는 주 서버에서 1개 이상의 복제 서버로 Write-Ahead Log (WAL) 변경 사항을 실시간에 가깝게 계속 전송합니다. 복제본은 받은대로 변경 사항을 순차적으로 적용합니다. 이 방법은 전체 데이터베이스를 복제하고 복제본이 동기화되어 있는지를 확인합니다.

장점

• 거의 실시간 동기화로 낮은 지연 시간.
• 전체 데이터베이스 복제에 효율적입니다.

단점

• 복제본은 읽기 전용이므로 모든 쓰기 트랜잭션은 주 노드로 전송되어야 합니다.
• 네트워크 연결이 끊기면 지연이 크게 증가할 수 있습니다.

논리적 복제

논리 복제는 낮은 수준의 WAL 데이터가 아닌 데이터 수준의 변경 사항을 전송합니다. 특정 테이블 또는 데이터베이스의 일부만 복제되는 선택적 복제를 가능하게 합니다. 논리 복제는 WAL 변경 사항을 SQL과 유사한 변경 사항으로 변환하기 위해 논리 디코딩 프로세스를 사용합니다.

장점

• 특정 테이블 또는 스키마의 선택적 복제를 허용합니다.
• 충돌 해결 옵션을 지원하는 쓰기 가능한 복제를 지원합니다.

단점

• 논리 디코딩 오버헤드로 인한 높은 지연 시간.
• 대규모 데이터셋의 경우 스트리밍 복제보다 효율성이 낮습니다.

복제 지연이 발생하는 방법

복제 지연은 주 서버에서 생성된 변경 사항의 속도가 복제 서버에 처리되고 적용되는 속도를 초과할 때 발생합니다. 이 불균형은 데이터 동기화 지연에 기여하는 각종 기본 요인으로 인해 발생할 수 있습니다. 복제 지연의 가장 일반적인 원인은 다음과 같습니다:

네트워크 지연

네트워크 지연은 주 서버에서 복제 서버로 데이터가 이동하는 데 걸리는 시간을 의미합니다. WAL (Write-Ahead Log) 세그먼트는 스트리밍 복제 중에 지속적으로 네트워크를 통해 전송됩니다. 네트워크 전송에 미세한 지연이 누적되어 복제가 지연될 수 있습니다.

원인

• 높은 네트워크 왕복 시간(RTT).
• 고용량의 WAL 데이터를 처리하기 위한 더 많은 대역폭.
• 네트워크 혼잡 또는 패킷 손실이 발생할 수 있습니다.

주 서버가 피크 트래픽 중에 상당한 변경 사항을 생성하는 경우, 느린 또는 과부하된 네트워크로 인해 레플리카가 WAL 변경 사항을 수신하지 못할 수 있습니다.

해결책

지연 시간이 낮고 대역폭이 높은 네트워크 연결을 사용하고 WAL 압축 (wal_compression = on)을 활성화하여 전송 중 데이터 크기를 줄입니다.

I/O 병목 현상

레플리카 서버의 디스크가 수신되는 WAL 변경 사항을 기록하기에 너무 느린 경우 I/O 병목 현상이 발생할 수 있습니다. 스트리밍 복제는 변경 사항을 적용하기 전에 디스크에 기록하는 것을 기반으로 하므로 I/O 서브시스템의 지연은 지연이 누적되도록 할 수 있습니다.

원인

• 느린 또는 과부하된 하드 드라이브 (HDD).
• 디스크 쓰기 처리량이 충분하지 않음.
• 다른 프로세스로 인한 디스크 경합.
• 레플리카 서버가 회전 디스크 (HDD) 대신 플래시 드라이브 (SSD)를 사용하는 경우, 데이터 변경에 따라 WAL 변경 사항이 충분히 빨리 기록되지 않을 수 있어 레플리카가 주 서버를 따라잡지 못할 수 있습니다.

해결책

레플리카의 디스크 I/O를 최적화하려면 더 빠른 쓰기 속도를 위해 SSD를 사용하고 다른 디스크 집중 작업으로부터 복제 프로세스를 격리시킵니다.

CPU/메모리 제약 사항

복제 프로세스는 변경 사항을 해독하고 기록하며 적용하기 위해 CPU와 메모리를 필요로 합니다. 복제 서버에 충분한 처리 능력이나 메모리가 부족하면 들어오는 수정 사항을 따라잡기 어려워져 복제 지연이 발생할 수 있습니다.

원인

• 제한된 CPU 코어 또는 느린 프로세서.
• WAL 버퍼에 대한 메모리 부족.
• 다른 프로세스가 CPU 또는 메모리 자원을 소모합니다.
• 복제가 진행되는 동안 복제가 처리 중인 대량의 트랜잭션이나 쿼리가 있다면 CPU가 포화 상태가 되어 복제 프로세스가 느려질 수 있습니다.

해결책

복제 서버에 더 많은 CPU 코어와 메모리를 할당합니다. WAL 처리 효율성을 개선하기 위해 wal_buffers의 크기를 늘립니다.

주 서버의 무거운 작업 부하

주 서버가 복제 서버가 처리하기에는 너무 많은 변경 사항을 너무 빠르게 생성하면 복제 지연이 발생할 수 있습니다. 대량의 트랜잭션, 대량 삽입 또는 빈번한 업데이트는 복제를 압도할 수 있습니다.

원인

• 대량 데이터 가져오기 또는 대규모 트랜잭션.
• 대형 테이블에 대한 고빈도 업데이트.
• 주 서버의 높은 동시성 작업 부하.
• 주 서버가 대량 데이터 가져오기와 같은 여러 개의 대규모 트랜잭션을 동시에 처리하면 트랜잭션 부하가 너무 무거워질 수 있습니다. WAL 데이터의 양이 복제 서버가 실시간으로 처리할 수 있는 양을 초과하여 지연이 증가할 수 있습니다.

해결책

거래 최적화를 위해 보다 작은 업데이트를 일괄 처리하고 장기간 실행되는 거래를 피하십시오. 엄격한 동기화가 중요하지 않다면 비동기 복제를 사용하여 복제 부하를 줄이세요.

자원 경합

자원 경합은 여러 프로세스가 CPU, 메모리 또는 디스크 I/O와 같은 동일한 자원을 경쟁할 때 발생합니다. 이는 기본 서버나 복제 서버 양쪽에서 발생할 수 있으며 복제 처리 지연으로 이어질 수 있습니다.

원인

• 다른 프로세스가 디스크 I/O, CPU 또는 메모리를 사용함.
• 백그라운드 작업인 백업이나 분석이 동시에 실행됨.
• 복제 트래픽과 다른 데이터 전송 간의 네트워크 경합.
• 복제 서버가 백업이나 분석 쿼리도 실행한다면 CPU와 디스크 자원을 경쟁하여 복제 프로세스가 느려질 수 있습니다.

해결책

다른 자원 집약적인 프로세스로부터 복제 워크로드를 격리하세요. 복제와 간섭을 방지하기 위해 백업 및 분석을 비정상적인 시간에 예약하세요.

복제 지연에 대한 수학적 공식

복제 지연을 계산하기 위해 다음 공식을 사용하세요:

논리적 복제에서는 논리 디코딩으로 인해 추가 시간이 소요됩니다:

복제 지연 모니터링

스트리밍 복제 모니터링

pg_stat_replication 뷰는 스트리밍 복제 지연을 모니터링하는 데 사용할 수 있습니다. 이 뷰는 기본 서버와 복제 서버 간의 상태 및 지연에 대한 통찰력을 제공합니다.

SELECT application_name, state, 

​

       pg_size_pretty(sent_lsn - write_lsn) AS lag_bytes,

​

       sync_state

​

FROM pg_stat_replication;

​

​

• sent_lsn: 복제본에 전송된 마지막 WAL 위치입니다.
• write_lsn: 복제본에 작성된 마지막 WAL 위치입니다.
• lag_bytes: 두 값의 차이는 지연을 나타냅니다.

논리 복제 모니터링

논리 복제 지연은 pg_stat_subscription 뷰를 사용하여 모니터링할 수 있습니다.

SELECT subscription_name, active,

​

       pg_size_pretty(pg_current_wal_lsn() - replay_lsn) AS lag_bytes

​

FROM pg_stat_subscription;

​

​

예제: 복제 지연 시각화

다음 Python 코드 스니펫은 시간에 따른 스트리밍 및 논리 복제 지연을 시각화합니다.

import matplotlib.pyplot as plt

​

time = ['12:00', '12:10', '12:20', '12:30', '12:40', '12:50', '13:00']

streaming_lag = [0.5, 0.6, 0.4, 0.7, 1.0, 0.9, 0.6]

logical_lag = [2.0, 2.5, 3.0, 2.8, 3.5, 4.0, 3.2]

​

plt.plot(time, streaming_lag, label='Streaming Replication Lag', marker='o')

plt.plot(time, logical_lag, label='Logical Replication Lag', marker='s')

​

plt.xlabel('Time')

plt.ylabel('Lag (seconds)')

plt.title('Replication Lag Over Time')

​

plt.legend()

plt.grid(True)

​

# Save the plot as an image file

plt.savefig('replication_lag_plot.png')

​

print("Plot saved as replication_lag_plot.png")

결과 그래프는 스트리밍 복제와 논리 복제의 성능을 비교합니다. 논리 복제는 디코딩 및 처리 오버헤드로 인해 더 변동성이 큰 지연을 보이는 경향이 있습니다.

복제 지연을 줄이는 방법

1. WAL 구성 최적화

• 메모리에 더 많은 WAL 데이터를 보관할 수 있도록 wal_buffers를 증가시킵니다.
• wal_writer_delay 값을 낮은 값(예: 10ms)으로 설정하여 WAL 데이터를 더 빠르게 기록합니다.

wal_buffers = 64MB

​

wal_writer_delay = 10ms

2. 네트워크 성능 개선

• 주 서버와 복제본 간에 저지연, 고대역폭 네트워크 연결을 사용합니다.
• 전송 중 WAL 데이터를 압축하여 전송 시간을 줄입니다: wal_compression = on.

3. 비동기 복제 사용(가능한 경우)

• 비동기 복제는 복제본이 변경 사항을 확인할 때까지 기다리지 않음으로써 지연을 줄이지만 데이터 손실 위험을 초래합니다.

ALTER SYSTEM SET synchronous_commit = 'off';

4. 논리 복제에서 병렬 적용 활성화

• PostgreSQL 14+는 논리 변경 사항의 병렬 적용을 허용하여 대규모 트랜잭션의 지연을 줄입니다.

ALTER SUBSCRIPTION my_subscription SET (parallel_apply = on);

5. 복제본에 더 많은 리소스 할당

• 복제본이 WAL 변경 사항을 빠르게 처리할 수 있도록 충분한 CPU와 메모리를 확보하십시오.
• 복제본에서 빠른 디스크 I/O를 위해 SSD를 사용하십시오.

6. 배치 트랜잭션

• 여러 개의 작은 업데이트를 더 적은 트랜잭션으로 그룹화하여 오버헤드를 최소화하십시오.

실제 사례

스트리밍 복제 지연 시간 줄이기

고 트래픽 PostgreSQL 클러스터를 운영하는 한 회사는 피크 시간 동안 복제 지연 현상을 겪었습니다. 그들은 wal_buffers를 64MB로 늘리고 wal_writer_delay를 10ms로 줄임으로써 복제 지연 시간을 절반으로 줄였습니다. 고속 네트워크 연결로 전환하여 지연 시간을 1초 이하로 줄였습니다.

논리적 복제 지연 시간 줄이기

여러 논리적 구독이 있는 시스템은 높은 쓰기 작업 부하에서 지연을 경험했습니다. PostgreSQL 14에서 병렬 애플리케이션을 활성화하여 작업 부하를 여러 작업자에 분산시켜 복제 지연 시간을 4초에서 1초 이하로 줄였습니다.

결론

복제 지연은 PostgreSQL 시스템의 성능과 일관성에 영향을 미치는 중요한 문제입니다. 스트리밍 복제는 낮은 대기 시간을 제공하지만 전체 데이터베이스를 복제해야 하며, 논리적 복제는 유연성을 제공하지만 더 높은 오버헤드를 동반합니다. pg_stat_replication 및 pg_stat_subscription를 사용한 정기 모니터링을 통해 관리자는 지연을 감지하고 완화할 수 있습니다.

WAL 구성을 최적화하고 네트워크 성능을 향상시키며 병렬 애플리케이션을 사용하고 충분한 리소스를 할당하면 지연을 크게 줄일 수 있습니다. 적절한 조정은 레플리카가 동기화되고 시스템이 고가용성과 성능을 유지하도록 보장합니다.