서버 비용 최적화 과정에서의 병목 요소 진단과 대응
1. 문제 상황: 예산 초과와 원인 불명 비용
클라우드 환경으로 마이그레이션을 마친 후 몇 개월 지나지 않아 예상보다 훨씬 높은 서버 비용이 청구되었다. 실제 서비스 트래픽은 크지 않았지만, 비용은 매달 증가하고 있었고, 원인을 파악하지 못해 조치를 취하지 못하는 상황이었다.
초기에는 다음과 같은 가설들을 세웠다.
- 과도한 오토스케일링 인스턴스 증가
- 불필요한 EBS 및 S3 리소스 사용
- 로드 밸런서 과다 생성
- 장기 실행 배치 작업 누적
그러나 명확한 근거 없이 어떤 자원을 줄이기엔 서비스 안정성이 걸려 있었다. 정밀한 진단과 분석이 우선이었다.
2. 해결 과정: 비용 병목 진단을 위한 단계별 접근
2.1 AWS Cost Explorer 활용
AWS 콘솔 내 Cost Explorer를 활성화하여 비용이 많이 발생하는 서비스를 분류했다. 분석 결과, 의외로 EC2와 RDS보다도 트래픽이 많지 않은 Elastic Load Balancer(ALB)에서 비용이 많이 나가고 있었다.
상세 리포트를 통해 다음과 같은 문제점을 도출했다.
- 테스트용으로 생성된 ALB가 삭제되지 않고 24시간 활성화 상태
- 모든 리전에서 동일한 테스트 리소스를 운영하고 있었음
2.2 CloudWatch와 Trusted Advisor 분석
CloudWatch를 통해 인스턴스의 CPU 사용률, 디스크 I/O, 네트워크 트래픽을 분석한 결과, 대부분의 EC2 인스턴스가 과소 활용되고 있었다. 평균 CPU 사용률은 15% 미만이었다.
AWS Trusted Advisor의 비용 최적화 보고서도 확인했는데, 미사용 EBS 볼륨과 퍼블릭 IP 유지 비용 등 숨은 비용 요소가 다수 존재했다.
3. 대응 전략: 서비스 영향 없이 비용 최적화하기
3.1 미사용 리소스 정리 자동화
Terraform으로 관리되고 있지 않은 테스트용 리소스들이 비용을 유발하고 있었기 때문에, 리소스 태깅 전략을 수립해 다음을 적용했다.
Environment=dev,Owner=tester태그 지정- 7일 이상 사용되지 않은 리소스를 자동 종료하는 Lambda 함수 작성
예외 대상은 태그로 구분되며, 유지가 필요한 테스트 환경만 지속되도록 구성했다.
3.2 EC2 인스턴스 리사이징
사용률이 낮은 EC2 인스턴스는 t3.medium에서 t3.micro 또는 t4g.small으로 다운사이징했다. ARM 기반의 Graviton 인스턴스를 활용하면 성능은 유지하면서도 최대 20~30%의 비용 절감이 가능했다.
3.3 RDS 예약 인스턴스 도입
항상 켜져 있는 RDS 인스턴스에 대해 1년 예약 인스턴스를 도입했다. 온디맨드 대비 최대 40%의 비용을 줄일 수 있었다.
3.4 CloudFront 캐시 전략 적용
S3에서 직접 서빙하던 이미지 리소스를 CloudFront로 캐싱하게 하여 데이터 전송량을 크게 줄였다. 특히 글로벌 사용자 비중이 있는 서비스일수록 캐시 전략이 비용 절감에 효과적이었다.
4. 지속 가능한 비용 최적화 체계 마련
4.1 비용 모니터링 자동화
매일 아침 슬랙으로 전송되는 비용 보고서를 만들었다. AWS Cost Explorer API와 Lambda를 연동해 특정 서비스별, 태그별 비용 변화를 시각화했다.
4.2 비용 알림 임계값 설정
AWS Budgets를 활용해 월간 예산을 설정하고, 사용량이 80%를 초과하면 이메일과 슬랙 알림이 자동 전송되도록 구성했다.
4.3 주기적 리소스 리뷰 및 청소일 운영
매월 마지막 금요일을 'Cloud Clean Day'로 지정해, 사용하지 않는 리소스를 점검하고 제거하는 팀 내 문화도 함께 구축했다.
5. 최종 정리
서버 비용 최적화는 단순히 인스턴스를 줄이는 일이 아니라, 사용 패턴을 이해하고 자동화 체계를 만드는 것이 핵심이다. 이번 경험에서 얻은 핵심 정리사항은 다음과 같다.
- Cost Explorer와 Trusted Advisor를 통해 원인 정확히 진단
- 미사용 리소스를 태그 기반으로 자동 정리
- 리사이징, 예약 인스턴스, CloudFront 캐싱 전략 적극 활용
- 지속 가능한 비용 모니터링 및 경보 체계 구축
결과적으로 총 클라우드 비용의 약 35%를 절감할 수 있었고, 서비스 안정성에는 영향이 거의 없었다. 이 과정은 인프라 개발자에게 필수적인 역량임을 다시금 깨달았다.