프로젝트:샐로그 / 모니터링 - 모니터링 결과 2
60초 내로 2.5만번 조회
이어서 2.6만번 가량의 요청이 임계점이라고 보고 그 아래 수준인 2.5만번의 조회 요청을 테스트 해보았다.
17:45 부터
이번에는 프로메테우스와의 연결이 끊겨 매트릭 수집이 멈추거나 애플리케이션이 비정상적으로 정지하는 일은 발생하지 않았다.
다만 요청에 대한 처리 시간이 좀 길다.
위의 모니터링 사진에서는 확인할 수 없지만 JMeter에서 요청을 보내는 건 17:48 정도에 끝난다.
하지만 계속해서 요청에 대한 처리를 진행하는 모습을 보이며
18:01 까지
이 처리 완료 사진에서 볼 수 있듯이 들어온 요청을 전부 처리하는데 약 16분 가량이 소요된다.
또한, 최대 요청 지연 시간은 0.6초, 평균은 0.05초 정도로 양호하지만 최대 요청 지연 시간이 48분 쯤 치솟았다가 떨어지고, 평균 요청 지연 시간이 하락하기 까지 시간이 오래 걸리는 것을 보니 (저 사진에서는 오르는 양상을 띄지만 바로 직후 0.03 초대로 떨어진다.) 병목 현상으로 인해 요청 처리에 걸리는 시간이 긴 것으로 보인다.
여기까지 정리하면, 60초 내로 처리할 수 있는 요청의 수는 최대 2.6만 번이며, 2.5만 번의 요청을 60초 내로 점진적으로 보낼 시 처리되는 데 16분 가량이 소요된다.
이는 병목 현상이 발생하여 요청 처리가 지연되는 것으로 보이며, 이후에도 메모리 누수가 발생하여 애플리케이션 자체가 느려진다.
현재 모니터링 시 나타나는 요청 지연 시간은 요청 처리에 대한 지연 시간으로 보아도 되는데, 요청 처리 지연 시간 자체는 양호하다.
즉, 병목 현상과 메모리 누수 이 두 가지가 주요 문제점으로 보인다.
이어서 60초 내로 2.6만번 까지의 요청을 처리할 수 있다는 것을 알게 되었는데, 600초가 기준일 때도 마찬가지로 26만번의 요청을 처리할 수 있는 것인지 궁금하여 조금 더 테스트를 진행해 보았다.
600초 내로 25만번 조회
단순히 계산하여 60초 내로 2.6만번 조회가 임계점이라면 600초를 기준으로 잡으면 26만 번까지 조회가 가능하지 않을까 생각되어 진행해 보았다.
만약 여기서 마찬가지로 2.6만번 이상 요청 시 애플리케이션이 비정상적으로 동작하면 리소스 부족으로 인해 요청을 받을 수 있는 최대치가 정해져 있다고 보아야 할 것이다.
15:10 부터
마찬가지로 2.6만 번 요청이 발생했을 쯤 프로메테우스와 연결이 끊기고 애플리케이션이 비정상적으로 정지한다.
600초 내로 20만번 조회
16:30 부터
요청 수를 조금 줄여봤지만 동일하게 2.6만번 쯤에서 멈춘다.
즉, 시간과 상관 없이 배포 환경과 비슷한 리소스 제한을 두었을 때 애플리케이션이 처리할 수 있는 최대 요청 수가 2.6만번 가량인 것이다.
결론
앞선 테스트로 알 수 있는 것은 리소스가 제한된 애플리케이션의 처리할 수 있는 요청 수가 2.6만 번으로 절대적인 제한이 걸려 있다는 것이다.
각 요청이 개별적으로 처리되는 데에 걸리는 시간은 0.0n 초 대로 문제가 없지만 전체적으로 보면 병목 현상으로 인해 처리 시간이 늘어지며, 메모리 누수로 인해 요청을 전부 처리했다 하더라도 인스턴스(여기선 인텔리제이)를 껐다 키지 않는 이상 애플리케이션 성능에 문제가 생겨 연속해서 테스트를 진행할 수 없다.
이를 해결할 수 있는 가장 간단한 방법은 리소스를 늘리는 것인데, AWS 무료 티어를 사용해야한다는 제약이 걸려있는 이상 이 방법은 사용할 수 없다.
그러면 최대한 논리적으로 문제를 풀어야 하기 때문에, 병목 현상과 메모리 누수, 이 두 가지를 어떻게 해결할 것인지 생각 해야한다.
우선 병목현상 문제를 해결해서 적용해보고 60초 내로 2.5만번 조회 요청 시 16분 가량이 걸리던 처리 시간이 얼마나 단축되는 지 확인하고 메모리 누수 문제를 해결하여 이후에도 연속해서 60초 내로 2.5만번 조회 요청을 보낼 시 잘 처리되는 지 확인하는 것을 목표로 최적화를 진행해 보자.
후기
이번 목표는 솔직히 쉽지 않다.
적당히 모니터링 도구를 적용해서 모니터링을 진행해보고 대충 쿼리 최적화나 인덱싱 정도 적용하면 되겠거니 생각했는데, 큰 오산이었다.
직접 진행해보니 어떤 것을 기준으로 어떻게 테스트를 진행할 지, 모니터링 도구로 나타난 결과에는 어떤 의미가 있는 지, 발생할 수 있는 시나리오는 어떤 게 있는 지 등등 생각해야할 문제가 너무 많았다.
그것 뿐만 아니라 이렇게 테스트와 모니터링을 진행했는 데 어떤 해결법을 적용해야할 지도 막막하다.
그냥 전체적으로 “기준” 이라는 게 참 애매한 것 같다.
소규모 애플리케이션이니까 어느 정도 부하면 될지 기준을 못 잡겠고, 이 테스트를 하는 의미가 뭔지 중간에 망각한 경우도 있다.
결과적으로는 여러 번 테스트를 진행하고 임계점을 찾아 어떤 것이 문제인 지 찾기는 했는데, 이것 마저도 결국 컴퓨팅 리소스 문제라 그냥 메모리 늘리면 되는데? CPU 코어 더 할당하면 되는데? 이런 생각 밖에 안 들었다…
그래도 반대로 생각하면 무한대로 스케일업, 아웃 할 수 있는 것도 아니기 때문에 규모가 큰 애플리케이션의 경우에도 이 과정이 아주 중요할 것이라 생각하고 최대한 할 수 있는 작업을 진행해보려 한다.
또, 그 어떤 순간에도 목적과 목표를 잃으면 안된다는 생각이 들었다.
중간 중간에 이걸 자꾸 잊어버려서 이걸 왜 하고 있지? 뭘 해야 되지? 라는 생각을 자주한 것 같다.
조금 더 힘내서 최적화까지 진행해보고 배포 환경에 적용해보자.