Amazon Aurora 읽기 전용 복제본이 지연되고 다시 시작된 이유는 무엇인가요?

간략한 설명

AuroraReplicaLag는 라이터 Aurora DB 인스턴스에서 Aurora DB 클러스터의 리더 인스턴스로 변경 사항을 복제할 때 지연 시간을 밀리초 단위로 측정합니다. Aurora 복제본은 라이터 인스턴스와 동일한 스토리지 볼륨에 연결됩니다. 라이터 인스턴스와 리더 인스턴스 간의 지연 시간을 측정하려면 Amazon CloudWatch의 AuroraReplicaLag 지표를 사용합니다.

Aurora DB 클러스터의 경우 AuroraReplicaLag 지표는 라이터 DB 인스턴스의 데이터 캐시와 비교한 Aurora 복제본의 데이터 캐시에 대한 지연 시간을 나타냅니다. 데이터 캐시는 버퍼 풀 또는 페이지 캐시를 포함합니다. 변경 사항은 공유 스토리지 볼륨에 동기적으로 기록됩니다. 그러나 변경 사항은 리더 인스턴스에 비동기적으로 복제되며, 변경 내용과 관련하여 메모리에 캐시된 모든 데이터는 읽기 일관성을 위해 무효화됩니다. 경우에 따라 리더 인스턴스 간에 변경 사항을 전파할 때 지연이 발생할 수 있습니다. 이러한 지연은 CloudWatch의 AuroraReplicaLag 지표 증가로 나타나며, 이로 인해 결국 재시작할 수도 있습니다.

AuroraReplicaLag에 대한 메타데이터를 거의 실시간으로 측정할 수 있습니다.

Amazon Aurora MySQL 호환 버전의 경우 INFORMATION_SCHEMA.REPLICA_HOST_STATUS 테이블에서 선택합니다.

mysql> select server_id AS Instance_Identifier, if(session_id = 'MASTER_SESSION_ID','writer', 'reader') as Role, 
replica_lag_in_milliseconds as AuroraReplicaLag from information_schema.replica_host_status;

+---------------------+--------+-------------------+
| Instance_Identifier | Role   | AuroraReplicaLag  |
+---------------------+--------+-------------------+
| myamscluster-aza-1  | writer |                 0 |
| myamscluster-azb-1  | reader | 5.150000095367432 |
| myamscluster-aza-2  | reader | 5.033999919891357 |
+---------------------+--------+-------------------+

Amazon Aurora PostgreSQL 호환 버전의 경우 aurora_replica_status() 함수를 호출하고 결과를 필터링합니다.

postgres=> select server_id, case when session_id= 'MASTER_SESSION_ID' then 'Writer' else 'Reader' end AS Role, 
replica_lag_in_msec as AuroraReplicaLag from aurora_replica_status();

server_id          | role   | aurorareplicalag
-------------------+--------+------------------
myapgcluster-aza-1 | Reader | 19.641
myapgcluster-azb-1 | Reader | 19.752
myapgcluster-aza-2 | Writer |
(3 rows)

참고: 이 문서에서 제공하는 솔루션은 글로벌 데이터베이스 보조 클러스터가 아닌 Amazon Aurora 단일 리전 및 글로벌 데이터베이스 기본 클러스터에 적용됩니다.

해결 방법

클러스터의 모든 인스턴스가 동일한 사양인지 확인

리더 인스턴스의 DB 인스턴스 클래스 구성이 라이터 DB 인스턴스보다 약한 경우 변경 볼륨이 너무 클 수 있습니다. 이 경우, 리더 인스턴스는 캐시에서 무효화된 다음 이를 따라잡을 수 없습니다. 따라서 Aurora 클러스터의 모든 DB 인스턴스 사양이 동일한 것이 가장 좋습니다.

지표 및 Enhanced Monitoring을 사용하여 세션 모니터링

여러 세션이 동시에 실행 중일 때 리더 인스턴스에서 지연이 발생할 수 있습니다. 사용 가능한 리소스가 부족하기 때문에 라이터에서 Aurora 복제본으로 필요한 변경 사항을 적용하는 속도가 느려질 수 있습니다. CPUUtilization, DBConnections, NetworkReceiveThroughput 등의 지표에서 이러한 지연을 확인할 수 있습니다. 리더의 리소스 사용량을 파악하기 위해 세분화된 1초 또는 5초 단위로 Enhanced Monitoring을 활성화할 수도 있습니다. 그리고 성능 개선 도우미를 사용하여 워크로드를 시각화할 수 있습니다. 또한 Aurora PostgreSQL과 호환되는 경우에만 ReadIOPS 지표를 사용합니다.

CloudWatch를 사용하여 쓰기 작업 시각화

이미 쓰기 작업이 많은 프로덕션 클러스터에서 갑자기 쓰기 작업이 급증하면 라이터 DB 인스턴스에 오버로드가 발생할 수 있습니다. 급증에 의한 추가적인 부담으로 인해 하나 이상의 리더 인스턴스가 지연될 수 있습니다. DMLThroughput, DDLThroughput 및 Queries 지표의 급증을 보여주는 CloudWatch에서 이를 확인할 수 있습니다.

Aurora PostgreSQL의 경우 WriteThroughput 지표에서 이를 확인할 수 있습니다.

점점 증가하는 HLL(History List Length) 조사(Aurora MySQL 호환)

MySQL InnoDB 엔진은 기본적으로 다중 버전 동시성 제어(MVCC)를 적용합니다. 즉, 트랜잭션 기간 동안 영향을 받는 모든 행에 발생한 모든 변경 사항을 추적해야 합니다. 장기 실행 트랜잭션이 완료된 후 스레드 제거 활동이 급증하기 시작합니다. 장기 실행 트랜잭션을 통해 생성된 백로그의 볼륨으로 인해 발생하는 갑작스러운 제거 작업이 원인이 되어 Aurora 복제본이 지연될 수 있습니다.

버전 1.19.2, 2.06 이상에서는 Aurora MySQL에 RollbackSegmentHistoryListLength 지표가 포함됩니다. CloudWatch에서 이 지표를 사용하여 이러한 제거를 확인할 수 있습니다. 또한 SHOW ENGINE INNODB STATUS의 결과에서 확인하거나 다음과 같이 정보 스키마를 쿼리하여 확인할 수도 있습니다.

mysql> select NAME AS RollbackSegmentHistoryListLength, 
COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

+----------------------------------+-------+
| RollbackSegmentHistoryListLength | COUNT |
+----------------------------------+-------+
| trx_rseg_history_len             |   358 |
+----------------------------------+-------+
1 row in set (0.00 sec)

이 지표가 과도하게 높은 수치에 도달하지 않도록 CloudWatch 경보를 설정합니다. 관계형 데이터베이스에서는 장기 실행 트랜잭션을 방지하는 것이 좋습니다.

짧은 네트워크 중단 방지

드물지만 라이터 인스턴스와 리더 인스턴스 간에 또는 인스턴스와 Aurora 스토리지 계층 간에 일시적인 네트워킹 통신 장애가 발생할 수 있습니다. 짧은 순간의 네트워킹 중단으로 인해 리더 인스턴스가 지연되거나 다시 시작될 수 있습니다. 또한 Aurora 복제본은 대량의 변경으로 인해 인스턴스의 네트워크 대역폭이 포화되어 지연될 수 있습니다. 이 문제를 방지하려면 DB 인스턴스의 크기와 그에 따른 네트워킹 용량을 고려하는 것이 좋습니다.

---

관련 정보

DB 클러스터에 Aurora 복제본 추가

Amazon Aurora MySQL을 사용한 단일 마스터 복제

Amazon Aurora 클러스터에서 지표 모니터링