Redis ENOTFOUND — 원래 항상 나던 에러
배포를 하고 나서부터 파드가 재기동될 때마다 로그에 Redis 연결 실패가 찍히기 시작했습니다.
Error: getaddrinfo ENOTFOUND <old-redis>.cache.amazonaws.com
errno: -3008, code: 'ENOTFOUND', syscall: 'getaddrinfo'호스트 이름을 못 찾겠다는 DNS 에러인데, 정작 서비스는 멀쩡히 돌고 Redis 를 쓰는 기능도 정상이었습니다. 캐시와 세션을 ElastiCache 로 띄운 Redis 에 두고 쓰는 서비스라 Redis 가 안 붙으면 바로 티가 나야 하는데, 에러만 찍히고 아무 일도 안 일어났습니다.
삭제된 지 몇 달 된 엔드포인트 조회
에러의 호스트 이름을 확인해봤더니, 이미 삭제된 ElastiCache 클러스터였습니다. 몇 달 전에 다른 걸로 교체됐는데, DNS 자체가 사라진 상태였습니다. 그래서 그 이름을 찾으면 당연히 ENOTFOUND 입니다.
문제는 앱이 왜 그 죽은 엔드포인트를 아직도 찾느냐였습니다.
이 앱은 Redis 연결 방식을 설정으로 분기했습니다.
| 설정 | 연결 대상 |
|---|---|
USE_REDIS_CLUSTER: true |
클러스터 모드 Redis (실제 운영) |
USE_REDIS_CLUSTER: false |
REDIS_HOST 의 단일 엔드포인트 |
운영은 USE_REDIS_CLUSTER: true 였고, REDIS_HOST 에 적힌 옛날 ElastiCache
엔드포인트는 실제로는 안 쓰는 값이었습니다. 클러스터를 교체하면서
REDIS_HOST 만 업데이트를 빠뜨린 채 남아 있었습니다.
초기화 때 안 쓰는 값 우선 조회
근본 원인은 앱 코드의 초기화 순서였는데, USE_REDIS_CLUSTER: true 인데도 일부
코드가 초기화 시점에 REDIS_HOST(죽은 엔드포인트)를 먼저 참조하고
있었습니다.
앱 시작
→ REDIS_HOST(죽은 ElastiCache) 먼저 조회 → ENOTFOUND (로그에 찍힘)
→ 클러스터 모드로 재연결 → 성공 (서비스 정상)그래서 에러는 매번 찍히지만, 곧바로 진짜 Redis(클러스터)로 붙어서 서비스는 멀쩡했습니다. 이 ENOTFOUND 는 장애가 아니라 원래 항상 나던 노이즈였습니다.
진짜 에러인지 판별하는 법
로그에 에러가 찍혔다고 다 장애는 아니라서, 이런 “폴백 과정의 에러” 는 뒤에 성공이 이어지는지로 갈라 봅니다.
- ENOTFOUND 직후에 Redis 연결 성공 로그가 이어지면 → 폴백 정상, 서비스 영향 없음
- 성공 로그가 없으면 → 그때는 진짜 연결 실패, Redis 상태를 점검
이걸 구분 안 하면, 원래 늘 있던 에러를 보고 “장애 났다” 며 엉뚱한 데를 파게 됩니다.
고칠 두 곳
인프라 쪽에서는 손댈 게 없었습니다. 안 쓰는 ElastiCache 엔드포인트라 갱신해도 의미가 없고, 근본 해결은 앱 코드 쪽입니다.
USE_REDIS_CLUSTER: true일 때REDIS_HOST참조 로직을 초기화에서 빼거나,REDIS_HOSTenv 자체를 배포 설정에서 제거해서 참조할 수 없게 만들거나.
남아 있던 옛 설정과 폴백 로그
죽은 설정이 남아 있던 것(클러스터 교체 때 REDIS_HOST 정리 누락)과 앱이
안 쓰는 값을 초기화 때 건드리는 것, 이 둘이 겹친 문제였습니다.
인프라를 바꾸면 그걸 참조하던 설정도 같이 정리해야 합니다. 안 쓴다고 남겨두면, 이렇게 몇 달 뒤에 “왜 없는 걸 찾지?” 하는 로그로 튀어나옵니다. 그리고 에러 로그를 볼 때는 그게 실제 실패인지, 폴백 과정에서 나는 로그인지부터 구분해야 합니다. 뒤에 성공이 이어지는지만 봐도 대부분 갈립니다.
댓글 0