예측 가능한 성능의 관리형 NoSQL, DynamoDB (DynamoDB, USENIX ATC 2022)

출처

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

한눈에

• 문제: 수십만 고객이 기계를 함께 쓰는 다중 테넌트 서비스에서, 테이블이 메가바이트에서 수백 테라바이트로 커져도 지연 시간이 흔들리지 않아야 합니다.
• 제안: 파티션마다 Multi-Paxos 로 복제하는 저장 계층, 테이블 단위로 처리량을 관리하는 전역 승인 제어, 트래픽에 맞춰 파티션을 나누고 옮기는 자동화, 그리고 데이터를 계속 검사하는 운영 체계를 갖추었습니다.
• 결과: 2021년 Prime Day 66시간 동안 Amazon 시스템이 DynamoDB 에 보낸 요청은 초당 최대 8,920만 건에 달했고, 한 자릿수 밀리초 응답을 유지했다고 보고합니다.
• 지금의 의미: 이 논문은 "절대 성능보다 예측 가능성" 이라는 DynamoDB 의 설계 철학을 처음으로 자세히 공개한 자료입니다.

왜 나왔나

2007년 Dynamo 논문 이후에도 Amazon 내부 팀들은 Dynamo 를 직접 설치하고 운영해야 했습니다. 단일 테넌트 시스템이라 팀마다 운영 부담을 졌습니다. 반면 관리형 서비스였던 SimpleDB 는 테이블이 10GB 로 제한되고, 모든 속성에 인덱스를 거는 탓에 지연 시간을 예측하기 어려웠습니다. 2012년 출시된 DynamoDB 는 Dynamo 의 확장성과 SimpleDB 의 쉬운 관리를 합치려는 시도였습니다(그림 1 의 연표).

논문은 DynamoDB 의 여섯 가지 기본 성질로 완전 관리형, 다중 테넌트, 한계 없는 확장, 예측 가능한 성능, 높은 가용성(일반 테이블 99.99%, 글로벌 테이블 99.999% SLA), 유연한 사용 방식을 꼽습니다. 이 글 전체는 이 성질들을 지키느라 무엇을 바꿨는지에 대한 기록입니다.

핵심 아이디어

아키텍처 (3절)

테이블은 파티션 키(필요하면 정렬 키와 함께) 로 항목을 식별하고, 파티션 키의 해시로 데이터를 여러 파티션에 나눕니다. 각 파티션은 서로 다른 가용 영역(AZ) 에 놓인 복제본들로 이루어진 복제 그룹이고, 그룹 안에서는 Multi-Paxos 로 리더를 뽑습니다. 리더만 쓰기와 강한 일관성 읽기를 처리하고, 리더 자격은 갱신 가능한 임대(lease) 로 유지합니다. 쓰기는 복제본 과반이 미리 쓰기 로그(WAL) 를 저장하면 확정됩니다. 최종 일관성 읽기는 아무 복제본에서나 읽을 수 있습니다.

복제본에는 두 종류가 있습니다. 저장 복제본은 WAL 과 B-트리를 함께 갖고, 로그 복제본은 최근 WAL 만 들고 Paxos 의 수락자 역할만 합니다. 이 밖에 메타데이터 서비스, 요청 라우터, 저장 노드, 그리고 함대 상태를 살피고 고장 난 복제본을 교체하는 autoadmin 서비스가 있습니다.

프로비저닝에서 온디맨드까지 (4절)

초기 DynamoDB 는 고객이 읽기 용량 단위(RCU) 와 쓰기 용량 단위(WCU) 를 미리 정하고, 이를 파티션 수로 똑같이 나눠 파티션별 한도로 삼았습니다. 논문의 예시에서 파티션 하나가 최대 1,000 WCU 를 처리할 때, 3,200 WCU 테이블은 파티션 4개가 각각 800 WCU 를 받습니다. 그런데 용량을 6,000 WCU 로 올리면 파티션이 8개로 나뉘어 각각 750 WCU 가 되고, 다시 5,000 으로 낮추면 각 파티션의 몫은 더 줄어듭니다(원문에는 675 WCU 로 적혀 있지만, 5,000 을 8로 나누면 625 입니다). 이처럼 분할 후 파티션당 처리량이 희석되고, 키 접근이 한쪽에 몰리면 테이블 전체 용량은 남는데도 요청이 거절되는 문제가 생겼습니다.

이를 풀기 위해 단계적으로 장치를 더했습니다.

• 버스팅: 쓰지 않은 용량을 최대 300초까지 모아 두었다가 순간 부하에 쓰게 했습니다. 노드에 여유가 있을 때만 허용합니다.
• 적응형 용량: 거절당하는 파티션의 한도를 사후에 올려 주었습니다. 쏠린 접근으로 인한 거절의 99.99% 이상을 없앴다고 합니다.
• 전역 승인 제어(GAC): 파티션 단위가 아니라 테이블 단위로 토큰을 관리하는 중앙 서비스입니다. 요청 라우터가 몇 초마다 GAC 에서 토큰을 받아 오고, 파티션 단위 토큰 버킷은 방어선으로 남겨 두었습니다.
• 사용량 기반 분할과 재배치: 처리량이 임계를 넘는 파티션은 실제 키 분포를 보고 분할 지점을 고릅니다. 다만 한 항목에만 몰리는 경우나 순차 접근은 분할해도 효과가 없으므로 분할하지 않습니다.
• 온디맨드 테이블: 이전 최고치의 두 배까지 즉시 받아들이고, 그 이상은 분할로 늘려 갑니다.

내구성과 정확성 (5절)

WAL 은 세 복제본 모두에 저장되고 주기적으로 S3 에 보관됩니다. 아직 보관되지 않은 로그는 보통 수백 MB 수준입니다. 노드가 죽으면 저장 복제본을 다시 만드는 데 몇 분이 걸리지만, 로그 복제본은 최근 로그만 복사하면 되므로 몇 초 만에 추가해 쿼럼을 회복합니다.

로그 항목, 메시지, 로그 파일마다 체크섬을 붙이고, 보관 에이전트가 소유권과 순번 공백을 확인합니다. 또 "스크럽" 프로세스가 살아 있는 복제본끼리, 그리고 보관된 로그로 다시 만든 복제본과 비교해 조용한 데이터 손상을 찾습니다. 복제 프로토콜은 TLA+ 로 명세하고 모델 검사기로 검증했습니다. 백업은 S3 에 저장하며 성능에 영향을 주지 않고, 지난 35일 안의 아무 시점으로 복원(PITR) 할 수 있습니다.

가용성 (6절)

쓰기 가용성에는 건강한 리더와 서로 다른 AZ 에 걸친 3개 중 2개의 쓰기 쿼럼이 필요합니다. 회색 장애(일부만 고장 난 상태) 때문에 멀쩡한 리더를 몰아내는 일을 막기 위해, 리더를 의심한 복제본은 먼저 다른 복제본들에게 리더와 통신이 되는지 물어본 뒤 선거를 시작합니다.

메타데이터 경로에도 교훈이 있습니다. 요청 라우터의 캐시 적중률은 약 99.75% 였지만, 라우터가 새로 뜨면 캐시가 비어 메타데이터 조회가 트래픽의 최대 75% 까지 치솟을 수 있었습니다. 그래서 MemDS 라는 분산 인메모리 저장소를 만들고, 캐시에 적중해도 비동기로 MemDS 에 갱신 요청을 보내게 했습니다. 이렇게 하면 적중률과 관계없이 MemDS 로 가는 트래픽이 일정해집니다. IAM 과 KMS 같은 외부 의존성도 결과를 캐시해 두고 비동기로 새로 고쳐, 의존 서비스가 잠시 멈춰도 버틸 수 있게 했습니다(정적 안정성).

실험과 결과

7절은 버지니아 북부 리전의 실제 DynamoDB 에 YCSB 워크로드 A(읽기 50%, 갱신 50%) 와 B(읽기 95%, 갱신 5%) 를 돌린 결과입니다. 항목 크기는 900바이트, 키는 균등 분포로 하고 처리량을 초당 10만 건에서 100만 건까지 늘렸습니다. 그림 5(읽기) 와 그림 6(쓰기) 에서 p50 과 p99 지연 시간은 처리량이 열 배 늘어나는 동안 거의 평평하게 유지됩니다. 논문이 말하는 "예측 가능한 성능" 을 보여주는 그림입니다.

운영 수치로는 Prime Day 2021 의 초당 최대 8,920만 건 요청, 그리고 리전마다 수백만 개의 Paxos 그룹이 돌아가고 있다는 점이 언급됩니다.

지금 AWS 에서는

논문에 나오는 기능은 대부분 지금 DynamoDB 의 공식 기능 이름으로 그대로 이어집니다.

• 온디맨드 용량 모드와 프로비저닝 용량 모드: 4절의 GAC 와 자동 분할 위에서 동작합니다.
• 특정 시점 복구(PITR): 5절에서 설명한 S3 보관 로그와 스냅샷으로 최근 35일 안의 시점으로 복원합니다.
• 글로벌 테이블: 99.999% SLA 의 근거가 되는 다중 리전 복제 기능입니다.
• 트랜잭션: 논문은 존재만 언급하며, 자세한 설계는 2023년 USENIX ATC 의 별도 논문 "Distributed Transactions at Scale in Amazon DynamoDB" 에 정리되어 있습니다.

함께 읽기

• DynamoDB 와 ElastiCache: 이 사이트의 기능 문서
• Dynamo 논문 해설: DynamoDB 의 출발점
• Physalia 논문 해설: 같은 시기 EBS 의 설정 저장소가 택한 다른 길
• USENIX ATC '22 발표 영상과 슬라이드
• 원문 PDF 에는 별도의 정오표가 있습니다. 그림 1 의 철자 오류와 감사의 글 누락을 고친 것으로, 본문 내용에는 영향이 없습니다.