AWS Aurora - Aurora의 Storage 특징

Aurora와 RDS MySQL의 차이를 한번 기입했었는데요. 여기에서는 좀더 Aurora의 내부적인 아키텍쳐와 그로인한 문제점을 써보려고 합니다.

이전에 썼던것처럼 Aurora의 가장 큰 특징은 스토리지입니다. 단일 스토리지가 아니라 Shared Storage를 사용합니다.

https://aws.amazon.com/ko/blogs/korea/amazon-aurora-under-the-hood-quorum-and-correlated-failure/

이 그림은 AWS 공식 Blog의 https://aws.amazon.com/ko/blogs/korea/amazon-aurora-under-the-hood-quorum-and-correlated-failure/ 에서 가져왔습니다.

Aurora 스토리지 내부 아키텍쳐를 이해하기 위해서는 쿼럼(Quorum)방식을 이해해야합니다. 여기서 쿼럼이란 무엇일까요?

제가 처음 Quorum이라는 용어를 들은 것은 Cassandra에서 였습니다. Cassandra는 세션별로 데이터 저장, 또는 조회시 몇개의 노드에 저장할지, 조회할지 선택할 수 있습니다.

물론 Global 하게 서버내에서 지정할수도 있습니다. 일반적으로 노드가 여러개 필요한 NoSQL의 경우 많이 나오는 용어입니다. 아래에서 좀 더 자세히 보겠습니다.

근데 NoSQL이 아닌 RDBMS에서는 왜 이런 Quorum이 필요할까요? 말씀드린것처럼 Aurora는 내부적인 가용성을 확보하기위해 총 3개의 AZ, 각각의 AZ별로 2개의 스토리지 영역을 두고 있습니다. 하나의 AZ가 무너져도 다른 AZ에서는 서비스가 가능하고 데이터 유실이 없게끔 해줍니다. 별도의 설정 없이 가능합니다.

6개의 Storage 영역이 있다면 쿼럼은 어떻게 설정되어야할까요? Aurora의 경우 6개라는 Storage 영역이 Static하게 설정되어 있기 때문에 Write는 4/6, Read는 3/6 Quorum을 사용합니다. 즉 write가 6개 중 4개의 storage에 성공해야 완료이고 read는 6개중 3개의 storage에서 성공해야 완료라는겁니다.

저는 아래와 같은 궁금증이 생겼고 AWS 측에 문의한 결과 답변을 얻었습니다.

1. write를 시도하는 storage 선정은 어떻게 하는가?

- write가 시도되는 storage는 응답이 가장 빠르게 오는 storage 입니다. Aurora 내부적으로 Storage의 latency를 측정하고 있습니다. 물론 Instance와 같은 AZ에 있는 Storage 영역이 가장 빠르게 응답할 것이고, 거기에 데이터가 쌓이겠죠. 그리고 또 다른 AZ의 Storage 영역에 데이터가 쌓일것입니다.

2. write를 시도할때 storage에 문제가 생긴다면  4개의 쓰기가 모두 성공할때까지 write는 계속 대기하는가?

- 이 부분은 조금 다르게 생각해야합니다. Instance 관점과 Storage 관점이 다릅니다. 이게 무슨소리지?? 하는 분들이 있을텐데요. 아래의 그림을 참조해주시기 바랍니다.

Primary Instance(Master)에서 write가 발생하면 Incoming Queue라는 것을 이용해서 비동기방식으로 처리하게됩니다. 왠 비동기? 하고 생각하실수도 있습니다.

저도 맨처음에 의아했는데 Aurora가 MySQL보다 왜 더 빠르게 Insert가 가능하지? 라고 생각했던것을 여기서 해소시켜줍니다.

모든 데이터 저장 스탭이 비동기로 이루어지기 떄문에 Insert가 빠르게 느껴지지만 실제로 스토리지가 움직이는건 비동기이기 때문에 Disk에 어디까지 저장됐는지는 Aurora 스토리지들만 알고 있습니다. 실제로 Incoming Queue가 밀리면 ACK가 늦을수도 있고 장애났을때 복구되는 타임도 늘어날 수 있다는 것을 알아야합니다.

제가 질문했던 4개의 쓰기가 모두 성공할때까지 대기하는가?에 대한 대답은 여기서 해소됩니다. incoming queue에 들어가고 update queue에 쌓이면 바로 ack하기 때문에 instance에서는 하나의 storage에 반영되면 바로 응답을 받기때문에 신경안쓰고 완료처리할 수 있습니다. 4개에 모두 쌓이는것을 대기하지 않는것이죠.

위 그림에 대해서는 나중에 다시 설명하도록 하겠습니다.

3. write가 4/6 quorum을 가지면 나머지 2개에는 데이터가 쌓이지 않는것인가?

- quorum이라는 것은 요청에 대한 응답을 보내기 위한 최소값입니다. 4/6 quorum이 충족되면 Storage는 VCL이라는 값을 가집니다. VCL은 Volume Completed LSN으로 볼륨에 쓰기가 완료됐다는 VCL입니다. 관련된 용어로는 CPL(Consistency Point LSN)이 존재합니다. CPL은 다른말로 최근에 Commit된 레코드입니다. 일관성이 보장된 마지막 포인트가 CPL이라는 것이기 때문에 장애시에는 최종 CPL이후의 값은 모두 지우고 복구가 일어납니다.

VCL이 일어난 다음에는 storage의 background 작업의 일환으로 나머지 2개의 스토리지에도 카피가 일어납니다. 즉 하나의 write에 대한 quorum은 6개의 스토리지중 4개이지만 저장은 6개 모두 일어나는 것입니다. 이해하는게 조금 까다롭습니다.

이처럼 Aurora의 경우 Storage 내부에 비동기방식과 Quorum 방식이 같이 존재하기 때문에 관리가 어렵지만 운영하는 입장에서 보면 내부적으로 무슨일이 일어나는이 알 수 없습니다. 이후 포스팅에서는 이런 Storage 내부 동작으로 인해 발생하는 문제점들에 대해 말하도록 하겠습니다. 실제 장애케이스라고 볼 수 있겠네요.