들어가며
운이 좋게도 서버 개발자 커리어 처음부터 비교적 트래픽이 많은 서버를 개발하고 관리하고있다.
최근엔 사내 모든 서비스들의 데이터를 저장하고 서빙하는 허브 역할의 서버를 개발하게되면서 상상이상의 높은 트래픽을 경험중이다.
그러다보니 자연스레 서버 성능에 대한 관심이 깊어져 관련된 내용을 많이 공부하다 글로 정리하면 좋을 듯 싶어 이렇게 글을 작성한다.
서버 성능에 대한 이야기는 아래 두 가지 주제로 작성할 예정이며, 이 글은 그 첫번째인 “성능 테스트를 통한 서비스 병목점 찾기”에 대해서 정리한다.
- 성능 테스트를 통한 서비스 병목점 찾기
- 서버 성능에 영향을 주는 요소
이번 글은 서버 개발자가 서버 성능에 대해서 왜 꼭 알아야하는지에 대한 이유를 시작으로, 서버 성능에 대한 평가 지표와 성능 테스트를 통해 어떤 부분을 개선해나가야하는지 설명한다.
1 왜 서버의 성능에 대해서 알아야할까?
💁♂️ 서버 성능이 서비스에 끼치는 영향은 생각보다 크다
서버 성능에 대해서 살펴보기전에 서버 성능이 서비스에 어떠한 영향을 끼치는지 고민해보면 좋을 것 같다.
기본적으로 내가 생각하는 서비스의 목적은 고객 창출과 고객 만족이다. 그리고 당연히 이를 통해 서비스는 이윤을 만들어 더 나은 서비스를 만들어나간다.
즉, 서버의 성능의 개선 및 저하가 고객 유입에 대해 크게 작용하며, 이는 서비스의 직접적인 영향을 끼치게된다.
실제로 구글에선 모바일 사이트내 응답이 3초가 넘으면 절반 이상(53%)이 서비스를 포기한다고 발표했다.
이 3초안에는 웹페이지 랜더링도 포함될테니 서버 입장에선 네트워크 포함 최대 3초내로 응답을 해줘야한다.
그렇지않으면 53%의 사용자가 떠난다.. 아무리 서비스가 좋고 유익하더라도 서버의 응답이 늦으면 점차 서비스의 이용률이 떨어지는건 어쩌면 당연하다.
물론 트래픽이 적으면 크게 신경 안써도 되지만, 트래픽이 많거나 확 몰리는 서버라면 서버 성능에 대한 이해가 필수라고 볼 수 있다.
왜냐하면 이를 이해해야 어떤 부분이 문제인 지 판단 할 수 있으며, 어떤 부분을 최적화하고 개선할 수 있을지 알 수 있기 때문이다.
💁♂️ 서버 개발자 입장에서 생각하는 서버 성능이 서비스에 끼치는 영향
위에서 언급한 영향외에도 서버 개발자 입장에서 느끼기에 서버 성능이 서비스에 끼치는 영향은 생각보다 굉장히 크다.
- 서버 응답 속도에 따른 사용자 경험.
- 앞서 살펴본대로 3초 이상 응답이 늦으면 반이상이 서비스를 떠난다.
- 즉, 응답속도가 고객 만족에 큰 영향을 끼친다.
- 폭발적으로 트래픽이 증가했을 때 견디지못해 발생하는 손실
- 서버 개발을 완료하고 해당 서버가 오류 없이 동작한다해도, 실제로 대규모 사용자에게 서비스를 한다는 것은 다른 영역이다.
- 보통 트래픽이 폭발적으로 늘어나면 점차 서버의 문제점들이 발견된다. 예를 들면, 비효율적인 비즈니스 로직, 스레드 밀림, Slow Query, Lock으로인한 병목 등등.
- 이때 트래픽을 견디지못하고 서버가 죽거나 지연이 발생하면 이는 자연스레 서비스의 운영 손실로 이어진다. 즉, 서버의 성능은 서비스 매출에도 지대한 영향을 끼친다.
- 서버 비용 (서비스 운영 비용)
- 서버 개발자 입장에선 서비스의 지출도 신경써야하기에, 서버 비용을 무시할 수 없다. 서버 비용이 결국 서비스 운영 비용으로 귀결되기 때문이다.
- 동일한 컴퓨터 사양에서도 최대한 빠른 응답과 높은 처리량을 수행하는 효율적인 서버를 구성해야한다.
💁♂️ 위와 같이 서버의 성능이 서비스에 끼치는 영향은 굉장히 크다. 그러므로 서버 개발자의 의무는 서버의 성능이 떨어져 서비스에 영향을 주지 않도록 하는 것이다.
조금 진부한 얘기일 수는 있지만.. 서버 개발자의 역할중 하나는 서버 구조내 병목 부분을 찾아 가능한 빠르고 효율적이게 지속적으로 개선해나가는 것이다.
자신이 개발하고 관리하는 서버의 성능 부분에서 어떤 부분이 병목점이고 어떤 부분을 개선할 지 모른다면 개인적으로 서버 개발자로서 직무유기라고 생각한다.
서버의 성능이 서비스에 영향을 끼치지않게하기위해 성능 좋은 서버를 만들기위해선 가장 먼저 서버의 문제점을 진단하는 것이며, 이는 성능 테스트를 통해 진단 할 수 있다.
성능 테스트의 결과에 따라 서버 성능에 영향을 주는 병목점을 찾고 개선해나가야한다.
2 서버 성능테스트를 통한 서버 성능 측정
서버 성능에 대해서 이야기하기위해선 성능의 높고 낮음을 판단하는 지표에 대한 이해가 필요하다.
그리고 어떤 부분을 개선해야하는지도 명확히 진단해야한다.
2-1 왜 성능 테스트를 해야하는걸까?
💁♂️ 성능 테스트란?
성능 테스트란 말 그대로 서버의 성능을 측정하기위해 인위적인 부하를 일으키는 작업이다.
서버에 부하를 일으킴으로써 서버가 어느정도의 부하를 견디고 처리할 수 있는지를 수치로 측정 할 수 있다.
성능 테스트도 여러가지 종류가 존재하는데 보통은 아래 3가지를 많이 이야기하는 듯 하다.
- smoke
- 최소한의 부하로 테스트 시나리오 오류를 검증하는 테스트. (VUser: 1~2)
- load
- 서비스의 평소 트래픽과 최대 트래픽을 서버가 견딜 수 있는지 검증하는 테스트.
- 평소 트래픽이 들어왔을떄 서버의 기능이 정상 동작하는지 검증한다.
- 보통 배포, 인프라 변경시 성능 변화를 테스트하기 위해 수행된다.
- stress
- 서비스의 한계점을 확인하는 테스트.
- 트래픽이 갑자기 폭발적으로 증가했을 때를 가정하여 테스트.
- 보통 최대 사용자, 최대 처리량등의 서버 한계점등을 확인한다.
💁♂️ 그렇다면 왜 성능 테스트를 진행할까?
앞서 말했듯이 서버 개발자가 가지고있어야 할 기본은 서버를 빠르고 효율적으로 만드는 것이다.
서버의 성능을 빠르고 효율적으로 만들기위해선 기본적으로 서버내 병목 부분을 찾아 해결해야한다.
즉, 성능 테스트의 목적은 현재 서버가 최대 몇 명의 사용자를 수용할 수 있을지 측정하고, 만약 희망하는 성능에 부합하지 않는다면 어떤 부분에서 병목이 발생하는지 찾기위함이다.
그리고 병목되는 부분을 발견했다면 분석 및 개선을통해 서버의 전반적인 성능을 올려야한다.
2-2 서버의 빠름과 느림의 기준
💁♂️ 서버 성능의 빠름과 느림의 기준은 무엇인가?
앞서 말했듯이 서버의 성능은 부하 테스트를 통해 측정한다. 이때 측정하는 지표를 통해 성능의 빠름과 느림을 판단한다.
상황별로 다양한 지표를 산출할 수 있겠지만, 아래 3가지가 보편적으로 사용된다.
- Throughput
- Latency
- Bandwidth
세 가지 지표의 관계를 파이프라인에 물을 흘려보내야하는 파이프 사례로 비유하면 아래와 같다.
물이 사용자의 요청이라고 비유하면 파이프의 넓이가 Bandwidth, 일정 시간내 파이프를 지나친 물의 양을 Throughput, 파이프의 길이가 Latency라고 볼 수 있다.
각각의 자표를 조금 더 자세히 살펴보면 아래와 같다.
1️⃣ Throughput
Throughtput이란 시간당 처리량을 의미한다. 대표적으로 TPS, TPM이 존재한다.
- TPS (Throughput Per Second)
- 1초에 처리되는 단위 작업의 수를 산출한 지표이다.
- HTTP 웹서버라고 가정한다면 1초에 처리가능한 HTTP 요청수를 수치화한 것이다.
- TPM (Throughput Per Minute)
- 1분에 처리되는 단위 작업의 수를 산출한 지표이다.
TPS말고 RPS (Request Per Second)라고도 얘기하는 경우가 많다.
쉽게 생각해서 A 서버가 1초에 500개의 작업을 처리하고 응답했다면 TPS 500/s이고, B 서버가 1초에 1000개의 작업을 처리하고 응답했다면 TPS는 1000/s이다.
당연히 높을 수록 좋기때문에 B 서버가 동일 시간내에 더 많은 작업을 수행하므로 성능면에서 더 좋다고 볼 수 있다.
파이프 예시로 비유하면 동일 시간내 더 많은 물을 흘려보낸 것이다.
2️⃣ Latency
Latency란 클라이언트가 요청하고 응답받기까지 걸리는 시간을 의미한다. (응답 시간)
즉, Latency는 서버가 작업을 얼마나 빠르게 처리할 수 있는지를 나타내는 성능 지표다.
영어 뜻 그대로는 지연시간이라는 의미이며, 클라이언트가 요청하고 응답을 받을 때까지 어느정도의 지연시간이 발생하는지를 나타내는 지표를 의미한다.
쉽개 생각해서 클라이언트가 A 서버로부터 100ms만에 응답을 받았고, B 서버로부터는 50ms만에 받았다면 B 서버가 성능이 더 좋다고 볼 수 있다.
파이프 예시로 비유하면 물이 흘러가는 파이프의 길이가 Latency가 될 수 있다.
3️⃣ Bandwidth
Bandwidth는 대역폭의 의미로 단위 시간당 전송할 수 있는 데이터의 양을 의미한다. 대표적으로 bps (bits per second) 단위로 측정된다.
보통 네트워크 부분의 성능을 의미하며, 네트워크가 초당 얼마나 많은 데이터를 전달할 수 있는지를 나타내는 지표다.
- Mbps (Megabits per second): 1초에 1Mb(메가비트) 전송 가능
- Gbps (Gigabits per second): 1초에 1Gb(기가비트) 전송 가능
파이프 예시로 비유하면 파이프의 넓이가 Bandwidth가 될 수 있다.
💁♂️ Throughput과 Bandwidth의 관계
Bandwidth와 Throughput의 차이점은 단위 시간당 Bandwidth는 최대 전송 가능 용량을 의미하지만, 반면 Throughput은 실제 전송된 데이터 양을 나타낸다는 것이다.
위 그림에서 볼 수 있듯이, 파이프의 크기가 Bandwidth라면 파이프를 지나치는 선이 Throughput라고 이해하면 된다.
파이프에 물을 흘려보내는 사례를 다시 떠올려보면, 파이프 크기이상의 물은 흘러가지 못할테니 파이프 크기가 Bandwidth가되고, 일정기간내 파이프를 통과한 물의 양이 Throughput이라고 보면 된다.
💁♂️ Throughput과 Latency의 관계
앞서 살펴본 위 그림에서도 알 수 있듯이, 보통 파이프의 길이(Latency)가 짧으면 물이 더 빠르게 파이프를 흘러 밖으로 나온다. 즉, Throughput이 높아진다고 볼 수 있다.
조금 더 쉬운 예시로 두 지표의 관계를 예시로 그래프를 그려보면 아래와 같다.
위 그래프는 하나의 예시로 x축은 Latency (지연시간), y축은 Throughput (처리량)을 나타낸다.
이론적으로는 Latency가 높을 수록 데이터가 도착하는 데 오래 걸리니까, Throughput은 줄어들 수 있고, Latency가 낮을 수록 빠르게 주고받으니 Throughput이 높게 나온다.
물론 아닐때도 있지만, 보통의 경우 위와 같이 반비례하는 경향을 보인다.
2-3 서버의 Throughput 측정 방법과 병목점 찾는 방법
인터넷 서비스는 보통 하나의 서버로만 구성되지않고 여러 시스템으로 구성된다.
가장 간단하게 만드는 모놀리식 서버 아키텍처만해도 보통 리버스 프록시 역할의 웹 서버, 비즈니스 처리하는 웹 애플리케이션 서버, 데이터를 저장하는 DB로 구성하는 경우가 많다.
쉬운 이해를 위해 아래와 같은 아키텍처로 서비스중인 예시를 활용하여 서버의 성능을 측정하고 병목점을 찾는 과정에 대해서 정리했다.
웹 애플리케이션은 비즈니스 로직상 Database를 조회하고 Internal Server를 조회하여 응답한다고 가정한다.
두 호출의 동기/비동기 상관없이 아래에서 설명하는 성능 관련 내용은 동일하다.
💁♂️ Throughput 측정하기
위와 같은 서버 아키텍처 구조에서 해당 서비스의 TPS (Throughput Per Second)는 얼마일까??
모든 시스템의 합이라고 많이 오해하지만, TPS의 경우는 모든 시스템중 최소 TPS가 해당 서비스의 TPS가 된다.
즉, 위 예시에서는 1000 TPS가 서비스의 TPS가 된다.
쉬운 이해를 위해 파이프에 물을 흘려보낸다고 생각하면 된다. 왼쪽에서 물을 흘려 오른쪽까지 흐르게 해야한다고 가정한다면, 각 파이프의 폭을 TPS라고 비유할 수 있다.
앞선 비유에선 파이프의 폭을 Bandwidth라고했으나, 여기선 스트레스 테스트를 진행한다고 가정하고 서버가 Max Bandwidth만큼의 Throughput이 나온다고 가정한다.
즉, 물이 항상 파이프의 폭만큼 들어온다고 가정한다. 그러면 자연스레 파이프의 폭이 Throughput이 된다.
위 그림에서 알 수 있듯이 앞 파이프가 아무리 파이프의 폭(Throughput)이 넓어도 Web Server Application의 중간 파이프의 Throughput이 높지않으면 물을 빠르게 통과하게 할 수 없다.
💁♂️ Throughput 병목점 찾고 올바른 병목점 성능 개선
Throughput 측정하기의 파이프에 물을 흐르게하는 비유에서 알 수 있듯이 가장 낮은 TPS를 가진 서버 성능의 병목점이 된다.
즉, 위 예시에서는 Web Application Server가 병목점이 된다.
이때 병목점을 제대로 찾지않고 아래와 같이 이미 처리량이 높은 Web Server와 Internal Server의 성능을 높인다면 서비스의 성능은 여전히 동일하다.
좋은 의도로 서버의 성능을 높였다한들 서비스의 성능은 높아지지않고 성능 업그레이드 비용만 낭비하게되는 불상사를 일으키게된다.
파이프의 그림으로 보면 아래와 같다.
여전히 전체 파이프의 시간당 통과하는 물의 양은 동일하다. 즉, 개선을 했음에도 결국 전체 서비스의 처리량이 동일하다.
물론 개선한 서버의 Latency가 낮아진다면 전반적인 Latency는 조금 낮아질 수도 있을 듯 하다.
💁♂️ 서비스의 시스템 전체 성능은 가장 느린 구간(Bottleneck)에 의해 결정된다
위와 같이 병목점을 제대로 찾지않고 수행하는 성능 개선은 자칫.. 의미없는 일이 될 수 있다.
올바른 서비스의 서버 성능 개선은 바로 아래와 같이 병목점이 되는 Web Application Server의 성능을 높이는 것이다.
위와 같이 가장 느린 구간인 Web Application Server의 병목점을 개선하니 전체 파이프의 시간당 흐르는 물의 양이 증가한 것을 볼 수 있다. 즉, 서비스의 전체 성능이 높아졌다.
이젠 3000TPS를 무조건 뽑아내야하는 서버라면 Web Application Server가 아닌 Internal Server가 병목점이 된다. Internal Server의 성능을 개선 할 차례인 것이다.
이렇듯 서비스 정확한 병목점을 찾아 지속적으로 개선해나가는 것이 서버 성능 개선의 핵심이라고 볼 수 있다.
💁♂️ 서비스의 성능을 높이기위해선 병목 구간을 지속적으로 찾고 개선해야한다.
예시에서 알 수 있듯이, 서비스의 전반적인 성능을 높이기위해선 병목 구간을 정확히 진단하고 집중적으로 개선하여 성능을 높여야한다.
그러기 위해선 내가 담당하고있는 서버의 성능 테스트를 주기적으로 시행하여 어느부분이 병목이 되는지 지속적으로 살펴보고 개선이 필요하다.
여러분들이 개발하고 관리하는 서버의 병목점은 어디인가요? 댓글로 남겨주세요 :)
2-4 서버의 Latency 측정 방법과 병목점 찾는 방법
💁♂️ Latency 측정하기
서비스의 Latency는 Throughput과 다르게 모든 시스템 Latency의 합이다.
위 예시에서는 동기식으로 처리된다는 가정하에 350ms와 같거나 높은 Latency를 가지게된다.
물론 Internal Server와 Database의 호출 결과가 서로 상관이 없어 비동기로 수행해도되는 로직이라면 300ms로 Latency를 개선할 수 있다.
물론 Web Application Server의 부하가 조금 더 증가하겠지만 Latency가 짧아짐에 따라 Throughput도 증가할 수 있기에 이 또한 하나의 서버 성능 개선이라고 볼 수 있다.
💁♂️ Latency 병목점 찾고 개선하기
Latency는 당연히 서버내 다앙한 원인으로인해 높아질 수 있다. Throughput과 조금 상이하게 Latency는 모든 시스템의 합이기때문에 Latency가 가장 큰 서버가 병목점이 된다.
즉, Latency가 가장 높은 서버부터 개선해나가면 전반적인 시스템의 Latency를 줄일 수 있다.
위 예시에서는 Web Application Server가 평균 Latency가 가장 높기때문에 이 서버가 개선의 최우선 대상이 된다.
한가지 주의할 점은 Throughput이 한계점에 도달하면 자연스레 Latency도 증가한다. 즉, Throughput의 하락이 Latency의 증가 원인이 될 수 있다.
그러므로 개인적으로 성능 개선시 두 지표를 같이 측정하고 성능 개선 계획을 수립하는 것이 중요하다고 생각한다.
개인적인 경험으론 TPS를 올리거나 Latency를 낮추기위해 개선하면 자연스레 둘 다 개선됐다.
❗️ 주의! - 각 API별로 Throughput과 Latency가 모두 다르다.
앞서 말한 Throughput과 Latency는 당연히 각 API 별로 조금씩 상이할 것이다.
각 API별 비즈니스 로직이 모두 상이하기때문에 어쩌면 당연한 이야기이기도하다.
또한 어떤 API는 비즈니스 코드의 처리가 더 필요하여 CPU bound가 더 필요할 수 있으며, 응답 값 자체가 커서 네트워크나 직렬화 Latency가 더 필요할 수도 있다.
흔히 성능 저하가 많이 발생하는 DB 조회쿼리에 대한 성능 저하도 API 별로 상이한 비즈니스 로직으로인해 DB 쿼리문이 다르기때문에 당연히 API별로 성능은 상이하다.
여기서 중요한 것은 많이 호출되는 API나 전반적으로 서버의 성능을 낮추게하는 API를 찾아 개선해나가는 것이다.
예를 들어, 비즈니스 로직을 Thread Per a Request 형식의 Blocking으로 처리하는 서버에선 요청 하나가 스레드 하나를 할당하기때문에, 자칫 외부 호출이 오래걸리거나하면 해당 서버의 스레드가 점차 밀리게된다.
이땐 캐시를 두거나, 외부 호출 Timeout 설정 및 서킷 설정등의 조치를 취할 수도 있다. I/O Bound 위주의 대부분의 서버에선 Pull 방식이 아닌 Push 방식인 Non-Blocking 방식으로 비즈니스 처리를 전환하는 것도 방법일 것이다.
위 내용과 관련해서는 다음 글에서 더 자세히 다룰 예정이다.
💁♂️ 클라이언트와 서버간 요청-응답 Throughput/Latency에 영향주는 부분
일반적인 서비스의 가장 기본 서버 아키텍처는 아래와 같다.
이때 Throughput과 Latency는 네트워크와 서버 처리로 나눌 수 있다.
물론 DB나 외부 서버를 호출할 때도 네트워크를 타고 해당 서버들도 처리를 하기때문에 조금 더 자세히 나눠보자면 아래와 같다.
이렇듯 요청-응답 구조의 클라이언트-서버 구조는 모두 위와 같이 두 가지 부분에서 성능이 판단된다고 볼 수 있다.
다만 네트워크 부분은 사실상 서버 기술 스택이나 로직 개선보단 인프라에 영향이 많아 서버 개발자가 따로 작업할 내용이 사실상 거의 없다.
그러므로 보통의 서버 개발자는 서버 처리에 관한 성능 개선만으로 충분하다.
정리
서버의 성능은 서비스에 비교적 큰 영향을 끼친다. 그러므로 서버 개발자는 서버의 성능을 파악하고 병목점이 어딘지 정확히 파악하여 개선해야한다.
그러기위해선 성능의 빠름과 느림의 기준을 판별 할 수 있는 지표인 Throughput, Latency, Bandwidth에 대한 이해가 필요하며,
지속적인 서버 대상으로 성능 테스트를 진행하여 병목 구간을 찾아 개선해야한다.
다음 글은 서버 성능에 영향을 주는 요소들을 내 나름대로의 정의한 서버 처리 계층 구조와 함께 설명한다.