[AWS] Aurora DB Serverless V2 전환 - 프로비저닝 Aurora → Serverless v2

AWS 로 내부 인프라를 옮긴 뒤 두번째 달이다. 

 

온프레미스 기반 인프라 → AWS 전환은 인프라는 타 회사에서 CTO를 지내셨었던 대표님의 지인분께서 키를 잡고 진행해주셨다.

이틀 정도에 걸쳐 전환을 진두지휘해 주셨고 나는 보조했다. 지인분께서 우리 서비스를 속속들이 아는 상태는 아니었기에, AWS 전환 설계는 지인분이, 서비스에 맞물린 세부는 내가 맡는 식이었다. 내가 진행해야 할 부분도 꽤 많았던 덕에, 인프라 전환이 실제로 어떤 방식과 절차로 이뤄지는지를 겪어볼 수 있었다. 전환은 업계 표준에 맞춰 진행됐고, 그 과정에서 업계 표준 세팅이 어떤 것인지도 함께 경험할 수 있었다.

당시에는 허겁지겁 따라가기 바빴지만, 그 이후로 어떻게·왜 이렇게 설정됐는지를 면밀히 들여다보고 있다. 1인 개발팀이다 놓치는 것이 없도록 세세한 것 하나하나를 면밀히 보게 된다. 전환된 환경은 업계 표준에 맞춰진 설정이다 보니 우리 서비스의 규모와 사용 패턴에 맞도록 개선할 수 있는 여지가 보였다. 

 

첫 달에는 새 환경에서 서비스가 안정적으로 실행되는지에 집중해서 모니터링했다. 모니터링 하면서 첫 달에 몇가지 수정이 있었고, 이전된 환경에서 서비스는 안정적으로 실행되었다. 별 탈없이 한 달이 지나고, 첫 달 청구서를 확인했다. 예상 비용 이내였으나, 청구서를 받고 보니 실제 운영 중인 리소스 대비 비용이 과하다는 생각이 들었다. 

 

서비스가 안정적으로 실행되는 것을 확인했으니, 이제는 비용 절감에 초점을 맞추기로 했다. 절감안은 당장 적용할 수 있는 것부터, 좀 더 모니터링한 뒤 적용할 수 있는 것까지 단계별로 정리하기로 했고, 청구서를 항목별로 분해한 결과 RDS가 전체의 43%로 가장 큰 비중을 차지했다. 가장 큰 항목부터 최적화 방안을 찾아보기로 했다.

RDS 비용을 분석해 보니, 87%가 컴퓨팅에서 발생한 비용이었고 스토리지 비용은 3%에 불과했다. DB 비용을 줄이기 위해서는 단순하게 보관하는 데이터 량을 줄이면 되지 않을까 ? 싶은데, 실제로는 그렇지 않다.

 

데이터가 당연히 비용에 영향을 미친다. 그렇지만 데이터 자체의 양이 아니라, 데이터를 얼마나 읽고 쓰느냐가 비용에 직접적인 영향을 미치게 된다. 데이터를 실제로 보관하는 데 드는 비용 자체는 크지 않지만, 데이터가 커지만 다음 경로로 비용이 늘 수 있다. 

1. I/O 요청 증가 — 데이터가 커지고 그걸 자주 조회하면 I/O 비용이 올라간다.
2. 인스턴스 크기 상향 — 데이터를 빠르게 조회하려면 더 큰 메모리 인스턴스가 필요하고, 그만큼 컴퓨팅 비용이 증가한다.

Aurora에는 두 종류의 요금제가 있는데, 그중 현재 사용 중인 것은 Aurora Standard 이다. Aurora Standard는 I/O를 요청당 과금한다. Aurora I/O-Optimized를 사용하면 I/O 과금이 없는 대신, 인스턴스가 약 25% 비싸고 스토리지도 2.5배가량 비싸진다. 그러나 우리는 I/O 비용이 전체 비용의 25%를 넘지 않아 Aurora Standard를 유지하고 있다.

 

 

Aurora Standard를 사용중인 우리는 발생하는 I/O만큼 비용을 지불하고 있다. AWS 비용에서 가장 큰 비중을 차지한 RDS를 다시 항목별로 나눠 보면 다음과 같다.

• 컴퓨트 (r6g.large × 2 dev/prd) :  87%
• I/O 요청 : 9%
• 스토리지 : 3%
• 기타 : 1%

비용의 정체는 db.r6g.large 인스턴스를 시간당 얼마에 빌리고 있느냐였다. 따라서 컴퓨팅 비용을 줄일 방안을 고민하기로 했다. 안 쓰는 시간에 꺼도 되는지, 사양을 줄여도 되는지 확인해야 했다. 먼저 CloudWatch로 리소스 사용량을 측정했다.

 

CPU 측정

개발 DB의 CPU 사용률은 평균 10%로 매우 가벼웠다. 대부분의 시간에는 거의 놀고 있었지만, 월초, 월말 배치성 무거운 쿼리가 실행될 때는 시간당 최대 99.6%까지 치솟았다. 

메모리 측정

FreeableMemory 는 남아있는 메모리를 나타낸다. 

최근 한달간 가장 메모리가 적게 남은 순간은 6월 2일 5.40 GiB 남은 순간이다. 

따라서 16 GiB(r6g.large 총 메모리) - 5.4 GiB(남은 메모리 최저값) = 약 10.6 GiB(최대 실사용 값) 을 계산할 수 있다. 

개발 DB는 16GiB 중 10.5GiB를 실제로 쓰고 있었다. DB에서 메모리는 대부분 자주 읽는 데이터를 올려 두어 디스크 접근을 줄이는 버퍼 캐시로 쓰인다. 10.5GiB를 쓰고 있다는 것은 그만큼을 캐시로 유지해 디스크 I/O를 줄이고 있다는 뜻이다. 반대로 이 값을 밑도는 사양으로 줄이면 캐시가 부족해져 디스크 I/O가 늘고, Aurora I/O 비용과 쿼리 지연이 함께 증가한다는 의미이기도 하다.

 

리소스 측정 결과, db.r6g.large를 저렴한 계열로 축소하는 방안은 기각했다. 후보 인스턴스들의 메모리가 실사용 10.5GiB보다 작아 캐시가 부족해지기 때문이다. 대신 불규칙하게 사용되는 개발 DB의 특성에 맞춰 서버리스로 전환하기로 결정했다. Aurora Serverless v2는 Aurora MySQL 3.02 이상이어야 전환이 가능한데, 우리 개발 DB 는 3.12 버전이라서 엔진 업그레이드 없이 전환이 가능했고, 0 ACU 자동정지(이쪽은 3.08 이상 필요)도 함께 지원됐다.

 

ACU 가 뭘까 ? 

Aurora Serverless v2는 프로비저닝의 반대 개념으로, 요청이 오면 그때 용량을 만들어 쓴 만큼만 과금한다. 이때 용량을 세는 단위는 ACU(Aurora Capacity Unit) 이다.

1 ACU는 대략 2GiB쯤 되는 메모리와, 거기에 비례해 딸려오는 CPU·네트워크를 의미한다. Serverless v2는 이 ACU를 부하에 따라 자동으로 오르내리며, 초 단위로 실제 쓴 만큼만 과금한다. 이 오르내리는 범위의 바닥과 천장을 정하는 값이 MinCapacity와 MaxCapacity다.

앞서 언급한 3.08 이상 가능한 0 ACU 자동정지는 MinCapacity를 0으로 설정하는 것을 의미한다. 최소 용량을 0으로 설정해두면 접속이 없을때 완정 정지하며, 이때 컴퓨팅 과금은 $0이 된다. 이렇게 완전 정지가 되면, 첫 접속 시 10~15 초 콜드 스타드가 발생하는데, 개발 DB에서는 문제가 되지 않기 때문에 MinCapacity를 0으로 설정하기로 결정했다. MaxCapacity 는 현재 실사용 메모리가 10.5GiB 로 측정되었기 때문에 기존 r6g.large 와 동일한 한도인 8ACU(16GiB) 로 설정해두기로 결정했다. 

 

전환절차

step 1. 스냅샷 확보

• Aurora and RDS 콘솔 → 클러스터 선택 → 작업 → 스냅샷 생성
• 롤백용으로 먼저 확보 한다. 

 

 

 

step 2. 인스턴스 클래스 변경

• Aurora and RDS 콘솔 →  인스턴스 선택 → 수정 → DB 인스턴스 클래스 에서 Serverless v2를 선택했다. 앞서 결정한대로 MinCapacity는 0ACU, MaxCapacity는 8ACU 로 설정했다. 

 

 

Step 3. 적용

1인 개발팀이라 조율이고 뭐고 할 것도 없었다. 내 일정만 확인하면 됐다. 수정 예약 화면에서 "즉시 적용"을 선택한 뒤 저장했다. 인스턴스가 재부팅되며 수 분간 끊긴다(개발 DB라 무관). 상태가 "사용 가능"으로 돌아오면 완료다.

 

이후 엔드포인트는 바뀌지 않는다. 인스턴스의 스펙을 바꾸는 것이지 주소를 바꾸는 것이 아니므로 앱의 연결 설정을 건드릴 필요가 없다. 서버리스 전환 후에는 총 메모리가 ACU 에 따라 변하므로 CloudWatch 에서 ServerlessDatabaseCapacity(현재 ACU)와 ACUUtilization(상한 대비 %) 지표를 봐야 한다.

 

AWS 비용에서 가장 큰 비중을 차지한 RDS를 항목별로 다시 나눠, 그중 가장 큰 컴퓨팅 비용부터 가장 빠르게 적용할 수 있는 방법으로 최적화했다.

 

예상 절감

계속 켜뒀을 때 개발 DB 컴퓨팅은 월 약 $228이었다. 서버리스로 바꾼 뒤에는 안 쓰는 동안 용량이 0에 가깝게 내려가고, 실제 쓴 만큼만 초 단위로 과금된다. 개발 DB는 CPU 평균 10%로 부하가 가벼우니, 계속 켜뒀을 때의 절반 이하로 줄어들 것으로 예상한다. 

가지고 있던 절감안 중에서 제일 빠르게 진행할 수 있을 것 같은 것부터 먼저 손댔다. 1인 개발팀이다 보니, 청구서가 나오면 어깨가 무거워진다. 다 논의를 거쳐 나온 비용인데도, 숨이 턱 막히고 머릿속엔 '최적화'밖에 떠오르지 않는다. 이제는 이번보다는 좀 더 고민이 필요한 것들이 남아 있다. 아무래도 가장 쉽게 해결할 수 있는 것부터 손댔기 때문에.. 사실 실제 적용 하는 것은 순식간이다(서버리스로의 전환도 AWS 콘솔에서 버튼 3개 정도만 누르면 된다) 정작 오래 걸리는 건 그걸 결정하기까지 이것저것 확인하는 과정이다. 결정을 할 때 그 이유에 대해서 내가 100% 논리적으로 설명할 수 있기 위해서는 확인할게 많다. 인프라 변경은 한번 전환하면 되돌리기 어려워질 수 있기 때문에 가장 보수적인 방법으로 움직이게 된다.