트러블 슈팅

상황 로그 스테이시의 Lag이 갑자기 선형적으로 증가하고, Kibana에서 ES 데이터가 조회가 안되는 상황.  원인[INFO ][logstash.outputs.elasticsearch][main][e38dddd91e7fd542db9b636944e2d369cbc7ce18c8d0a46ff86880f6be7cfd2b] retrying failed action with response code: 429 ({"type"=>"cluster_block_exception", "reason"=>"index [log-2024-10-05] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-..

개요 기존에 20초 이상 걸리는 보고서 쿼리가 있었다. 해당 쿼리는 스프링 어플리케이션에서 native 쿼리를 사용하여 원시 통계 테이블을 조회한 후 보고서 형식에 맞게 반환해주는 코드였다. admin 페이지 특성 상 B to C 프로덕트 보다는 성능 이슈가 덜하지만 개선할 수 있는 여지가 있어 이를 개선하였다. 내용 내가 생각하는 가장 큰 원인은 두 가지였다. 첫번째는 원시 통계 테이블을 그대로 조회한다는 것이었고, 두번째는 계층 구조의 이점을 살리지 못한다는 것이 그것이다. 기존의 구조, 원시 통계 테이블 참조  원시 통계 테이블을 참조했을 때 발생하는 가장 큰 이슈는 쿼리를 날렸을 때 스캔해야 할 row 수가 너무 많다는 것이다.(조회 기준이 따라 다르지만 수천만 ~ 수억건이 될 수 있다) 이렇게 ..

상황트래픽이 급격히 증가했을 때 HTTP 요청 지연이 발생하였음.JVM 내 스레드 급격히 증가스레드는 급격히 증가한 후 peak치 유지한 후 점진적으로 감소동시점에 http duration 급증, 마찬가지로 급진적 감소 원인일시적으로 평시의 2~4배에 달하는 요청이 인입됨.스레드 생성으로 인한 CPU Usage 증가요청 처리를 위한 스레드 생성 대기열로 인한 CPU load 증가요청 대기로 인한 지연 발생생성된 스레드는 Tomcat이 수거하기 전까지 수 시간 이상 Idle Thread pool 잔류 해결 방안spring boot의 server.tomcat.threads.min-spare 값을 튜닝하여 스파이크 상황에서 스레드 생성으로 인한 대기 현상을 최소화 함. 참고max-thread는 4K로 잡혀있으..

문제 상황 어플리케이션에서 모든 비즈니스 로직이 정상 동작하지 않는 문제가 발생했다. 대표적으로, 결제 로직에서 소진 되어야 하는 한도가 초과 했음에도 불구하고 계속 소진되고 있던 것이었닼 원인 MariaDB의 Slave Node에서정합성 오류가 발생하고 있었다. SHOW SLAVE STATUS; 알고보니 팀의 개발자 분께서 배포중에 Primary DB에 추가 해야하는 값을 Slave DB에 Insert 해버리신 것이었다. 그런데 그럼 데이터 정합성 문제가 없을거 같은데..? 알고보니 Slave DB와 primary DB 두군데 전부 insert 하셨다고 한다. 따라서 해당 작업 이후의 쓰기 작업 데이터는 Primary DB에만 업데이트가 되고, Secondary DB는 복사를 하고 있지 않은 상황인 것..