이전에 언급했듯, 서버 명목과 프론트엔드 병목은 발생한 위치를 기준으로 구분한다.
- 서버 또는 서버 구성요소(DB, Redis 등)에서 발생 → 서버 병목
- 사용자의 브라우저(JavaScript 실행, 렌더링 등)에서 발생 → 프론트엔드 병목
※ 잘못된 코드로 인해 다수의 사용자가 동시에 느려지더라도
문제가 발생하는 위치는 각 사용자의 브라우저이므로 프론트엔드 병목에 해당한다.그렇다면 병목이 발생한 위치는 어떻게 판단할 수 있을까?
물론 직접 서비스를 사용하며 증상을 체감하거나 사용자 제보를 확인하는 방법도 있지만, 보다 객관적이고 정확한 분석을 위해서는 성능 분석 도구를 활용하는 것이 효과적이다.
이번 글에서는 서버 병목과 프론트엔드 병목을 구분하기 위해 활용할 수 있는 주요 성능 분석 도구와 핵심 지표들에 대해 살펴보겠다.
성능 분석 도구
로딩 속도와 개선이 필요한 영역을 파악해 앱 또는 웹 서비스의 성능을 측정하고 개선하는 데 도움을 주는 도구.
프론트엔드와 서버중 어디서 병목이 일어났는지 파악하려면, 성능 분석 도구를 통해 병목 위치를 먼저 파악하고,
그에 맞는 해결책을 적용하는 것이 핵심이다.
서버 성능 분석 도구
대표적인 도구로는 AWS CloudWatch, Datadog 등이 있으며, 주로 아래 지표를 측정한다.
- API 응답 시간
- CPU / 메모리 사용률
- DB 슬로우 쿼리
프론트엔드 성능 분석 도구
대표적인 도구로는 Chrome DevTools, Lighthouse 등이 있으며, 주로 아래 지표를 측정한다.
- FCP (첫 콘텐츠 표시 시간)
- TTI (인터랙션 가능 시간)
- Long Task (50ms 이상 JS 실행)
- 번들 크기
시스터디 결론
악성 우결충 윤아는 스터디원에게 실시간으로 여자를 소개해주는 WebSocket 기반 웹게임을 만들었다.
그런데 예상치 못한 스터디원의 인기로 동시 접속자가 급증하자 메시지 딜레이와 화면 끊김 현상이 발생했다.
이 문제가 서버 병목인지, 프론트엔드 렌더링 병목인지 어떻게 구분하고 분석할 것인가?
Q. 서버 병목과 프론트엔드 랜더링 병목은 어떻게 구분하고 분석되는가?
A. 서버 병목과 프론트엔드 병목은 병목이 발생한 위치를 기준으로 구분합니다. 서버 또는 서버 구성요소(DB, Redis 등)에서 발생한 문제는 서버 병목이며, 브라우저의 JavaScript 실행이나 렌더링 과정에서 발생한 문제는 프론트엔드 병목입니다.
이를 토대로 우선 유저 경험과 내부 테스트를 통해 문제 상황을 파악하겠습니다. Chrome DevTools의 Network 및 Performance 패널을 활용하여 WebSocket 메시지의 수신 시점과 화면 렌더링 시점을 비교하고, FPS 저하나 과도한 렌더링 여부를 확인하여 어느 구간에서 문제가 발생하는지 먼저 좁혀 나가겠습니다.
이후 성능 분석 도구를 활용해 가설을 검증하겠습니다. 서버 측에서는 CloudWatch나 Datadog을 활용하여 API 응답 시간, CPU·메모리 사용률, DB 슬로우 쿼리, Redis 응답 시간 등을 확인하고, 서버 또는 서버 구성요소의 성능 저하 여부를 분석하겠습니다.
프론트엔드 측에서는 Chrome DevTools와 Lighthouse를 활용하여 FCP, TTI, Long Task, 번들 크기 등의 지표를 분석하고 렌더링 및 실행 성능 문제를 확인하겠습니다.
마지막으로 수집한 지표를 바탕으로 관련 로직과 아키텍처를 추적하여 병목 지점을 좁혀 나가고, 근본 원인을 파악하여 개선 방안을 도출하겠습니다.
이상입니다.
