7000만 쿼리로 본 저장 분리 엔진 (Elastic Query Engine on Disaggregated Storage, NSDI 2020)

출처

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

한눈에

• 2016년 논문이 "어떻게 만들었나" 였다면, 이 논문은 "실제로 어떻게 쓰이나" 입니다. 2018년 2월에 연속된 14일 동안의 쿼리 약 7000만 건을 분석했습니다.
• 쿼리 유형은 읽기 전용 약 28%, 쓰기 전용 약 13%, 읽고 쓰기 약 59% 였고, 쿼리마다 중간 데이터 크기가 몇 자릿수씩 차이 났습니다.
• 고객 영구 데이터의 약 0.1% 크기인 로컬 캐시로도 평균 적중률이 읽기 전용 쿼리에서 80% 가까이, 읽고 쓰기 쿼리에서 60% 안팎이었습니다.
• 탄력성은 웨어하우스의 약 20% 만 썼고, CPU 평균 사용률은 약 51%, 메모리는 약 19% 였습니다. 저자들은 이 숫자를 근거로 컴퓨트와 임시 저장소까지 분리하고 테넌트끼리 자원을 공유하는 다음 구조를 연구 과제로 제시합니다.

왜 나왔나

클라우드 데이터 웨어하우스의 구조는 많이 소개되었지만, 실제 고객 작업 부하에서 그 구조가 어떻게 동작하는지 공개한 자료는 거의 없었습니다. 저자들은 이와 비슷한 데이터 기반 분석을 한 선행 연구를 알지 못한다고 적습니다. 또 2016년 이후 클라우드 환경도 변했습니다. 초 단위 과금이 일반화되면서 미리 데워 둔 유휴 노드의 비용이 커졌고, 새로운 하드웨어가 나왔습니다. 논문은 Snowflake 의 설계 가정을 운영 데이터로 점검하고, 시스템 연구자에게 풀어야 할 문제를 제시하는 것을 목표로 합니다.

핵심 아이디어

데이터 두 종류와 전체 구조 (2절)

논문은 데이터를 둘로 나눕니다. 테이블에 저장된 영구 데이터는 오래 살고 내구성이 중요합니다. 쿼리 실행 중에 연산자 사이를 오가는 중간 데이터는 수명이 짧고 내구성보다 지연이 중요합니다. 그림 1의 구조에서 영구 데이터는 S3, 중간 데이터는 각 VW 노드의 메모리와 로컬 SSD 로 이루어진 임시 저장 시스템에 둡니다. 클라우드 서비스가 쿼리를 계획하고 작업을 나눠 주며, 노드가 실패하면 작업을 다시 배정합니다.

데이터셋 (3절)

쿼리를 영구 데이터 읽기량과 쓰기량으로 나눠 그린 그림 2를 보면, 읽기 전용 쿼리의 읽기량은 아홉 자릿수, 쓰기 전용 쿼리의 쓰기량은 여덟 자릿수에 걸쳐 퍼져 있습니다. 읽고 쓰기 쿼리 다수는 읽은 만큼 쓰는 전형적인 ETL 입니다. 읽기 전용 쿼리는 평일 낮에 몰리고 쓰기 전용은 시간대와 무관하게 꾸준합니다.

임시 저장 시스템 (4절)

중간 데이터는 메모리, 로컬 SSD 순으로 쓰고, 그래도 넘치면 다른 노드가 아니라 S3 로 내보냅니다. 저장 계층을 얇고 단순하게 유지하려는 선택입니다. 그림 3은 중간 데이터 크기가 쿼리마다 크게 달라 일부는 10TB 에서 100TB 를 주고받고, 컴퓨트 양과 중간 데이터 양의 비율도 여섯 자릿수까지 벌어짐을 보여 줍니다. 노드 수를 정할 때 메모리와 SSD 를 컴퓨트에 묶어서 사면 어느 한쪽이 낭비된다는 뜻입니다.

임시 저장소의 남는 공간은 영구 데이터 캐시로 씁니다. 파일 이름의 일관 해싱으로 캐시 위치를 정하고 LRU 로 내보내며, 중간 데이터가 항상 우선합니다. 쓰기는 캐시와 S3 에 함께 쓰는 write-through 입니다.

작업 스케줄링 (5절)

작업은 해당 파일이 해시되는 노드에서 실행해 캐시 지역성을 살립니다. 이렇게 하면 쿼리의 병렬도가 파일 배치에 묶이므로, 읽는 파일이 적은 쿼리도 모든 노드에 퍼집니다(그림 6). 한 노드에 일이 몰리면 다른 노드가 그 작업을 가져가 S3 에서 직접 읽는 작업 훔치기로 균형을 맞춥니다.

탄력성과 게으른 일관 해싱 (6절)

미리 데워 둔 노드 풀 덕분에 수십 초 단위로 VW 크기를 바꿀 수 있습니다. 노드가 추가되어도 데이터를 바로 옮기지 않고, 그 파일이 필요한 작업이 새 노드에서 처음 실행될 때 S3 에서 가져오는 게으른 일관 해싱(그림 7)을 씁니다. 옛 노드의 사본은 시간이 지나 LRU 로 사라집니다.

다중 테넌시 (7절)

VW 마다 노드와 임시 저장소를 따로 두어 성능 격리는 확실하지만 자원 사용률은 낮습니다. 저자들은 테넌트가 캐시와 중간 데이터 공간을 함께 쓰면서도 서로 격리되는 공유 구조, 메모리를 CPU 와 따로 늘리는 메모리 분리를 다음 과제로 꼽습니다.

실험과 결과

통제된 벤치마크가 아니라 운영 측정치입니다.

• 쿼리 구성 (그림 2): 읽기 전용 약 28%, 쓰기 전용 약 13%, 읽고 쓰기 약 59%.
• 캐시 (그림 5): 캐시 용량은 고객 영구 데이터의 평균 약 0.1% 인데, 평균 적중률은 읽기 전용 쿼리 80% 가까이, 읽고 쓰기 쿼리 60% 안팎이었습니다. 중앙값은 평균보다 높았습니다.
• 탄력성 (그림 8, 그림 9): 그림 8 설명은 VW 의 82% 가 탄력성을 전혀 쓰지 않았다고 적고, 본문은 약 20% 의 VW 에서 쓰인다고 적습니다. 쓰는 VW 는 노드 수가 두 자릿수 배까지 바뀌었지만, 크기 변경은 쿼리 도착 간격보다 훨씬 굵은 시간 단위로 일어났습니다.
• 사용률 (그림 10, 그림 11): 시스템 전체 평균 CPU 약 51%, 메모리 약 19%, 네트워크 송신 약 11%, 수신 약 32% 였습니다. 그림 11은 많은 VW 에서 CPU 와 메모리 사용량의 변동 계수가 크다는 점을 보여 줍니다.

지금 Snowflake 에서는

• 논문이 설명한 VW, S3 위 영구 데이터, 로컬 캐시와 일관 해싱 구조는 Snowflake 가 계속 쓰는 기본 구조입니다. 기본 설계는 SIGMOD 2016 논문에 있습니다.
• 공개된 Snowset 데이터셋은 이후 클라우드 데이터베이스 연구에서 작업 부하 자료로 쓰입니다.
• 논문이 연구 과제로 남긴 테넌트 간 자원 공유와 서버리스형 탄력성이 이후 제품에서 어떤 내부 구조로 구현되었는지는 공식 논문으로 확인하지 못해 여기서는 연결하지 않습니다.

함께 읽기

• 웨어하우스와 크레딧: 이 사이트의 기능 문서
• Snowflake 아키텍처: 이 사이트의 기능 문서
• 저장과 컴퓨트를 나눈 클라우드 웨어하우스 (SIGMOD 2016)
• 프루닝 (SIGMOD 2025): 캐시 이전에 아예 읽지 않을 파일을 거르는 기법
• 데이터셋: Snowset (GitHub)
• 리뷰 글: the morning paper 의 해설