[부하 테스트] 분석 (1차)

이번 장에서는 [부하 테스트] 결과 (1차) (링크)의 결과를 분석하여 문제가 발생한 시점을 파악해본다.

---

분석

가장 먼저 확인한 부분은 docker container의 상태를 저장한 파일이다.
기본적으로 컨테이너가 재실행 되었을 때 재실행 원인이 Status.ExitCode에 표시된다.
하지만 컨테이너가 세번이나 재실행되었음에도 ExitCode가 0으로 표시되어 해당 파일로는 원인을 파악이 불가능했다.
(아마 컨테이너가 Kill되었을 경우 자동으로 Restart 되도록 설정해두었는데 Restart되면서 기록이 사라진게 아닐까 싶다.)

"State": {
    "Status": "running",
    "Running": true,
    "Paused": false,
    "Restarting": false,
    "OOMKilled": false,
    "Dead": false,
    "Pid": 11297,
    "ExitCode": 0,
    "Error": "",
    "StartedAt": "2021-11-17T08:37:18.945716712Z",
    "FinishedAt": "2021-11-17T08:37:17.490070637Z"
}

다음으로 확인한 파일은 nmonchart로 생성한 html파일에서 CPU와 Memory 부분이다.
어떠한 요청으로 인해 CPU 사용량이 일시적으로 80%이상까지 치솟는 현상이 발견되었다.
사용률이 100%를 넘기지는 않았으므로 CPU 사용량 초과로 발생한 문제는 아닐것으로 예상된다.

여기서 잠깐!
필자가 테스트를 진행한 Instance의 유형은 m5.xlarge이므로 80%이상으로 치솟아도 문제로 인식하지 않았다.
하지만 여러분이 사용하는 Instance 유형이 T Type 이라면 얘기는 달라진다.
T Series의 경우 크레딧 개념이 존재하며 지속적으로 일정 수치 이상의 CPU 사용률을 유지하면 100%를 사용하지 않아도 문제가 발생할 수 있다.
자세한 내용은 버스트 가능 성능 인스턴스 (링크)을 확인하길 바란다. 필자의 경우 버스트 가능 성능 인스턴스에 대한 이해도가 부족하여 잘못된 분석을 했던 경험이 있다.
이 글을 읽은 사람이라면 필자와 같은 실수는 하지 않길 바란다.

중간에 CPU가 치솟는 원인은 추후에 분석하고 Container가 Kill되는 원인을 먼저 분석해본다.

다음으로 메모리 사용량을 확인해본다.
빨간 테두리가 있는 부분이 컨테이너가 재실행된 부분이다.
컨테이너가 재실행 되기 직전에는 항상 active memory가 memtotal에 도달직전인 것을 확인할 수 있다.
이러한 점을 보았을 때 결국 컨테이너는 메모리 부족으로 재실행되었음을 짐작할 수 있다.

노란 테두리로 표시되어 있는 부분을 확인해보면 어느 순간 메모리 사용량이 적게는 300MB 많게는 1.2GB까지 치솟은 것을 확인할 수 있다. 어떤 상황에서 메모리가 치솟는 것인지 원인을 찾아야한다. 가장 상승폭이 높았던 5:26 ~ 5:27 구간을 타겟으로 원인을 찾아본다.

확인 결과 필자가 운영하는 서비스에 엑셀 다운로드기능이 있다.
이 때 쿼리 결과를 Memory에 올려놓고 Return한 이후 정상적으로 Memory가 회수되지 않아서 발생하는 문제로 파악이 되었다.
이러한 문제를 확인하기 위해서 OOM 시점에 HeapDump를 생성하고 분석을 하였다.
HeapDump를 생성하고 분석하는 방법은 이 방법만으로도 상당히 긴 글이 필요하므로 필자가 추후에 따로 작성하도록 하겠다.

---

이번 장에서는 1차 부하 테스트의 결과를 분석하고 엑셀 다운로드 기능에 문제가 있다는 것을 발견하였다.
2차 부하 테스트에서는 1차 부하 테스트에서 발생한 문제를 해결한 코드를 가지고 다시 한번 부하 테스트를 진행해본다.