📌 [벡엔드 애플리케이션 성능 테스트하기] 01. 성능 테스트를 시작하기 전에 알아야 할 배경지식

📖 지연시간(Latency)과 처리량(Throuhput)

지연시간(Latency)

지연시간 : 요청 한건 당 처리시간
-> 어떤 요청이 처리되어서 사용자에게 응답이 되기까지 1초 걸렸다면 Latency는 1초이다.

처리량(Throuhput)

처리량 : 단위 시간동안 몇 건이나 처리할 수 있는지
-> API가 1초 동안 1000개의 API 요청이 들어올 때 1000개의 요청을 문제없이 처리해낼 수 있다고 하면 이 API의 Throuhput은 1000TPS 이상이다 라고 볼 수 있다.

대역폭 : 네트워크가 단위시간 동안 전송할 수 있는 최대한의 처리량을 의미한다.
-> 해당 네트워크를 최대한 활용했을 때 얼마나 빠른 속도록 많은 데이터를 보낼 수 있는지 이야기 한다.
반면에 처리량은 우리가 측정해본 데이터 전송량이다.
대역폭은 네트워크에서 유의미하지만 벡엔드 애플리케이션에서는 여러 요소들이 간섭을 주기 때문에 정확한 대역폭을 측정 할 수 없다.

우리는 지연시간, 처리량에 집중하자.

성능 테스트 목표

보통 성능을 측정할 때 지연시간과 처리량을 결합하여 성능 테스트 목표를 세운다.

100%가 아닌 99%인 이유 : 여러 변수가 존재 할 수 있기 때문이다. 뒤에서 알아보자!

지연시간과 처리량을 동시에 목표로 삼아야 하는 이유

일반적으로 처리량이 낮을 때는 지연시간이 낮고 일정하게 유지되다가 처리량이 점점 높아지면 지연시간이 함께 높아지는 경향이 있기 때문이다. 넘나 당연한 말!

📖 운영체제와 서버 자원

운영체제(OS; Operating System)

운영체제 : 물리적인 자원을 관리하면서 필요한 곳에 자원을 할당하여 컴퓨터에서 애플리케이션을 실행하도록 도와주는 역할을 한다.

이때 수행되는 작업의 단위를 프로세스라고 한다.

서버에 포커스를 맞춰보자.
서버에서 주로 사용되는 운영체제는 리눅스이다.
서버는 물리적으로 CPU, 메모리, 디스크 같은 자원을 가지고 있다.

CPU, 메모리, 디스크

운영체제는 애플리케이션을 프로세스라는 존재로 생성해서 관리하게 된다.
프로세스는 서버가 가지고 있는 CPU, 메모리, 디스크를 필요하다면 할당받아서 작업을 처리한다. 백엔드 애플리케이션이라면 API 요청을 받아서 처리하는 과정에서 이런 자원들을 사용한다.

어떤 작업은 CPU가 많이 필요할 수 있고 메모리가 많이 필요할 수도 있다.

자원은 유한하기 때문에 많이 사용중이라면 추가적인 요청이 왔을 때 처리가 지연 될 수 있다.

따라서 성능 테스트를 할 때 자원 사용률이 높아지는 자원이 있다면 해당 자원의 사용률을 낮추는 방법을 고민해야 한다. -> 병목이 되기 때문이다.

디스크에 저장되어 있는 실행될 수 있는 파일이나 소프트웨어 집합을 프로그램이라고 한다.

프로그램을 실행시키면 메모리 위로 올라가서 실행되는데 이때 프로세스라고 부른다.

프로세스는 메모리(Stack, Heap 등) + 코드로 이루어져 있다.

CPU는 프로세스가 가진 코드에 따라 실행 시킨다.
-> 코드에 적힌 대로 변수에 값을 넣기도 하고 읽기도 한다.

프로세스가 많아지면 모든 프로세스를 RAM위에 올릴 수 없다. 그럼 다운될까?
-> 아니다. 운영체제는 이런 문제를 막기 위해 물리적인 메모리를 디스크에 일부 저장했다가 불러오는 작업을 한다. 이 작업을 페이징이라고 한다.

백엔드 애플리케이션을 프로세스를 실행하기 위해서는 CPU와 메모리와 디스크 세가지 요소가 서로 상호작용을 하면서 애플리케이션을 실행한다는 점을 기억하자!

그렇다면 어떤 동작이 자원을 많이 사용하는 것일까?

상호작용 하기 때문에 CPU 사용량이 높아지면 RAM 사용량이 높아질 것이다. 그 반대도 마찬가지다.

인스턴스가 특히 많이 일어나는 작업이 존재한다면 이 인스턴스를 정리하는 과정에서 CPU가 개입하여 사용하는 인스턴스인지 아닌지를 구별하여 정리해야 할 것이다.

디스크의 공간을 얼마나 차지하고 있느냐도 중요하지만 디스크로 얼마나 많은 양의 데이터가 빠르게 읽혀지고 쓰여지고 있는지가 중요하다.

네트워크

중요한 자원으로 네트워크도 존재한다.

다른 서버에 있는 자원을 사용하려면 네트워크 I/O가 반드시 필요하다.

자세한 내용은 아래에~!!

지연시간, 처리량과의 관계

요청 하나하나의 작업을 완료하기 위해서는 CPU, 메모리, 디스크가 모두 사용되어야 하는데 서버 자원들이 너무 바쁜 상태가 되면 한 건조차도 제대로 처리가 되지 못하고 타임아웃이 난다.

이렇게 경쟁상태에 있는 경우 처리량이 오히려 평소 요청이 적게 들어올 때보다 낮아질 수도 있다.

지나치게 경쟁적인 상태를 해소하기 위해

해당 강의를 참고하자.

📖 네트워크

네트워크를 이해하지 못하고 성능 테스트를 하면 완전히 잘못된 성능 측정 결과를 가져올 수 있다. 또한 개선 포인트도 잘못 잡을 수 있으니 네트워크는 성능테스트 부분에선 매우매우 중요하다고 할 수 있다!

지연시간의 대부분을 차지하는 네트워크 호출

응답을 보내고 받기까지를 지연 시간이라고 했다. API를 사용하면 서버 내부 자원을 사용할 것이며 API특성에 따라 CPU, 메모리, 디스크의 사용량의 차이가 날 것이다.

서버 내부 자원을 사용하는 것 이외에도 데이터베이스를 호출하거나 다른 API를 호출해서 결과를 활용하기도 한다.

이때 아래와 같이 네트워크 비용이 발생한다.

이 네트워크 비용이 크다. 서버 내부 자원을 사용할 때 1ms 미만이 걸린다면 네트워크는 1ms 이상 최대 수백,수천ms가 걸릴 수 있다.
따라서 네트워크 비용을 줄이기 위해 캐시를 사용하는 등 여러 방법을 고려해야 한다.

네트워크는 마법이 아니다.

네트워크는 빛이 아니기 때문에 거리에 굉장히 영향을 많이 받는다.

네트워크는 여러 라우터들을 거쳐야 하기 때문에 133.3ms보다 더 클 것이라는 것은 충분히 예측 가능하다.

실무에서는 IDC라는 단위로 서버들이 모여 있는데 IDC 내에서는 서버들끼리 1ms미만의 시간만으로도 통신할 수 있다.

네트워크 대역폭과 지연시간의 관계

50mb/s는 보내지지 않고 버리지던가 클라이언트쪽에 쌓일 것이다.

대역폭보다 큰 데이터를 전송하려고 하면 보내지지 못하고 지연시간이 늘어날 것이다.

대역폭은 가장 댁역폭이 낮은 회선에 맞춰진다.

대역폭은 가장 낮은 100에 맞춰진다!

📖 데이터베이스

데이터베이스도 일종의 애플리케이션이다.

데이터베이스도 CPU, RAM, 디스크를 사용한다.

어떤식으로 사용하는지는 다음과 같다.

데이터베이스의 지연시간(Latency)가 길어지는 상황 - 많은 요청이 들어올 때

데이터베이스의 지연시간이 길어지는 상황들에 대해 알아보자.

짧은 시간 동안 많은 요청이 들어오는 경우 데이터베이스가 설치된 서버의 물리적인 자원들을 활용해서 요청을 처리해야 하는데 이들 자원이 요청을 처리하기 위해 경쟁적인 상태에 빠질 수 있다. 따라서 처리량이 급격히 많아지면 지연시간이 늘어날 수 있다.

데이터베이스의 지연시간(Latency)가 길어지는 상황 - 많은 데이터 중 필요한 데이터를 찾아야 할 때

데이터베이스의 지연시간(Latency)가 길어지는 상황 - 한번에 많은 데이터를 응답으로 줘야할 때

만약 100MB짜리 데이터를 응답으로 줘야 한다면 데이터베이스의 서버 자원 자체도 이를 메모리에 올리기 위해 많은 비용이 들 거고 이를 응답으로 서버에게 주려면 데이터베이스와 서버 사이의 네트워크 대역폭도 많이 차지를 하게 된다.
그리고 다시 이 큰 데이터를 받는 서버 입장에서도 받는 데이터를 메모리에 다시 올려서 처리를 하기 때문에 서버 자원을 사용하게 된다.

데이터베이스의 지연시간(Latency)가 길어지는 상황 - 락이 너무 자주 걸리는 경우

락이란, 특정 스레드가 데이터를 제어하고 있으면 다른 스레드의 접근을 막는 매커니즘을 의미한다.

데이터베이스와 관련된 성능 개선을 진행해야 한다면 락이 어떻게 걸리고 있는지 파악해야 한다. 그리고 락을 좀 더 좁은 범위의 데이터에 그리고 더 짧은 시간동안만 걸리게 할 수 있는 방법을 고려해야 한다.

때로는 락에 의해서 데드락이 발생하기도 한다. 데드락이 발생하면 요청이 처리되기까지 쓰레드가 계속 기다려야 한다. 이러면 처리되지 못한 요청들이 점점 쌓이고 결국에는 데이터베이스와 서버의 모든 자원을 고갈시켜버린다.

지금까지는 데이터베이스와 직접적인 내용이었고 다음은 간접적인 내용에 대해 알아보자.

HDD? SSD?

HDD는 메모리와 CPU보다 훨씬 느리게 작동한다. 따라서 CPU와 메모리는 HDD 속도에 맞출 수 밖에 없다.

HDD보다 빠른 SSD로 디스크를 구성하면 성능이 좋아질 것이다. 문제가 되는 부분은 비용이다.

그래서 둘이 혼합하여 사용하는데 최근에 저장되었거나 자주 사용되는 데이터들은 SSD에 저장하고 거의 사용되지 않는 데이터들은 HDD에 저장한다.

데이터베이스 IDC 이중화 관련 주의사항

인프라에 대한 이야기지만 아에 관련없는 내용은 아니니 알아두자.

데이터를 서로 동기화 해줄 때 대용량의 데이터를 동기화 해주어야 할 것이다. 그럼 대역폭을 많이 잡아먹을 것이고 성능에 악영향을 미칠 것이다.

따라서 다음과 같이 데이터 동기화에 사용하는 전용회선을 만들어서 다른 통신을 할 때 대역폭을 잡아먹지 않게 할 수 있다.

데이터베이스도 서버 자원을 사용하는 하나의 애플리케이션이라는 점을 기억하고 모든 생각이 여기서 시작된다!

📖 스레드 풀과 커넥션 풀

데드락이 발생하면...

락에 의해 데드락이 발생하면 데이터베이스와 서버 자원들이 고갈되면서 성능에 악영향을 끼친다.

데드락이 발생하면 대기 중인 상태가 되기 때문에 실질적으로 서버의 물리적인 자원은 많이 소모하진 않지만, 스레드 풀이나 커넥션 풀처럼 제한적인 숫자만 생성되는 자원이 빠르게 소모된다.

스레드 풀

스레드 풀은 애플리케이션 서버가 요청을 받아서 처리하는 자원이다.

요청이 많아지면 모든 쓰레드가 사용 중인 상태가 되고 일부 요청은 Q에 저장되었다가 쓰레드가 사용 가능한 상태가 되면 그 이후에 처리되기도 하지만 Q역시 모두 찰 경우 이후 요청은 버려지게 된다.

이런 문제를 해결하고자 너무 많은 요청을 처리하려고 하면 서버의 물리적인 자원이 고갈되고 지나치게 경쟁적인 상태가 될 것이다.

그럼 오히려 적은 숫자의 쓰레드로 요청을 처리하는 것보다 처리량은 더 낮아질 수도 있다.

이런 경우 로드밸런싱을 사용하여 여러 서버가 트래픽을 받도록 개선하던가 비동기적으로 요청을 처리하는 방식으로 바꾸는 것이 좋다.

백엔드 애플리케이션의 수만 늘린다고 해결되지 않음

서버만 증설한다고 해도 인프라 요소에 의존하고 있다면 그 인프라 요소에 많은 부하가 가해질 것이다. 그럼 애플리케이션 성능은 그 인프라 요소의 성능에 맞춰질 것이다.
즉, 병목이 발생하게 된다.

병목을 개선하거나 시스템 설계 자체를 바꿔야 할 수 있다.

커넥션 풀

커넥션 풀은 백엔드 애플리케이션과 데이터베이스가 서로 데이터를 주고받기 위해 맺는다.

쓰레드 풀과 마찬가지로 미리 생성해두고 재사용을 하는데 처리량이 많아지면 커넥션 풀 역시 빠르게 고갈될 수 있다.

백엔드 애플리케이션을 여러 개 띄울 경우 데이터베이스와 맺는 커넥션 수가 많아질 수 있다. 문제는 데이터베이스가 최대 커넥션 수 제한을 걸어놨을 수 있다는 것이다.
이러면 나중에 뜨는 백엔드 애플리케이션은 커넥션을 생성하지 못하고 커넥션 풀이 정상적으로 생성되지 않을 것이다. 이 부분을 꼭 확인해야한다.

데이터베이스에서 최대 커넥션 숫자를 제한하는 이유는 커넥션이 지나치게 많아도 데이터베이스 서버의 자원이 지나치게 경쟁적인 상태가 될 수 있기 때문이다.

결과적으로 쓰레드 풀과 커넥션 풀은 여러 번 성능 테스트를 해보면서 적절한 숫자를 찾아서 설정해야 한다.

📖 성능 테스트의 방향성

성능 테스트의 방향성

실무에선 많은 처리량을 감당할 수 있는 충분한 인프라를 투입할 수 있지만 실무가 아닌 경우 인프라를 제대로 구성해서 테스트하기 어렵다.

실무에서의 성능 테스트

실무가 아닌 환경에서의 성능 테스트

인프라 구성은 그대로 유지한 채로 테스트를 진행하고 지연시간이 치솟는 지점이 식별 된다면 그 지점부터 시작해서 성능을 개선하자.

서버의 자원을 모니터링하거나 로그 등을 통해 해당 기능이 수행되는데 어느 정도의 시간이 걸리는 지를 보며 병목이 되는 지점을 탐색해 나가면 된다.

본 포스팅은 백엔드 애플리케이션 성능 테스트하기 참고하여 작성하였습니다.