상황트래픽이 급격히 증가했을 때 HTTP 요청 지연이 발생하였음.JVM 내 스레드 급격히 증가스레드는 급격히 증가한 후 peak치 유지한 후 점진적으로 감소동시점에 http duration 급증, 마찬가지로 급진적 감소 원인일시적으로 평시의 2~4배에 달하는 요청이 인입됨.스레드 생성으로 인한 CPU Usage 증가요청 처리를 위한 스레드 생성 대기열로 인한 CPU load 증가요청 대기로 인한 지연 발생생성된 스레드는 Tomcat이 수거하기 전까지 수 시간 이상 Idle Thread pool 잔류 해결 방안spring boot의 server.tomcat.threads.min-spare 값을 튜닝하여 스파이크 상황에서 스레드 생성으로 인한 대기 현상을 최소화 함. 참고max-thread는 로그가 기본적으..
문제 상황 어플리케이션에서 모든 비즈니스 로직이 정상 동작하지 않는 문제가 발생했다. 대표적으로, 결제 로직에서 소진 되어야 하는 한도가 초과 했음에도 불구하고 계속 소진되고 있던 것이었닼 원인 MariaDB의 Slave Node에서정합성 오류가 발생하고 있었다. SHOW SLAVE STATUS; 알고보니 팀의 개발자 분께서 배포중에 Primary DB에 추가 해야하는 값을 Slave DB에 Insert 해버리신 것이었다. 그런데 그럼 데이터 정합성 문제가 없을거 같은데..? 알고보니 Slave DB와 primary DB 두군데 전부 insert 하셨다고 한다. 따라서 해당 작업 이후의 쓰기 작업 데이터는 Primary DB에만 업데이트가 되고, Secondary DB는 복사를 하고 있지 않은 상황인 것..
상황Grafana로 어플리케이션 메모리 사용량을 분석한 결과, 기동 후 메모리 사용량이 감소하지 않는 문제가 확인된다. 즉 GC가 정상적으로 동작하지 않은 것이다. 원인 해당 어플리케이션과 다른 어플리케이션에서 Heap dump를 통해 메트릭을 비교한 결과, metrics 수가 비정상적으로 많음을 확인했다. local에서 기동 후 metric을 확인한 결과, 기동 직후와 2분 후 메모리 사용량이 계속 증가하는 것을 확인했다. micrometer로 metrics를 등록할 때 JVM 메모리를 지속적으로 사용하는 문제가 있었는데, 어플리케이션 내부적으로 batch job, batch step을 생성할 때 이름에 시간을 함께 붙여서 생성하는 구조로 개발이 되어 있었다. spring batch metric들은..
문제 상황 요약쿠버네티스 워커 노드 중 하나가 장애로 인해 죽었지만, 회복 후 해당 노드에 있던 레디스 클러스터 노드도 함께 복구되었다. 그러나 레디스를 사용하는 어플리케이션에서 간헐적으로 타임아웃 에러가 발생하였다. 원인 분석복구된 레디스 노드 중 하나가 자신의 IP를 이전 IP로 인식하고 있었다. 이를 '금쪽이 노드'라고 하자.레디스 클라이언트는 클러스터 노드 중 하나에게 목적지를 질의하면 모든 노드는 full-mesh 구조로 되어 있으므로 질의에 대한 응답을 해줄 수 있다. 간헐적인 타임아웃의 원인은 다음과 같다클라이언트가 금쪽이 노드에게 목적지 질의를 함.금쪽이 노드가 자신을 잘못된 IP로 인식하고 있어, 클라이언트에게 잘못된 IP를 응답함.즉, 금쪽이 노드에게 자신의 이름을 물었더니 잘못된 이름..
