제니퍼 닷넷 적용 사례 (9) - DB 서비스에 부하가 걸렸다?!
(지금은 종료한) 제니퍼 프로모션 기간 동안,
제니퍼 .Net, PHP, Python 무료 설치 프로모션_2022
; https://jennifersoft.com/ko/blog/event-blog/2022-06-13/
발생한 재미있는 사례가 하나 있어 소개합니다. 프로모션에 신청한 해당 고객사는 마침 "DB에 부하가 걸리는 현상들이 발생"하고 있다면서 실제로 문제가 발생한 시간을 특정하면서 그때 "DB Service가 먹통이 된 현상"을 겪었다고 합니다.
자, ^^ 제니퍼가 설치되었으니 그 시간대의 성능 관련 자료들을 조회해 보면 문제의 원인이 나오지 않을까요? ^^
이를 위해, 제니퍼 "분석" 메뉴의
"X-View" 조회 화면으로 들어가 고객 측에서 알려 준 시간의 요청 처리 상황을 확인했습니다.
[그림 1: 우측 상단의 "필터링" 조건에서 "ERROR가 포함된 트랜잭션만 표시"를 체크한 결과]
위의 화면은 그 시간대에 발생한 요청 중 "ERROR"가 발생한 경우만 보여주는데요, 왜냐하면 DB Service가 먹통이 되었으니 aspx에 대한 처리 중 예외가 발생했을 것이기 때문입니다.
보다시피, 저 시간대에만 약 22만 건에 해당하는 예외가 발생했고, 게다가 좌측 "애플리케이션" 목록에 (blur 처리되었지만) 나오는 것처럼 단 하나의 aspx 페이지 요청에 집중된 걸로 봐서, 분명한 장애 상황이 맞습니다. 자, 그럼 어떤 예외가 발생했는지 볼까요? ^^
위의 화면에서 빨간색 점들을 포함하도록 마우스를 이용해 드래그 동작으로 영역을 지정하면 해당 점들이 가진 프로파일 정보를 볼 수 있습니다. 아래는 그 프로파일 중, 예외 메시지를 포함하고 있는 항목입니다.
...[생략]...
[0003][14:47:37 361][ 0][ 0] EXTERNAL-CALL [HTTP] WebReq.http://192.168.100.5 [12 ms]
[0004][14:47:37 373][ 12][ 0] url=http://192.168.100.5/DB/ExcuteQuery,response=One or more errors occurred. (각 소켓 주소(프로토콜/네트워크 주소/포트)는 하나만 사용할 수 있습니다.)
...[생략]...
아마도, 오류가 발생한 aspx 페이지는 내부의 또 다른 API 서버를 HTTP 호출로 경유해 DB 접근을 하는 듯합니다. 그리고, 프로파일의 오류 메시지를 통해 장애의 결정적인 원인을 파악할 수 있습니다.
해당 오류 메시지는,
Only one usage of each socket address (protocol/network address/port) is normally permitted
각 소켓 주소(프로토콜/네트워크 주소/포트)는 하나만 사용할 수 있습니다.
동일한 포트로 소켓 바인딩을 하려고 할 때 발생합니다. 따라서, HTTP 호출에서 이런 오류가 발생했다는 것은 로컬의 TCP 포트가 모두 소진되었다는 것을 의미합니다. 결국 이런 문제가 발생하면 그 원인은 다음과 같이 나눌 수 있습니다.
1. 해당 웹 애플리케이션에서 HTTP 연결에 LEAK이 발생하는 경우
2. 해당 머신의 다른 응용 프로그램에서 문제가 있는 경우
A. 그 시간에 실행이 되도록 스케줄링된 프로세스가 과다하게 연결을 사용한다거나,
B. 혹은 기존 프로세스에서 과다하게 TCP 연결을 많이 (또는 역시 LEAK이 발생) 하고 있는 경우
아쉽지만, 저것들 중 어느 것이 원인인지는 제니퍼에서 알 수는 없습니다. 단지, 저것이 원인일 것이라는 단서가 나왔으므로 다음부터는 제니퍼 모니터링 중 저런 상황이 발생하면 "netstat -ano" 명령어를 실행해 어떤 프로세스가 과다하게 포트를 소진하고 있는지 특정할 수 있습니다.
혹은, 해당 서버에 설치된 응용 프로그램을 잘 알고 있다면 개별 응용 프로그램의 소스 코드를 살펴 LEAK의 원인이 있는지 확인해 오류를 해결할 수 있을 것입니다.
어쨌든 위의 내용을 포함한 분석 결과를 해당 고객사에 전달했고, 이후 그 고객사는 문제 해결에 큰 도움이 되었다는 회신을 보내왔습니다. (어떤 해결을 했는지 알려주셨으면 더 좋았을 텐데. ^^)
여기서 중요한 것은, 그동안 고객사는 "DB 서비스가 먹통"이라고 판단했다는 점입니다. 하지만, "측정"을 한 결과, 그것은 "DB"의 문제가 아니라 호출 측의 문제였다는 점!
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]