사례2건

2건 중 1~2번째

1. IL-0445 EKS 로 옮기던 레거시 시스템에서 conntrack 테이블이 넘쳐 연결이 끊겼고, 이어 CoreDNS 파드가 축출될 때와 node-local-dns 를 넣은 뒤에 DNS 오류가 났다

   Chatwork2021

   증상

   Route53 가중치로 EC2 와 EKS 를 함께 돌리며 레거시 시스템을 옮기던 중, 일정 비율이 넘는 요청을 EKS 쪽으로 보내자 서비스가 갑자기 불안정해졌다. 일부 노드에서 conntrack 테이블이 한계를 넘어 애플리케이션으로 가는 연결이 드롭되고 있었다.

   간헐적 연결 실패DNS 조회 실패간헐적 타임아웃부하 불균형

   촉발

   첫 번째 불안정은 Route53 가중치로 EKS 쪽에 보내는 요청 비율을 일정 이상으로 올리면서 시작됐다. 두 번째 불안정은 문서에 나온 매니페스트로 force_tcp 를 쓰는 node-local-dns 를 운영 환경에 apply 하면서 시작됐다.

   원인

   용량 한계

   구성 요소

   conntrack 테이블CoreDNSkube-proxy클라이언트 쪽 DNS 리졸버와 캐시VPC DNS 리졸버

   기여 요인

   기본 설정 방치스테이징 불일치한계 미인지

   조치

   • conntrack 상한이 기본값과 다른 값으로 설정되어 있었고 그 값은 kube-proxy 가 정하고 있었다. 팀은 kube-proxy 설정에서 conntrack 의 maxPerCore 를 늘렸다.
   • EKS 에 빠져 있던 dns-autoscaler 를 넣었다. CoreDNS 파드가 어느 정도 늘자 서비스가 크게 안정됐다.
   • CoreDNS 파드가 축출될 때 나던 DNS 오류를 없애려고 각 노드에 DaemonSet 으로 실행되는 node-local-dns 를 넣었다.
   • node-local-dns 설정에서 force_tcp 를 빼고 prefer_udp 로 바꾸자 DNS 가 안정됐다.

   교훈

   EKS 에서 DNS 를 안정시킨 것은 dns-autoscaler 를 넣은 것과, force_tcp 없이 node-local-dns 를 넣은 것 두 가지였다. node-local-dns 를 쓸 때는 eksctl 로 kubelet 의 DNS 대상을 바꿀 필요가 없고, kube-dns 를 그대로 두면 된다. node-local-dns 를 업데이트하는 동안처럼 잠시 쓸 수 없을 때는 dummy device 덕에 애플리케이션의 DNS 요청이 CoreDNS 로 바로 가므로 클러스터 전체의 가용성이 오른다. DNS 가 불안정하면 조회가 막혀 파드가 쓸데없이 늘어나므로, 파드 수를 알맞게 유지하는 데도 DNS 안정이 중요하다.

   사례 보기
2. IL-0399 AWS eu-west-1 의 EC2 DNS resolver 문제로 GOV.UK PaaS 와 그 위의 애플리케이션이 DNS 조회에 간헐적으로 실패했다

   Government Digital Service2016

   증상

   2016년 12월 15일 새벽 GOV.UK PaaS 의 VM 에 DNS 조회 오류가 기록되기 시작했고, PaaS 에 배포한 애플리케이션이 DNS 조회에 간헐적으로 실패했다. 그 때문에 서비스가 데이터베이스, 백엔드 서비스, API 에 연결하지 못했을 수 있다. 01:00 부터 03:17 사이에 이 애플리케이션을 쓴 사용자는 간헐적인 느려짐과 오류를 봤을 수 있다.

   DNS 조회 실패간헐적 연결 실패모니터링 중단

   원인

   클라우드 제공자 장애

   구성 요소

   VPC DNS 리졸버

   기여 요인

   잡음에 묻힌 신호

   감지

   장애가 난 시각에 팀은 PaaS 를 24시간 지원하지 않았다. 팀은 12월 15일 업무를 시작하면서 모니터링 알림이 나가 있던 것을 알아챘다. 08:00 에 팀원이 경고를 보고, 모니터링에서 영향이 끝났음을 확인했다.

   후속 조치

   • 디스크 모니터링 데이터가 들어오지 않을 때는 모니터링 시스템이 메일을 보내지 않게 한다. 메일이 너무 많으면 다른 알림을 알아보기 어렵기 때문이다.
   • 장애를 tenant 에게 더 쉽고 빠르게 알릴 수 있게 한다.
   • 업무 시간 밖 지원에 쓸 알림을 곧 도입하고, 어떤 알림을 둘지는 이 장애를 예로 삼아 정한다.
   • PaaS 를 쓰는 서비스의 필요에 맞춰 곧 24시간 지원을 시작한다.

   사례 보기

원인별2