사례3건

3건 중 1~3번째

1. 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일에 원인과 수정본이 이미 있었지만 단계적 배포가 끝나기 전에 고객 영향이 시작됐다. 서버 바이너리의 초기 이상 신호는 고객 영향이 없을 때도 운영 상태 분석에서 잡고 제때 조사해야 한다.

   사례 보기
2. IL-0178 EKS 에서 HPA 가 파드를 줄일 때 엔드포인트 제거보다 컨테이너 종료가 먼저 끝나 502 가 났고, 블루/그린 전환 뒤에는 conntrack 에 남은 연결이 삭제된 파드로 가서 클라이언트가 타임아웃을 받았다.

   Lotte E-commerce2022

   증상

   롯데온 서비스에서 HPA 가 파드 수를 줄이는 스케일 인 때마다 일정 시간 동안 요청이 오류로 끝났다. 엔드포인트에서 파드 IP 가 빠지기 전에 컨테이너가 먼저 지워지면, 들어오는 트래픽이 여전히 지워진 컨테이너로 가서 502 에러가 났다.

   오류율 상승간헐적 타임아웃오래된 엔드포인트 라우팅

   촉발

   두 가지 작업이 각각 장애를 일으켰다. 하나는 HPA 가 파드를 줄이는 스케일 인이고, 다른 하나는 Service 레이블 셀렉터를 그린 디플로이먼트로 바꾼 뒤 블루 파드를 지우는 블루/그린 배포다.

   원인

   DNS·네트워크 장애

   구성 요소

   수평 파드 오토스케일러파드 종료 처리kube-proxyconntrack 테이블클라우드 로드 밸런서인그레스 컨트롤러

   기여 요인

   기본 설정 방치

   조치

   • 컨테이너 종료를 늦춰 Service 엔드포인트에서 파드가 빠질 때까지 기다리게 했다. 방법은 애플리케이션의 SIGTERM 처리 로직에서 기다리게 하거나 preStop 훅에 sleep 을 넣는 것이다. 무한정 기다리지 않도록 terminationGracePeriodSeconds 도 함께 설정한다.
   • 대상 그룹 한도인 1000개를 넘지 않는 일부 워크로드에서 ingress 로 만드는 ALB 를 instance 모드에서 IP 모드로 바꿨다.

   후속 조치

   • ALB IP 모드를 전체 워크로드에 점진적으로 적용한다.

   교훈

   Kubernetes 에서 엔드포인트 제거와 컨테이너 종료는 동시에 진행되므로, 종료를 늦추지 않으면 스케일 인 때 지워진 컨테이너로 트래픽이 가서 502 가 날 수 있다. preStop 훅으로 기다릴 때는 terminationGracePeriodSeconds 로 최대 대기 시간을 함께 정해야 한다. ALB 를 instance 모드로 쓰면 트래픽이 노드의 iptables 와 conntrack 을 거치므로, 블루/그린 전환 뒤에도 established 연결이 지워진 파드로 갈 수 있다. IP 모드는 이 경로를 없애고 네트워크 홉도 줄이지만, 대상 그룹에 대상을 1000개까지만 넣을 수 있다.

   사례 보기
3. IL-0208 GitLab Helm 차트 업그레이드가 Service 와 Deployment 의 포트 이름을 바꿔 GCP 로드 밸런서가 다시 구성되는 동안 GitLab.com 요청이 느려지고 50x 오류가 났다

   GitLab2022

   증상

   2022-03-31 07:53 UTC 에 GitLab.com 웹 서비스의 50x 오류가 늘기 시작했고, 1분 뒤 당직 엔지니어가 오류율 증가 페이지를 받았다. 사용자에게는 GitLab.com 이 느려졌고 간헐적으로 500 오류 페이지가 떴다.

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

   촉발

   gitlab-com/gl-infra/k8s-workloads/gitlab-com!1643 머지 요청을 배포하는 파이프라인이 07:49 UTC 에 gprd-cny 로 배포를 시작했다. 이 변경에는 GitLab 차트 버전 업그레이드가 들어 있었고, 새 차트는 Prometheus ServiceMonitor, PodMonitor 설정과 관련된 변경으로 Kubernetes Service 와 Deployment 의 포트 이름을 바꿨다.

   원인

   설정 변경

   구성 요소

   Helm클라우드 로드 밸런서HAProxy

   기여 요인

   자동화 증폭

   감지

   07:53 UTC 에 50x 오류가 늘기 시작했고 07:54 에 PagerDuty 알림이 당직 엔지니어를 호출했다. 변경을 배포하던 엔지니어가 오류를 보고 그 변경과 연결해 원인을 짚었다.

   조치

   • 08:05 UTC 에 당직 엔지니어가 카나리 환경을 트래픽에서 뺐다가 08:25 에 다시 넣었다.
   • 08:15 에 cluster c 와 cluster d 배포 작업을 시작 전에 취소했다.
   • 08:51 에 HAProxy 에서 gprd-us-east1-d 클러스터를 뺐다가 08:56 에 다시 넣었다.
   • 09:31 에 최소 레플리카 수를 100 넘게 올리는 변경 !1650 을 머지했다.
   • 09:53 에 HAProxy 에서 gprd-us-east1-c 클러스터를 빼고, 09:57 에 이 클러스터에 !1643 을 배포한 뒤 10:07 에 다시 넣었다.
   • 10:19 에 최소 레플리카 상향을 되돌리는 변경 !1652 를 머지했다.

   후속 조치

   • 리전 클러스터 하나에서 트래픽을 통째로 안전하게 빼는 graceful drain 기능을 만든다.
   • PagerDuty 를 유지보수 모드로 바꾸는 ChatOps 명령을 만든다.

   교훈

   알림은 정확하게 울렸다. 원인이 바로 직전에 배포한 변경이라는 것을 알았기 때문에, 그 변경을 배포하던 파이프라인을 멈추는 것이 자연스러운 첫 대응이었다.

   사례 보기

원인별3