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

최종 업데이트 날짜: 2021년 2월 2일

프로덕션 Amazon Aurora DB 클러스터를 실행 중입니다. “읽기 전용 복제본이 마스터보다 너무 많이 지연되었습니다. MySQL을 다시 시작합니다” 또는 “읽기 전용 복제본이 마스터보다 너무 많이 지연되었습니다. postgres를 다시 시작합니다"라는 오류 메시지가 표시되면서 리더 노드가 다시 시작되었습니다. 리더가 다시 시작된 이유는 무엇인가요?

간략한 설명

AuroraReplicaLag는 기본 Aurora DB 인스턴스에서 Aurora DB 클러스터의 리더 노드로 업데이트를 복제할 때 지연 시간을 밀리초 단위로 측정합니다. Aurora 복제본은 기본 DB 인스턴스와 동일한 스토리지 볼륨에 연결되며 읽기 작업만 지원합니다. Amazon CloudWatch의 AuroraReplicaLag 지표를 사용하여 기본 노드와 리더 노드 간의 지연 시간을 측정할 수 있습니다.

Aurora PostgreSQL DB 클러스터의 경우 AuroraReplicaLag 지표는 기본 DB 인스턴스의 페이지 캐시와 비교한 Aurora Replica의 페이지 캐시에 대한 지연 시간을 나타냅니다. 즉, 클러스터 볼륨에 데이터가 쓰여진 후, 라이터 노드와 리더 노드 모두 거의 실시간으로 데이터에 액세스할 수 있습니다.

읽기 노드 간에 변경 사항이 전파되도록 하려면 읽기 일관성을 위해 캐싱된 데이터를 무효화해야 합니다. 경우에 따라 리더 노드 간에 변경 사항을 전파할 때 지연이 발생할 수 있습니다. 이러한 지연은 CloudWatch의 AuroraReplicaLag 지표 증가로 나타나며, 이는 결국 재시작을 유발합니다.

Aurora MySQL의 경우 INFORMATION_SCHEMA.REPLICA_HOST_STATUS 테이블을 통해 AuroraReplicaLag와 관련한 메타데이터를 거의 실시간으로 측정할 수 있습니다.

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  |
+---------------------+--------+-------------------+
| primary-instance    | writer |                 0 |
| reader-node-02      | reader | 5.150000095367432 |
| reader-node-03      | reader | 5.033999919891357 |
+---------------------+--------+-------------------+

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
-------------+--------+------------------
read-node-01 | Reader | 19.641
read-node-02 | Reader | 19.752
primary-node | Writer |
(3 rows)

해결 방법

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

리더 노드의 DB 인스턴스 클래스 구성이 라이터 DB 인스턴스보다 빈약한 경우 변경 데이터의 볼륨이 너무 커서 리더가 캐시의 데이터를 무효화하고 따라잡을 수 없게 됩니다. 이 시나리오에서는 Aurora 클러스터의 모든 DB 인스턴스 사양이 동일한 것이 좋습니다.

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

여러 세션이 동시에 실행 중일 때 리더 노드에서 지연이 발생할 수 있습니다. 사용 가능한 리소스가 부족하기 때문에 프라이머리에서 Aurora 복제본으로 필요한 변경 사항을 적용하는 속도가 느려질 수 있습니다. CPUUtilization, DBConnections, NetworkReceiveThroughput, ActiveTransactions 등의 지표에서 이러한 지연을 확인할 수 있습니다.

Aurora PostgreSQL의 경우 ActiveTransactions 대신 ReadIOPS 지표를 사용합니다. Enhanced Monitoring을 최소 5/1초 단위로 활성화하여 리더 노드의 사용률을 파악할 수 있습니다. 성능 개선 도우미를 사용하여 워크로드를 시각화할 수도 있습니다.

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

이미 쓰기 작업이 많은 프로덕션 클러스터에서 갑자기 쓰기 작업이 급증하면 라이터 DB 인스턴스에 오버로드가 발생할 수 있습니다. 이러한 급증에 따른 처리 부담으로 인해 리더 노드에서 지연이 발생할 수 있습니다. DMLThroughput, DDLThroughputQueries 지표의 급증을 보여주는 Amazon 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 스토리지 계층 간에 일시적인 네트워킹 통신 장애가 발생할 수 있습니다. 짧은 순간의 네트워킹 중단으로 인해 리더 노드가 지연되거나 다시 시작될 수 있습니다. 대량의 변경 데이터 또는 짧은 순간의 AZ 간 패킷 손실로 인한 네트워크 포화로 인해 Aurora Replica가 지연될 수 있습니다. 이 문제를 방지하려면 DB 인스턴스의 크기와 네트워킹 용량을 고려하는 것이 좋습니다.

중요: 버전 1.17.4부터 Aurora MySQL 1.x에는 다음과 같은 몇 가지 주목할 만한 기능이 있습니다.

  • aurora_enable_replica_log_compression은 복제 페이로드를 압축하여 프라이머리와 Aurora 복제본 간의 네트워크 대역폭 사용률을 개선하는 클러스터 파라미터입니다. 이는 네트워크 포화 상태가 명확하게 나타날 때 유용합니다.

  • aurora_enable_zdr은 열려 있는 연결을 유지하고 Aurora Replica를 다시 시작할 때 연결을 유지하는 데 활용할 수 있는 클러스터 파라미터입니다.

  • aurora_enable_staggered_replica_restore는 Aurora 복제본이 시차가 있는 재시작 일정에 따라 클러스터 가용성을 높일 수 있는 클러스터 파라미터입니다.