
프로젝트를 진행하면서 AWS 프리티어 EC2 서버를 사용하고 있었다.
프리티어 인스턴스의 메모리는 1GB라서 처음에는 가벼운 서비스 정도는 충분히 돌릴 수 있을 거라고 생각했다.
하지만 프로젝트가 커지면서 문제가 발생했다.
서비스 구조는 대략 이랬다.
처음에는 모든 것을 하나의 서버에서 같이 실행했다.
Spring Boot
MySQL
AI Model
결과는 예상보다 빠르게 나타났다.
서버 다운.
처음에는 단순히 서버가 느려지는 수준이었다.
하지만 어느 순간부터는 아예 서버가 멈췄다.
SSH 접속도 안 되고, EC2 상태를 보면 메모리 부족(OOM) 상황이었다.
1GB 메모리 환경에서 동시에 돌아가고 있던 것들:
특히 Spring Boot의 JVM + Python 모델 메모리 사용량이 생각보다 컸다.
결국 구조 자체를 다시 고민하게 됐다.
가장 쉬운 방법은 EC2 인스턴스를 업그레이드하는 것이었다.
하지만 프로젝트 특성상 프리티어 환경에서 최대한 해결해보고 싶었다.
그래서 두 가지 접근을 했다.
1️⃣ 백엔드와 DB의 메모리 사용량을 줄인다
2️⃣ AI 모델을 서버에서 분리한다
Spring Boot는 기본 설정 그대로 실행하면 JVM 메모리를 꽤 많이 사용한다.
그래서 JVM 옵션을 조정했다.
-Xms256m
-Xmx512m
초기 메모리와 최대 메모리를 제한해서 Spring이 서버 메모리를 과도하게 점유하지 않도록 설정했다.
또한 불필요한 dependency를 제거하고
로깅 레벨도 최소화했다.
MySQL 역시 기본 설정으로 두면 메모리 사용량이 꽤 높다.
그래서 다음 설정을 조정했다.
대표적으로:
innodb_buffer_pool_sizemax_connections프리티어 서버 환경에 맞게 버퍼 크기를 줄이고 연결 수를 제한했다.
결과적으로 MySQL 메모리 사용량을 꽤 줄일 수 있었다.
가장 큰 문제는 AI 모델이었다.
Python 기반 모델은 메모리를 꽤 많이 사용하고,
특히 모델이 로드될 때 메모리를 크게 차지했다.
그래서 구조를 다음처럼 변경했다.
Client
↓
Spring Server
↓
AI Model (same server)
Client
↓
Spring Server
↓
FastAPI AI Server
AI 모델은 별도의 서버에서 FastAPI로 운영했다.
Spring에서는 AI 요청이 필요할 때
POST /predict
API를 호출하도록 만들었다.
이렇게 하면서 얻은 장점은 명확했다.
구조를 변경한 이후
무엇보다 좋았던 점은 인프라 구조에 대해 더 깊이 고민하게 됐다는 것이다.
단순히 "서버 사양을 올리는 것"보다
같은 것들을 실제로 경험해 볼 수 있었다.
이번 경험을 통해 느낀 점은 하나였다.
"문제가 생기면 서버를 키우기 전에 구조를 먼저 고민해보자."
특히 AI 서비스는
를 분리하는 구조가 훨씬 안정적이라는 걸 직접 체감했다.
AWS 프리티어 같은 제한된 환경에서도
구조를 잘 설계하면 충분히 운영할 수 있다는 것도 배웠다.
다음에는 다음 부분도 개선해보고 싶다.
아직 작은 프로젝트지만
이런 기술 고민들이 쌓여서 더 좋은 구조를 만들 수 있다고 생각한다.