[Aurora] 인스턴스 스펙 무중단 Scale-Up

AWS Aurora 인스턴스 스펙 변경 시 장애 발생에 유연하게 대처할 수 있도록 순단 테스트를 진행하였습니다.

 

테스트 환경

• 인스턴스 : Mulit AZ 구성(1 라이터, 1 리더)
• 스펙 : db.t3.small => db.t3.medium
• 1s 마다 1 connection 실행

 

---

 

테스트 진행

전체 테스트 시나리오는 아래의 순서로 진행됩니다. Multi-AZ 구성 시 아래의 방법을 통해 진행할 경우 전체 다운타임을 최소화할 수 있습니다.

 

1. 리더 인스턴스 스펙 변경
2. Failover를 통한 리더, 라이터 인스턴스 Switch
3. Switch된 나머지 인스턴스 스펙 변경

 

우선 JMeter를 통해 리더 엔드포인트(-ro-)에 연결한 후 리더와 라이터가 Switch 되는 것을 확인하기 위해
1s 마다 show variables like '%innodb_read_only%'; 쿼리를 호출합니다.

이후 AWS 리더 인스턴스부터 스펙을 변경합니다. 우선 인스턴스 변경에는 총 7분 40초가 소요됐습니다. 다만 인스턴스 변경 도중 1초 정도의 짧은 순단이 발생하였습니다.

 

 

기존 호출 시에는 innodb_read_only 플래그 값이 on이었는데 이 에러 시점을 기준으로 OFF값으로 변경되었습니다.

에러전

에러후

 

왜 갑자기 인스턴스의 read_only 값이 변경된 것일까?

 

If a failover occurs, you can use the writer endpoint to reconnect to the newly promoted or created primary DB instance, or use the reader endpoint to reconnect to one of the Aurora Replicas in the DB cluster. During a failover, the reader endpoint might direct connections to the new primary DB instance of a DB cluster for a short time after an Aurora Replica is promoted to the new primary DB instance

 

Aurora에서는 HA를 보장하기 위해 DB인스턴스가 중단되었을 경우 클러스터 엔드포인트를 사용하게 되면
Available 한 상태에 있는 다른 인스턴스로 쿼리를 전달하여 처리하게 되는데 테스트 환경인 라이터 1, 리더 1의 구성에서 일시적으로 라이터 인스턴스가 리더의 작업을 처리하게 됩니다. (다른 리더 인스턴스가 있다면 리더 우선 전달됨) 인스턴스 스펙업 완료 후 다시 쿼리를 호출하면 리더 인스턴스가 읽기 작업을 처리하 면서기 존의 ON플래그 값이 표시됩니다.

에러전

 

Cloud Watch 로그에서도 라이터 인스턴스에 커넥션이 발생한 것을 확인할 수 있습니다.

 

(노란색 : 리더, 파란색 : 라이터)

 

이후 Failover를 통해 리더와 라이터를 Switch 합니다. Failover의 경우 총 65초 정도가 소요되었습니다. 일반적으로 Failover의 경우 60~120초 정도안에 처리된다 하며 Failover의 완료 시점은 Failover중의 트랜잭션이 복제본에 반영이 되었을 때로 트랜잭션량에 따라 시간이 더 소요될 수 있다고 합니다.

 

Failover의 경우 리더 인스턴스로 진행하였으며 약 5초의 순단이 발생하였습니다. 이 경우에도 위와 동일하게 Failover 후 라이터 인스턴스가 리더의 작업을 처리한 것을 확인할 수 있습니다.

 

 

이후 동일하게 스위치 된 리더 인스턴스로 동일하게 스펙업을 진행해줍니다.

 

 

리더 1 라이터 1 두 개의 인스턴스 스펙업에 총 소요된 시간

• 인스턴스 스펙업 각각 : 7분 40초, 8분 15초
• Failover 스위칭 : 1분 5초
• 총 : 17분
• 순단 시간 : 7초

 

총 17분의 시간이 소요되었으며 실제 서비스에 발생한 순단 시간은 7초가 소요되었습니다. AWS에서 Zero 다운타임의 무중단 서비스 스펙업은 불가하다고 하며 위의 방법으로 가용성을 보장한 최소한의 중단시간으로 처리가 가능합니다.

 

추가로 읽기 작업이 많은 경우 리더 인스턴스의 중단은 다른 인스턴스에 부하를 줄 수 있기에 신규로 인스턴스를 추가한 후 작업하는 것이 좋다고 합니다.