사례7건

7건 중 1~5번째

1. IL-0081 ingress-nginx 의 enable-serial-reloads 옵션이 NGINX 리로드 중에 엔드포인트 동적 갱신을 막아, 배포 중 트래픽이 이미 없는 파드로 가면서 API 요청이 타임아웃됐다.

   Cresta2025

   증상

   배포 도중 쿠버네티스로 들어오는 트래픽이 갈 곳을 잃기 시작했다. 일부 API 요청이 타임아웃됐다.

   간헐적 타임아웃오래된 엔드포인트 라우팅지연 시간 증가

   촉발

   오래 걸리는 NGINX 전체 리로드가 진행되는 동안 배포 롤아웃으로 백엔드 엔드포인트가 바뀌었다. ingress-nginx 컨트롤러에는 enable-serial-reloads 옵션이 켜져 있었다.

   원인

   소프트웨어 결함

   구성 요소

   인그레스 컨트롤러

   기여 요인

   –

   조치

   • 문제를 풀어 보려고 NGINX Ingress 컨트롤러를 재시작했다.

   후속 조치

   • enable-serial-reloads 가 엔드포인트 동적 갱신을 막는 문제를 kubernetes/ingress-nginx 에 이슈로 올린다.

   교훈

   자원 소모를 막으려고 켠 무해해 보이는 플래그 하나가, 라우팅이 실제 배포 상태와 어긋나는 구간을 만들 수 있다. 엔드포인트 동적 갱신이 리로드에 묶이면 배포 중 트래픽이 사라진 파드로 간다.

   사례 보기
2. IL-0131 새로운 형태의 GenerateContent 요청이 Vertex AI 예측 API 서버에 세그폴트를 일으켰고, 동시에 재시작하는 서버가 늘자 서빙 용량이 모자라 여러 리전에서 오류가 치솟았다.

   Google Cloud2024

   증상

   2024년 6월 12일 12:06 US/Pacific 부터 Vertex AI Online Prediction, Dialogflow CX, Agent Assist 에서 여러 리전에 걸쳐 오류율이 올라갔다. 영향을 받은 리전은 us-central1, asia-southeast1, europe-west3, europe-west4, us-east1, us-west1, northamerica-northeast1, us-east4 였다.

   오류율 상승지연 시간 증가간헐적 타임아웃

   촉발

   6월 8일부터 새로운 형태의 GenerateContent API 요청이 Vertex Serving Prediction API 서버에 간헐적인 세그폴트를 일으켰고, 6월 12일 이런 요청의 비율이 늘었다.

   원인

   소프트웨어 결함

   구성 요소

   모델 추론 서버클라우드 로드 밸런서

   기여 요인

   부분 배포여유 용량 부재

   감지

   6월 10일 07:35 US/Pacific 에 내부 운영 모니터링이 엔지니어들에게 세그폴트 문제를 알렸다. 이때는 고객 영향이 없었다. 6월 12일 12:06 에는 Vertex Prediction 위에 만든 여러 서비스에서 운영 중인 사용자 요청이 영향을 받았다는 보고가 올라왔다.

   조치

   • 6월 12일의 새 장애가 6월 10일에 찾은 세그폴트와 원인이 같다는 것을 확인했다.
   • 이미 진행 중이던 수정본 배포를 앞당겨 15:59 US/Pacific 에 마쳤다.

   후속 조치

   • 서버 바이너리 문제의 초기 신호를 운영 상태 분석에서 잡아내고 제때 조사하게 한다.
   • 기능 변경과 업데이트를 운영에 내보낼 때 릴리스 검증을 거치게 한다.

   교훈

   로드밸런서가 크래시로 내려간 서버를 피해 요청을 보내는 동안에는 고객 영향이 보이지 않는다. 하지만 크래시를 일으키는 요청이 늘면 동시에 빠지는 서버가 늘어 서빙 용량이 부하를 감당하지 못하게 된다. 이번에는 6월 10일에 원인과 수정본이 이미 있었지만 단계적 배포가 끝나기 전에 고객 영향이 시작됐다. 서버 바이너리의 초기 이상 신호는 고객 영향이 없을 때도 운영 상태 분석에서 잡고 제때 조사해야 한다.

   사례 보기
3. IL-0161 앞선 API 업데이트가 의도대로 동작하지 않아 토론토 데이터센터에서 새 LKE 클러스터 프로비저닝이 타임아웃으로 사흘 넘게 실패했다.

   Linode2024

   증상

   2024년 4월 22일 14:05 UTC 쯤 토론토 데이터센터에서 새 LKE 클러스터가 프로비저닝되지 않았다.

   클러스터·노드 생성 정체간헐적 타임아웃

   촉발

   앞서 배포한 API 업데이트가 의도대로 동작하지 않았고, 새 LKE 클러스터를 프로비저닝할 때 타임아웃을 일으켰다.

   원인

   소프트웨어 결함

   구성 요소

   노드 풀

   기여 요인

   –

   감지

   2024년 4월 22일 14:05 UTC 쯤 Linode 팀이 토론토 데이터센터에서 새 LKE 클러스터가 프로비저닝되지 않는 것을 알아채고 조사를 시작했다.

   조치

   • 4월 23일 15:03 UTC 에 문제가 된 토론토 데이터센터의 인프라를 새 LKE 클러스터 프로비저닝에 쓰지 않도록 껐다.
   • 4월 25일 16:45 UTC 쯤 의도대로 동작하지 않던 API 업데이트를 바로잡는 수정을 적용했고, 18:05 UTC 에 새 클러스터 생성이 완전히 돌아온 것을 확인했다.
   • 수정을 적용한 뒤 잠시 빼 두었던 인프라를 다시 프로비저닝에 넣었다.

   교훈

   원인은 오류가 드러난 인프라가 아니라 앞서 배포한 API 업데이트에 있었다. 그런데도 실패는 대부분 한 데이터센터의 백엔드 자원 하나에 몰렸다. 그 자원을 새 클러스터 프로비저닝에서 빼서, 근본 원인을 찾는 데 걸린 사흘 동안 고객 영향을 줄였다.

   사례 보기
4. IL-0112 나중에 회수된 EKS 노드 AMI 로 노드를 교체한 뒤 노드가 PLEG is not healthy 를 보고하며 NotReady 를 오갔고 파드 네트워크 타임아웃이 났다

   DFDS2022

   증상

   2022-10-31 13:45 UTC 에 팀은 계획된 vpc-cni EKS 애드온 업그레이드를 배포 파이프라인으로 시작했다. 14:10 에 파이프라인이 업그레이드 중 타임아웃으로 실패했다. 45개 aws-node 파드 가운데 약 10개만 업그레이드됐다. 5개는 Terminating 에 멈췄고, 나머지 30개는 업그레이드를 시도하지도 못했다.

   노드 NotReady업그레이드 정체간헐적 타임아웃간헐적 연결 실패

   촉발

   매일 도는 노드 롤오버가 2022-10-31 07:30 UTC 에 가장 최신 EKS 노드 AMI 인 v20221027 을 가져와 기존 노드를 이 AMI 로 만든 새 노드로 바꿨다. 이 AMI 는 나중에 커널 문제로 회수됐다.

   원인

   소프트웨어 결함

   구성 요소

   노드 운영체제 이미지리눅스 커널kubeletAWS VPC CNI노드 런치 템플릿Terraform

   기여 요인

   단계적 배포 부재자동화 증폭장애 중첩모니터링 사각지대헬스 프로브 부재

   감지

   07:30 롤오버 뒤 14:10 에 vpc-cni 업그레이드 파이프라인이 타임아웃으로 실패했다. 팀은 롤오버 7시간 뒤인 14:30 에 노드가 NodeNotReady 를 오가는 것을 보고 이상을 알았다. 감지까지 7시간이 걸렸다. 알림은 NodeNotReady 이벤트와 소켓 증가를 잡지 못했다. 팀은 17:21 에 GitHub 에서 v20221027 의 PLEG 관련 이슈를 찾고 나서 원인을 알았다.

   조치

   • Terminating 에 멈춘 노드를 하나씩 cordon, drain, 삭제해 vpc-cni 업그레이드를 끝냈다. 모두 15대를 지웠다.
   • 특정 AMI 를 지정할 수 있도록 인프라 모듈의 terraform 을 고치고 테스트해 master 브랜치에 머지했다.
   • 파이프라인으로 EC2 Auto Scaling 그룹 launch configuration 의 AMI 를 이전의 정상 버전으로 되돌려 노드를 다시 만들었다.

   후속 조치

   • 각 팀에 readiness, liveness 프로브를 쓰자고 제안한다.
   • readiness, liveness 프로브 적용 현황을 보여 주는 대시보드를 만든다.
   • readiness, liveness 프로브와 그 쓸모를 설명하는 위키 글을 쓴다.
   • 인프라 모듈에서 특정 AMI 를 지정할 수 있게 고친다.
   • 최신 AMI 를 바로 받을지, 새 AMI 를 배포 전에 어떻게 시험할지 논의하는 자리를 잡는다.
   • 비정상적인 NodeNotReady 이벤트나 소켓 사용 증가를 잡는 알림을 만든다.
   • 팀 안에 Kubernetes 학습 과정을 만든다.
   • 노드 로그를 중앙에서 모은다.
   • 나와 있는 최신 AMI 를 조회하는 Prometheus exporter 를 만들고, 이를 쓰는 대시보드와 알림도 만든다.

   교훈

   새 AMI 를 배포한 날에는 다른 컴포넌트 업그레이드를 매우 조심해야 한다. 이번에는 새 노드 AMI 를 쓴 날 EKS 컴포넌트도 함께 올리면서 원인을 가리기 어려웠다. 장애나 문제가 생겼을 때 각 팀과 소통하는 경로도 개선해야 한다. 문제를 알린 팀에게서 자세한 내용을 받기 어려웠고, 팀별 당직 호출 경로도 없었다. 팀이 Kubernetes 컴포넌트를 깊이 이해하지 못했던 점도 장애에 영향을 준 요인이었다.

   사례 보기
5. IL-0146 Central India 에서 새로 만든 Azure CNI 클러스터의 VM 이 높은 값의 MAC 주소를 받으면서 bridge 모드 Azure CNI 의 오래된 버그가 드러나 터널 연결이 끊기고 kubectl exec 와 파드 간 통신이 타임아웃됐다.

   Microsoft Azure2020

   증상

   2020년 12월 4일 00:00 UTC 무렵부터 Central India 에서 Azure CNI 로 새로 만든 AKS 클러스터에 터널 연결 문제가 생겼다. 진단 페이지에는 터널 exec 문제가 표시됐다.

   간헐적 타임아웃

   촉발

   Central India 의 VM 들이 평소처럼 00 으로 시작하는 MAC 주소가 아니라 06 으로 시작하는, 훨씬 높은 값의 MAC 주소를 받기 시작했다.

   원인

   소프트웨어 결함

   구성 요소

   Azure CNI노드 운영체제 이미지

   기여 요인

   –

   조치

   • VMSS 클러스터 사용자에게 노드 이미지 업그레이드나 패치 버전 업그레이드 같은 쿠버네티스 업그레이드로 bridge 를 쓰지 않는 Azure CNI 를 받으라고 안내했다.
   • VMAS 클러스터 사용자에게 클러스터를 늘린 뒤 MAC 주소 값이 높고 bridge 모드로 동작하는 VM 을 지우라고 안내했다.
   • 영향을 받은 클러스터가 막 만든 것이라면 다시 만들라고 안내했다.

   후속 조치

   • transparent 모드를 모든 리전의 기본값으로 만드는 핫픽스를 배포한다.

   교훈

   VM 에 배정되는 MAC 주소 범위처럼 플랫폼 쪽에서 바뀐 값 하나가 오래 드러나지 않던 CNI 버그를 드러낼 수 있다. 같은 증상이라도 노드의 MAC 주소와 CNI 모드를 함께 봐야 영향 여부를 가를 수 있다.

   사례 보기

원인별1