AWS EC2 서버 다운스케일해 비용절감하기
AWS EC2 r6i.2xlarge에서 r6i.xlarge로 데이터 웨어하우스 서버를 다운스케일하여 월 $698의 비용을 절감한 실제 사례와 검토 과정을 상세히 설명합니다.
개요
많은 분들이 다운스케일이라고 하면 곧바로 성능 저하를 걱정하실 것입니다.
하지만 철저한 사전 검토와 튜닝을 통해, 서버 사양을 줄이면서도 성능 저하 없이 안정적인 운영을 이어갈 수 있습니다.
이 글에서는 데이터 웨어하우스(Data Warehouse, DW)로 사용 중인 서버의 다운스케일 과정을 공유해 드립니다. 성능과 비용을 모두 고려하여 r6i.2xlarge 인스턴스에서 r6i.xlarge 인스턴스로 스펙을 축소한 과정을 설명합니다.
목표
인스턴스 변경 계획
현재 상태: r6i.2xlarge
목표 상태: r6i.xlarge
예상 비용 절감: 월 $706 절감
일반적으로 Aurora로 r6i.2xlarge를 운영할 때 월 비용 $1022가 지출됩니다.
그러나 스펙다운을 타겟으로 한 EC2 서버에서 Volume을 사용하는걸로 구축이 되어 있었고 윈도우 SQL Server edition으로 사용 중이었습니다. 이 경우 윈도우 라이선스 비용이 추가로 붙게 됩니다. 그래서 월 비용은 $1412.28이 지출됩니다. 그리고 한단계 다운스케일 할 경우 월 비용은 $706.64로 줄어듭니다. 따라서 스펙을 한 단계 낮출 경우 월 비용 $706을 절감할 수 있습니다.
아래는 r6i.2xlarge로 운영되던 서버의 비용을 한단계 낮춘 뒤 비용 지출이 절반으로 줄어든 모습을 보여줍니다.
비용 비교
중요 포인트
EC2에서 직접 데이터베이스를 운영할 경우 RDS보다 저렴합니다. 다만 이를 운영할 수 있는 숙련된 DBA가 필요할 수 있습니다. Windows 라이선스 비용이 Linux 대비 약 4배 높습니다.
여담으로 Windows Server는 비용 효율적인 AWS의 Graviton 프로세서 기반(r6g 시리즈) 인스턴스를 사용할 수 없습니다.
실행 정보
계획 실행일: 2025년 2월 25일
영향 받는 서비스: 데이터 웨어하우스(DW) 서버
다운타임: 예상 5분
스펙 비교 분석
인스턴스 스펙 상세
검토 결과
위의 표에서 표현된 떨어지게 되는 성능이 현재 수준에서 문제 없는지를 종합적으로 판단하면 됩니다. 검토 결과 Microsoft SQL Server의 메모리가 가장 걱정되는 지점이었습니다. 현재 SQL Server에서 사용하는 메모리 설정을 32GB → 24GB로 조정하면 성능에 문제가 없을 것으로 판단하여 다운스케일을 결정했습니다.
상세 검토 내용
1. CPU 사용량 분석
최근 1주일 동안의 모니터링 결과는 아래와 같습니다.
CPU 사용률 평균: 50% 이하 유지
CPU 사용률 최대치: 30% 수준
결론: CPU 리소스에 충분한 여유가 있음
2. 메모리 사용량 분석
시스템 가용 메모리 확인
Windows PowerShell 명령어로 확인한 Available Memory:
Get-Counter "\\\\Memory\\\\Available MBytes"
결과: 18,167MB의 여유 공간이 확인되었습니다.
SQL Server 메모리 사용량 분석
메모리 사용 현황:
전체 메모리: 64GB
현재 사용 중: 약 46GB
SQL Server max server memory 설정값: 40GB
현재 SQL server는 40GB 메모리를 사용하도록 설정되어 있었고 풀로 사용중이었습니다.
3. Buffer Pool 메모리 최적화
버퍼풀 메모리 사용을 검토하기 위해 PLE(Page Life Expectancy)를 확인했습니다.
PLE는 Buffer Pool 내 데이터 페이지가 유지되는 평균 시간(초)을 의미합니다.
PLE가 낮으면(300~500 이하) 메모리가 부족하여 SQL Server가 지속적으로 디스크 I/O를 수행 중일 가능성이 큼.
PLE가 높으면 SQL Server가 충분한 Buffer Pool 메모리를 가지고 있으며 다운스케일이 가능할 수 있음.
PLE가 1000 이상이면 현재 Buffer Pool 크기를 줄여도 성능 저하 위험이 낮음
PLE 메모리 설정에 따른 지표 테스트
초기 상태: 33,092초(약 9시간)
23GB 테스트: 595초(약 10분)로 급격한 감소
최종 24GB 설정: 10,000초 이상 안정적 유지
현재 40GB 할당 기준으로 PLE가 매우 높았기 때문에 23G로 줄이고 테스트해보았습니다. 하루 뒤 확인 시 595로 떨어진 것이 확인되었고 24GB로 늘렸을 때 10000 이상으로 안정된 값이 확보되었습니다. PLE가 높을 경우 디스크 I/O를 높일 가능성이 있고 이는 CPU 성능에도 영향을 줄 수 있습니다.
4. 디스크 스왑 최적화
디스크 스왑이 활성화된다면 I/O로 인한 병목이 가능합니다.
Windows Page File 설정:
현재 최대 사용량: 188MB (미미한 수준)
수동 설정값: 2GB (안정성 확보)
https://gist.github.com/japing81/71455f0a8ed4346da3d4328492927c10
현재 기준 Windows Page File은 188MB를 사용 중으로 스왑메모리가 거의 사용되지 않앗다는 의미입니다. 현재 스왑 사용량은 무시할 수 있는 수준이나 안정적인 운영을 위해 부수적으로 2G로 셋팅했습니다.
5. Buffer Pool 캐시 분석
버퍼풀에 저장된 캐시를 분석하고 빠르게 최적화할 부분이 있는지 검토합니다. 아래 명령으로 가장 많이 캐싱된 테이블을 조회하여 필요 없는 대량 데이터가 버퍼 풀을 점유하고 있는지 점검했습니다.
과도한 메모리를 사용하는 곳에 인덱스 추가해 사용량 줄일 수 있도록 조치했습니다. 더불어 인덱스가 없는 테이블도 발견해 인덱스를 추가했습니다. HEAP 테이블(인덱스가 없는 테이블)이 많다면 커버링 인덱스 또는 클러스터형 인덱스 추가를 해줄 필요가 있습니다.
6. 시스템 성능 지표 분석
기타 주요 시스템 성능 지표를 분석했습니다.
IOPS: 최대 850
EBS 대역폭: 40% 이하 사용
네트워크 트래픽: 현재 사용률 10% 이하 다운스케일 후 20% 속도 감소 예상되지만 문제 없다고 판단
IOPS의 경우 일반적인 gp3 볼륨은 기본으로 3,000 IOPS를 제공합니다. 850은 충분히 처리 가능한 수준으로 판단했습니다.
EBS 대역폭은 40% 이하라면다운 스케일이 가능합니다. 대역폭이 10Gbps에서 5Gbps로 절반으로 줄 예정으로 만약 70%를 상회할 경우 성능 저하의 가능성이 있습니다.
서버 스펙 변경 후 모니터링 결과
다운스케일 후 다음날 DW 적재 및 DM(Data Mart) 집계 프로세스 정상 동작 여부를 확인했습니다. 현재는 서버 스펙 변경 후 한달 이상이 자났으며 종합적으로 다운스케일과 관련된 성능 이슈는 전혀 발생하지 않았습니다.
CPU 사용률 다운스케일 후 CPU는 맥스 55.6%로 다소 높아졌습니다. 이는 기존 데이터 백업 및 데이터를 원본 데이터베이스로 이관하는 작업 중에 꾸준히 발생하고 있으나 그 수준을 계속 유지하고 있습니다.
메모리 사용량 32GB의 메모리가 줄어들었으나 여유 메모리는 18GB -> 3.6GB로 여전히 유지되고 있습니다.
PLE(Page Life Expectancy) 26989로 안정적인 값이 유지되고 있습니다.
IOPS 최대치 800 정도로 다운스케일 이후에도 전혀 높아지지 않았습니다.
네트워크 입력 최대 340M로 최대치 10GBps 대비 문제가 없습니다.
마치며
이번 다운스케일 프로젝트는 단순한 비용 절감을 넘어 서버 자원과 SQL Server 운영 환경을 전반적으로 최적화하는 의미 있는 과정이었습니다.
이번 경험을 통해 다시 한 번 느낀 점은, "다운스케일은 단순히 사양을 줄이는 작업이 아니라, 시스템을 깊이 이해하고 균형 잡힌 의사결정을 하는 과정"이라는 것입니다.
메모리, CPU, 디스크 I/O, 네트워크 트래픽과 같은 각각의 요소가 서로 긴밀하게 연결되어 있기 때문에, 표면적인 리소스 수치만을 보고 결정하는 것은 위험할 수 있습니다.
특히
• SQL Server의 Buffer Pool 운용 상태
• 디스크 스왑 발생 가능성
• EBS 대역폭과 IOPS 여유 여부
를 꼼꼼히 점검하고 대응한 것이 이번 다운스케일 성공의 핵심 포인트였습니다.
또한, 예상보다 빠르게 안정성과 비용 절감 효과를 모두 검증할 수 있었던 것은 사전 시뮬레이션과 단계별 테스트를 철저히 수행했기 때문이라고 생각합니다.
Note: 이 글은 저희 프로덕션 환경에서의 경험을 바탕으로 작성되었습니다. 여러분의 환경에 적용하실 때는 반드시 충분한 테스트와 검증을 거쳐 주시기 바랍니다.
FinOps 커뮤니티에 함께 하실래요?
저는 최근 48%, $36000의 AWS 비용절감을 달성했습니다.
클라우드 비용을 효율화하고 싶은 분들, 비슷한 고민을 나누고 싶다면 제가 운영 중인 AWS-FINOPS-KR Slack 커뮤니티에 참여하세요. 실제 절감 사례, 질문, 전략 공유를 나누실 수 있습니다.
