SSR 서버 최적화로 비용 아끼기
정진우/문현경 토스 · 토스 기술 블로그
AI 핵심 요약
서비스와 트래픽이 늘면서 SSR 서버 수가 많아지자, 토스는 같은 트래픽을 더 적은 자원으로 처리하기 위해 성능 측정과 최적화에 나섰다. Pod 배치에 따른 편차를 없애는 전용 환경을 마련하고, K6 벤치마크와 CPU·Event Loop 지표, Profiling 및 OpenTelemetry 추적으로 병목을 분석했다. React Query 캐시의 serializer를 제거하고 Yarn을 3.6.1 이상으로 업데이트했으며, Express를 Node.js 내장 HTTP 서버로 바꾸는 등 불필요한 오버헤드를 줄였다. 그 결과 CPU 사용률을 평균적으로 약 20% 낮춰 SSR 서버 대수를 줄였으며, 신뢰할 수 있는 측정 환경과 런타임 이해가 최적화의 기반이라는 점을 확인했다.
- 벤치마크 결과를 신뢰하려면 Pod 배치와 호스트 자원 같은 변인을 통제한 전용 측정 환경이 필요하다.
- Maximum RPS만 보지 말고 CPU·메모리 사용량과 Event Loop Lag·Utilization을 함께 확인해야 한다.
- K6와 CPU Profiling, OpenTelemetry 추적으로 병목이 발생하는 컴포넌트와 작업을 구체적으로 찾아낼 수 있다.
- SSR 데이터가 직렬화 가능한 구조라면 불필요한 serializer 단계를 제거해 렌더링 오버헤드를 줄일 수 있다.
- 서버 요구사항에 맞지 않는 프레임워크 기능은 비용이 될 수 있으므로, Express 대신 Node.js 내장 HTTP 서버를 검토할 수 있다.
소개
오늘은 SSR 아키텍처 운영을 위해 반드시 알아두어야 할, SSR 서버의 최적화와 관련된 이야기를 해보려 합니다. 최적화를 통해 토스는 서비스 운영에 필요한 SSR 서버의 수를 절감하여 비용을 개선할 수 있었습니다.
비슷한 학습 자료
문서 토스 프론트엔드 챕터
프론트엔드 서비스 최적화? 토스에서는 '이렇게' 합니다! | EP.9 모닥불
문서 정석호
200여개 서비스 모노레포의 파이프라인 최적화
문서 함종현
서버 증설 없이 처리하는 대규모 트래픽
문서 박명순