Aurora MySQL 3.05.0 스토리지 확장 테스트

Aurora MySQL 3.05.0 스토리지 확장 테스트를 이야기 하기에 앞서 Aurora 스토리지 아키텍처에 대해서 간략하게 이야기 하고 무엇을 위해 테스트를 진행했는지 살펴보도록 하자.

Aurora 스토리지 아키텍처

Aurora의 스토리지 서버들은 로컬 디스크 SSD를 가지고 있는 EC2 서버들이 수백대로 구성되어 있다. 이 EC2 서버들이 1개의 Aurora 서비스에 종속되어 있는 것이 아니라 여러 개의 Aurora 서비스가 1개의 EC2 서버를 사용하고 있는 형태라고 볼 수 있다.

 

 

스토리지 볼륨은 1개 이상의 스트라이프 세트들(Stripe Sets)로 구성되어 있고, 1개의 스트라이프 세트(Stripe Set)는 16개의 보호 그룹들(Protection Groups)로 구성되어 있다. (이후부터는 PG 라고 말함)

Aurora 클러스터를 만들면 그 클러스터에는 총 160GB의 스트라이프 세트 1개가 할당된다. 과금은 PG 단위로 발생하는데, PG의 크기는 10GB이기 때문에 5GB만 사용해도 1개의 프로텍션 그룹의 10GB 만큼의 사용 요금을 내야 한다. 이 의미는 160GB의 스트라이프 세트 1개가 할당된다고 해서 150GB에 대해서 요금을 내지는 않는다는 것이다. 그냥 Free Allocate된 상태이고 고객한테 할당이 되어 있는 것이다. 이렇게 할당하는 이유는 PG를 다 채우게 되면 두 번째 PG를 사용하게 될텐데 이 새로운 PG를 할당받는 사이에 I/O Pending 현상이 발생할 수 있어서 미리 16개의 PG를 할당해놓는 것이다. 즉 Aurora를 만들면 데이터가 없더라도 1개의 스트라이프 세트는 무조건 할당되는 것이다. 만일 할당받은 160GB를 다 사용하게 되면, 이 때도 160GB를 다 사용할 때까지 기다리는 것이 아니라 스트라이프 세트의 PG가 13~16개를 넘어가고 있을 때 다시 160GB를 할당하게 된다. 그래서 160GB에서 170GB로 넘어갈 때도 I/O Pending 없이 서비스를 이어나갈 수 있다.

 

 

여담으로 Aurora 스토리지에서 6개의 데이터 사본이 3개의 가용영역에 걸쳐서 저장되어 있지만 PG는 실제로는 3개의 Full Segment(Page image + Deltas)와, 3개의 Tail Segment(Deltas)로 구성되어 있다. 테일 세그먼트는 로그의 변경값만을 저장하며 가용영역당 하나씩 분배되어 있다. 동일한 리두 로그를 전달받기 때문에 동일한 세그먼트인 것은 맞지만 내부적으로는 이렇게 차이점이 존재한다.

 

Aurora MySQL 3.05.0 스토리지 확장 테스트

Aurora 스토리지의 아키텍처에 대해서 이야기 해보았는데, 위 글에서 빨간색으로 칠해진 문장을 보자.

160GB에서 170GB로 넘어갈 때도 I/O Pending 없이 서비스를 이어나갈 수 있다.

바로 이 부분이 이번 테스트를 진행한 목적이다.

원래는 스토리지가 160GB 배수로 확장되어도 아무런 문제 없이 (내가 경험한 Aurora MySQL 3.04.0 미만에서는) 서비스를 이어나갈 수 있었다. 그런데 최근에 Aurora MySQL 3.04.0에서 스토리지 볼륨을 확장하면 Reader 서버가 크래시 및 재시작되는 버그가 발생했었다. (과거에 Aurora 2버전에서도 발생했었다고 한다.) 아마 3.04.0으로 업그레이드한 고객들은 전부 이 버그를 맞이했을 것이다.

​

이슈가 재기된 이후 Aurora팀에서 Aurora MySQL 3.05.0 버전을 릴리즈 했다. 해당 버그를 픽스했다는 내용과 함께..

그들의 말을 못믿는 것은 아니지만 백문이 불여일견이라고 직접 테스트하며 픽스된 버그를 눈으로 확인해보고자 한다.

 

첫 번째 테스트

사용 중인 스토리지 용량이 800GB에 가까운(160GB * 5) DB 서버를 Aurora 3.05.0으로 스냅샷 복원하여 Aurora MySQL 3.04.0에서 발생했던 버그를 재현해본다.

- 버그 내용: Storage Volume이 160GB 배수로 확장될 때 Reader 서버의 크래시 + 재시작

 

초기 스토리지 볼륨 용량

- Aurora의 스토리지 총 용량: 128TB (140,737,488,328byte)

- 남은 스토리지 가용 공간: 127.23TB (139,900,190,031,872byte)

- 현재 사용 중인 스토리지 용량: 779.79GB (Aurora의 스토리지 총 용량 - 남은 스토리지 가용 공간)/1024/1024/1024

- 160GB 배수의 스토리지 확장까지 남은 용량: 20.20GB (800GB - 현재 사용 중인 스토리지 용량)

 

 

800GB~960GB 스토리지 확장 시점 (160GB*5, 160GB*6)

- Aurora의 스토리지 총 용량: 128TB (140,737,488,355,328byte)

- 남은 스토리지 가용 공간: 127.22TB (139,800,518,746,112byte)

- 현재 사용 중인 스토리지 용량: 798.11GB (Aurora의 스토리지 총 용량 - 남은 스토리지 가용 공간)/1024/1024/1024

- 160GB 배수의 스토리지 확장까지 남은 용량: 1.88GB (800GB - 현재 사용 중인 스토리지 용량)

 

 

사용 중인 스토리지 용량이 800GB를 넘은 그래프

 

 

사용 중인 스토리지 용량이 960GB를 넘은 그래프

 

 

사용 중인 스토리지 용량이 800GB를 넘었으나, Reader 인스턴스의 크래시 및 재시작 이벤트가 발생하지 않음

 

 

두 번째 테스트

사용 중인 스토리지 용량이 800GB에 가까운(160GB * 5) DB 서버를 Aurora 3.04.0으로 스냅샷 복원하여 버그를 재현해본다. 더불어 스토리지 확장 시점 또한 확인해본다.

​

Reader 서버 재시작 시점

- 사용 중인 스토리지 용량: 835.23GB

- 800GB보다 +35.23GB

- 960GB보다 -124.77GB

​

사용 중인 스토리지 용량이 835.23GB일 때 Reader 서버가 재시작됨.

 

 

160GB의 배수인 800GB와 960GB에 해당되지 않으나 800GB에 근접함.

 

 

테스트 결과

금번 스토리지 확장 테스트를 통해 Reader 서버의 크래시 및 재시작 버그는 Aurora MySQL 3.05.0 버전에서 픽스되었음을 확인할 수 있었다. 그런데 두 번째 테스트 결과는 뭔가 속시원하지 않다. 분명 이전 스트라이프 세트에서 13~15 PG를 사용할 때쯤 스토리지가 확장되었을텐데 새로 할당된 스트라이프 세트에서 5~6개 PG(약 50GB)를 사용했을 때쯤 Reader 서버가 재시작되었다. 스토리지가 960GB로 확장되기까지는 124GB나 남은 상황이었기 때문에 분명 800GB 스토리지 확장을 인식한 것이다. 나는 2개의 궁금함이 남는다.

​

- 정말 160GB 배수로 스토리지가 확장되는 것이 맞을까?

- Reader 서버는 스토리지 확장을 인식하는 시점이 언제일까?