상황 카프카를 운영하다 보니, 가끔 일부 컨슈머에서 이유를 알 수 없는 지연이 발생할 때가 있었다. 현재 컨슈머에 문제가 생기면 자동으로 재시작되도록 설계되어 있어 큰 문제가 되지 않는다. 그런데 인터널 토픽을 사용하는 스트림에서는 상황이 좀 다르다. 인터널 토픽에서 지연이 발생하면 컨슈머가 재시작되지 않는 문제가 있는 것 같다. 이를 해결하기 위하여 종종 수동으로 statefulset 재시작하였고, 추후 재시작 자동화를 위해서 하기 아래 포스팅과 같이 세팅을 해주었다. (Kafka) Kafka Streams에서 Repartition Topic을 Consume하지 못하는 장애 (feat: Metric으로 Lag값 추출)상황카프카를 운영하다 보니, 가끔 일부 컨슈머에서 이유를 알 수 없는 지연이 발생할 ..
상황카프카를 운영하다 보니, 가끔 일부 컨슈머에서 이유를 알 수 없는 지연이 발생할 때가 있었다. 현재 컨슈머에 문제가 생기면 자동으로 재시작되도록 설계되어 있어 큰 문제가 되지 않는다. 그런데 인터널 토픽을 사용하는 스트림에서는 상황이 좀 다르다. 인터널 토픽에서 지연이 발생하면 컨슈머가 재시작되지 않는 문제가 있는 것 같다. 카프카 Streams에서는 내부적으로 Repartition Topic을 사용하는데 이 중 repartition Topic에서 장애가 발생한 것이다. 이를 해결하기 위하여 종종 수동으로 statefulset 재시작하였다. 원인우선 저수준에서 일어나는 일을 분석하여 보았다. 컨슈머 지연(Lag)의 근본적인 원인은 컨슈머 스레드와 파티션 매핑이 꼬여 발생하는 것으로 판단되었다. n-1..
상황 WebClient를 사용해서 통신을 하고 있는데, 모종의 이유로 통신이 전혀 되지 않는 상황. 이로 인해 외부 서버와 통신하는 어플리케이션에서 장애가 발생함. 장애가 발생한 어플리케이션에서는 타임 아웃등의 에러가 떨어지는 중. 원인 WebClient는 API 요청 시 Connection Pool을 사용한다. 이미 사용 중이지 않은 Connection이 있다면 이를 재사용하고, 그렇지 않다면 새로운 Connection을 맺어 요청을 처리한다. 요청들은 대기열(Event Queue)에 대기하다가 순차적으로 처리된다. 여러 WebClient 인스턴스를 별도로 선언해 사용하더라도, 각 WebClient에 별도의 Connection Pool을 설정하지 않으면 글로벌 Queue를 공용으로 사용하게 된다...
상황 특정 토픽을 Consume 어플리케이션에서 장애가 난 상황. 이로 인해 Lag이 천정부지로 치솟고 있었다. 또한 이 토픽을 사용하는 kafka to s3 커넥터에서도 장애가 발생하였다. 원인 해당 토픽을 사용하는 어플리케이션들은 해당 토픽의 Value를 Json으로 기대하여 Json 파싱하고 있었다. 그런데 유효하지 않은 데이터가 들어가서, Json Parsing 에러를 발생시킨 것. 해결 방안 우선 장애가 발생한 파티션을 찾아야했다. 장애가 발생한 파티션을 찾기 위해서 쉘 스크립트를 만들어 돌려서, 장애 발생 토픽을 찾아냈다.BROKER="브로커 호스트"GROUP="장애가 발생한 토픽을 사용하는 컨슈머 그룹 명"TOPIC="토픽 명"MAX_MESSAGES=15 (콘솔에서 보여줄 메세지 갯수)/op..