합의 없이 커밋하는 Aurora (Avoiding Distributed Consensus, SIGMOD 2018)

출처

참고 이 페이지는 원문 번역이 아니라 한국어 해설이에요. 정확한 표현과 수치는 원문을 확인하세요.

한눈에

• 문제: 분산 저장 시스템은 보통 커밋에는 2단계 커밋, 복제에는 Paxos, 멤버십 변경에는 또 다른 합의를 씁니다. 이런 합의는 왕복이 많아 지연이 길고 흔들립니다.
• 제안: 쓰기 인스턴스가 하나뿐이라는 점을 활용합니다. 로그 순번(LSN) 을 한 곳에서 단조 증가하게 배정하고, 각 저장 세그먼트가 어디까지 받았는지만 추적하면, 정상 경로에서는 합의 없이도 일관된 상태를 알 수 있습니다.
• 멤버십 변경: 고장 난 세그먼트를 교체할 때도 "두 쿼럼을 동시에 만족" 하는 중간 단계를 두어, 되돌릴 수 있고 멈추지 않는 방식으로 바꿉니다.
• 비용 절감: 6개 사본 중 3개만 데이터 페이지를 갖고 나머지 3개는 로그만 갖는 구성으로, 6개 사본의 내구성을 3개 사본에 가까운 비용으로 얻습니다.
• 지금의 의미: 2017년 Aurora 논문 이 "무엇을" 했는지 설명했다면, 이 논문은 "왜 그것이 안전한지" 를 설명합니다.

왜 나왔나

2017년 논문은 Aurora 가 redo 로그만 저장 계층으로 보내고 6개 사본에 4개 쿼럼으로 쓴다는 구조를 소개했습니다. 하지만 쿼럼 시스템에는 까다로운 질문이 남습니다. 쓰기가 일부 세그먼트에만 도착한 채로 인스턴스가 죽으면 어디까지가 유효한가? 읽을 때마다 3개 세그먼트를 읽어야 하나? 세그먼트 하나가 죽어 새것으로 바꾸는 동안 쿼럼은 어떻게 정의되나?

이 논문은 수십만 개의 RDS 인스턴스를 운영한 경험을 바탕으로, 이 질문들에 합의 프로토콜 대신 "단조 증가하는 상태" 로 답합니다. 논문 범위는 쓰기 인스턴스 하나와 읽기 복제본으로 이루어진 구성입니다.

핵심 아이디어

효율적인 쓰기 (2절)

쿼럼의 기본 규칙은 읽기 집합과 쓰기 집합이 겹쳐야 하고, 쓰기 집합이 전체의 과반이어야 한다는 것입니다. Aurora 는 세그먼트(최대 10GB) 6개로 보호 그룹을 만들고 3개 AZ 에 2개씩 둡니다. 그림 1 은 왜 6개가 필요한지 보여줍니다. 3개 중 2개 쿼럼은 AZ 하나를 잃으면 버틸 여유가 없지만, 6개 중 4개 쓰기와 3개 읽기 쿼럼은 AZ 하나와 노드 하나를 더 잃어도 데이터를 지킵니다.

핵심 불변식은 LSN 이 볼륨 전체에서 하나의 순서로, 쓰기 인스턴스가 직접 배정한다는 것입니다. 각 로그 레코드에는 볼륨, 세그먼트, 블록 각각의 직전 LSN 을 가리키는 링크가 붙어 있어, 세그먼트는 자신이 어디서 빠진 레코드가 있는지 스스로 압니다.

네트워크 묶음 전송도 다르게 합니다. 버퍼가 다 찰 때까지 기다리는 대신, 첫 레코드가 들어오면 바로 전송을 예약하고 실제로 보내질 때까지 버퍼를 채웁니다. 기다림 때문에 생기는 지연과 흔들림을 줄이는 방법입니다.

일관성 지점과 커밋

그림 3 은 지점들이 어떻게 계산되는지 보여줍니다.

• SCL(Segment Complete LSN): 세그먼트가 빈틈 없이 받은 가장 높은 LSN
• PGCL(Protection Group Complete LSN): 보호 그룹 6개 중 4개의 SCL 이 넘은 지점
• VCL(Volume Complete LSN): 그 아래의 모든 레코드가 쿼럼을 만족한 지점

그림 3 의 예시에서는 PG1 의 PGCL 이 103, PG2 의 PGCL 이 104 일 때 VCL 이 104 가 됩니다. 커밋 레코드가 VCL 아래로 들어오면 그 트랜잭션은 확정입니다. 작업 스레드는 커밋을 큐에 넣고 바로 다른 일을 하며, 전용 스레드가 VCL 이 앞으로 나아갈 때 클라이언트에 응답을 보냅니다. 별도의 플러시도 합의도 필요 없습니다.

복구와 펜싱

인스턴스가 죽으면 새 인스턴스는 각 보호 그룹에서 읽기 쿼럼만큼 세그먼트의 SCL 을 모아 PGCL 과 VCL 을 다시 계산하고(그림 4), 그 위의 로그를 잘라냅니다. 세그먼트가 필요할 때 페이지를 스스로 만들기 때문에 redo 재생 단계도 없습니다.

뒤늦게 도착하는 옛 인스턴스의 쓰기는 "볼륨 에포크" 로 막습니다. 복구 시 에포크를 올려 각 보호 그룹의 쓰기 쿼럼에 기록하면, 저장 노드는 낡은 에포크의 요청을 거절합니다. 논문은 임대가 끝나길 기다리지 않고 "문의 자물쇠를 바꾸는 것" 에 비유합니다.

효율적인 읽기 (3절)

쿼럼 읽기는 최소 3번, 실제로는 5번 정도의 I/O 가 필요해 비쌉니다. Aurora 의 인스턴스는 어떤 세그먼트가 블록의 최신 확정 버전을 갖는지 알고 있으므로 그중 하나에서만 읽습니다. 보통 가장 빠른 세그먼트를 고르고, 가끔 다른 세그먼트도 시험해 지연을 갱신하며, 느린 읽기는 다른 세그먼트에 한 번 더 보내 꼬리 지연을 줄입니다.

읽기 복제본은 같은 저장 볼륨을 붙여 쓰고, 쓰기 인스턴스의 redo 스트림 중 자기 캐시에 있는 블록에 해당하는 것만 적용합니다. B-트리 분할 같은 구조 변경은 미니 트랜잭션 단위로 원자적으로 보이도록 VDL 까지만 적용합니다. 저장 계층은 모든 복제본의 읽기 지점 가운데 가장 낮은 값(PGMRPL) 보다 오래된 버전만 정리합니다.

멤버십 변경 (4절)

64TB 볼륨에는 세그먼트가 38,400 개 있으니 고장은 일상입니다. 세그먼트 F 가 의심스러워 G 로 바꾸고 싶을 때, ABCDEF 에서 ABCDEG 로 단번에 넘어가지 않습니다(그림 5). 먼저 에포크를 올려 두 구성을 동시에 인정합니다. 이때 쓰기는 ABCDEF 의 4/6 과 ABCDEG 의 4/6 을 모두 만족해야 하고, 읽기는 둘 중 하나의 3/6 이면 됩니다. G 가 다 따라잡고 F 가 확실히 죽었다고 판단되면 다시 에포크를 올려 ABCDEG 만 남깁니다. F 가 살아나면 반대 방향으로 되돌릴 수 있습니다. 중간에 E 까지 고장 나도 같은 규칙을 겹쳐 적용하면 되고, ABCD 네 개에만 써도 모든 조합의 쿼럼이 만족됩니다.

비용 줄이기: 전체 세그먼트와 꼬리 세그먼트

보호 그룹의 6개 세그먼트 중 3개는 로그와 페이지를 모두 갖는 "전체 세그먼트", 3개는 로그만 갖는 "꼬리 세그먼트" 로 만듭니다. 쓰기 쿼럼은 6개 중 4개 또는 전체 세그먼트 3개 모두, 읽기 쿼럼은 6개 중 3개 또는 전체 세그먼트 중 1개입니다. 이렇게 하면 AZ+1 장애 내성을 유지하면서 저장 비용은 6벌이 아니라 3벌에 가까워집니다.

실험과 결과

이 논문은 성능 벤치마크를 싣지 않은 설계 논문입니다. 숫자로 제시되는 것은 쿼럼 크기(4/6, 3/6), 세그먼트 크기(10GB), 64TB 볼륨의 세그먼트 수(38,400), 그림 3 의 LSN 예시 정도입니다. 성능 수치는 2017년 논문 을 함께 보면 됩니다.

결론에서 저자들은 정상 처리 중에는 "국지적인 일관성의 오아시스" 가 계속 만들어지므로, 합의는 복구 순간에만 필요하다고 정리합니다.

지금 AWS 에서는

• Amazon Aurora (MySQL 호환판, PostgreSQL 호환판) 의 저장 계층은 지금도 3개 AZ 에 걸친 6개 사본과 쓰기 4개, 읽기 3개 쿼럼으로 설명됩니다.
• 공유 저장 볼륨 위의 Aurora 복제본이 쓰기 인스턴스로 승격될 때 커밋된 데이터를 잃지 않는 이유가 3.2절의 설명입니다.
• 논문은 단일 쓰기 구성만 다루며 다중 쓰기로의 확장은 가능성으로만 언급합니다. 이후 AWS 가 내놓은 분산 SQL 서비스(Aurora DSQL) 는 별도의 설계로, 이 논문과 직접 연결하지 않습니다.

함께 읽기

• RDS 와 Aurora, Aurora DSQL: 이 사이트의 기능 문서
• Aurora 2017 논문 해설
• Aurora Serverless 논문 해설
• Physalia 논문 해설: 같은 시기 EBS 가 택한 "작은 합의 그룹을 수백만 개" 두는 접근