AWS 용량 판단하기

요약

완벽한 스펙을 처음부터 계산하는 것은 쉽지 않다.

일단 작게 만들고, 모니터링 후 필요하면 올리는 전략을 사용한다. → dev, beta 에서 충분히 테스트 진행.

보수적인 스펙 (t3.medium , m5.large 등) 으로 시작하고 CloudWatch, Grafana 등 알람 설정, 모니터링 후 기준 사용치 초과하면 조정.

 

--

 

DevOps 엔지니어라면 EC2 인스턴스나 RDS를 만들 때 한 번쯤 이런 생각을 해본 적 있을 것이다.

"이 서비스, t3.medium으로 충분할까? 아니면 m5.large로 가야 하나?"

명확한 기준 없이 감으로 정하거나, 무조건 크게 잡아두는 경우가 많다.

실무에서 사용하는 판단 기준을 정리해본다.

 

- 기존 리스소를 참고한다.

가장 빠르고 현실적인 방법. 같은 환경에서 유사한 역할을 하는 리소스가 어떤 스펙을 쓰는지 확인

이미 운영 중인 서비스들이 검증된 스펙을 쓰고 있기 때문에, 비슷한 트래픽과 역할이라면 그대로 따라 가는것이 안전하다.

dev : prod보다 1~2단계 아래

beta: prod와 동일하거나 1단계 아래

dev: 부하 테스트 또는 실측 데이터 기반

 

- 실제 사용량 측정 (운영 중인 경우)

이미 서비스가 올라와 있으면 Cloudwatch나 Grafana에서 CPU, 메모리 등 사용량을 확인.

 

- 다운사이즈를 고려해야할 때

ㄴCPU 평균 사용량이 20~30% 이하 지속될 때

ㄴ메모리 사용률이 50% 미만으로 안정적일 때

 

- 업사이즈를 고려해야할 때

ㄴCPU 스파이크가 자주 발생하고 응답 지연이 생길 때

ㄴ메모리 사용률이 70% 이상이 계속해서 유지될 때

 

- OOM 이슈가 반복될 때

ㄴ1~2주 동안 측정하는 것이 권장 → 월말, 월초 트래픽이 많을 수 있기 때문에 (배치 등)

 

- 서비스 특성으로 판단

데이터가 없는 신규 서비스라면, 서비스의 성격으로 인스턴스 계열을 선택.

API 서버 : CPU / c 계열

DB, 캐시 : 메모리 / r, x 계열

배치, 데이터 처리 : 일시적 고부하 (spot 인스턴스)

Spring boot 기반 java API 서버라면 JVM 메모리를 고려해서 최소 2GB RAM 이상을 확보하는 것을 권장,

t3.medium(2vCPU, 4GB)이 dev 환경 기본값으로 많이 쓰인다.

 

- Kubernetes / EKS 환경은 pod 스펙을 중점적으로 확인

Pod의 request / limit 값 설정

request : 평균 사용량 기준

limit : 최대 사용량 기준

request 를 너무 낮게 잡으면 pod가 한곳에 몰리고, 너무 높으면 노드가 낭비됨 → 보장하는 값

 

- Java 서비스 메모리 계산 예시

컨테이너 메모리 limit 을 잡을 때는 Heap 만 고려하면 안됨.

limit = heap + Metaspace + Thread stack + Native Memory 등 여유롭게 잡아야함

대략 heap * 1.5~2 배를 잡는 것을 권장