API 서버 성능 이해하기
API 서버 성능이 좋다는 것의 의미는?
- 많은 사람이 사용해도 API 응답 시간이 짧고 안정적이다.
=> 얼마나 많은 사람?, 몇 초면 짧은 걸까?, 안정적? 마음의 안정?
1초 동안 5명의 요청을 처리하는 경우
A는 한 명씩의 처리는 빠르지만 한번에 한 명씩만 처리할 수 있는 경우
B는 동시에 여러명을 처리할 순 있지만 각 사용자의 요청을 처리하는데 오래걸리는 경우
5명이 동시에 호출했을 때 응답 시간이 평균 1초인 경우
A, B, C, D와 같이 같은 경우이지만 디테일한 요소에서 차이가 발생하는 대 이러한 것을 Latency와 Throughput입장에서 살펴봐야한다.
Latency vs Throughput
Latency: 요청자의 입장에서 완료까지 얼마나 걸리는가
Throughput: 작업자의 입장에서 시간 당 얼마나 처리하는가
도로에 비유를 많이한다. 만약 도로에 차를 많이 지나갈 수 있게 할려면
제한속도를 높일 것인가?(=Latency를 줄이는 것) or 도로의 폭을 넓힐 것인가?(= Throughput을 높이는 것)
따라서 다수의 요청을 효율적으로 처리하기 위해선 Latency와 Throughtput을 적절히 관리해서 최적점을 찾아가야한다.
WRK 활용한 서버 성능측정
wrk -c 10 -d 5 http://127.0.0.1:8080/random-user위 CLI는 10개의 connection을 생성하고 5초 동안 요청을 지속(duration)한 경우이다.
위 결과를 통해서 Latency부터 보면 10명의 사용자가 동시적으로 5초 동안 계속 요청했을 때,
한 사용자가 random하게 사용자이름을 받는데까지 평균적으로 11.27ms가 걸렸다는 것이다.
Requests/sec를 보면 종합적으로 1초에 약 885개의 요청을 처리하는 것을 확인할 수 있습니다.
wrk -c 100 -d 5 --latency http://127.0.0.1:8080/random-user--latency 옵션을 통해 latency 정보를 더 자세히 볼 수 있다.
latency가 평균적으로 103.80ms 걸렸는대 100명의 사용자 중에 50%는 103.41ms이 소요되었고 사용자의 99%는 127.89ms의 시간이 소요되었다.
그러면 이 서버는 1초에 약 995개의 요청을 처리할 수 있는대, 이 벤치마킹 정보를 가지고
우리의 서버는 1초에 약 995명의 사용자가 접속해도 안전한 서버입니다라고 주장할 수 있을까?
벤치마킹
벤치마킹 상황은 마치 출근길 지하철을 타는 상황과 같다.
서버가 버틸 수 있을 때까지 최대한 많은 요청을 보낸 것이다.
이렇게 탑승한 승객 한명 한명은 지하철안에서 만족스럽지 못한 상태로 이동하게 될 것이다.
마찬가지로 앞선 벤치마킹 점수를 통해 1초에 995명의 사용자가 들어온다면 각 사용자들의 UX는 좋지않을 것이다.
즉, 벤치마킹은 서버의 한계치를 아는대에는 도움이 되지만
이 결과지표가 우리가 서버를 운영할 때 동시접속자를 몇 명받을 수 있는지 답은 될 수 없다.
wrk2
그래서 앞선 문제를 개선해서 등장한 wkr2가 있다.
https://github.com/giltene/wrk2
wrk2 -c 100 -d 30 -R 100 --latency http://127.0.0.1:8080/random-user100명의 connection을 생성해서 30초 동안 요청을 보내는 것 까진 동일하지만
추가된 옵션은 -R 옵션을 활용해서 각 사용자가 1초에 100개의 요청을 보낸다라는 조건을 추가할 수 있다.
이로인해 앞서 wrk에선 얼마나 처리할 수 있고, 얼마의 latency를 갖는지만 알 수 있었지만
wrk2에선 사용자가 요청했을 때 응답받을 수 있는 시간이 얼마나걸리는지 알 수 있다.
즉, 얼마나 처리할 것인지를 미리 정해놓고 그랬을때 얼마나 쾌적한지, 빠른지를 알 수 있는 것이다.
따라서 100명의 사용자가 1초에 각 100개씩 요청할 경우 각 요청마다 약 4ms의 latency로 응답을 받는다.
wrk2 -c 100 -d 30 -R 1000 --latency http://127.0.0.1:8080/random-user
하지만 100명의 사용자가 1초에 각 1000개의 요청을 할 경우엔 요청은 10배 증가했는대
latency는 약 300배 정보 길어진 것을 볼 수 있다.
따라서 위 결과를 통해 지속적으로 밴치마킹해서 latency를 사용자가 쾌적하게 느끼는 시간을 200ms으로 맞추겠다 라고 한다면 동시 접속자 수와 요청의 밀도를 적절히 조정해서 한계점을 찾는 방식으로 최적화하는 것이 좋다.
API 서버를 더 빠르게 개선하려면?
1. 서버 대수를 늘린다.
서버 pc 수를 늘려도 되고, 서버안에서 돌아가는 프로세스 수를 늘려도 된다.
대부분 Nginx-WAS-DB 순으로 배치할 것인대 여기서 어떤 서버를 늘려야하는가도 고려해야할 요소인대, Nginx나 DB서버의 경우 상용SW이기에 최적화가 잘 되어있다.
WAS는 직접 구현하는 경우가 많아서 상대적으로 느리기에 병목(Bottle Neck)이 생길 수 있어서
만약, 서버를 증설한다면 WAS를 늘리는 것이 좋다.
하지만 WAS를 지속적으로 늘리다보면 WAS 쪽의 처리속도가 빨라져서 어느 순간 병목지점이 DB서버쪽으로 생길 수도 있다. 그러면 DB 서버를 증설하면 된다!
따라서 어느 부분이 Request를 처리하는 폭이 좁은지(latency 가 긴지) 지속적으로 밴치마킹 툴, 코드 분석해서 보면서 필요한 부분을 확장해가는 것이 좋다.
서버를 늘리는 것이 편하고 확실한 방법이긴 하지만 실제로 Production해서 사용하는 과정에선 Cost와 직결되는 문제인 것은 사실이다.
다른 방법으로 서버의 응답 속도를 향상시킬 순 없을까?
2. 코드를 효율화한다.
WAS 측에서 주로 적용할 수 있는 방법인대, 다음과 같다.
- 효율적인 쿼리 작성
- 알고리즘 개선
DB 측도 개선할 수 있다.
- 적절한 DB 인덱스 추가
- Denormalization
내용 정리
- 서버의 성능을 나타내는 지표는 다양하며, 정답이 없다.
- 성능 측정 시
"몇 명의 사용자가 어느 정도의 밀도로 API 요청할 때 서버의 응답속도 분포는 ~"의 형태가 현실적이다. - 서버의 성능은 상황에 따라 scale-out하거나 코드를 효율화하는 방법 등이 있다.
참조
