박정국 CTO가 알려주는 ‘서버 성능 측정 방법’ (포브스 선정, 신입 개발자, API, 백엔드)

💡 영상

https://www.youtube.com/watch?v=HSNyJnobBws

세미나 내용

• 이번에 API 서버를 하나 만들었는데, “성능이 아주 빨라 / 안정적이야 / 좋아 / 높아” 라는 말을 많이 한다. 그럼 이게 어떤 의미일까?
• 이런말이 있다. “많은 사람들이 사용해도 API 응답 시간이 짧고 안정적이다.”
• 그럼 여기서 의문점이 생긴다. 많은사람? 응답시간이 짧고? 안정적
• 얼마나 많은 사람? 어느정도 시간이면 짧은거야? 마음의 안정이라는거야?

두가지 상황

• 10명이 동시에 호출햇을 때 1초 안에 모두가 응답을 받음 vs 100명이 동시에 호출했을 때 10초 안에 모두가 응답을 받았다.
  • 둘중에 어떤게 더 빠른가? 정답이 없다.
  • 1초동안 5개의 처리를 동기적으로 할수도 있고, 1초동안 병렬로 5개를 처리할수도 있다.
    

    

  • 평균이 1초라고 할때, 각 요청이 병렬로 했을때 1초일수도 있고, 5개가 순차적으로 진행되면서 1초일수도 있다.
    

    

  • 이렇게 되면 평균은 애매해지는거 아니냐?

Latency vs Throughput

• Latency란 요청자의 입장에선 응답까지 얼마나 걸리는가?
• Throughput은 작업자 입장에서 시간당 얼마나 처리하는가?
• 고속도로로 비유를 들어보면, Latency가 낮다는것은 제한속도가 굉장히 빨라서 차가 빠르게 다닐수 있다는 것이고, Throughput이란 차선이 많아서 한번에 통과할 수 있다는 차량이 많다는 의미이다.
• 성능 개선을 할때 둘중에 적절한 선택을 함으로써 처리하는게 중요하다.

wrk / wrk2

• https://github.com/wg/wrk
  • wrk는 현대적인 HTTP 벤치마킹 도구로, 단일 다중 코어 CPU에서 실행될 때 상당한 부하를 생성할 수 있습니다
  • 기본적으로 아래와 같이 사용가능하다.
  • wrk -t12 -c400 -d30s http://localhost:8080/hello
  • 몇가지 옵션을 살펴보자.
    • -c(—connections): 각 스레드가 처리하는 HTTP 연결의 총 수
    • -d(—duration): 테스트의 지속시간
    • -t(—threads): 사용할 스레드의 수
    • -s(—script): LauJIT 스크립트
    • -H(—header): 요청에 추가할 HTTP 헤더
    • —latency: 자세한 Latency 통계 출력
    • —timeout: 응답을 받지 못할 경우 시간 제한
    • cf) LauJIT스크립트란 HTTP 요청 생성, 응답 처리, 사용자 정의 보고를 수행하는 것으로 특정 요구사항에 맞춰 커스텀 할수 있습니다.
  • 그럼 한번 간단하게 해보자.
    • 간단하게 Spring으로 사용자들중에 랜덤으로 하나 리턴하는 API를 만들었습니다.
    • 코드는 따로 공개하진 않을텐데, 실제 Service는 아래와 같이 전체 user를 다 가져와서 random을 돌리는 풀테이블 스캔을 이용하려는 목적으로 하였습니다.
    • fun random(): User { return userRepository.findAll() .random() }
    • 결과
      

      

      

    • 12개의 스레드에서 400개의 연결을 했던 결과 latency는 평균 42.32ms이며, 1초당 10577개를 처리한것을 알수 있다.
    • 단순히 Latency만 나오기 떄문에 좀더 효과적으로 출력을 보여주기 위해 wrk2가 나오게 됩니다.
• wrk2
  • https://github.com/giltene/wrk2
  • wrk2는 wrk를 기반으로 한 HTTP 벤치마킹 도구로 일정한 처리량 부하를 생성하고 충분한 시간동안 실행될 경우 높은 정확도의 Latency를 제공하기 위함입니다.
  • wrk2 -t2 -c100 -d30s -R2000 --latency http://localhost/hello
  • –R을 이용해 일정한 요청율을 지정 할 수 있는게 다른 점 입니다.
  • Mac M 시리즈 맥북에서 이게 동작을 하지 않기 때문에 예시를 할수가 없습니다 ㅠㅠ
• API 서버를 더 빠르게 개선하려면?
• 가장 쉬운 방법은 서버를 늘리는 것이다.
  • 웹서버 - WAS - DB
  • 이렇게 있다고 해봅시다.
  • 이때 웹서버에 웹서버의 요청은 12개, WAS는 3개, DB는 6개를 처리할 수 있다고 해봅시다.
  • 그렇다면 한번 처리할때 3개씩 처리할 수 잇을겁니다. 왜냐하면 WAS가 3개만 처리가 가능하니깐요. 그렇다면 이때 병목지점은 WAS입니다. WAS가 6개로 처리된다면 다른곳 없이 더 늘릴수 있지 않을까요? 따라서 WAS를 늘린다면 6개로 처리가 가능할겁니다.
  • 그렇다면 이제 12개를 처리하고 싶다. 라고 할때 웹서버는 12개씩 가능할꺼에요. 그러나 아직 WAS는 6개를 처리가 가능합니다. 그렇다면 2개를 더 늘리면 12개가 처리가 가능하겠죠. 그러나 DB에서는 6개만 처리가 가능하기 때문에 결국 6개만 처리할수 있습니다. 그렇다면 DB부하가 생길테니, DB도 한개 더 늘립니다.
  • 이렇게 각 상황을 보고 서버를 늘리는것이 중요합니다.
• 코드 효율화 한다.
  • 처리하는 크기를 줄이는 것입니다. 즉, 6개를 처리하는것을 크기를 줄여 12개를 처리하게 할 수 있는거죠.
  • 그런걸 할 수 있는 것은 WAS(애플리케이션)에서는 효율적인 알고리즘을 사용한다거나, N+1을 해결하거나 메모리나 로직을 리팩톨이한다거나.
  • DB도 줄일수 잇습니다. 적절한 DB 인덱스를 사용한다거나, Denormalization을 한다거나.

결론

• 서버 성능을 나타내는 지표는 다양하며, 정답이 없다.
• 성능 측정 시, 몇 명의 사용자가 어느 정도의 밀도로 API 요청을 할 때 서버의 응답속도 분포는~ 의 형태가 현실적이다
• 서버의 성능을 상황에 따라 scale-out 하거나 코드를 효율화 하는 방법이 있다.

후기

• 성능이라는 것을 명확히 빨라야 한다. 좋아야 한다. 어떻게 하면 좋을수 있을까? 어떤 지표를 봐야 할까? 등등 이런 고민들을 해볼수 있었던거 같습니다.
• 아주 간단하게 내가 만든 API의 성능은 어떨까? 얼마나 버틸수 있을까?에 대한것을 알수 있는 시간이였던거 같습니다.
• 굉장히 기본적인 내용이지만, 가장 중요한 내용들을 담은 영상이 아니였을까 생각이 듭니다.
• 사실 가장 중요한건 우리의 서비스가 현재 얼마나 버틸수 있는가?를 알아가는게 좋을거 같습니다.
• 얼마나 많은 사람들이 동시에 사용할 수 있는 지 / 일정동안 얼마나 많이 처리 할 수 있는지를 꾸준히 체크하는게 좋을거 같다.
• 이러한 부분들을 차후엔 그라파나를 통해서 처리해보고 싶긴 하네요!