수백만 개의 작은 데이터베이스 Physalia (Millions of Tiny Databases, NSDI 2020)

출처

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

한눈에

• 문제: EBS 볼륨은 주 복제본과 보조 복제본으로 복제되고, 장애가 나면 "지금 누가 주 복제본인가" 를 강한 일관성으로 기록해야 합니다. 이 설정 저장소가 멈추면 대규모 장애 때 볼륨이 복구되지 못합니다.
• 제안: 볼륨마다 7개 노드로 이루어진 작은 Paxos 셀을 두고, 셀을 그 볼륨의 클라이언트(EC2 인스턴스와 저장 서버) 가 있는 곳 가까이에 배치합니다. 모든 키를 모든 곳에서 쓸 수 있게 하는 대신, 각 클라이언트가 필요로 하는 키만 그 클라이언트 쪽에서 매우 높은 가용성으로 제공합니다.
• 결과: 배포 후 설정 저장소의 가용성이 통계적으로 뚜렷하게 좋아졌고(그림 8, p = 7.7x10^-5), 시뮬레이션에서는 단일 데이터베이스보다 가용성을 잃을 확률이 최대 4배 낮았습니다(그림 11).
• 지금의 의미: 장애의 영향 범위(blast radius) 를 작게 쪼개는 셀 기반 설계와 "인프라를 아는 배치" 를 보여주는 대표 논문입니다.

왜 나왔나

EBS 는 체인 복제로 볼륨 데이터를 두 곳에 둡니다. 한쪽이 죽으면 남은 쪽이 새 짝을 찾아 복제를 다시 시작하는데, 이때 어느 서버가 주인인지 기록하는 "설정 마스터" 가 필요합니다. 이 정보는 반드시 강한 일관성(선형화 가능성) 을 가져야 합니다. 두 서버가 동시에 자신을 주인이라고 믿으면 데이터가 갈라지기 때문입니다.

2011년의 한 사고에서는 네트워크 설정 변경을 계기로 한 AZ 의 EBS 볼륨 13% 가 사용할 수 없게 되었습니다. 복제 메타데이터가 API 트래픽과 같은 데이터베이스를 쓰고 있었고, 대량의 재시도 부하가 제어 평면을 마비시켰습니다. 이 경험에서 저자들은 큰 장애일수록 설정 저장소가 더 바빠진다는 점, 그리고 하나의 데이터베이스는 하나의 장애 범위라는 점을 배웠습니다.

CAP 정리에 따르면 네트워크가 갈라질 때 강한 일관성과 가용성을 동시에 가질 수 없습니다. 하지만 저자들은 관점을 바꿉니다. 볼륨 하나에 관심 있는 참가자는 인스턴스, 주 복제본, 보조 복제본 셋뿐입니다. 그렇다면 데이터를 그 참가자들과 같은 쪽에 두면, 분할이 일어나도 필요한 쪽에서는 계속 쓸 수 있습니다. 논문 초록의 표현대로, 이들은 데이터베이스 하나가 아니라 수백만 개를 원했습니다.

"We wanted millions." (초록)

핵심 아이디어

노드, 셀, 콜로니 (2.1절)

논문은 세 가지 용어를 씁니다. 노드는 하나의 프로세스, 셀은 키 하나(EBS 에서는 볼륨 하나) 를 담당하는 Paxos 상태 기계, 콜로니는 한 설치 전체입니다(그림 2, 3). 노드 하나는 여러 셀에 참여하고, 셀끼리는 서로 독립적입니다. EBS 설치에서 셀은 7개 노드로 Paxos 를 돌립니다. 저자들은 7개 복제가 볼륨 데이터의 2개 복제보다 약 5,000배 높은 내구성을 준다고 계산합니다. 그림 4 는 셀 크기에 따라 무작위 장애와 상관된 장애에 대한 내성이 어떻게 달라지는지 보여줍니다.

데이터 모델과 API (2.3절)

각 셀은 트랜잭션을 지원하는 작은 타입 있는 키-값 저장소입니다. 일괄 연산과 조건부 쓰기가 엄격한 직렬화 가능성으로 실행되고, 노드마다 계산 결과가 달라질 수 있는 부동소수점 형식은 아예 뺐습니다. API 는 DynamoDB 에서 영감을 받았고, 읽기와 조건부 쓰기를 한 번에 하는 연산과 임대(lease) 기능을 더했습니다.

재구성과 이동 (2.4절)

셀 멤버십 변경은 Paxos 로그에 기록하되, 기록한 시점에서 α 칸 뒤(보통 α = 3) 부터 효력을 가집니다(그림 6, 7). 노드는 한 번에 하나씩 바꾸고, 클라이언트가 움직이면 셀도 클라이언트 가까이로 조금씩 옮겨 갑니다. 새 노드를 따라잡게 하는 방법도 여러 가지를 씁니다.

찾기 캐시 (2.5절)

클라이언트가 자기 셀이 어느 노드에 있는지 알기 위한 캐시는 최종 일관성만 가집니다. 캐시가 틀리면 요청이 느려질 뿐, 정확성에는 영향이 없도록 설계했습니다.

가용성을 위한 배치와 색 (3절)

셀 노드는 서로 다른 랙과 전원 영역에 흩어 두되, 클라이언트와 같은 네트워크 쪽에 있도록 배치합니다(3.1, 3.2절). 소프트웨어 배포나 과부하처럼 여러 노드에 한꺼번에 영향을 주는 상관 장애에 대비해 색(color) 을 도입했습니다(3.3, 3.4절). 각 셀은 같은 색의 노드로만 이루어지고, 배포는 색 단위로 진행합니다. 잘못된 배포가 나가도 한 색의 셀만 영향을 받습니다. 합의 시스템은 과부하에 약하므로, 파이프라인이 가득 차면 새 요청을 거절해 스스로를 지킵니다(3.5절).

테스트와 검증 (4절)

네트워크와 시간을 흉내 내는 인메모리 "simworld" 하네스에서 분산 시나리오를 단위 테스트처럼 돌립니다. 테스트 하나가 10줄 미만의 Java 코드이고 100ms 안에 끝나며, 이런 테스트를 수백 개 만들었습니다. 이 밖에 패킷 손실과 재정렬 테스트, Jepsen 을 이용한 선형화 가능성 검사, 실제와 비슷한 환경에서의 게임 데이, 그리고 TLA+ 와 TLC 모델 검사기로 핵심 프로토콜의 안전성을 확인했습니다.

실험과 결과

5절은 운영 결과와 시뮬레이션을 함께 보여줍니다.

• 운영 규모: 논문 시점에 AWS 의 60개 넘는 가용 영역에서 운영 중이었습니다.
• 그림 8: 한 운영 콜로니에서 EBS 주 복제본 입장에서 본 설정 저장소의 월별 평균 가용성입니다. 기존 시스템을 Physalia 로 바꾼 뒤 가용성이 뚜렷하게 개선되었습니다(p = 7.7x10^-5).
• 그림 9: EBS 마스터의 오류율이 내부 목표인 0.05% 를 넘은 시간이 한 달에 몇 시간인지 보여주며, 배포 이후 줄어들었습니다.
• 그림 10: 대규모 클러스터 하나에서 읽기는 p99 기준 10ms 아래, 쓰기는 대체로 50ms 아래였습니다.
• 그림 11: 집선(agg) 계층 장치 고장으로 네트워크가 갈라지는 상황을 시뮬레이션하면, 셀 크기 5와 9 모두에서 단일 데이터베이스 대비 가용성을 잃을 확률이 최대 4배 낮았습니다.
• 그림 12: 3계층 데이터센터 네트워크에서 장치 고장이 늘면 Physalia 의 부하가 선형으로 늘다가 최대 29% 에서 꺾입니다.

운영 중 겪은 롤백 사고를 계기로 제어 평면 요청에 속도 제한과 긴급 차단 장치를 더했다는 경험담도 실려 있습니다.

지금 AWS 에서는

• 논문 시점 기준으로 Physalia 는 Amazon EBS 의 볼륨 복제 설정을 저장하는 데 쓰였고, 저자들은 AWS 의 다른 곳에서도 쓰인다고 밝혔습니다. 지금의 세부 운영 현황은 공개 자료로 확인하지 않았습니다.
• 장애 범위를 셀 단위로 나누고 배포를 단계별로 진행하는 생각은 AWS Well-Architected 의 백서 "Reducing the Scope of Impact with Cell-Based Architecture" 와 Amazon Builders' Library 글들에서 일반적인 설계 지침으로 정리되어 있습니다.

함께 읽기

• EBS, EFS, FSx 와 AWS Backup: 이 사이트의 기능 문서
• Dynamo 논문 해설: 가용성을 위해 일관성을 내려놓은 반대 방향의 선택
• DynamoDB 논문 해설: 파티션마다 Paxos 그룹을 두는 비슷한 구조
• Marc Brooker 의 블로그 글