문제 상황 요약
쿠버네티스 워커 노드 중 하나가 장애로 인해 죽었지만, 회복 후 해당 노드에 있던 레디스 클러스터 노드도 함께 복구되었다. 그러나 레디스를 사용하는 어플리케이션에서 간헐적으로 타임아웃 에러가 발생하였다.
원인 분석
복구된 레디스 노드 중 하나가 자신의 IP를 이전 IP로 인식하고 있었다. 이를 '금쪽이 노드'라고 하자.
레디스 클라이언트는 클러스터 노드 중 하나에게 목적지를 질의하면 모든 노드는 full-mesh 구조로 되어 있으므로 질의에 대한 응답을 해줄 수 있다. 간헐적인 타임아웃의 원인은 다음과 같다
- 클라이언트가 금쪽이 노드에게 목적지 질의를 함.
- 금쪽이 노드가 자신을 잘못된 IP로 인식하고 있어, 클라이언트에게 잘못된 IP를 응답함.
즉, 금쪽이 노드에게 자신의 이름을 물었더니 잘못된 이름을 대답한 상황과 같다.
원인을 찾아낸 방법
- 치밀한 로그 분석을 통해 커넥션 타임아웃이 발생하는 어플리케이션 로그를 타임라인 순서로 정리.
- 시간상의 특징은 없었으나, 공통적으로 같은 IP에 대한 타임아웃이 발생.
- 레디스 클러스터 파드들을 확인한 결과, 해당 IP를 가진 클러스터 노드가 없음을 확인.
- 첫 번째 의심: 클러스터 노드가 본인이 인식하고 있는 IP가 다름.
- 두 번째 의심: 레디스 클라이언트가 클러스터 노드의 IP를 추적하는 방식에 문제 있음.
확인 과정
레디스 클라이언트는 5분마다 토폴로지 정보를 갱신하도록 설정되어 있었다. 즉, 첫 번째 의심이 원인임을 확인.
각 레디스 노드들이 인식하고 있는 클러스터 정보를 확인한 결과, 잘못된 IP를 인식하고 있는 금쪽이 노드를 찾아냈다.
해결 방안
문제가 되는 노드의 파드를 재실행시켜 IP를 재인식하도록 유도함. 재실행 후 해당 노드는 올바른 IP를 할당받아 문제를 해결하였다.
결론
어플리케이션에서 발생한 간헐적인 타임아웃 문제는 쿠버네티스 노드 장애로 인해 레디스 노드가 잘못된 IP를 인식한 것이 원인이었다. 문제 노드의 파드를 재실행하여 IP를 재할당받음으로써 문제를 해결하였다.
'트러블 슈팅 > 인프라' 카테고리의 다른 글
(ES) 엘라스틱 서치 용량 부족으로 인한 미적재 이슈 (0) | 2024.10.06 |
---|---|
(Kafka) Kafka Streams에서 Repartition Topic을 Consume하지 못하는 장애(feat: kafkaAdminCli) (0) | 2024.06.16 |
(Kafka) Kafka Streams에서 Repartition Topic을 Consume하지 못하는 장애 (feat: Metric으로 Lag값 추출) (0) | 2024.05.18 |
(Kafka) 유효하지 않은 레코드가 토픽에 들어와 카프카 어플리케이션 장애가 났을 때 (2) | 2024.05.08 |
(Airflow) 배치 날짜값 오차로 인한 통계값 오류가 발생한 이슈 2 (8) | 2024.05.01 |