BLOG
관리형 서비스 중 하나인 PostgreSQL용 Amazon RDS는 리전 간 읽기 복제가 가능합니다. 교차 리전 간 읽기 복제 기능을 사용하면 재해 복구 솔루션, 읽기 데이터베이스 워크로드 확장, 리전 간 마이그레이션이 가능합니다. 이 리전 간 읽기 복제본은 Amazon RDS 콘솔, AWS CLI, 또는 API create-db-instance-read-replica를 사용하여 생성할 수 있으며, 이 경우 추가 데이터 전송 요금이 발생합니다.
Amazon RDS는 교차 리전 읽기 복제본을 단순하게 만들지만 이 외에도 본 서비스를 최대한 활용하기 위해선 몇 가지 주의 사항을 알고 있어야 합니다. 하여 오늘 메가존 테크블로그에서는 다음의 주제를 바탕으로 PostgreSQL용 Amazon RDS의 리전 간 복제에 대한 모범 사례를 소개합니다.
- 교차 리전 복제본이 생성되는 동안 수행되는 작업
- 복제 지연을 최소화하는 방법
- PostgreSQL용 Amazon RDS 교자 리전 복제본을 사용할 때 발생하는 일반적인 문제
교차 리전 복제본이 생성되는 동안 수행되는 작업
PostgreSQL용 Amazon RDS는 9.5.2 버전 이상에 대한 리전 간 읽기 복제본을 지원합니다. 교차 리전 복제본을 생성하는 동안 시스템은 다음 단계를 수행합니다.
- 원본 인스턴스에서 스냅샷을 생성합니다.
- 스냅샷을 대상 영역에 복사합니다.
- 원본 복제본과 교차 리전 복제본 간에 복제 슬롯 스트리밍을 구성합니다.
- 원본에서 복제본으로 WAL(Write-ahead Log) 스트리밍을 시작합니다. WAL 파일은 PostgreSQL 트랜잭션 로그입니다. 영구 스토리지에 데이터 변경 사항을 기록하기 전에 이러한 변경 사항은 WAL 파일에 먼저 기록됩니다.
PostgreSQL용 Amazon RDS에 대한 교차 영역 복제본을 만드는 가장 쉬운 방법은 다음과 같습니다.
- Amazon RDS 콘솔에서 PostgreSQL용 Amazon RDS를 선택합니다.
- Actions 드롭다운 메뉴에서 Create Read Replica(읽기 복제본 생성)을 선택합니다.
- 원하는 리전을 선택합니다.
위의 방법 말고도 AWS CLI create-db-instance-read-replica 를 사용하여 교차 리전 읽기 복제본을 생성할 수도 있습니다. 동일한 리전의 복제본에 대해 물리적 복제를 스트리밍하는 것과는 달리 PostgreSQL용 Amazon RDS는 교차 리전 복제본에 대한 슬롯과 함께 물리적 스트리밍 복제를 사용합니다. 기존 스트리밍 복제에서 매개 변수 wal_keep_segments는 인스턴스의 WAL 파일 수를 유지합니다. archive_command매개 변수는 Amazon S3에 있는 추가 WAL 파일의 아카이브를 결정합니다. 물리적 복제 슬롯은 이 매개 변수에 대한 종속성을 해결합니다. 복제 슬롯은 교차 영역 복제본이 WAL 세그먼트를 수신할 때까지 마스터가 WAL 세그먼트를 제거하지 않도록 자동화된 방법을 제공합니다. 이렇게 하면 리전 간의 네트워크 이슈가 발생될 때 WAL은 아카이브되지 않고 원본 인스턴스에 누적됩니다. 따라서 아카이브된 위치에서 WAL 파일을 복원하여 발생하는 복제 지연과 복제 성능 저하와 같은 문제를 예방할 수 있습니다.
다음의 다이어그램은 PostgreSQL용 Amazon RDS가 서로 다른 리전에서 원본과 복제본 간에 복제를 수행하는 방법을 보여줍니다.
복제 지연 최소화
원본 인스턴스에서 발생하는 데이터 변경 사항이 리전 간 복제본에 즉시 반영되지 않는 경우는 많습니다. 다음으로는 PostgreSQL용 Amazon RDS를 사용하는 동안 복제 지연을 최소화하는 모범 사례를 설명해 드리겠습니다.
인스턴스 클래스 및 저장소 유형
최적의 성능을 위해 복제본 인스턴스는 원본 인스턴스와 동일한 클래스 이상이어야 합니다. 복제본 인스턴스는 마스터와 유사한 쓰기 작업을 재생할 뿐만 아니라 추가 읽기 작업량도 제공합니다. 따라서 복제본을 적절한 인스턴스 클래스에 필수적으로 배치해야 합니다. 복제본이 하위 인스턴스 클래스에 호스트되는 경우 CPU, 메모리 및 처리량이 부족할 수 있습니다. 이로 인해 복제 성능이 전반적으로 저하되어 복제 지연이 발생할 수 있습니다.
마찬가지로 복제본을 원본 인스턴스와 동일한 저장소 유형에 두는 것이 좋습니다. 예를 들어 마스터 인스턴스가 20000PIOPS에 500GB Provisioned IOPS SSD 유형 스토리지를 사용하는 경우, 교차 리전 복제본이 원본을 최적으로 사용하는 동안 500GB GB General Purpose SSD 스토리지로 더 나쁜 성능을 발휘할 수 있습니다. 원본 인스턴스의 쓰기 작업을 재생하지 못할 경우 복제본의 리소스(예: CPU, 메모리 및 IOPS)가 부족하기 때문에 복제 지연 시간이 증가합니다.
원본 인스턴스에서 액티비티 쓰기
RDS 스토리지에 데이터를 쓰려면 먼저 WAL 파일에 트랜잭션을 기록한 다음 이러한 변경 사항을 물리적 스토리지 블록에 기록합니다. 원본 인스턴스에서 쓰기 작업이 많으면 WAL 파일이 많이 유입될 수 있습니다. WAL 파일이 많이 생성되고 읽기 복제본에서 이러한 파일을 재생하면 전체 복제 성능이 저하됩니다. Amazon CloudWatch의 WriteIOPS및 WriteThroughput 매트릭을 모니터링하여 원본 인스턴스 쓰기 성능을 모니터링할 수 있습니다.
다음은100GB GP2 스토리지가 있는 원본 인스턴스에서 높은 쓰기 처리량을 보여 줍니다.
다음은 원본 인스턴스의 많은 쓰기 작업으로 인한 리전 간 높은 복제본 지연을 보여 줍니다.
원본 인스턴스의 명시적 잠금
ALTER TABLE, TRUNCATE, DROP TABLE, REINDEX, CLUSTER 및 VACUUM FULL 등의 PostgreSQL 명령은 테이블에서 가장 제한적인 잠금 모드인 액세스 배타적 잠금을 유발합니다. 이 모드는 다른 모든 잠금 모드와 충돌합니다. 이 잠금 장치는 다른 모든 트랜잭션이 잠금 유지 기간 동안 테이블에 접근하는 것을 방지합니다. 일반적으로 테이블은 거래가 끝날 때까지 잠겨 있습니다. 잠금이 걸린 트랜잭션의 결과는 복제 충돌로 이어질 수 있습니다. 예를 들어, 원본 인스턴스에 테이블을 놓는 경우, 해당 테이블에 대한 쿼리가 액세스하는 경우 복제본은 변경사항을 적용하지 않습니다.
자세한 내용은 PostgreSQL 웹사이트에서 ‘Explicit Locking(명시적 잠금)’ 항목을 참고해 주십시오.
이러한 상황을 방지하려면 pg_locks 및 pg_stat_activity 카탈로그 테이블을 주기적으로 쿼리하여 이 상황을 모니터링해야 합니다. 예를 들어, 다음 코드는 PostgreSQL 9.6 이상 PostgreSQL 인스턴스에서 잠금을 모니터링합니다.
SELECT pid,
usename,
pg_blocking_pids(pid) AS blocked_by,
QUERY AS blocked_query
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;
다른 대안으로는 Amazon RDS Performance Insights를 사용하여 데이터베이스 잠금을 모니터링하는 방법이 있습니다. Performance Insights는 데이터베이스 성능을 분석하고 문제를 해결할 수 있도록 Amazon RDS DB 인스턴스 로드를 모니터링합니다. Performance Insights 대시보드를 사용하면 데이터베이스 로드를 시각화하고 대기, SQL 명령문, 호스트 또는 사용자를 기준으로 로드를 필터링할 수 있습니다. 다음의 그래프는 22:23 ~ 22:53 사이의 높은 LWLock:buffer_mapping 과LWLock:buffer_content대기 이벤트를 보여줍니다.
교차 영역 복제본의 매개변수 설정
기본 구성에서 원본 인스턴스는 읽기 쿼리 시작 시간과 교차 리전 복제본에서 액세스한 행의 정보를 인식하지 못합니다. 이 행이 복제본 인스턴스에서 사용될 수 있다는 사실을 모른 채 이전 버전을 정리(VACUM)합니다. 복제본이 이 정리를 재생하고 행을 읽는 모든 쿼리를 강제로 취소해야 합니다. 따라서 해당 행이 원본 인스턴스에서 업데이트되거나 삭제될 경우 크로스 영역 복제본에서 장기간 실행되는 읽기 쿼리가 실패할 수 있고 다음과 같은 에러가 발생할 수 있다.
복제본 인스턴스에서 이러한 행이 사용될 수 있다는 사실을 모른 채 이전 버전을 정리(VACUUM)합니다. 복제본은 이 정리를 재생하고 이 행을 읽는 모든 쿼리를 강제로 취소해야 합니다. 따라서 원본 인스턴스에서 해당 행이 업데이트되거나 삭제될 경우 다음의 에러 메시지와 함께 교차 리전 복제본에서 장기간 실행되는 읽기 쿼리가 실패할 수 있습니다.
ERROR: canceling statement due to conflict with recovery
Detail: User query might have needed to see row versions that must be removed.
hot_standby_feedback 매개 변수를 활성화하면 이러한 상황을 방지할 수 있습니다. 이 설정은 복제본에서 행의 이전 버전에 액세스할 때까지 해당 테이블의 VACUUM을 연기합니다. 이 설정의 단점은 테이블이 심하게 부풀어 오르고 스토리지 부족 문제와 트랜잭션 ID가 처리될 위험이 있다는 것입니다. 자세한 내용은 PostgreSQL 웹사이트의 ‘Routine Vacuuming’을 참고해 주시기 바랍니다..
다른 방법으로 복제본 인스턴스에서 max_standby_archive_delay또는 max_standby_streaming_delay와 같은 매개 변수를 사용하도록 설정하여 장기간 실행되는 읽기 쿼리를 완료할 수도 있습니다. 복제본에서 읽기 쿼리가 실행되는 동안 해당 원본 데이터가 수정된 경우 두 매개 변수는 복제본에서 WAL 재생을 일시 중지합니다. -1 값은 WAL 재생이 읽기 쿼리가 완료될 때까지 기다리게 한다. 그러나 이러한 일시 중단은 복제 지연을 무한정 증가시키고 WAL 축적으로 인해 원본에서 높은 스토리지 소비를 유발합니다. 이러한 매개변수의 높은 값은 교차 리전 복제본에서 높은 복제 지연을 유발할 수 있습니다. 예를 들어, 조회가 복제본에서 30분 동안 실행되는 경우, max_standby_streaming_delay를 30분으로 설정하면 복제 지연 시간이 최대 30분이고 원본 인스턴스에서 WAL로그가 30분 누적될 수 있습니다. 이 세 가지 매개 변수 중 하나를 수정하는 경우 복제본 인스턴스에서 장기간 실행되는 읽기 쿼리를 감시하여 원본 인스턴스를 정상 상태로 유지하고 복제 지연을 관리할 수 있도록 해주시기 바랍니다.
다음과 같은 SQL 쿼리가 유용할 수도 있습니다. 읽기 복제본에 다음 코드를 입력하면 5분 이상 실행되는 읽기 트랜잭션이 모두 삭제됩니다.
SELECT
pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE (now() – pg_stat_activity.query_start) > interval ‘5 minutes’;
PostgreSQL용 Amazon RDS 교자 리전 복제본을 사용할 때 발생하는 일반적인 문제
워크로드를 관리하고 인스턴스 구성을 수정하여 교차 리전 복제본의 대부분의 문제를 해결할 수 있습니다. 그렇다면 이번에는 PostgreSQL용Amazon RDS 교차 리전 복제본과 관련된 몇 가지 일반적인 문제와 해결책을 소개해 드리겠습니다.
복제본에 발생하는 복제지연
원본 인스턴스에서 실행 중인 워크로드가 없는 경우 교차 영역 복제본에서 최대 5분 지연이 발생할 수 있습니다. 예기치 않은 지연이 있는 경우 원본의 쓰기 작업량 강도를 확인하고, 인스턴스와 저장소 클래스가 원본 및 복제본과 일치하는지 확인하여 원본과 복제본 간에 기존 네트워크 문제가 있는지 찾아보시기 바랍니다. 또한 원본 또는 복제본이 CPU, 메모리 또는 IOPS와 같은 리소스를 제한하지 않는지 확인해 주십시오.
그래도 여전히 지연의 원인을 확인할 수 없는 경우엔, AWS Support을 통해 사례를 열어 지역 간의 네트워크 문제를 추적해 주시기 바랍니다. 원본 인스턴스에서 pg_stat_activity 보기를 보고 복제 프로세스를 방해할 수 있는 특정 실행 쿼리를 종료하는 것도 중요합니다. CloudWatch 메트릭 ReplicaLag 를 사용하여 복제 지연을 모니터링할 수 있다. 또한 select pg_current_wal_lsn(); 명령을 선택하면 복제본의 LSN이 증가하는지 확인할 수 있습니다.
원본 인스턴스의 스토리지 부족
교차 영역 읽기 복제본은 원본 인스턴스에서 작성된 실제 복제 슬롯을 사용합니다. 복제 슬롯은 WAL 파일을 보존하기 때문에 교차 영역 복제 지연은 원본 인스턴스에 WAL이 많이 축적되고 결국 스토리지 부족과 같은 심각한 문제를 야기할 수 있습니다. CloudWatch 메트릭스 OldestReplicationSlotLag 및 TransactionLogsDiskUsage를 사용하여 복제본 지연 크기 및 트랜잭션 로그에서 사용되는 디스크 공간을 결정할 수 있습니다. 이 문제에 대한 즉각적인 해결책은 기존의 교차 영역 복제본을 삭제하고 새 복제본을 만드는 것입니다.
FreeStorageSpace에 대해 CloudWatch 경보를 설정하면 원본 인스턴스에서 워크로드 관련 문제를 해결하고 복제본을 다시 만들지 않아도 됩니다. 이에 대한 자세한 내용은 ‘How can I create CloudWatch alarms to monitor the Amazon RDS free storage space and prevent storage full issues?(CloudWatch 경보를 생성하여 Amazon RDS의 사용 가능한 스토리지 공간을 모니터링하고 스토리지 전체 문제를 방지하는 방법)’ 페이지의 글을 참고해 주시기 바랍니다.
글을 마치며…
AWS는 데이터베이스 복제 성능을 더욱 안정적이고 효율적으로 만듭니다. PostgreSQL용Amazon RDS 교차 영역 복제본은 영역 간 읽기 지연 시간 단축, 교차 영역 데이터베이스 마이그레이션 및 낮은 RPO/RTO 재해 복구에 탁월한 도구입니다. Amazon RDS는 한 번의 클릭으로 복제본 작성을 관리하지만 복제 문제가 발생하지 않도록 워크로드 및 인스턴스 구성을 숙지해야 합니다. PostgreSQL용Amazon RDS의 읽기 복제본 제한, 모니터링 및 문제 해결에 대한 더 많은 정보를 알고 싶으시다면 ‘Working with PostgreSQL Read Replicas in Amazon RDS’ 페이지를 확인해 주시기 바랍니다.
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.