Brain519. AWS Aurora 서버리스와 분산 스토리지 쿼럼
⚠️ 이 문서는 "낮에는 손님이 1만 명이라 서버 10대가 필요하고, 새벽에는 손님이 0명이라 서버를 다 끄고 싶은데, 데이터베이스는 껐다 켤 수가 없잖아?"라는 클라우드 시대의 가장 큰 딜레마를, 스토리지와 연산을 완벽하게 분리하여 DB 엔진을 1초 만에 껐다 켤 수 있게 만든 'Aurora Serverless' 아키텍처를 다룹니다.
(※ 390번 문서에서 Aurora의 기본 아키텍처를 다루었으며, 이 문서는 서버리스(Serverless) 관점의 확장성과 과금 모델을 심화로 다룹니다.)
핵심 인사이트 (3줄 요약)
- 본질: 데이터베이스의 '저장소(Storage)'는 항상 켜두지만, 쿼리를 처리하는 '뇌(Compute)'는 트래픽이 있을 때만 켜지고 트래픽이 없어지면 0(Zero)으로 꺼져버리는 클라우드 네이티브 아키텍처다.
- 가치: 24시간 켜둘 필요가 없는 개발용 DB나, 이벤트 때만 트래픽이 100배로 폭주하는 비정기적 워크로드에서 데이터베이스 유지 비용을 최대 90%까지 극단적으로 절감해 준다.
- 기술 체계: **스토리지-컴퓨팅 분리(501번 문서)**와 4/6 쿼럼 쓰기(390번 문서) 기술이 결합되어, CPU가 꺼졌다 켜지는 찰나의 순간에도 데이터의 영속성(Durability)을 완벽하게 보장한다.
Ⅰ. 개요: 24시간 도는 택시 미터기 (Context & Necessity)
아마존 RDS(일반적인 클라우드 DB)에 db.m5.large 서버를 하나 만들었다.
- 한 달에 10만 원이 나온다.
- 근데 우리 회사 서비스는 사내 그룹웨어라서 직원들이 밤 10시부터 아침 8시까지는 아예 접속을 안 한다.
- 주말(토, 일) 이틀 동안에도 아무도 접속을 안 한다.
- 결론: 우리는 10만 원을 냈지만, 실제로 DB가 일한 시간은 3만 원어치도 안 된다. 7만 원을 허공에 버리고 있다.
"밤이랑 주말에는 DB를 잠깐 끄면 안 될까?" 하지만 일반 DB는 끄고 켜는 데 수분이 걸리고, 꺼져있을 때 갑자기 직원이 접속하면 에러(장애)가 난다. 이 문제를 해결한 것이 **오로라 서버리스(Aurora Serverless)**다. "트래픽이 0이면 DB CPU를 아예 0(Zero)으로 꺼버릴게! 그러다 누군가 쿼리를 딱 날리면, 내가 0.1초 만에 CPU를 깨워서 대답해 줄게. 그리고 돈은 CPU가 켜져 있던 시간(초 단위)만큼만 내!"
📢 섹션 요약 비유: 일반 DB가 **'한 달 내내 렌트한 자동차'**라면(타든 안 타든 돈을 내야 함), 서버리스 DB는 **'우버(Uber) 택시'**와 같습니다. 평소에는 차가 없어서 돈을 안 내다가, 내가 부를 때만 딱 나타나서 목적지까지 데려다주고 이동한 시간만큼만 돈을 받습니다.
Ⅱ. 서버리스가 가능한 이유: Proxy와 Storage ★
DB 엔진을 껐다 켜는데 어떻게 데이터가 안 날아가고 앱에서 에러가 안 날까? 그 비밀은 Aurora의 '3단 분리' 아키텍처에 있다.
1. Proxy Fleet (문지기) - 24시간 깨어있음
- 애플리케이션(Java)은 DB 엔진의 주소(IP)를 모른다. 무조건 아마존이 세워둔 '프록시(Proxy)'와 연결을 맺는다.
- 프록시는 24시간 살아있기 때문에, 뒤에 있는 DB CPU가 꺼져있어도 앱 입장에서는 "어? DB랑 연결이 잘 되어있네?"라고 착각한다. (커넥션 유지)
2. Compute Fleet (연산 노드) - 껐다 켜짐
- 트래픽이 0일 때는 이 CPU 노드들이 싹 다 사라진다. (과금 0원)
- 갑자기 프록시로 쿼리가 훅 들어오면? 아마존이 예비로 만들어둔 거대한 'Warm Pool(대기 중인 CPU 군단)'에서 CPU 하나를 낚아채서 프록시 뒤에 딱 붙여버린다. 이 시간이 0.1초도 안 걸린다. (Cold Start 최소화)
3. Storage Node (분산 스토리지) - 24시간 깨어있음
- 진짜 데이터 파일은 3개의 가용 영역(AZ)에 6개의 복제본으로 쪼개져서(4/6 Quorum) 아주 튼튼한 스토리지에 24시간 살아있다.
- 0.1초 만에 켜진 CPU가 이 스토리지에 빨대만 딱 꽂으면, 1초 전의 최신 데이터를 완벽하게 이어서 처리할 수 있다.
Ⅲ. 실무 팁: Serverless v1 vs v2
Aurora Serverless는 두 번의 거대한 진화를 거쳤다. 실무 도입 시 반드시 알아야 할 차이다.
- v1의 한계 (스케일링 렉): v1은 CPU를 2개에서 4개로 늘릴 때, "잠깐만! 진행 중인 트랜잭션들 다 끝날 때까지 1초만 멈춰봐!" 라며 숨을 고르는 시간(Scaling Point)이 필요했다. 이때 쿼리가 멈춰서 실무(운영 DB)에서는 욕을 엄청 먹었다.
- v2의 완성 (In-place Scaling): v2는 미친 기술력을 도입해서, 쿼리가 돌아가고 있는 그 찰나의 순간에 CPU와 메모리를 0.5개 단위로 쪼개어 실시간으로 쑥쑥 늘리고 줄여버린다. (In-place) 이제 멈춤 현상이 아예 사라져서 메인 운영 DB로 써도 손색이 없게 되었다.
┌──────────────────────────────────────────────────────────────┐
│ Aurora Serverless의 스케일링(Scaling) 작동 시각화 │
├──────────────────────────────────────────────────────────────┤
│ │
│ [ 👨💻 사용자 (Spring Boot) ] │
│ │ (Connection 연결 유지됨) │
│ ▼ │
│ ┌──────────────────────────┐ │
│ │ 🛡️ Proxy Fleet (항상 켜짐) │ ◀── 앱은 얘랑만 대화함. │
│ └───────┬──────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────┐ (트래픽이 0일 땐 0개로 소멸) │
│ │ 🧠 Compute Node (켰다 꺼짐) │ ◀── (트래픽이 폭주하면 100개로 복제됨) │
│ └───────┬──────────────────┘ │
│ │ (빨대 꽂기) │
│ ▼ │
│ ┌──────────────────────────┐ │
│ │ 💾 Storage Node (항상 켜짐) │ ◀── (6개의 복제본과 4/6 Quorum으로 방어)│
│ └──────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
Ⅳ. 결론
"서버리스는 클라우드의 최종 진화 형태다." Aurora Serverless는 데이터베이스 인프라 관리의 종말을 알리는 신호탄이다. DBA가 밤을 새워가며 "이벤트 날이니까 CPU 100개짜리 서버로 마이그레이션(Scale-up) 해놔야겠다"라고 삽질하던 시대는 끝났다. 최신 아키텍처에서 데이터베이스 엔진은 물 쓰듯, 전기 쓰듯, 내가 쿼리를 던진 딱 그 0.1초의 순간에만 켜져서 연산을 해주고 사라지는 유틸리티(Utility)로 변해가고 있다. "가장 비싼 자원(Compute)을 가장 짧게 쓰게 만든다"는 이 철학을 이해하는 것이 클라우드 네이티브 엔지니어의 핵심 경쟁력이다.
📌 관련 개념 맵
- 선행 기술: 스토리지-컴퓨팅 분리 (501번 문서), 4/6 Quorum 복제 (390번 문서)
- 클라우드 과금 모델: ACU (Aurora Capacity Unit - CPU+RAM을 묶은 서버리스 과금 단위)
- 대척점 모델: Provisioned Database (미리 용량을 정해놓고 24시간 켜두는 일반 DB)
- 해결하는 문제: Over-provisioning (최대 트래픽에 맞춰 비싼 서버를 사놓고 평소에 놀리는 낭비 현상)
👶 어린이를 위한 3줄 비유 설명
- 일반 데이터베이스는 '월정액 무제한 헬스장'이에요. 한 달 내내 매일 가든, 하루만 가든 똑같이 비싼 회비를 내야 하죠.
- 서버리스 데이터베이스는 '코인 노래방'이에요. 내가 평소에는 돈을 1원도 안 내다가, 딱 노래(쿼리)를 부르고 싶은 그 3분 동안만 500원을 넣고 기계(CPU)를 켜서 노는 거랍니다.
- 노래방 기계는 꺼져도 내가 부를 노래 목록(Storage)은 기계 안에 영원히 안전하게 보관되어 있으니 걱정할 필요가 없어요!