RDS 및 Aurora Cluster 의 Replica Lag 와 instance type 의 연관성

해당 페이지에서는 RDS 및 Aurora Cluster 에서 각각 Replica, Reader 를 사용시 발생 할 수 있는 Replica Lag 및

instance type 의 연관성에 대하여 다룬다.

 

또한 이 게시글은 AWS re:post 의 내용과 연관되어 있다.

 

[1] https://repost.aws/ko/knowledge-center/aurora-mysql-read-replicas

 

 

RDS, Aurora Cluster 에서의 데이터 동기화 방식

 

Replica Lag 는 단어 그대로 replication 이 얼마나 지연 되었는지 알 수 있는 Cloudwatch 내 지표다.

 

RDS, Aurora Cluster 에서는 우리가 온프레미스에서 일반적으로 생각하는 replication 지연을 기본으로 추가적인 내용들을 확인 후 이를 지표화 한다.

 

RDS 는 replica 를 구성 시, 우리가 일반적으로 생각하는 replication 구조를 기본으로 하여 추가적인 내부 logic 을 합쳐 처리되고 Aurora Cluster 는 일반적인 replication 구조를 사용하지 않지만, 내부적인 데이터 동기화 과정이 있기에 이를 기준으로 지표를 만든다.

 

 

Instance type 과의 연관성

 

여기까지만 보면, instance type 과의 연관성을 크게 생각하지 못 할 수 있다. 그러나 이 두 서비스는 온프레미스 서버에 단순히 DB 를 설치해서 사용하는 단순 개체가 아니라 여러 요소들이 결합된 복합체이다.

 

그러다 보니 해당 복합체들의 instance spec 차이가 클수록 lag 의 발생 빈도 및 강도가 높아지게 되어 있다.

 

그래서 우리가 온프레미스에서 DB 를 구성할 때, 읽기 용도로만 사용하는 reader 는 writer 보다 사용빈도가 적으니 writer 보다 spec 을 적게 잡는 경우를 RDS, Aurora Cluster 의 instance 에도 그대로 적용하면 CW 의 Replica Lag 가 필연적으로 발생하게 되어 있다.

 

그렇기에 RDS Replica, Aurora Cluster reader 추가 시 이를 염두해두고 master, writer 인스턴스의 동일한 spec 으로 맞추는 걸 권장한다.