부하에 맞춰 늘고 주는 Aurora Serverless (Aurora Serverless, VLDB 2024)

출처

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

한눈에

• 문제: 데이터베이스 부하는 시간에 따라 크게 출렁이지만, 고정 크기 인스턴스는 최대 부하에 맞춰 사야 합니다. 그렇다고 크기를 바꿀 때마다 재시작하면 연결과 캐시를 잃습니다.
• 제안: Aurora Serverless v2(ASv2) 는 가상 머신 안에서 메모리와 CPU 를 실행 중에 붙였다 떼어 인스턴스 크기를 제자리에서 바꿉니다. 호스트가 비좁아지면 인스턴스를 다른 호스트로 실시간 이전합니다.
• 결과: 그림 1 의 읽기 전용 실험에서 ASv2 는 128 ACU 로 고정한 인스턴스가 쓰는 ACU-시간의 54.9% 만 썼습니다. 실제 함대에서는 크기 증가 요청의 99.98% 를 이전 없이 제자리에서 처리했습니다.
• 지금의 의미: "단순하게 시작하고, 데이터가 보여준 만큼만 똑똑해진다" 는 원칙으로 만든 운영형 자원 관리 사례입니다.

왜 나왔나

Aurora 는 2014년 발표되었고, 첫 서버리스 버전(ASv1) 은 2018년 8월, 지금의 ASv2 는 2022년 4월에 나왔습니다. ASv1 은 크기를 바꿀 때 데이터베이스를 새로 띄우고 세션을 옮기는 방식이었습니다. 크기를 두 배씩만 바꿀 수 있어 부하가 경계 근처에 있으면 늘었다 줄었다를 반복했고, 중간에 다중 테넌트 프록시가 필요해 기능 제약도 있었습니다.

ASv2 는 이 한계를 없애려고 처음부터 다시 설계했습니다. 크기 단위는 0.5 ACU 로 잘게 하고, 트랜잭션이 열려 있어도 멈추지 않고 크기를 바꾸며, 프록시를 없애 일반 Aurora 와 거의 같은 기능을 제공하는 것이 목표였습니다.

핵심 아이디어

용량 단위와 경계 (2절)

용량 단위 ACU(Aurora Capacity Unit) 하나는 메모리 2GB 와 그에 맞는 CPU(현재 0.25 vCPU), 네트워크, 블록 I/O 를 뜻합니다. 고객은 최소와 최대 ACU 를 정하고(논문 시점 기준 0.5 에서 128 ACU), 요금은 초 단위로 측정한 ACU-시간으로 냅니다. 저자들은 최소 ACU 를 애플리케이션의 작업 데이터가 버퍼 풀에 들어갈 정도로 잡으라고 권합니다. 너무 낮게 잡으면 캐시가 비어 성능이 떨어지기 때문입니다.

설계 원칙은 "워크로드에 대한 가정을 최소로 두고, 데이터로 증거가 쌓인 뒤에야 구체화한다" 입니다. 예측 모델 대신 최근 측정값에 반응하는 제어를 쓰고, 초기 사용률 목표도 보수적으로 잡은 이유가 여기에 있습니다.

세 층의 자원 관리 (3절)

자원 관리는 세 시간 단위로 나뉩니다.

• 인스턴스 수준 (초 단위): 인스턴스 안에서 얼마만큼 자원을 쓸지 정합니다.
• 함대 수준 (분에서 시간 단위): 한 AZ 안의 호스트 풀에서 어느 호스트에 어떤 인스턴스를 둘지, 언제 옮길지 정합니다.
• 함대 크기 (주에서 월 단위): 호스트를 얼마나 확보할지 정합니다.

두 수준은 인스턴스마다 정하는 "최대 허용 ACU" 값 하나로만 연결됩니다(그림 3). 함대 관리자는 호스트가 붐비면 이 값을 현재 예약량에 묶어 두고, 인스턴스 관리자는 그 안에서만 자랍니다. 이렇게 느슨하게 결합하면 각 층을 따로 개선할 수 있습니다. 호스트 하나는 256 ACU 규모로 조달합니다.

함대 수준: 열 관리와 실시간 이전 (4절)

매초 다음 세 단계를 돕니다. 먼저 최근 몇 분간 예약된 ACU 합이 임계를 넘는 호스트를 "뜨겁다" 고 판정합니다. 다음으로 걸러내기, 선호 순위, 점수의 세 단계 휴리스틱으로 옮길 인스턴스를 고르고, 마지막으로 최적 적합(best-fit) 과 CPU, 메모리, 네트워크 균형 점수를 섞어 목적지 호스트를 고릅니다. 구체적인 임계값은 공개하지 않았습니다.

흥미로운 점은 함대를 일부러 불균형하게 유지한다는 것입니다. 모든 호스트를 고르게 채우면 큰 인스턴스가 옮겨 갈 빈 호스트가 없어지기 때문입니다. 새 인스턴스를 배치할 때는 고객의 최소 ACU 를 수요로 보고, 줄어드는 것보다 빨리 늘어나는 것을 우선합니다.

호스트 수준: 제자리 크기 조절 (5절)

저자들은 처음에 Firecracker 를 검토했습니다. VM 당 오버헤드가 5MB 정도로 작지만, 사용자 공간에서 I/O 를 가상화하는 방식이 캐시 지역성이 낮은 데이터베이스 워크로드에는 너무 느렸습니다. 그래서 Nitro 위에 SR-IOV 로 I/O 를 처리하는 새 인스턴스 유형을 만들었습니다.

CPU 와 메모리는 오버커밋합니다. 메모리를 돌려받기 위해 게스트 커널에서 메모리 오프라인, 차가운 페이지 식별, 2MB 단위의 빈 페이지 보고, 압축(compaction) 을 씁니다. 경계는 cgroups 로 잘게 지키고, 큰 단위는 CPU 와 메모리 핫플러그로 바꿉니다.

크기 결정은 여러 "결정자" 가 매초 몇 분치 기록을 보고 내립니다. 버퍼 풀 결정자는 지난 1분간 최대 사용량을, CPU 결정자는 30초간 p50 과 60초간 p70 을 봅니다. 늘릴 때는 결정자 중 가장 큰 값을 따르고, 줄일 때는 모든 결정자가 동의해야만 줄입니다. 늘어나는 속도는 현재 크기가 클수록 커지는 토큰 버킷으로 조절하고, 줄어드는 속도는 일부러 더 느리게 합니다.

실험과 결과

6절은 PostgreSQL 함대 두 곳의 2024년 1월 운영 데이터를 분석합니다.

• 함대 1 (us-east-1, 17일): 인스턴스 33,792 개, 크기 증가 이벤트 16,440,024 건 가운데 실시간 이전이 필요했던 것은 2,923 건으로, 99.98% 를 제자리에서 처리했습니다. 이전이 필요했던 이벤트의 52% 는 이전 한 번으로 끝났고 평균 1.68 회였습니다.
• 함대 2 (us-west-2, 31일): 인스턴스 12,467 개, 이벤트 8,151,229 건 중 1,214 건이 이전을 필요로 했고, 평균 1.56 회였습니다.
• 기준선 비교 (6.3절): 단순한 최적 적합 배치와 비교하면, 기준선은 이전 횟수가 함대 1 에서 82%, 함대 2 에서 57% 더 많았습니다.
• 그림 6: 실시간 이전의 도움으로 크기가 커지는 과정을 정규화된 시간 축으로 보여줍니다. 실제 시간과 임계값은 공개하지 않았습니다.
• 그림 1: 128 ACU 고정 인스턴스와 0.5 에서 128 ACU 범위의 ASv2 를 비교한 실험으로, 사용한 ACU-시간이 54.9% 였고, 할당이 최대치의 약 50% 아래로 내려간 구간에서 지연 시간 차이가 가장 컸습니다.

8절의 교훈은 단순하게 시작할 것, 성장 속도를 조금 희생하더라도 예측 가능한 탄력성을 줄 것, 최근 데이터에 반응하는 제어를 쓸 것, 함대와 호스트 관리를 느슨하게 결합할 것, 데이터베이스에 맞춰 하이퍼바이저와 커널을 함께 설계할 것입니다.

지금 AWS 에서는

• 이 논문이 설명하는 시스템은 지금의 Aurora Serverless v2 입니다. 같은 클러스터 안에서 프로비저닝 인스턴스와 섞어 쓸 수 있고, 읽기 복제본으로도 쓸 수 있습니다.
• 논문 이후 ACU 범위가 넓어졌습니다. 2024년 말부터는 최소 0 ACU 로 설정해 유휴 시 자동 일시 중지할 수 있고, 최대 ACU 도 256 까지 늘었습니다. 논문의 0.5 에서 128 ACU 범위는 집필 시점의 값입니다.
• 첫 세대 ASv1 은 지원이 종료되었으므로, 지금 "Aurora Serverless" 라고 하면 사실상 v2 를 뜻합니다.

함께 읽기

• RDS 와 Aurora, Aurora DSQL: 이 사이트의 기능 문서
• Aurora 2017 논문 해설: Serverless 가 그대로 쓰는 공유 저장 계층
• Firecracker 논문 해설: 이 논문이 검토했다가 쓰지 않은 가상화 기술
• Marc Brooker 의 블로그 글