사례25건

25건 중 11~15번째

1. IL-0046 계획된 재시작 뒤 Prometheus 가 WAL 을 다 읽기 전에 startupProbe 에 걸려 재시작을 반복했고 지표가 빠졌다

   UK Ministry of Justice2024

   증상

   2024-04-15 12:32 에 계획된 Prometheus 변경을 적용한 뒤 Prometheus 를 쓸 수 없게 되었다. 팀은 prometheus 파드가 여러 번 재시작한 것을 보았다. 그동안 Cloud Platform 에는 모니터링이 없었고 지표가 빠졌다.

   모니터링 중단프로브 실패

   촉발

   계획된 변경으로 Prometheus 를 재시작했는데 그때 WAL 수가 평소보다 많아, WAL 다시 읽기가 startupProbe 기본 허용 시간인 15분 안에 끝나지 않았다.

   원인

   용량 한계

   구성 요소

   Prometheus

   기여 요인

   기본 설정 방치한계 미인지

   감지

   계획된 Prometheus 변경 뒤 팀이 prometheus 파드가 여러 번 재시작한 것을 보고 알았다. 처음 감지한 시각은 2024-04-15 12:32 였다.

   조치

   • startupProbe 허용 시간을 기본값 15분에서 30분으로 늘려 WAL 다시 읽기가 끝날 때까지 기다리게 했다.

   후속 조치

   • 팀은 계획된 Prometheus 재시작을 WAL 수가 적을 때 해서 재시작 시간을 줄이는 방안을 논의했다.
   • Prometheus 의 기본 CPU 와 메모리 요청값을 최대 사용량에 맞춰 설정했다.
   • 운영 환경의 WAL 수를 재현하는 테스트 환경을 만든다.
   • memory-snapshot-on-shutdown 과 auto-gomaxprocs 기능 플래그를 검토한다.
   • WAL 파일을 다른 위치의 원격 저장소에 두는 방법을 검토한다.
   • 운영과 같은 구성의 블루그린 Prometheus 를 만들어 운영에 적용하기 전에 변경을 시험하는 방안을 알아본다.
   • Amazon Managed Prometheus 를 간단히 조사한다.

   사례 보기
2. IL-0083 멀티 테넌트 쿠버네티스 클러스터에서 노드 로컬 dnsmasq 가 동시 질의 한도에 걸리고 cluster.local 응답을 캐시하지 못한 데다 ndots 검색 도메인 질의가 CoreDNS 로 몰려, 서비스 간 호출이 간헐적인 5xx 를 냈다.

   Adevinta2023

   증상

   어느 금요일 오후, 고객 한 곳이 SCHIP 에서 돌리는 일부 서비스에서 HTTP 5xx 오류가 튄다고 알려 왔다. 팀은 바로 장애를 선언했다.

   오류율 상승DNS 조회 실패지연 시간 증가

   원인

   DNS·네트워크 장애

   구성 요소

   CoreDNS클라이언트 쪽 DNS 리졸버와 캐시텔레메트리 에이전트

   기여 요인

   기본 설정 방치한계 미인지초기 신호 무시미검증 가정

   감지

   고객이 SCHIP 에서 돌리는 일부 서비스의 HTTP 5xx 가 튄다고 알려 와서 알았다. DNS 와의 관계는 한참 뒤에야 드러났고, 그때 보니 그동안 무시해 온 이 클러스터의 DNS Latency SLI 가 다른 클러스터보다 낮아져 있었다.

   조치

   • dnsmasq 의 노드당 동시 DNS 질의 한도를 150에서 Google 권장값인 1500으로 올렸다.
   • CoreDNS 가 응답에 RA 비트를 항상 넣도록 header 설정에 set ra aa, clear rd 를 넣어 dnsmasq 가 cluster.local 응답을 캐시하게 했다.
   • 노드 로컬 dnsmasq 에서 ndots 때문에 생긴 풀 수 없는 도메인 질의를 가로채 NXDOMAIN 으로 응답하도록 설정해 CoreDNS 로 넘어가지 않게 했다.
   • fluent-bit 가 로그 라우터에 접속할 때 쓰는 호스트 이름을 서비스 이름에서 FQDN 으로 바꿨다.
   • 영향받은 고객에게 앱의 내부 이름 해석을 FQDN 으로 바꾸도록 요청했다.

   교훈

   SLO 를 보기 좋은 지표로만 두지 말고 안전장치로 써야 한다. 이번에는 나빠진 DNS Latency SLI 를 오래 무시한 탓에 원인을 늦게 찾았다. SLO 를 안전장치로 쓰려면 믿을 수 있는 SLI 가 먼저 있어야 한다. 조사가 여러 당직자에게 흩어져 있었고, 관찰 결과와 가설을 한곳에 모으지 않아 같은 가설이나 이미 버린 가설을 다시 붙잡기도 했다. 가설 하나를 버린 뒤에 다음 가설로 넘어가야 한다. 기존 지표에 없는 데이터는 DNStop 처럼 직접 모아야 한다. 멀티 테넌트 환경에서는 DNS 를 한 번 개선하면 모든 고객이 그 효과를 본다.

   사례 보기
3. IL-0151 us-east-1 의 Lambda 셀 하나가 처음 겪는 규모로 커지며 잠재 결함이 드러나 Lambda 호출이 실패했고, Lambda 에 기대는 EKS 의 새 클러스터 생성도 오류와 지연을 겪었다.

   Amazon Web Services2023

   증상

   2023년 6월 13일 11:49 AM PDT 부터 us-east-1 리전에서 Lambda 함수 호출의 오류율과 지연이 늘었다. Amazon EKS 에서는 새 클러스터를 만들 때 오류율과 지연이 늘었고, 기존 EKS 클러스터는 영향을 받지 않았다.

   오류율 상승지연 시간 증가자격 증명 획득 실패

   촉발

   트래픽이 평소 하루 패턴 범위 안에서 늘어 10:01 AM 부터 Lambda Frontend 플릿이 확장했고, 11:49 AM 에 셀 하나가 한 번도 도달한 적 없는 용량 임계를 넘었다.

   원인

   소프트웨어 결함

   구성 요소

   서버리스 함수 플랫폼

   기여 요인

   한계 미인지

   감지

   엔지니어링 팀이 곧바로 투입돼 조사를 시작했고, 12:26 PM 에 잠재 결함과 그 결함이 컴퓨트 용량 공급에 준 영향을 찾았다.

   조치

   • 트래픽이 줄어든 것을 확인하고 Lambda Frontend 플릿을 결함이 나타나지 않는 규모로 줄였다.

   후속 조치

   • 장애를 일으킨 Lambda Frontend 플릿의 확장 작업을 곧바로 막았다.
   • 잠재 결함을 고쳐 모든 리전에 배포했다.
   • 셀 확장에서 드러난 시급한 문제에 대응하는 여러 조치를 마쳤다.
   • 모든 셀을 충분히 시험한 크기 안에 묶어 예상하지 못한 확장 문제를 막는 더 큰 작업을 2023년 안에 마친다.

   교훈

   셀 구조여도 셀 하나가 한 번도 겪지 않은 크기로 커지면 잠재 결함이 드러날 수 있다. 이번 장애로 Lambda Frontend 를 확장할 때 셀 구조에 빈틈이 있다는 것이 드러났다. Lambda 함수 호출에 기대는 STS, 콘솔, EKS 같은 서비스도 함께 오류와 지연이 늘었다. EKS 에서는 새 클러스터 생성만 실패했고 이미 돌던 클러스터는 영향이 없었다.

   사례 보기
4. IL-0194 kube-apiserver 재시작 뒤 Vector DaemonSet 의 파드 list 요청이 한꺼번에 몰려 etcd 메모리가 세 배 가까이 늘고 마스터 노드가 연쇄적으로 재시작했다.

   Palark2023

   증상

   일상적인 kube-apiserver 재시작 직후 etcd 메모리 사용량이 거의 세 배로 치솟았고, 그 여파로 모든 마스터 노드가 연쇄적으로 재시작했다. 고객사의 운영 클러스터였다.

   컨트롤 플레인 무응답데이터베이스 과부하

   촉발

   일상적인 kube-apiserver 재시작 뒤, Vector 로그 수집기 DaemonSet 의 파드 전부가 캐시를 다시 채우려고 한꺼번에 파드 list 요청을 보냈다.

   원인

   용량 한계

   구성 요소

   etcd쿠버네티스 API 서버텔레메트리 에이전트

   기여 요인

   한계 미인지기본 설정 방치

   감지

   kube-apiserver 재시작 직후 마스터 노드 전체 메모리와 etcd 메모리 그래프가 치솟고 마스터 노드가 연쇄적으로 재시작하면서 알았다. 원인이 된 DaemonSet 은 감사 로그를 보고 찾았다.

   조치

   • limit-list-custom 이라는 PriorityLevelConfiguration 을 만들어 요청 대기열을 설정했다. 값은 문서의 표준 설정을 그대로 썼다.
   • 같은 이름의 FlowSchema 를 만들어, 이 DaemonSet 서비스 어카운트가 보내는 파드 list 와 get 요청을 그 대기열로 보냈다.

   후속 조치

   • 쿠버네티스 Rust 라이브러리에 resourceVersion 설정을 넣는 PR 을 냈다.
   • Vector 로그 수집기 쪽에 이 문제를 고치는 PR 을 열었다.
   • Cilium CNI 에서도 비슷한 문제를 찾아 같은 방법으로 해결했다.

   교훈

   etcd 는 필드 셀렉터와 레이블 셀렉터를 모르기 때문에, kube-apiserver 에는 가벼워 보이는, 필터를 건 list 요청도 etcd 에서는 그 종류의 객체 전체를 읽는 일이 된다. 데이터가 꼭 최신이어야 하는 컨트롤러가 아니라면 resourceVersion=0 으로 kube-apiserver 캐시에서 읽게 할 수 있다. 다만 kube-apiserver 가 여러 대면 인스턴스마다 다른 데이터를 받을 수 있다. 여러 파드가 한꺼번에 보내는 요청은 Priority and Fairness 로 대기열에 넣어 kube-apiserver 와 etcd 를 지킬 수 있다. 위험한 것은 파드 요청만이 아니어서 Cilium CNI 에서도 비슷한 문제가 나왔다.

   사례 보기
5. IL-0461 메트릭 질의 서비스를 롤아웃할 때마다 DNS 오류가 나며 질의가 실패했다

   Datadog2022

   증상

   2021년 9월부터 메트릭 질의 서비스의 업데이트를 롤아웃할 때마다 오류가 늘었다. 서비스 로그에는 DNS 오류 때문에 메트릭 데이터 저장소에 연결하지 못했다는 내용이 찍혔다. 클라이언트가 실패한 질의를 자동으로 재시도해 사용자에게 보이는 오류는 적었지만, 재시도 때문에 대시보드와 모니터의 지연이 늘었다.

   오류율 상승DNS 조회 실패지연 시간 증가OOMKilled패킷 손실오래된 엔드포인트 라우팅

   촉발

   2021년 8월 메트릭 질의 클라이언트의 업데이트를 롤아웃하면서 새 기본값인 gRPC round_robin 부하 분산 정책이 처음 적용됐다. round_robin 은 끊긴 채널을 자동으로 다시 연결하는데, 오래전에 넣어 둔 매우 공격적인 gRPC 재연결 타임아웃과 겹쳐 서비스 롤아웃 때마다 사라진 파드 IP 로 SYN 이 쏟아졌다.

   원인

   설정 변경

   구성 요소

   conntrack 테이블Cilium리눅스 커널CoreDNS클라이언트 쪽 DNS 리졸버와 캐시external-dnsHTTP·RPC 클라이언트 라이브러리

   기여 요인

   늦게 드러난 변경재시도 폭주한계 미인지모니터링 사각지대

   감지

   2021년 9월부터 메트릭 질의 서비스 롤아웃 때 오류가 늘어나는 것을 보았고, 서비스 로그에서 DNS 오류가 데이터 저장소 연결을 막는 것을 확인했다.

   조치

   • node-local-dns 파드의 메모리를 64 MB 에서 256 MB 로 올렸다. OOM 오류는 멈췄지만 DNS 오류는 계속됐다.
   • AWS 가 더 많은 연결을 추적할 수 있다고 한 더 큰 인스턴스 유형으로 서비스 인프라를 올려 보았고, 그것만으로 문제가 사라지는 것을 확인했다.
   • SYN 폭주를 일으킨 사용자 지정 gRPC 재연결 파라미터를 지우고 기본값으로 되돌리는 PR 을 만들었다. 다음 롤아웃에서는 오류가 나지 않았다.

   후속 조치

   • Cilium 프로젝트에 PR 을 기여한다. 이 PR 은 옛 파드 IP 에 unreachable 경로를 더해, 지워진 파드로 가는 요청이 martian 패킷이 되지 않게 한다. 그러면 역경로 필터가 SYN 을 버리지 않고, 클라이언트는 분명한 ICMP 오류를 받는다.

   교훈

   gRPC, 쿠버네티스, AWS 같은 강력한 추상화도 엣지 케이스에서는 평소에 숨어 있던 복잡함이 오류로 드러난다. 몇 달을 조사한 끝에, 이번 장애의 뿌리가 팀이 직접 한 변경에 있다는 것을 찾았다. 의존성의 버그를 피해 가려던 변경, 이전 장애를 고치려던 변경, 기본 재연결 파라미터를 덮어쓴 변경이었다. 이 변경들은 당시에는 안전해 보였지만 한참 뒤에 상관관계를 찾기 어려운 때에 뜻밖의 결과를 냈다. DNS 문제처럼 보여도 DNS 문제가 아닐 때가 있다. AWS ENA 지표와 VPC Flow Logs 는 연결 추적을 들여다보는 데 중요하다. DNS 전파 시간은 여러 요인에 좌우된다.

   사례 보기

원인별7