AlloyDB는 컴퓨팅과 스토리지를 분리하는 아키텍처를 갖추고 있어, 각 요소를 독립적으로 확장할 수 있습니다. 기본 인스턴스와 읽기 풀 인스턴스는 동일한 기반 스토리지를 공유하지만, 읽기 복제본 전반에서 데이터 일관성과 최신성을 유지하기 위해 복제는 여전히 중요한 프로세스입니다. AlloyDB 클러스터에서는 쓰기 작업이 기본 인스턴스에서 수행된 뒤 공유 스토리지의 미리 쓰기 로그(WAL)에 기록됩니다. 그런 다음 이러한 변경사항이 읽기 풀 인스턴스의 인메모리 캐시에 복제됩니다. 문제 해결을 위해서는 이 복제 프로세스의 두 가지 주요 단계를 이해하는 것이 핵심입니다.
WAL 플러시: 데이터베이스 변경사항이 포함된 미리 쓰기 로그(WAL)가 기본에서 복제본으로 전송됩니다. 이어서 복제본은 WAL을 즉시 디스크에 영구 저장합니다. 이 두 단계 중 어느 한쪽에서라도 지연이 발생하면 이른바 복제 지연이 발생합니다. 다만 이 용어는 다소 모호할 수 있습니다. 보다 정확히 말하면 복제 지연을 다음 두 구성요소로 나눌 수 있습니다.
플러시 지연 또는 네트워크 지연: WAL 플러시 단계에서 발생하는 지연입니다. 이는 WAL이 기본 인스턴스에서 전송되어 복제본에 영구 저장될 때까지 걸리는 시간입니다.
리플레이 지연: WAL 적용 단계에서 발생하는 지연입니다. 이는 복제본이 WAL의 변경사항을 적용하는 데 걸리는 시간입니다.
플러시 지연과 리플레이 지연 중 어느 쪽을 더 중점적으로 봐야 하는지는 사용 사례에 따라 달라집니다.
- 예를 들어 리전 간 복제본처럼 데이터 손실이 우려되는 경우에는 플러시 지연을 면밀히 확인해야 합니다. WAL이 아직 복제본에 영구 저장되지 않은 상태에서 기본 인스턴스가 장애로 종료되면, 복제본의 관점에서는 해당 변경사항이 손실됩니다.
- 읽기 복제본의 데이터 최신성이 중요하다면 리플레이 지연을 면밀히 확인해야 합니다. 리플레이 지연이 크면 읽기 복제본의 데이터가 오래된 상태임을 의미합니다.
복제 지연 확인
Google Cloud 콘솔에서 읽기 풀 인스턴스의 복제 지연을 모니터링할 수 있습니다. 자세한 내용은 인스턴스 모니터링을 참조하세요. 또한 측정항목 기준점 알림 정책 만들기를 사용하면 읽기 풀 복제 지연을 모니터링하고 지정한 기준점에서 알림을 받을 수 있습니다.
복제 지연의 일반적인 원인
다음은 복제 지연의 일반적인 원인과 그 해결 방법입니다.
리소스 경합
복제는 CPU 및 메모리와 같은 시스템 리소스에 대한 경합으로 인해 느려질 수도 있습니다.
- CPU 및 메모리 압박: 읽기 풀 인스턴스에서 과도한 읽기 워크로드가 발생하면 복제 프로세스와 CPU 및 메모리 리소스를 두고 경쟁할 수 있습니다. Google Cloud 콘솔에서 인스턴스의 CPU 및 메모리 사용량을 확인할 수 있습니다. 리소스 사용률이 높게 나타난다면 읽기 풀 인스턴스를 수직 확장하거나 수평 확장해야 할 수도 있습니다.
- 읽기 풀 노드 크기: 기본 인스턴스가 읽기 풀 노드보다 훨씬 큰 경우, 읽기 노드가 처리할 수 있는 속도보다 더 빠르게 복제 로그를 생성할 수 있습니다. 이러한 경우 복제본에 더 많은 리소스를 제공하기 위해 더 큰 크기의 읽기 노드를 사용하는 것이 좋습니다.
복제 충돌
읽기 쿼리는 복제 프로세스가 기다리고 있는 리소스를 점유하고 있기 때문에, 경우에 따라 복제 프로세스를 차단할 수 있습니다. 예를 들어 읽기 쿼리가 복제 프로세스가 업데이트해야 하는 데이터베이스 객체에 잠금을 설정하고 있다면, 해당 잠금이 해제될 때까지 복제가 차단됩니다. 이러한 현상을 버퍼 핀 충돌이라고 합니다.
로그 탐색기에서 postgres.log 파일을 확인하여 canceling statement due to conflict with recovery 메시지를 찾으면 이러한 충돌을 식별할 수 있습니다.
복제 충돌을 완화하기 위해 다음과 같은 조치를 취할 수 있습니다.
max_standby_streaming_delay감소: 이 파라미터는 복제를 차단하고 있는 쿼리를 취소하기 전에 복제 프로세스가 얼마나 오래 대기할지를 결정합니다. 기본값은 30초입니다. 이 값을 줄이면 복제 지연을 줄이는 데 도움이 될 수 있지만, 읽기 쿼리가 더 자주 취소될 수도 있습니다. 애플리케이션에 가장 적합한 균형을 찾기 위해 이 파라미터를 조정할 수 있습니다.장시간 실행되는 쿼리 회피: 읽기 풀에서 장시간 실행되는 쿼리는 복제 충돌 발생 가능성을 높일 수 있습니다. 복제 지연이 크게 중요하지 않은 다른 읽기 풀로 장시간 실행되는 쿼리를 이동하는 것을 고려하세요.
alloydb.promote_cancel_to_terminate사용 설정: 기본적으로 사용 설정된 이 플래그를 사용하면, 취소 요청에 응답하지 않는 쿼리 백엔드를 AlloyDB가 강제로 종료할 수 있습니다. 이를 통해 응답하지 않는 백엔드가 장시간 복제를 차단하는 상황을 방지할 수 있습니다.
임시 읽기 쿼리 제한
AlloyDB는 google_storage.log_replay_throttle_read_transactions 플래그를 사용하여 읽기 노드에서 복제 지연 기반 읽기 쿼리 제한을 사용 설정할지 여부를 제어할 수 있도록 합니다. 이 파라미터가 기본값인 on으로 설정되어 있으면, 복제 지연 시간이 1초를 초과할 때 최대 1분 동안 새 쿼리의 시작과 새로운 버퍼 읽기가 일시 중지되어 읽기 쿼리가 제한됩니다. 이 기능은 리플레이에 더 많은 리소스를 할당하여 복제 지연을 더 빠르게 따라잡도록 개선하는 대신, 읽기 지연 시간이 증가할 수 있다는 장단점을 갖습니다. 애플리케이션이 복제 지연에 민감하지 않다면, google_storage.log_replay_throttle_read_transactions를 off로 설정하여 읽기 쿼리 지연 시간 개선을 우선할 수 있습니다.
다음 방법을 사용하여 쿼리 제한의 영향을 모니터링할 수 있습니다.
로그: 로그 탐색기의
postgres.log파일에서Delayed.*due to replica lag메시지를 검색하면 복제 지연으로 인해 쿼리가 지연되는 시점을 식별할 수 있습니다.Cloud Monitoring:
alloydb.googleapis.com/instance/postgresql/wait_count측정항목을 사용하여 제한된 쿼리 수를 확인할 수 있습니다. 이를 위해wait_event_name으로 측정항목을 필터링하고HighLagThrottle을 확인하세요. 쿼리가 제한된 총 시간을 확인하려면 동일한 필터를 사용하여alloydb.googleapis.com/instance/postgresql/wait_time측정항목을 사용할 수 있습니다. 자세한 내용은 시스템 인사이트 측정항목 참조를 확인하세요.쿼리 통계: 쿼리 통계 대시보드의 활성 쿼리 보기에서는 복제 지연으로 인해 쿼리가 제한될 때 대기 이벤트 열에
HighLagThrottle대기 이벤트가 표시됩니다. 자세한 내용은 활성 쿼리 모니터링을 참조하세요.
과도한 워크로드
기본 인스턴스에서 쓰기 워크로드가 갑자기 증가하면 대량의 복제 로그가 생성되어 읽기 풀 인스턴스를 압도하고 복제 지연을 유발할 수 있습니다. Google Cloud 콘솔에서 기본 인스턴스의 쓰기 트래픽을 모니터링할 수 있습니다.
대규모 트랜잭션
많은 행에 영향을 미치는 COMMIT 또는 ABORT 레코드와 같은 대규모 트랜잭션은 읽기 풀 인스턴스로 복제되는 데 오랜 시간이 걸릴 수 있습니다. PostgreSQL 14에서는 많은 배타적 잠금을 장시간 유지하는 트랜잭션으로 인해 읽기 복제본의 메모리 사용량이 증가할 수 있으며, 이로 인해 결국 읽기 풀 인스턴스가 비정상 종료될 수 있습니다.
이 문제를 완화하기 위해 기본 인스턴스에서 장시간 실행 중인 트랜잭션을 종료할 수 있습니다.
복제를 방해하는 문제 해결
복제 지연이 발생하려면, 그 이전에 정상적으로 동작하는 읽기 풀이 반드시 존재해야 합니다. 다음과 같은 문제는 읽기 풀 생성을 방해하거나 읽기 복제본이 비정상 종료되게 만들어, 복제가 아예 발생하지 않도록 할 수 있습니다.
읽기 풀 생성 문제
읽기 풀을 만들지 못하면 Cloud Logging의 AlloyDB 로그에서 Failed to create read pool 메시지가 표시될 수 있습니다. 이 문제는 클러스터가 최대 스토리지 한도에 도달하여 기본 인스턴스가 추가 공간을 할당하지 못할 때 발생할 수 있습니다. AlloyDB는 스토리지를 자동으로 확장하지만 스토리지를 소비하는 요소를 조사하여 불필요한 데이터를 삭제하거나, 지원팀에 문의하여 스토리지 할당량 증가를 요청해야 할 수도 있습니다.
읽기 풀 인스턴스 비정상 종료
PostgreSQL 14에서는 기본 인스턴스에서 많은 배타적 잠금을 장시간 유지하는 트랜잭션으로 인해 읽기 복제본의 메모리 사용량이 증가할 수 있으며, 이로 인해 결국 읽기 풀 인스턴스가 비정상 종료될 수 있습니다.
이 문제를 완화하기 위해 기본 인스턴스에서 장시간 실행 중인 트랜잭션을 종료할 수 있습니다.
인스턴스 크기 조절이 복제 지연에 미치는 영향
AlloyDB의 스토리지 아키텍처는 인스턴스 크기 조절이 읽기 풀 플러시 지연에는 영향을 주지 않도록 보장합니다. 하지만 리플레이에는 동일하게 적용되지 않습니다. 복제본이 리플레이를 수행할 수 있는 능력은 현재 부하 상태에 따라 달라집니다. 예를 들어 인스턴스 크기를 조절하는 등 인스턴스 구성을 변경하면, 워크로드에 따라 작업이 완료된 시점에 복제본의 캐시가 완전히 워밍되지 않았을 수 있습니다. 이는 아직 캐시되지 않은 레코드를 리플레이하거나 처리하는 속도가 느려진다는 것을 의미합니다. 이러한 경우 리플레이 지연이 일시적으로 증가할 수 있습니다.