트래픽은 적은데 부하는 높은 서비스에서 할 일

서비스를 운영하다 보면 방문자가 아주 많지 않은데도 서버가 꾸준히 버거워하는 경우가 있다. 내가 팜스테이션 관리 사이트를 다루며 자주 본 장면도 그랬다. 원인은 대개 단순했다. 요청 수보다 요청 한 번이 먹는 비용이 컸고, 파일 처리나 외부 연동, 후속 작업이 한 번에 몰려 있었기 때문이다. 그래서 처음부터 트래픽 숫자만 보고 판단하지 않고, 어떤 요청이 CPU와 메모리와 저장소를 오래 붙잡는지 먼저 나눠 보는 습관이 생겼다.

실무에서 가장 효과가 컸던 방법은 사용자가 기다려야 하는 일과 나중에 처리해도 되는 일을 분리하는 것이었다. 관리 화면은 바로 응답하되, 시간이 걸리는 후속 처리는 SQS로 넘기고 결과물은 S3를 중심으로 정리했다. Spring Boot 쪽에서는 한 요청 안에 너무 많은 책임이 몰리지 않도록 흐름을 쪼갰다. 이렇게 구조를 나누면 겉보기에는 작은 변화 같아도, 장애가 났을 때 어디가 막혔는지 훨씬 빨리 찾을 수 있었다. AWS Elastic Beanstalk를 쓰는 환경에서는 이런 분리가 특히 중요했다.

또 하나 배운 점은 운영자는 평균보다 순간적인 체감에 더 민감하다는 사실이다. 전체 요청 수가 낮아도 특정 시간대에 업로드나 집계가 겹치면 "오늘 왜 이렇게 느리지"라는 반응이 바로 나온다. 그래서 성능 개선도 거창한 튜닝보다 병목 구간을 줄이는 데 집중했다. 응답 경로에서 꼭 필요하지 않은 작업을 뒤로 미루고, 파일과 데이터 저장 위치를 분리하니 체감 속도가 눈에 띄게 나아졌다.

이 경험 이후로 나는 부하 문제를 볼 때 "사용자가 몇 명인가"보다 "한 요청이 얼마나 무거운가"를 먼저 묻는다. 적은 트래픽 서비스라도 처리 단위가 크면 구조를 잘못 잡았을 때 금방 피로해진다. 다음에도 비슷한 운영형 서비스를 맡는다면 기능 추가보다 먼저 동기 처리와 비동기 처리의 경계를 다시 점검할 것이다.