로그와 저장을 떼어 낸 SQL Server (Socrates, SIGMOD 2019)

출처

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

한눈에

• 기존 Azure SQL Database 는 노드 4대가 각각 데이터 전체를 들고 로그를 복제하는 구조였고, 그래서 최대 크기 4TB, 데이터 크기에 비례하는 복구와 확장이라는 한계가 있었습니다.
• Socrates 는 내구성(로그와 장기 저장)과 가용성(계산과 페이지 캐시)을 서로 다른 계층으로 떼어 내는 것을 핵심 아이디어로 삼습니다.
• 계산 노드, XLOG 로그 서비스, 페이지 서버, XStore(Azure Storage)의 네 계층으로 100TB 급 데이터베이스, 상수 시간 백업과 복원, 빠른 읽기 전용 복제본 추가를 목표로 했습니다.
• 이 설계는 Azure SQL Database Hyperscale 로 출시되었습니다.

왜 나왔나

2장은 당시 Azure SQL Database 의 HADR 구조(그림 1)를 설명합니다. 1차 노드 하나와 2차 노드 셋이 로그를 복제하는 상태 기계로 동작하고, 각 노드가 데이터베이스 전체를 로컬에 둡니다. 로그는 5분마다, 차등 백업은 매일, 전체 백업은 매주 받습니다. 이 구조는 단순하고 검증되었지만 몇 가지가 데이터 크기에 묶여 있습니다. 새 복제본을 만드는 시딩, 백업과 복원, 더 큰 장비로 옮기는 확장이 모두 데이터 크기에 비례하는 시간(O(size-of-data))이 걸리고, 데이터베이스 크기는 장비 한 대의 디스크에 묶입니다.

표 1은 저자들이 세운 목표를 오늘(HADR)과 비교해 보여 줍니다. 최대 크기 4TB 에서 100TB 로, 가용성 99.99 에서 99.999 로, 확장과 축소는 O(데이터 크기)에서 O(1) 로, 저장 복사본은 4벌에서 2벌로, 커밋 지연 3ms 에서 0.5ms 미만으로, 로그 처리량 50MB/s 에서 100MB/s 이상으로 바꾸는 것입니다. 2장은 Spanner, Aurora, Oracle Exadata 와도 비교하는데, 특히 Aurora 가 저장 계층에 6개 복제본을 두고 그중 4개에 기록되면 커밋하는 방식과 대비됩니다.

핵심 아이디어

재사용한 SQL Server 기능

3장은 Socrates 가 기대는 SQL Server 기능들을 먼저 설명합니다. 스냅샷 격리용 행 버전을 저장 계층에 두는 영구 버전 저장소, 버전 저장소를 이용해 실행 취소(undo) 단계를 거의 없애 복구 시간을 체크포인트 간격으로 묶는 Accelerated Database Recovery(ADR), 버퍼 풀을 로컬 SSD 로 확장하면서 재시작 후에도 내용이 살아남는 RBPEX(Resilient Buffer Pool Extension), 원격 페이지 I/O 용 RBIO 프로토콜, XStore 스냅샷을 이용한 백업 등입니다. 옵티마이저, 실행 엔진, 보안, 트랜잭션 처리는 그대로 두어 T-SQL 호환성을 유지했습니다.

네 계층

그림 2의 전체 구조는 네 계층입니다.

계산 노드와 페이지 서버는 상태가 없어서 언제든 새로 띄울 수 있고, 진짜 상태는 XLOG 와 XStore 에만 있습니다. 이것이 "내구성과 가용성의 분리"입니다.

XLOG 로그 서비스

1차 노드는 로그 블록을 랜딩 존(Landing Zone)에 동기식으로 씁니다. 랜딩 존은 Azure Premium Storage 위의 작은 원형 버퍼로, 저장소 자체가 3개 복제본을 유지하므로 짧은 커밋 지연과 내구성을 함께 얻습니다. 동시에 1차 노드는 로그를 XLOG 프로세스에도 보내고, XLOG 는 랜딩 존에서 굳어진(hardened) 블록만 2차 노드와 페이지 서버에 배포합니다. 아직 내구화되지 않은 로그가 퍼지지 않게 하려는 장치입니다. 최근 로그는 메모리, 그다음 로컬 SSD 캐시, 그다음 랜딩 존, 마지막으로 장기 저장소에서 찾아 제공하며, 로그는 시점 복원을 위해 30일 동안 XStore 에 보관됩니다. 로그 소비자는 필요한 블록을 직접 가져가는(pull) 방식이라 XLOG 가 소비자를 추적할 필요가 없습니다.

페이지 서버와 GetPage@LSN

페이지 서버는 데이터베이스의 한 파티션(논문 기준 약 128GB)을 맡아, 자기 파티션에 해당하는 로그만 받아 적용합니다. 파티션의 모든 페이지를 RBPEX 에 담는 "covering" 캐시를 두고, 주기적으로 체크포인트를 XStore 로 내보냅니다. 수백 TB 데이터베이스라면 페이지 서버가 수천 대가 됩니다.

1차 노드는 자기 캐시에 없는 페이지를 GetPage@LSN 요청으로 페이지 서버에서 가져옵니다. 요청에는 "이 LSN 까지 반영된 버전이 필요하다"는 값이 붙고, 페이지 서버는 그 LSN 까지 로그를 적용한 뒤 페이지를 돌려줍니다. 1차 노드는 페이지마다 LSN 을 기억하지 않고, 쫓아낸 페이지들의 최고 LSN 을 해시 맵으로 관리해 안전한 값을 계산합니다.

2차 계산 노드는 HADR 의 로그 적용 로직을 재사용하되 로그를 저장하지 않으며, 캐시에 없는 페이지에 대한 로그는 건너뜁니다. B-트리를 내려가다 서로 다른 시점의 페이지를 보게 되면 이를 감지하고 잠시 기다린 뒤 다시 탐색합니다.

백업과 복원

백업은 XStore 스냅샷이므로 데이터 크기와 상관없이 상수 시간이며 계산 노드의 CPU 와 I/O 를 쓰지 않습니다. 시점 복원은 스냅샷을 복사하고 그 위에 해당 시점까지 로그를 적용해 이루어집니다.

실험과 결과

7장은 Hyperscale 미리 보기 환경과 테스트 클러스터에서 HADR 와 비교합니다. 벤치마크는 Azure 내부의 CDB 입니다.

• 기본 처리량(표 2): 1TB, 8코어 VM, 클라이언트 스레드 64개에서 HADR 는 초당 1402 트랜잭션, Socrates 는 1335 트랜잭션으로 약 5% 낮았습니다. 절반은 원격 I/O 대기로 CPU 를 덜 쓴 탓, 나머지 약 2.5% 는 XLOG 로 로그를 보내는 CPU 비용 탓으로 분석합니다.
• 캐시 적중률(표 3, 표 4): 1TB CDB 에서 메모리 56GB 와 RBPEX 168GB(데이터의 약 15%)로 로컬 캐시 적중률 52%, 30TB TPC-E 에서 메모리 88GB 와 RBPEX 320GB(약 1%)로 32% 였습니다.
• 로그 처리량(표 5): 갱신 위주 부하에서 HADR 56.9MB/s, Socrates 89.8MB/s 였습니다. 백업을 저장 계층 스냅샷으로 넘긴 덕분에 1차 노드가 로그를 더 많이 만들 수 있었습니다.
• 부록(표 6, 표 7): 랜딩 존을 XIO 대신 DirectDrive 에 두면 단일 스레드 커밋 지연 중앙값이 3300마이크로초에서 800마이크로초로 줄었고, 약 70MB/s 로그 처리량을 내는 데 필요한 스레드가 128개에서 16개로 줄었습니다.

지금 Azure 에서는

Socrates 는 Azure SQL Database 의 Hyperscale 서비스 계층입니다. 논문 결론도 이 점을 밝힙니다. 공식 문서가 설명하는 Hyperscale 구조의 계산 노드, 페이지 서버, 로그 서비스, Azure Storage 는 논문의 네 계층과 같고, 백업과 복원이 파일 스냅샷 기반이라 크기와 거의 무관하게 빠르다는 설명도 3.5절과 4.7절의 설계 그대로입니다. 읽기 전용 2차 노드는 지금 고가용성 복제본과 이름 있는 복제본(named replica) 형태로 제공됩니다.

함께 읽기

• Azure SQL: 이 사이트의 기능 문서
• Windows Azure Storage: XStore 의 바탕이 된 저장소 구조
• POLARIS: 같은 SQL Server 엔진을 분산 분석 엔진으로 확장한 사례
• Hyperscale 서비스 계층 공식 문서
• SIGMOD 2019 발표 영상 (TIB AV-Portal)