트러블 슈팅

상황Grafana로 어플리케이션 메모리 사용량을 분석한 결과, 기동 후 메모리 사용량이 감소하지 않는 문제가 확인된다. 즉 GC가 정상적으로 동작하지 않은 것이다. 원인 해당 어플리케이션과 다른 어플리케이션에서 Heap dump를 통해 메트릭을 비교한 결과, metrics 수가 비정상적으로 많음을 확인했다. local에서 기동 후 metric을 확인한 결과, 기동 직후와 2분 후 메모리 사용량이 계속 증가하는 것을 확인했다.  micrometer로 metrics를 등록할 때 JVM 메모리를 지속적으로 사용하는 문제가 있었는데, 어플리케이션 내부적으로 batch job, batch step을 생성할 때 이름에 시간을 함께 붙여서 생성하는 구조로 개발이 되어 있었다.  spring batch metric들은..

문제 상황 요약쿠버네티스 워커 노드 중 하나가 장애로 인해 죽었지만, 회복 후 해당 노드에 있던 레디스 클러스터 노드도 함께 복구되었다. 그러나 레디스를 사용하는 어플리케이션에서 간헐적으로 타임아웃 에러가 발생하였다. 원인 분석복구된 레디스 노드 중 하나가 자신의 IP를 이전 IP로 인식하고 있었다. 이를 '금쪽이 노드'라고 하자.레디스 클라이언트는 클러스터 노드 중 하나에게 목적지를 질의하면 모든 노드는 full-mesh 구조로 되어 있으므로 질의에 대한 응답을 해줄 수 있다. 간헐적인 타임아웃의 원인은 다음과 같다클라이언트가 금쪽이 노드에게 목적지 질의를 함.금쪽이 노드가 자신을 잘못된 IP로 인식하고 있어, 클라이언트에게 잘못된 IP를 응답함.즉, 금쪽이 노드에게 자신의 이름을 물었더니 잘못된 이름..

상황 카프카를 운영하다 보니, 가끔 일부 컨슈머에서 이유를 알 수 없는 지연이 발생할 때가 있었다. 현재 컨슈머에 문제가 생기면 자동으로 재시작되도록 설계되어 있어 큰 문제가 되지 않는다. 그런데 인터널 토픽을 사용하는 스트림에서는 상황이 좀 다르다. 인터널 토픽에서 지연이 발생하면 컨슈머가 재시작되지 않는 문제가 있는 것 같다.  이를 해결하기 위하여 종종 수동으로 statefulset 재시작하였고, 추후 재시작 자동화를 위해서 하기 아래 포스팅과 같이 세팅을 해주었다. (Kafka) Kafka Streams에서 Repartition Topic을 Consume하지 못하는 장애 (feat: Metric으로 Lag값 추출)상황카프카를 운영하다 보니, 가끔 일부 컨슈머에서 이유를 알 수 없는 지연이 발생할 ..

상황카프카를 운영하다 보니, 가끔 일부 컨슈머에서 이유를 알 수 없는 지연이 발생할 때가 있었다. 현재 컨슈머에 문제가 생기면 자동으로 재시작되도록 설계되어 있어 큰 문제가 되지 않는다. 그런데 인터널 토픽을 사용하는 스트림에서는 상황이 좀 다르다. 인터널 토픽에서 지연이 발생하면 컨슈머가 재시작되지 않는 문제가 있는 것 같다. 카프카 Streams에서는 내부적으로 Repartition Topic을 사용하는데 이 중 repartition Topic에서 장애가 발생한 것이다. 이를 해결하기 위하여 종종 수동으로 statefulset 재시작하였다. 원인우선 저수준에서 일어나는 일을 분석하여 보았다. 컨슈머 지연(Lag)의 근본적인 원인은 컨슈머 스레드와 파티션 매핑이 꼬여 발생하는 것으로 판단되었다. n-1..