Amazon Aurora 읽기 전용 복제본이 지연되고 다시 시작된 이유는 무엇입니까?

최종 업데이트 날짜: 2020년 6월 22일

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

간략한 설명

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

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

읽기 노드 간에 변경 사항이 전파되도록 하려면 읽기 일관성을 위해 캐싱된 데이터를 무효화해야 합니다. 경우에 따라 리더 노드 간에 변경 사항을 전파할 때 지연이 발생할 수 있습니다. 지연 발생 여부는 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,
cur_replay_latency_in_usec*1000/60/60/60 as AuroraReplicaLag 
from aurora_replica_status();

  server_id   |  role  | aurorareplicalag 
--------------+--------+---------------------
 read-node-01 | Reader |                 71
 read-node-02 | Reader |                 79
 primary-node | Writer |                    

해결 방법

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

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

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

여러 세션이 동시에 실행 중일 때 리더 노드에서 지연이 발생할 수 있습니다. 사용 가능한 리소스가 부족하기 때문에 마스터에서 Aurora 복제본으로 필요한 변경 사항을 적용하는 속도가 느려질 수 있습니다. CPUUtilization, DBConnections, NetworkReceiveThroughputActiveTransactions 같은 지표를 사용하여 이를 시각화할 수 있습니다.

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

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

이미 쓰기 작업이 많은 프로덕션 클러스터에서 갑자기 쓰기 작업이 급증하면 라이터 DB 인스턴스에 오버로드가 발생할 수 있습니다. 이러한 급증에 따른 처리 부담으로 인해 리더 노드에서 지연이 발생할 수 있습니다. Amazon CloudWatch를 통해 DMLThroughput, DDLThroughputQueries 지표가 갑자기 급증하는 현상을 관찰하는 방법으로 이를 시각화할 수 있습니다.

Aurora PostgreSQL의 경우 WriteThroughPut 지표를 사용하여 이를 시각화할 수 있습니다.

갈수록 길어지는 HLL(History List Length) 조사(Aurora MySQL)

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

1.19.22.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_restoreAurora 복제본이 시차가 있는 재시작 일정에 따라 클러스터 가용성을 높일 수 있는 클러스터 파라미터입니다.