프로젝트:샐로그 / 모니터링 - 모니터링 결과 1
개요
지난 번 포스트에서 배포 상태와 비슷하게 프로젝트에 mysql 데이터베이스를 적용하고 프로메테우스로 매트릭을 수집, 그라파나로 시각화하는 작업을 진행했다.
그러고서 대충 최적화 해보자, 하고 결론이 나왔는데, 생각할 수록 어떤 지표를 바탕으로 무엇을 기준 삼아 “최적화”를 진행해야하는가? 라는 고민에 빠졌다.
특히 별다른 문제점을 발견하지 못 했는데, 이대로 어림잡아 진행하기도 애매한 상태였다.
그렇기 때문에 문제점에 조금이라도 더 가까이 가고자 보다 다양한 시나리오를 생각해 모니터링을 이어서 진행해 보았다.
또한, 내용이 길기 때문에 1과 2로 두 개의 포스트에서 다룰 예정이다.
추가된 설정
또 다른 시나리오로 모니터링을 진행하기 전, 모니터링의 목적에 대해 먼저 생각했다.
이 모니터링은 이전 H2 데이터베이스로 테스트 환경(로컬)에서 진행했던 것과 달리 Mysql 데이터베이스를 적용함으로써 실제 배포 환경에서 부하가 발생하면 어떤 식으로 동작하는 지가 관건이었다.
그래서 나는 최대한 배포 환경인 AWS 인스턴스, 즉, AWS에서 제공하는 무료 컴퓨터와 동일한 환경을 조성해야 했고, 이를 위해 인텔리제이에서 프로젝트를 실행시키기 전에 “CPU”와 “메모리”를 최대한 비슷하게 구성했다.
AWS 무료 티어에서 제공되는 컴퓨터는 CPU 1코어, 최대 1gb 용량의 메모리였기 때문에 인텔리제이의 VM 옵션에서
1
-Xmx1024m
이와 같이 메모리의 용량을 1gb로 제한해 두었으며 cpu는 작업관리자를 활용하여 랜덤하게 1코어만 할당했다.
이러한 설정 작업을 통해 AWS 무료 티어로 제공되는 배포용 컴퓨터와 최대한 비슷한 환경을 조성했으며, 이제서야 비로소 모니터링을 제대로 진행해볼 수 있게 되었다.
모니터링 결과
앞서 말했듯이 AWS 무료 티어를 사용 중이기 때문에 1코어 CPU와 1gb 메모리라는 하드웨어 적인 제약에 있다.
그래서 애플리케이션의 임계점이 낮을 것이라고 생각하고 이번 부하 테스트에서는 이 임계점을 먼저 찾아 어느 시점에 비정상적으로 동작하는 지 파악하는 것을 첫 번째 목표로 정했다.
즉, 어느 부분까지는 괜찮지만 일정 수준을 넘어가면 비정상적으로 동작한다는 것을 먼저 찾고, 모종의 최적화를 진행하여 이 임계점을 높인다는 최종 결과에 도달하기 위함이다.
다시 한번 정리하자면, 최대한 배포 환경과 비슷하게 조성하기 위해 메모리는 1gb, CPU는 1코어만 할당하고 모든 테스트, 모니터링을 진행했다.
여기서 배포 환경은 AWS 무료 플랜인 t2.micro 인스턴스를 뜻한다.
또한, post 요청에 대한 것은 고려하지 않고, 가장 빈번하게 일어날 가능성이 높은 get 요청만 고려했다.
디폴트
별도의 부하를 주지 않고 타 시나리오들과 비교를 위해 매트릭 수집 요청만 하는 기본 상태이다.
전체 쿼리 수는 초기화하지 않아서 높은 것이기 때문에 의미가 없다.
단순히 켜놓고 매트릭을 수집하는 요청만 들어오기 때문에 요청 지연 시간이 0.0n 초대로 아주 빠르다.
다만, 리소스 자체가 적기 때문에 디스크 사용 비율이나 힙 메모리 사용량은 점진적으로 증가한다.
60초 내로 10만번 조회
JMeter로 60초 동안 10만번의 조회 요청을 점진적으로 보내도록 했다.
15:50 부터
일별 조회를 들어가기도 전에 월별 조회에서 애플리케이션이 비정상적으로 정지했다.
JMeter에서는 요청이 2.6만번 보낼 때 쯤 멈춰버리고 애플리케이션에서 로그가 더 이상 출력되지 않으며 인텔리제이가 정지해버린다.
임계점을 넘었다고 생각하여 여기서부터 1만 번씩 요청을 줄여나갔다.
참고로 이 테스트를 진행하기 전에 CPU를 1코어만 할당하지 않고 전체 할당했을 때는 정상적으로 동작했는데, 1코어만 주고나니 비정상적으로 동작했다.
60초 내로 9만번 조회
JMeter로 60초 동안 9만번의 조회 요청을 점진적으로 보내도록 했다.
16:40 부터
마찬가지로 2.6만번 쯤 요청이 들어왔을 때 요청도 멈추고 애플리케이션이 정지해버린다.
이 때 알게된 것이 애플리케이션이 완전히 정지하지는 않지만 과도한 요청으로 인해 프로메테우스 연결이 끊기고 매트릭 수집이 되고 있지 않다는 것이었다.
그런데, 이내 애플리케이션도 정지해버린다.
여기까지 진행하고서 60초 내로 처리할 수 있는 요청이 최대 2.6만 번 가량이라고 파악했다.
60초 내로 3만번 조회
앞선 내용으로 2.6만번 요청이 들어오는 시점에 애플리케이션이 비정상적으로 동작한다는 것을 알았으니 확인을 위해 3만번 조회도 진행해 보았다.
17:00 부터
예상대로 2.6만 번 조회 요청이 들어오는 시점부터 매트릭 수집이 정지하고 이내 애플리케이션이 정지해 버린다.
리소스에 대해 제한을 두지 않고 진행했던 전 테스트와는 달리 상당히 빨리 임계점에 도달했다고 볼 수 있는데, 이는 결국 배포되어 있는 샐로그 애플리케이션의 임계점이라고 보아야할 것이다.
이제 배포 환경의 애플리케이션이 2.6만번까지의 요청을 처리할 수 있다는 것을 알게 되었으니 다음은 그 아래 수준의 부하를 주어 어떻게 동작하는지 확인이 필요하다.
다음 포스트에서 이어서 작성한다.