사례7건

7건 중 1~5번째

1. IL-0347 FR-PAR-1 가용 영역에서 하이퍼바이저 약 25% 의 VPC 연결이 11분 동안 끊겼다

   Scaleway2024

   증상

   FR-PAR-1 가용 영역의 하이퍼바이저 약 25% 가 리전의 나머지와 VPC 로 통신하지 못했다. 7:50 부터 8:01 UTC 까지 Managed Database, Redis, Serverless, Kubernetes Kapsule 처럼 VPC 에 기대는 제품이 함께 영향을 받았다.

   네트워크 도달 불가패킷 손실노드 NotReady

   촉발

   6:20 UTC 에 랙 하나의 ToR 스위치 소프트웨어가 충돌했다. 이 불안정이 같은 랙의 하이퍼바이저에서 돌던 VPC 용 BGP 경로 반사기를 비정상 상태에 빠뜨렸다.

   원인

   소프트웨어 결함

   구성 요소

   네트워크 컨트롤 플레인BGP 라우팅네트워크 스위치데이터베이스관리형 쿠버네티스 컨트롤 플레인과 제공자 API

   기여 요인

   과도한 영향 범위자동화 증폭

   감지

   Scaleway 의 Customer Excellence 팀과 SRE 팀이 영향을 알아채고 사고를 열었다. RR 의 헬스 체크 모니터링도 이상을 잡았지만 자동 재시작은 실패했다.

   조치

   • 멈춘 VPC 경로 반사기 두 대를 손으로 고쳤다.

   후속 조치

   • 멈춘 상태의 경로 반사기를 고치지 못한 자동 복구 장치를 고쳤다. 수정 내용은 https://github.com/FRRouting/frr/pull/17163 이다.
   • 버그 하나가 여러 경로 반사기를 한꺼번에 멈추지 않도록 경로 반사기의 소프트웨어 버전을 서로 다르게 둔다.
   • 경로 반사기를 멈춘 상태에 빠뜨린 소프트웨어 문제를 깊이 조사한다.

   사례 보기
2. IL-0110 Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.

   DFDS2024

   증상

   2024-03-13 10:01 UTC 에 쿠버네티스 노드 하나가 NotReady 상태가 됐다. 그때 노드에 잡힌 requests 는 CPU 78%, 메모리 82% 였다. 10:03 에 Slack 으로 알림이 왔고, 10:05 에 알림을 보고 조사를 시작했다.

   노드 NotReady컨테이너 재시작 반복OOMKilled모니터링 중단

   촉발

   Hangfire 로 작업을 실행하는 개발 컨테이너가 Grafana Agent 가 메모리를 많이 쓰고 있던 노드에 배치됐고, 작업이 OOM 으로 실패하며 CrashLoopBackOff 를 반복했다.

   원인

   용량 한계

   구성 요소

   텔레메트리 에이전트컨테이너 메모리 한도데이터베이스

   기여 요인

   과도한 영향 범위리소스 요청과 한도 미설정수동 조치 악화모니터링 사각지대

   감지

   10:03 UTC 에 Slack 으로 알림이 왔고, 10:05 에 알림을 확인하고 조사를 시작했다. 두 번째 노드는 15:03 에 Slack 알림이 왔고 15:09 에 확인했다. 탐지까지 걸린 시간은 4분이었다.

   조치

   • 10:22 에 EC2 인스턴스를 비정상으로 표시해 새 노드를 띄웠다.
   • 10:30 에 NotReady 노드를 cordon 하고 강제로 drain 했고, 10:36 에 그 EC2 인스턴스를 종료했다.
   • 13:02 에 네임스페이스에서 LimitRange 를 지우고 Grafana Agent 파드를 재시작했다.
   • 14시대에 문제의 개발 컨테이너를 0개로 줄였고, 몇 분 뒤 EC2 네트워크 트래픽이 정상으로 돌아왔다.
   • 두 번째 NotReady 뒤 15:15 에 개발 컨테이너를 다시 0개로 줄였고, 15:18 에 새 노드가 추가됐다.
   • 15:19 에 개발 컨테이너를 맡은 팀에 메일을 보냈고, 15:52 에 그 팀이 문제를 확인하고 수정 중이라고 답했다.

   후속 조치

   • grafana-agent 를 모니터링 노드 그룹으로 옮긴다.
   • 클러스터 전체 대역폭이 정해 둔 기준에 닿으면 알림을 보낸다.
   • grafana-agent Helm 차트에 메모리 한도를 걸 수 있는지 조사한다.
   • grafana-agent 의 메모리 사용량을 조사한다.
   • grafana-agent 에 PVC 를 써야 하는지 Grafana 지원팀에 묻는다.
   • 보존 기간을 제한한 채 노드 로그를 Loki 로 보내는 방안을 검토한다.
   • 쿠버네티스 노드 문제를 조사할 때 확인할 자주 쓰는 지표와 로그 쿼리를 위키 페이지로 만든다.

   교훈

   포스트모템에서 나온 후속 조치를 끝까지 챙겨야 한다. CloudWatch 에서 어떤 지표가 쓸모 있는지가 팀에 제대로 공유되지 않아 진단과 조사가 어려웠다.

   사례 보기
3. IL-0172 AWS 도쿄 리전 한 AZ 의 냉각 장애로 쿠버네티스 위에서 돌던 CockroachDB 노드 60대 중 6대가 22분 만에 죽었고, AZ 토폴로지 설정이 없어 일부 Range 가 정족수를 잃었다.

   Devsisters2021

   증상

   2021년 2월 19일, DB 노드 한 대가 내려갔다는 에러 알람이 슬랙에 올라왔다. CockroachDB 는 노드 일부가 죽어도 견디도록 만든 분산 데이터베이스라서 데브옵스 엔지니어들은 처음에는 크게 걱정하지 않았다.

   노드 NotReady데이터 유실서비스 중단

   촉발

   AWS 도쿄 리전 데이터센터의 냉각 시스템이 고장 나 그 범위에 있던 DB 서버들이 과열로 멈췄다.

   원인

   클라우드 제공자 장애

   구성 요소

   데이터베이스Helm

   기여 요인

   미검증 가정과도한 영향 범위

   감지

   회식 중에 DB 노드 한 대가 내려갔다는 에러 알람이 슬랙에 올라왔고, 이어서 다른 노드들의 장애 알람이 Ops 채널에 연달아 들어왔다.

   조치

   • INSERT INTO new_table SELECT * FROM old_table WHERE {unaffected_ranges} 같은 쿼리로 깨진 Range 를 뺀 데이터를 새 테이블로 옮겼다.
   • Cockroach Labs 엔지니어와 화면을 공유하며 debug unsafe-remove-dead-replicas 명령을 실행해 사라진 Data Range 2개 중 하나를 살렸다.
   • 남은 Data Range 하나는 1차 장애 때와 같은 방법으로 스토리지 레이어에서 직접 복원해 유저 데이터를 잃지 않고 복구했다.

   후속 조치

   • Locality 를 설정해 데이터를 여러 AZ 에 고르게 나눠 저장했다.
   • 차트 한 벌에 배포할 AZ 마다 다른 values 파일을 쓰는 방식으로 Locality 를 설정했다.
   • Locality 를 설정한 노드를 기존 클러스터에 넣고 모든 AZ 에 레플리카가 복제된 것을 확인한 뒤, Locality 가 없는 기존 노드를 클러스터에서 뺐다.

   교훈

   쿠키런: 킹덤 정도 규모의 게임에서 멀티 AZ 전략은 선택이 아니라 필수다. 분산 DB 라도 레플리카가 어느 AZ 에 놓이는지 정하지 않으면, AZ 하나가 죽을 때 동시에 잃는 노드 수가 안전 마진을 넘을 수 있다. 차트를 깔끔하게 만드는 것보다 반복적이더라도 확실하게 토폴로지를 설정하는 쪽이 낫다. 클라우드 업체를 믿기보다 스스로 할 수 있는 최대한의 대비를 해 두어야 한다.

   사례 보기
4. IL-0035 ElastAlert 에 새로 넣은 알림 규칙 때문에 ElastAlert 파드가 메모리를 끝없이 써서 노드가 잇달아 NotReady 가 되었고, 같은 클러스터의 도구와 Grafana, Prometheus 가 함께 흔들렸다.

   NU.nl2019

   증상

   팀은 여러 서비스가 이상하게 동작한다는 보고를 받았다. 가끔 오류 페이지가 뜨고, 응답이 느리고, 타임아웃이 났다.

   노드 NotReady오류율 상승지연 시간 증가간헐적 타임아웃모니터링 중단OOMKilled

   촉발

   장애 직전에 팀원 한 명이 ElastAlert 에 새 알림 규칙을 명령줄로 배포했다. Cloudfront-* 인덱스에 일정 시간 새 문서가 들어오지 않으면 울리는 규칙이었다.

   원인

   설정 변경

   구성 요소

   컨테이너 메모리 한도kubeletPrometheus

   기여 요인

   리소스 요청과 한도 미설정기본 설정 방치한계 경보 부재모니터링 사각지대과도한 영향 범위

   감지

   여러 서비스에서 오류 페이지, 느린 응답, 타임아웃이 난다는 보고가 팀에 들어왔다. 알림은 하나도 울리지 않았다. 팀은 Prometheus 와 Grafana 가 안정적인 노드로 옮겨 간 뒤 파드 메모리 사용량 대시보드에서 원인을 찾았다.

   조치

   • NotReady 노드를 하나씩 종료해 오토스케일링 그룹이 새 노드를 띄우게 했다. 새 노드도 곧 NotReady 가 되어 이것만으로는 풀리지 않았다.
   • Prometheus 와 Grafana 가 안정적인 노드에 다시 스케줄된 뒤 파드 메모리 대시보드를 보고 ElastAlert 파드가 원인임을 찾아냈다.
   • 원인인 ElastAlert 문제를 고쳤다.

   후속 조치

   • CPU, 메모리, 디스크 공간 같은 자원 사용량에 알림 규칙을 정의한다.
   • 여러 출처를 함께 쓰는 알림 전략을 계속 연구한다. 지금은 Elasticsearch, 아직 설정하지 않은 Prometheus alertmanager, APM 용 New Relic 이 있다.
   • 지표를 클러스터 밖으로 내보내고 Grafana 도 클러스터 밖으로 옮기는 방안을 검토한다. 옮길 곳은 EC2 나 별도 쿠버네티스 클러스터가 될 수 있다.
   • 중요한 지표를 ELK 에서 시각화하거나 Prometheus 와 Grafana 의 가용성을 높인다. 지표 전략도 개선한다.
   • ElastAlert 의 자원 한도를 Helm values 로 지정한다.
   • 네임스페이스에 메모리 요청값의 기본값과 한도를 설정한다.
   • 고객 대면 워크로드를 빌드, 로깅, 모니터링 워크로드와 떼어 놓는다. 먼저 운영 클러스터 안의 전용 노드 그룹으로 옮기고, 경험에 따라 별도 도구 클러스터도 검토한다.
   • 모든 배포를 Jenkins 파이프라인 같은 자동화로 하고, 새 버전 배포에 GitOps 방식을 검토한다.
   • 배포 뒤 스모크 테스트 단계가 있는 파이프라인으로 배포한다.
   • 쿠버네티스와 클라우드 인프라 작업을 팀 스프린트에 넣어 모든 팀원이 경험 많은 팀원과 짝을 지어 맡게 하고, 주제별 심화 워크숍을 연다.

   교훈

   근본 원인 하나만 탓하는 포스트모템은 장애로 이어진 문제의 15% 정도만 다룬다. 이번에도 ElastAlert 를 고친 것은 일부일 뿐이었다. 알림이 없었고, 모니터링이 같은 클러스터 안에 있었고, Helm 차트의 자원 한도에 기본값이 없었다. 운영 도구와 고객 워크로드가 자원을 나눠 썼고, 손으로 한 배포를 팀이 몰랐고, 스모크 테스트가 없었고, 운영 지식이 일부에게만 있었다. 이렇게 배우려면 장애 건수나 해결 시간만 보지 않고 비난 없는 포스트모템을 허용하는 문화가 필요하다.

   사례 보기
5. IL-0073 Kafka 연결이 끊기자 로깅 사이드카가 Docker 데몬에 부하를 주어 노드가 줄줄이 비정상이 되었고, 재스케줄링으로 생긴 노드 약 41,000개가 Consul gossip 메시를 오염시켜 Vault 와 배포 엔진까지 멈췄다

   Target2019sev1

   증상

   어느 저녁 데이터센터 OpenStack 의 네트워크 하위 시스템을 업그레이드한 뒤 Kafka 연결이 몇 시간 동안 간헐적으로 끊겼다. 개발 환경 워크로드 약 2,000개를 올린 큰 쿠버네티스 클러스터에서 노드들이 쿠버네티스에 비정상이라고 보고하기 시작했다.

   노드 NotReady부하 불균형지연 시간 증가자격 증명 획득 실패

   촉발

   OpenStack 의 네트워크 하위 시스템을 업그레이드하다가 예상과 달리 네트워크가 몇 시간 동안 끊겼고, Kafka 에는 간헐적으로만 닿았다. 그러자 모든 워크로드에 딸린 로깅 사이드카가 한꺼번에 깨어나 노드의 Docker 데몬에 높은 부하를 주었다.

   원인

   의존성 장애

   구성 요소

   컨테이너 런타임서비스 디스커버리텔레메트리 에이전트파드용 자격 증명 중개자

   기여 요인

   과도한 영향 범위자동화 증폭단일 장애점미패치 알려진 버그

   조치

   • Consul 의 gossip 암호화를 켜서 오염된 gossip 메시에서 오는 메시지를 바로 거부하게 했고, 이것으로 Consul 과 Vault 를 되살렸다.
   • 배포 엔진을 안정시킨 뒤 암호화 설정을 반영하려고 개발 환경 전체를 다시 배포했고, 암호화가 설정되지 않은 인스턴스는 종료했다.
   • 큰 클러스터를 다루는 수정이 들어간 Consul 1.2.3 으로 제자리 업그레이드했고, UI 버그 때문에 최종적으로 1.3.0 으로 올렸다. 운영 환경의 오염된 gossip 메시도 이 업그레이드로 빠르게 정리됐다.

   후속 조치

   • 노드의 워크로드가 함께 쓰는 Docker 데몬은 깨지기 쉬운 장애 지점이므로, 데몬 하나의 장애가 미치는 범위를 줄이는 데 더 힘쓴다. 작은 클러스터를 여러 개 두는 방침과 같은 방향이다.

   교훈

   글쓴이는 작은 클러스터를 여러 개 두라는 자신의 원칙이 옳았다고 확인했다. 더 작은 개발 클러스터와 운영 클러스터의 워크로드는 큰 클러스터처럼 영향을 받지 않았고, 개발과 운영이 한 클러스터에 있었다면 훨씬 큰 일이 났을 것이다. 노드의 워크로드가 함께 쓰는 Docker 데몬은 깨지기 쉬운 장애 지점이다. 워크로드마다 자기 로깅 사이드카와 메트릭 사이드카를 두는 방식이 옳다고도 확신하게 됐다. 이것들이 클러스터 공용 자원이었다면 문제가 거의 틀림없이 더 커졌고 고치기도 훨씬 어려웠을 것이다.

   사례 보기

원인별5