Incident Library

IL-0268 AdGuard DNS · 2025-11-25networking

유럽 여러 거점의 AdGuard DNS 리졸버가 과부하에 걸려 DNS 조회가 타임아웃되거나 SERVFAIL 을 냈다

AdGuard DNS 리졸버는 필터를 적용하려면 사용자의 필터링 설정을 로컬에 갖고 있어야 한다. 리졸버는 시작할 때 로컬 파일에서 전체 사용자 데이터의 캐시 사본을 읽고, 그 뒤로는 비즈니스 로직 서비스에 바뀐 부분만 주기적으로 묻는다. 로컬 캐시가 오래됐거나 손상됐으면 비즈니스 로직 서비스에서 전체 데이터를 받아야 하고, 이 작업은 느리고 양쪽에 훨씬 큰 부하를 준다. AdGuard 는 2025년 11월 25일 14시 30분 UTC 에 이 방식을 개선하는 새 버전을 배포하기 시작했다. 이 버전은 버그 때문에 캐시 파일에 최근 바뀐 일부만 저장해서, 캐시가 아주 작거나 비어 있었다. 첫 배포는 네트워크 문제로 한 시간쯤 뒤 중간에 실패해 서버의 절반쯤만 새 버전으로 돌았다.

15시 30분에 배포를 다시 시도하자 많은 리졸버가 동시에 캐시가 비었거나 쓸 수 없다는 것을 알고 전체 동기화를 시작했다. 비즈니스 로직 서비스로 가는 트래픽과 리졸버의 자원 사용이 치솟았다. DNS 오류율과 서버 부하 알림이 울렸고, 조사해서 캐시 버그를 빨리 찾았다. 16시부터 모든 서버에서 동시에 롤백하기로 했다. 암스테르담에서는 32 GiB 서버가 먼저 떨어져 나가고 64 GiB 서버도 이어서 실패했다. 트래픽 일부를 다른 유럽 거점으로 돌리자 프랑크푸르트와 런던의 부하가 크게 늘었다.

프랑크푸르트와 런던은 하드웨어가 같았지만 잘못 잡힌 한도와 높은 동시성 때문에 크게 나빠졌다. 파이프라이닝 깊이가 5여서 연결 하나에 처리 중인 요청이 여러 개 실렸다. 요청마다 고루틴과 버퍼가 따로 생겨 힙이 커졌고, Go 가비지 컬렉터에 압박이 걸렸다. AdGuard 의 설명에 따르면 connlimit 은 Go 런타임이 가비지 컬렉션을 강하게 돌리기 전까지 관리 힙에 쓰는 메모리의 최댓값을 정하는 설정이다. 64 GiB 서버에서는 이 한도가 높아 힙이 크게 자란 뒤 가비지 컬렉션이 CPU 를 오래 썼다. 16시 30분부터 17시 30분 사이에 프랑크푸르트와 런던의 연결 동시성과 파이프라인 깊이를 줄이고 한도를 실제 하드웨어에 맞췄다. 손상된 캐시 파일과 사용자 데이터 스냅샷도 고쳤다. 프랑크푸르트에서 파이프라인 깊이를 5에서 1로 줄이자 매우 빨리 회복됐다. 17시 30분부터 18시 사이에 롤백이 끝나 캐시가 일관된 상태로 돌아왔다. 트래픽 분배도 정상으로 돌아와 오류율이 평소 수준으로 내려왔다.

심각도
–
영향 범위
AdGuard DNS resolution in several European locations: intermittent timeouts and SERVFAIL for a significant portion of traffic, for up to 2.5 hours
영향 사용자
some AdGuard DNS users
지역
Europe, primarily Amsterdam, Frankfurt and London
감지까지
–
복구까지
2h 30m

증상

DNS 오류율과 서버 부하가 늘었다는 알림이 울렸다. 일부 AdGuard DNS 사용자는 DNS 조회가 느려지거나 실패했고, 타임아웃과 SERVFAIL 응답을 받았다.

영향은 주로 유럽, 그중에서도 암스테르담, 프랑크푸르트, 런던에 몰렸다. 이 거점들에서 트래픽의 상당 부분이 최대 2.5시간 동안 간헐적으로 실패했다. 상위 DNS 공급자들은 내내 정상으로 빠르게 응답하고 있었다. 실패는 리졸버 계층이 내부 타임아웃이나 클라이언트 타임아웃이 지나기 전에 응답을 처리해 보내지 못해서 났다.

암스테르담 클러스터는 RAM 32 GiB 서버와 64 GiB 서버가 섞여 있었고, 설정은 64 GiB 에 맞춰져 있었다. 32 GiB 서버가 먼저 쓸 수 있는 메모리를 다 쓰고 내부 한도에 닿아 사실상 트래픽을 처리하지 못했다. 부하가 64 GiB 서버로 몰리자 그 서버들도 연결 한도에 닿고 큐가 길어지며 실패하기 시작했다.

프랑크푸르트에서는 시스템 수준의 CPU 사용률이 꽉 차 보이지 않았는데도 꼬리 지연 시간이 크게 늘었다. 클러스터가 연결 한도에 닿은 채 머물렀고, 기존 연결이 평소보다 오래 붙잡혀 있어서 새 클라이언트는 연결을 맺기 어려웠다. 메모리 압박으로 Go 가비지 컬렉션이 잦아지고 비용이 커져서 쿼리마다 리졸버 안에서 머무는 시간이 길어졌다.

클라이언트와 재귀 리졸버는 실패한 쿼리를 다시 시도했다. 재시도가 부하를 더 키워 연결 한도가 계속 꽉 찬 상태로 남았다. 가비지 컬렉션 압박, 연결 포화, 클라이언트 재시도가 서로를 키웠다.

AdGuard 는 암스테르담을 안정시키려고 트래픽 일부를 다른 유럽 거점으로 돌렸다. 그러자 암스테르담은 안정됐지만 프랑크푸르트와 런던에 부하가 크게 늘었다.

증상 DNS 조회 실패간헐적 타임아웃지연 시간 증가메모리 압박

원인

원인 배포 결함

구성 요소 재귀 DNS 리졸버 서비스언어 런타임 설정
기여 요인 데워진 캐시에 기댄 구조재시도 폭주수동 조치 악화자동 테스트 공백
촉발
AdGuard 는 11월 25일에 사용자 데이터 캐시 방식을 개선하려는 새 AdGuard DNS 버전을 배포했다. 버그 때문에 리졸버가 로컬 캐시 파일에 전체 사용자 데이터가 아니라 최근에 바뀐 일부만 저장했다. 다시 시도한 배포에서 많은 리졸버가 한꺼번에 전체 동기화를 시작했다.

감지

15시 30분에서 16시 UTC 사이, 두 번째 배포를 시작한 뒤 DNS 오류율과 서버 부하가 늘었다는 알림이 울렸다.

조치

후속 조치

교훈

노드마다 다르게 움직인 데에는 사용할 수 있는 RAM, Go 가비지 컬렉터, connlimit 설정이 서로 맞물린 것이 컸다. 메모리가 큰 서버에서 connlimit 을 너무 높게 잡으면 힙이 크게 자란 뒤에야 가비지 컬렉션이 강하게 돈다. 그러면 메모리는 남아도 CPU 시간이 가비지 컬렉션에 점점 더 쓰여, 지연이 늘고 처리량이 준다. AdGuard 는 이것을 메모리를 많이 쓰는 애플리케이션에서 connlimit 이 만드는 알려진 최악의 경우라고 했다. 메모리가 작은 서버는 캐시 크기와 연결 한도를 RAM 에 맞춰 줄이지 않아서 더 일찍 실패했다. 여기에 높은 파이프라이닝과 많은 재시도가 겹쳐 가비지 컬렉션 압박, 연결 포화, 클라이언트 재시도가 서로를 키우는 고리가 생겼다.

출처

관련 사례

–

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 재귀 DNS 리졸버 서비스, 언어 런타임 설정. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.