iwinv VM 한 대로 어디까지 가능한가 — 6개월 측정치

팀이 작으면 인프라 예산도 작다. 우리는 국내 클라우드 iwinv 에서 2vCPU / 2GB RAM / SSD 50GB 사양의 VM 한 대로 여러 서비스를 6개월째 운영 중이다. 이 글은 실제 측정치를 기반으로 어디까지 가능하고 어디서 막히는지를 정리한다.

운영 중인 것들

단일 VM 위에서 돌리고 있는 주요 항목은 다음과 같다.

• nginx (리버스 프록시 + 정적 파일 서빙)
• Java 애플리케이션 서버 (스프링 기반)
• MySQL 8.x (Docker)
• Redis (Docker)
• Node.js 기반 정적 사이트 (Astro 빌드 결과물 서빙)
• 관리용 웹 툴 (Docker)

여기에 swap 2GB 를 추가해 메모리 압박을 완충한다.

6개월 측정치 요약

메모리: 평상시 사용량은 1.4~1.6GB 수준. 배포 직후 Java 애플리케이션 JVM 워밍업 구간에서 1.9GB 까지 올라간 적이 있다. 이때 swap 이 없었다면 OOM 킬러가 작동했을 것이다.

CPU: 평균 515% 점유. 배치 작업이 실행되는 시간대에 5070% 까지 올라간다. 피크 구간이 짧고 예측 가능하기 때문에 지금까지 문제가 없었다.

스토리지: 6개월 동안 로그 누적으로 약 18GB 소비. 주기적인 로그 로테이션이 없었다면 디스크 가득 차서 서비스가 멈췄을 것이다. 자동 로테이션 설정은 필수다.

네트워크: 일 트래픽 20GB 제한이 있다. 지금까지 초과한 적은 없지만, 대용량 파일 업로드나 미디어 서비스를 추가할 경우 CDN 없이는 곧 한계에 부딪힐 것이다.

운영하면서 배운 것

Docker Compose 로 묶어서 관리하면 편하다. 서비스 간 의존성을 선언적으로 관리하고, docker compose down && docker compose up -d 한 줄로 전체를 재시작할 수 있다. 수동으로 PID 추적하는 것보다 훨씬 안정적이다.

배포 순서가 중요하다. Java 앱을 재시작하면 JVM 워밍업 동안 메모리 스파이크가 생긴다. 이 시간대에 배치 작업이 겹치지 않도록 배포 시간을 트래픽 최저 구간으로 고정했다.

모니터링은 간단할수록 지속된다. 복잡한 모니터링 스택을 붙이면 그 자체가 리소스를 잡아먹는다. 우리는 htop 과 주기적인 df/free 확인, 그리고 nginx 접근 로그 요약으로 운영한다.

한계

동시 접속이 증가하거나 DB 부하가 올라가면 이 사양은 빠르게 병목이 된다. 지금은 트래픽 규모가 작아서 괜찮지만, 서비스가 성장하면 DB 분리가 첫 번째 개선 조치가 될 것이다. 2vCPU / 2GB 는 팀 내부 도구와 소규모 서비스의 안정적인 범위라는 것이 6개월의 결론이다.

— by mings