Aurora PostgreSQL에서 REPLICA IDENTITY FULL의 성능 문제 방지

PostgreSQL 논리적 복제를 사용하려면 구독자가 업데이트하거나 삭제할 올바른 행을 찾을 수 있도록 게시된 각 테이블에 복제본 ID가 있어야 합니다. 기본적으로 프라이머리 키는 복제본 ID 역할을 합니다. 테이블에 프라이머리 키 또는 적절한 고유 인덱스가 없는 경우 복제본 ID를 FULL로 설정하여 PostgreSQL이 전체 행을 키로 사용하도록 할 수 있습니다.

REPLICA IDENTITY FULL은 프라이머리 키 없이 테이블을 복제하는 즉각적인 문제를 해결하지만 게시자와 구독자 모두에게 심각한 성능 문제를 일으킬 수 있습니다. 블루/그린 배포와 같이 내부적으로 논리적 복제에 의존하는 기능을 포함하여 Aurora PostgreSQL에서 논리적 복제를 사용하는 모든 사용자에게 이러한 영향을 이해하는 것이 중요합니다.

REPLICA IDENTITY FULL로 인해 문제가 발생하는 이유

게시자의 WAL 볼륨 증가

REPLICA IDENTITY 설정은 PostgreSQL이 미리 쓰기 로그(WAL)에 쓰는 정보를 제어하여 업데이트되거나 삭제된 행을 식별합니다. 기본 복제본 ID(프라이머리 키)에서는 키 열만 이전 행 ID로 로깅됩니다. FULL을 사용하면 PostgreSQL은 각 UPDATE 및 DELETE에 대해 모든 열의 이전 값을 기록합니다. 이로 인해 다음과 같은 여러 결과가 발생합니다.

구독자의 느린 행 조회

구독자가 UPDATE 또는 DELETE 로그 레코드를 수신하면 테이블의 로컬 복사본에서 일치하는 행을 찾아야 합니다. REPLICA IDENTITY FULL을 사용하면 구독자는 이전 행 이미지의 모든 열 값과 일치하는 행을 검색합니다.

PostgreSQL이 이 검색을 수행하는 방법은 PostgreSQL 메이저 버전에 따라 다릅니다.

REPLICA IDENTITY FULL이 복제 지연을 유발하는 방법

게시자의 더 큰 WAL과 구독자의 더 느린 행 조회라는 두 가지 문제가 결합되어 복제 지연이 발생합니다.

기본적으로 PostgreSQL 논리적 복제는 구독당 단일 적용 작업자 프로세스를 사용하여 게시자로부터 변경 사항을 수신하고 구독자의 테이블에 적용합니다. 적용 작업자는 한 번에 한 행씩 순차적으로 변경 사항을 커밋 순서로 처리합니다. 즉, 구독자의 처리량은 각 개별 변경 사항을 얼마나 빨리 적용할 수 있는지에 따라 제한됩니다.

REPLICA IDENTITY FULL이 적절한 인덱스가 없는 테이블에 설정된 경우 UPDATE 및 DELETE마다 일치하는 행을 찾기 위해 전체 테이블을 순차적으로 스캔해야 합니다. 테이블에 수백만 개의 행이 있는 경우 이러한 각 작업은 몇 초 이상 걸릴 수 있습니다. 그 결과 계단식 문제가 발생합니다.

이 문제는 자주 UPDATE 또는 DELETE 작업을 받는 테이블의 경우 특히 심각합니다. 구독자에 대한 행 조회가 필요하지 않으므로 INSERT 작업은 영향을 받지 않습니다.

블루/그린 배포에 미치는 영향

Amazon Aurora의 블루/그린 배포는 데이터베이스당 단일 구독을 설정하여 그린 환경을 블루 환경과 동기화된 상태로 유지하기 위해 내부적으로 논리적 복제를 사용합니다. 그린 환경의 논리적 복제 적용 프로세스는 단일 스레드입니다. 단일 적용 작업자 프로세스는 블루 환경에서 모든 변경 사항을 수신하고 한 번에 하나씩 커밋 순서로 적용합니다. 블루/그린 복제 경로에는 병렬이 적용되지 않습니다.

이 단일 스레드 설계는 블루 환경을 따라잡는 그린 환경의 기능은 전적으로 적용 작업자가 각 개별 변경을 처리할 수 있는 속도에 달려 있음을 의미합니다. 테이블이 프라이머리 키 또는 적절한 인덱스 없이 REPLICA IDENTITY FULL을 사용하는 경우 적용 작업자에 미치는 영향은 PostgreSQL 버전에 따라 달라집니다. 16 이전 버전에서는 해당 테이블의 모든 UPDATE 및 DELETE에서 적용 작업자가 전체 테이블을 순차적으로 스캔하여 일치하는 행을 찾도록 강제합니다. 버전 16 이상에서 PostgreSQL은 적절한 인덱스를 사용할 수 있는 경우 적절한 인덱스를 사용하지만, 적격 인덱스가 없는 경우에도 적용 작업자는 여전히 순차적 스캔으로 돌아갑니다. 적용 작업자가 한 행에 대해 큰 테이블을 스캔하는 동안 모든 테이블에서 대기 중인 다른 모든 변경 사항은 대기 중입니다.

블루/그린 배포의 결과는 중요합니다.

이러한 문제를 방지하려면 블루/그린 배포를 생성하기 전에 모든 테이블에 ALTER TABLE ... REPLICA IDENTITY USING INDEX를 사용하여 복제본 ID로 명시적으로 구성된 프라이머리 키 또는 적절한 고유 인덱스가 있는지 확인합니다. PostgreSQL 16 이상에서 암시적 인덱스를 선택할 때 REPLICA IDENTITY FULL에 의존하지 마세요. 구독자가 선택이 잘못된 인덱스를 선택하거나 순차 스캔으로 돌아갈 수 있기 때문입니다. 대표적인 쓰기 워크로드로 배포를 테스트하여 그린 환경이 따라갈 수 있는지 확인합니다.

블루/그린 배포 제한 사항에 대한 자세한 내용은 Amazon Aurora 블루/그린 배포 관련 제한 사항 및 고려 사항 섹션을 참조하세요. 모범 사례는 블루/그린 배포 모범 사례에 대한 Aurora PostgreSQL 모범 사례 섹션을 참조하세요.

REPLICA IDENTITY FULL을 사용하여 테이블을 식별하는 방법

다음 쿼리를 실행하여 REPLICA IDENTITY FULL에서 모든 테이블을 찾습니다.

SELECT n.nspname AS schema, c.relname AS table_name, c.relreplident
FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind = 'r'
  AND c.relreplident = 'f'
  AND n.nspname NOT IN ('pg_catalog', 'information_schema')
ORDER BY n.nspname, c.relname;

relreplident 열 값은 다음과 같습니다.

해결 방법 및 모범 사례

가능한 경우 프라이머리 키 추가

가장 효과적인 솔루션은 프라이머리 키가 없는 테이블에 프라이머리 키를 추가하는 것입니다. 프라이머리 키가 있는 경우 PostgreSQL은 이를 기본 복제본 ID로 사용하여 구독자에 대한 효율적인 행 조회를 제공하고 게시자의 WAL 오버헤드를 최소화합니다.

ALTER TABLE my_table ADD COLUMN id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY;

애플리케이션 제약으로 인해 프라이머리 키를 추가할 수 없는 경우 NOT NULL 열 세트에 고유 인덱스를 추가하고 이를 복제본 ID로 설정하는 것이 좋습니다.

CREATE UNIQUE INDEX my_table_replica_idx ON my_table (col1, col2);
ALTER TABLE my_table REPLICA IDENTITY USING INDEX my_table_replica_idx;

암시적 인덱스 선택에 의존하지 마세요(PostgreSQL 16 이상).

PostgreSQL 16부터 구독자의 적용 작업자는 복제본 ID가 FULL로 설정된 경우 해당 인덱스가 복제본 ID로 명시적으로 구성되지 않은 경우에도 행 조회에 btree 또는 해시 인덱스를 사용할 수 있습니다. 이렇게 하면 경우에 따라 순차적 스캔을 방지할 수 있지만 다음과 같은 이유로 이러한 암시적 동작에 의존하는 것이 안티 패턴입니다.

대신 복제된 모든 테이블에 대해 복제본 ID를 명시적으로 구성합니다.

두 옵션 모두 사용할 수 없는 테이블에 대해서만 REPLICA IDENTITY FULL을 예약하고 성능이 직접 제어할 수 없는 요인에 따라 달라진다는 점을 이해합니다.

복제 지연 모니터링

REPLICA IDENTITY FULL을 사용하는 경우 복제 지연을 면밀히 모니터링하여 구독자가 심각해지기 전에 속도 저하를 감지합니다.

게시자에서 현재 WAL 위치와 구독자가 확인한 내용 간의 지연을 확인합니다.

SELECT slot_name, confirmed_flush_lsn, pg_current_wal_lsn(),
       (pg_current_wal_lsn() - confirmed_flush_lsn) AS lag_bytes
FROM pg_replication_slots
WHERE slot_type = 'logical';

lag_bytes 값이 꾸준히 증가하면 구독자가 뒤처지고 있음을 나타냅니다. pg_stat_replication_slots 뷰는 각 복제 슬롯의 사용량에 대한 추가 통계를 제공합니다.

구독자에서 pg_stat_subscription 뷰는 수신 및 보고된 마지막 WAL 위치를 포함하여 각 적용 작업자의 상태를 표시합니다.

SELECT subname, received_lsn, latest_end_lsn,
       last_msg_send_time, last_msg_receipt_time
FROM pg_stat_subscription;

received_lsn과 latest_end_lsn 사이의 큰 간격 또는 last_msg_send_time의 기한 경과 타임스탬프는 적용 작업자가 따라잡기 위해 어려움을 겪고 있음을 나타낼 수 있습니다. 또한 pg_stat_subscription_stats 뷰는 지연에 영향을 미칠 수 있는 적용 오류 및 충돌을 추적합니다.

Aurora PostgreSQL의 경우 복제 슬롯에서 가장 뒤쳐진 슬롯의 바이트 지연을 추적하는 OldestReplicationSlotLag CloudWatch 지표를 모니터링할 수도 있습니다. 값 상승은 복제 지연의 초기 경고 신호입니다. 자세한 내용은 Aurora PostgreSQL 논리적 복제를 위한 라이트-스루 캐시 및 논리적 슬롯 모니터링 단원을 참조하세요.

적용 중에 최적화되지 않은 인덱스를 사용할 수 있는 테이블 확인

구독자는 적용 작업자가 과도한 힙 읽기를 수행하는 테이블을 식별할 수 있습니다. 이는 적용 중에 테이블에 행 조회에 대한 효율적인 인덱스가 없음을 나타낼 수 있습니다. 구독자에 대해 다음 쿼리를 실행합니다.

SELECT relname, heap_blks_read, heap_blks_hit,
       idx_blks_read, idx_blks_hit,
       heap_blks_read + heap_blks_hit AS total_heap_access
FROM pg_statio_user_tables
WHERE heap_blks_read > 0
ORDER BY heap_blks_read DESC
LIMIT 10;

idx_blks_read에 비해 heap_blks_read 값이 높은 테이블은 적용 작업자가 효율적인 인덱스를 사용하여 UPDATE 및 DELETE 작업에 대한 행을 찾지 못하고 있음을 나타낼 수 있습니다. 이는 REPLICA IDENTITY FULL이 사용 중일 때 복제 지연의 일반적인 원인입니다.

REPLICA IDENTITY FULL이 필요한지 평가

REPLICA IDENTITY FULL을 설정하기 전에 실제로 필요한지 여부를 고려하세요. 이를 사용하는 일반적인 이유는 다음과 같습니다.

프라이머리 키가 없어서 유일한 이유가 있다면 거의 항상 프라이머리 키를 추가하는 것이 더 나은 경로입니다. CDC에 대한 전체 사전 이미지가 필요한 경우 CDC 소비자가 상태를 외부로 유지하여 전체 행을 재구성할 수 있는지 여부를 고려하면 REPLICA IDENTITY FULL의 WAL 및 구독자 오버헤드를 피할 수 있습니다.

권장 사항 요약