Incident Library

IL-0433 MonotaRO · 2023-08-24 (게시일)kubernetesawsnetworking

EC2 에서 EKS on Fargate 로 트래픽을 옮기던 중 CoreDNS 과부하로 이름 해석 오류가 쏟아져 롤백했다

MonotaRO 의 SRE 그룹은 엔드포인트가 200개가 넘는 모놀리스 백엔드 API 를 EC2 에서 Fargate 노드를 쓰는 EKS 로 옮기고 있었다. ALB 로 엔드포인트마다 요청 비율을 바꾸며 진행했고, 일부 엔드포인트를 옮긴 뒤 나머지를 모두 옮기려고 비율을 1% 에서 25% 로 올렸다. 트래픽이 적은 시간대였고 전환 때 요청량은 1000RPS 안팎이었다. 이때 Sentry 에 이름 해석 오류가 대량으로 나서 데이터베이스와 프록시에 연결하지 못했고, 팀은 요청 비율을 VM 쪽으로 되돌렸다.

CoreDNS 는 CPU requests 100m, 메모리 limits 170Mi 로 설정되어 Fargate 에서 0.25vCPU 머신에 올라갔고, replicas: 2 로 파드 두 개만 돌았다. 부하가 큰 원인은 파드의 /etc/resolv.conf 에 있는 options ndots:5 였다. 점이 다섯 개보다 적은 이름은 search 도메인을 차례로 붙여 질의하므로, example.com 하나를 풀 때마다 NXDOMAIN 질의가 여러 번 먼저 났다. 캐시 TTL 도 따로 정하지 않아 기본값 5초였고, 이는 CoreDNS 가 질의를 넘기는 상위 DNS 의 캐시 TTL 보다 짧았다.

팀은 먼저 기존 CoreDNS 설정을 바꾸지 않고 HPA 로 CoreDNS 파드를 오토스케일하게 해 EKS 이전을 마쳤다. 그러나 비용이 계속 들고, 스케일인 때 파드가 끝나면서 처리 중인 요청이 끊겨 가끔 이름 해석 오류가 났다. 이후 애플리케이션 Deployment 의 dnsConfig 로 ndots 를 1 로 낮추고, CoreDNS ConfigMap 의 cache 를 600 으로 늘렸다. CoreDNS 이미지는 distroless 라 preStop 에서 sleep 을 쓸 수 없었으므로, health 플러그인의 lameduck 30s 로 종료를 늦췄다. 팀은 관리형 서비스이니 문제가 없으리라 짐작하고 사례 조사와 부하 시험, 감시를 하지 않은 것이 이번 문제의 원인이라고 보았다.

심각도
–
영향 범위
Requests to the backend API on EKS failed to reach the database and outside services through the proxy, so the traffic shift was rolled back
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

남은 엔드포인트의 요청 비율을 EKS 쪽으로 1% 에서 25% 로 올리자 Sentry 에 DNS 이름 해석 오류가 대량으로 올라왔다. API 가 데이터베이스와 외부 서비스에 연결하지 못했다.

프록시 연결에서는 NewConnectionError('<urllib3.connection.HTTPSConnection object at 12345678>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution') 가 났다. 데이터베이스 연결에서는 OperationalError:(2005, "Unknown MySQL server host 'db.example.com' (-3)") 가 났다.

쿠버네티스에서 이름 해석은 CoreDNS 가 맡으므로 팀은 곧바로 CoreDNS 를 의심했다. 요청 비율을 VM 쪽으로 되돌린 뒤 CPU 와 메모리 사용량을 보니, CPU requests 가 100m 인 CoreDNS 파드에 그보다 큰 부하가 걸려 있었다. CoreDNS 는 replicas: 2 로 파드 두 개뿐이었고, Fargate 에서 0.25vCPU 머신으로 프로비저닝되어 있었다.

CoreDNS 로그에는 example.com.default.svc.cluster.local, example.com.svc.cluster.local, example.com.cluster.local 의 A 와 AAAA 질의가 NXDOMAIN 으로 끝난 뒤에야 example.com. 질의가 NOERROR 로 풀리는 줄이 이어졌다.

HPA 로 CoreDNS 파드를 오토스케일하게 한 뒤에는 CoreDNS 가 스케일인할 때 가끔 이름 해석 오류가 났다.

증상 DNS 조회 실패오류율 상승

원인

원인 용량 한계

구성 요소 CoreDNS클라이언트 쪽 DNS 리졸버와 캐시컨테이너 CPU 한도수평 파드 오토스케일러파드 종료 처리
기여 요인 기본 설정 방치리소스 요청과 한도 미설정스테이징 불일치미검증 가정
촉발
ALB 로 엔드포인트마다 요청 비율을 바꾸며 이전하던 중, 남은 엔드포인트의 요청 비율을 EKS 쪽으로 1% 에서 25% 로 올렸다.

감지

요청 비율을 EKS 쪽으로 올린 직후 Sentry 에 DNS 이름 해석 오류가 대량으로 올라온 것을 확인했다.

조치

후속 조치

교훈

MonotaRO 는 관리형 서비스이니 문제가 없으리라 짐작하고 사전 사례 조사, 부하 시험, 감시 같은 측정을 하지 않아 이번 문제가 났다고 보았다. 그래서 짐작하지 말고 측정하라는 원칙을 다시 새겼다. 운영 환경과 스테이징 환경의 차이가 컸다. 네트워크 구성이 달라 환경마다 ndots 가 달랐고, 스테이징 환경의 데이터베이스 사양으로는 고부하 시험을 할 수 없었다. 직접 관리하지 않는 부분의 리소스도 잘 알지 못했다. 쿠버네티스로 옮긴 다른 회사의 사례를 조사했다면 이번 문제를 어느 정도 예측할 수 있었다고 했다.

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: CoreDNS, 클라이언트 쪽 DNS 리졸버와 캐시, 컨테이너 CPU 한도. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

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