[주니어 백엔드 개발자가 반드시 알아야 할 실무 지식] 2.1 응답시간과 처리량

'주니어 백엔드 개발자가 반드시 알아야 할 실무 지식' 책의 공부 내용을 기록하는 포스트입니다.

1장은 인트로의 내용이라 넘어가고 바로 2장부터 시작하겠습니다.

 

2년차 주니어 SI 개발자이지만, 기초가 탄탄하지 않은 것 같아 공부의 필요성을 느끼던 중에 해당 책을 서점에서 발견해 공부하기 시작했다. 공부한 내용을 미래의 나를 위해 기록하기 위해, 추후 내가 개발 공부를 꾸준히 해왔다는 증거의 의미로 공부한 내용을 정리해 포스팅 해 갈 예정이다.

 

 

0. 성능

온라인 서비스를 이용 중에 의도한 결과가 늦게 표시되거나 타임아웃 에러가 발생할 때, 우리는 성능이 나쁘다고 표현한다.

그럼 성능을 결정하는 지표로는 무엇이 있을까. 네트워크 속도, 디스크 속도, 메모리 크기, 디바이스의 CPU 속도 등이 해당한다.

그 중 가장 서버 성능과 관련 있는 중요한 지표를 2가지 꼽자면 응답 시간과 처리량을 들 수 있다.

 

1. 응답 시간

응답 시간은 사용자의 요청을 처리하는데 걸리는 시간을 의미하고, 구체적으로는 API를 호출하고 전체 JSON 응답을 받을 때까지 소요된 시간이 바로 응답 시간이다.

 

요청 ~ 응답 까지의 과정에 대한 자세한 설명은 다음과 같다.

 

요청 ~ 응답 까지의 과정

1) API 요청

- 서버 연결 : TCP를 이용해서 서버에 연결한다.

- 데이터 전송 : 정해진 규칙(프로토콜)에 따라 데이터를 서버에 전송한다. 예를 들어, HTTP 프로토콜에 따라 POST 방식으로 JSON 데이터를 보낼 수 있다.

 

2) 서버 처리 

서버 처리 시간에는 다음과 같은 요소가 있다.

- 로직 수행

- DB 연동(SQL 실행)

- 외부 API 연동

- 응답 데이터 생성(전송)

이 중에서도 DB 연동과 외부 API 연동이 서버 처리 시간에 큰 비중을 차지한다.

따라서 응답 시간을 줄일 필요가 있다면 DB 연동과 외부 API 연동 시간 단축에 집중하는 것이 좋다.

 

3) API 응답

서버가 로직의 실행 결과를 응답 데이터로 클라이언트에 전송할 때, API 요청 과정에서 서버와 연결된 소켓을 이용한다.

 

- 응답시간 측정 지표

• TTFB(Time to First Byte) : 응답 데이터 중 첫 번째 바이트가 도착할 때까지 걸린 시간
• TTLB(Time to Last Byte) : 응답 데이터의 마지막 바이트가 도착할 때까지 걸린 시간

응답 데이터의 크기가 작다면 TTFB와 TTLB의 차이가 크기 않다. 하지만 파일 다운로드처럼 전송할 데이터가 크거나 네트워크 속도가 느리면 TTFB와 TTLB의 차이가 커질 수 있다. 따라서 서버 성능을 정확하게 평가하려면 데이터 특성이나 네트워크 환경을 고려해 TTFB와 TTLB 중 적절한 지표를 선택해 측정해야 한다.

 

[참고] 응답 시간을 고려해야하는 이유

구글의 'Spped Matters for Google Web Search'에 따르면 검색 지연 시간이 길어질수록 사용자당 검색 횟수가 줄어드는 경향이 확인되었다고 한다. 응답 시간이 100ms 증가할 때마다 매출이 1% 감소한다는 내용이었다. 즉, 응답 시간이 증가하면 트래픽과 매출이 줄어들기에 응답 시간의 중요하다는 것을 알 수 있다. 

 

추가로 응답 시간 증가는 사용자 이탈로도 이어질 수 있어 응답 시간을 최대한 줄일 수 있는 방법을 적용하는 것이 중요하다.

 

2. 처리량

처리량은 단위 시간당 시스템이 처리하는 작업량을 의미하고, TPS(Transaction Per Second)나 RPS(Request Per Second)로 처리량을 나타낸다.

 

최대 TPS

• 시스템이 동시에 처리할 수 있는 최대 요청 수를 의미
• 만약 서버가 한 번에 동시 처리할 수 있는 요청 수가 5개이고, 각 요청 처리 시간이 1초라면 해당 서버의 처리량은 5TPS가 된다.(위 그림의 보라색 화살표 참조)
• 동시 요청 수 > 최대 TPS일 경우, 서버는 초과한 요청을 나중에 처리한다(위 그림의 빨간색 화살표 참조)

요청 대기는 사용자 이탈로 이어질 수 있기에 TPS를 최대한 높이는 것이 중요한데, 방법은 다음이 있다.

• 최대 TPS를 늘려 대기하는 요청 수 최대한 줄이기
• 처리 시간 자체를 줄여 대기 시간 줄이기

 

3. 모니터링

성능을 개선하기 위해선 가장 먼저 현재 서버의 1) TPS 와 2) 응답시간을 아는 것이 중요하다. 

- 트래픽이 많은 시간대의 TPS와 응답 시간이 얼마인지 측정하고

- 결과를 바탕으로 목표 TPS와 응답시간을 설정하고

- 효과적인 성능 개선안을 도출해야한다

 

1) TPS 확인

TPS를 확인하는 가장 간단한 방법은 모니터링 시스템을 활용하는 것이다.

참고로 모니터링 도구들은 TPS의 근사치를 계산한다(ex. 5초 간격으로 처리한 요청 수를 5로 나누는 방식으로).

 

관련 모니터링 도구는 다음과 같다. 이를 활용하면 과거 특정 시점 및 실시간 TPS 확인이 가능하다.

• 스카우터
• 핀포인트
• 뉴렐릭

2) TPS 산출

보다 정확한 TPS를 알고 싶다면 웹 서버 접근 로그를 활용하면 되는데 방법은 2가지 읻.

 

- 엘라스틱서치나 핀포인트 같은 별도 시스템에 접근 로그를 수집한 뒤 집계

- 접근 로그 파싱(약간의 리눅스 명령어와 코딩만으로 TPS 산출 가능하다)