SSR 서버 최적화로 비용 아끼기

서비스와 트래픽이 늘면서 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 서버를 검토할 수 있다.