사례3건

3건 중 1~3번째

1. IL-0084 베어메탈 업체 vSwitch 의 패킷 드롭으로 Namespace 의 fra3 리전이 빠져 전 세계 용량이 모자랐고, 다음 날에는 컨트롤 플레인 노드의 느린 NVMe 쓰기로 쿠버네티스 API 서버 CPU 가 치솟아 zrh1 이 멈췄다.

   Namespace2024

   증상

   10월 17일부터 fra3 리전에서 패킷이 드문드문 버려지기 시작했다. 처음 이틀은 TCP 와 QUIC 의 재전송이나 컨트롤 플레인의 재시도로 대부분 넘어갔지만, 시스템이 조금씩 불안정했다. 이런 실패는 비결정적이라 겉으로 잘 드러나지 않았다.

   간헐적 연결 실패지연 시간 증가컨트롤 플레인 지연서비스 중단

   촉발

   fra3 에서 베어메탈 업체의 vSwitch 를 지나는 패킷이 무작위로 드문드문 버려지기 시작했다. 두 번째 장애는 컨트롤 플레인 노드 하나의 느린 NVMe 가 쿠버네티스의 변경 속도를 더는 따라가지 못하면서 일어났다.

   원인

   클라우드 제공자 장애

   구성 요소

   쿠버네티스 API 서버

   기여 요인

   용량 계획 부재여유 용량 부재장애 중첩

   감지

   패킷 드롭은 비결정적이라 바로 보이지 않았다. 주요 상호작용에 잡아 둔 백분위 지연 SLO 의 에러 버짓이 줄어드는 것을 보고 영향을 알아챘다.

   조치

   • fra3 의 고객 트래픽을 모두 다른 리전으로 돌렸다.
   • vSwitch 대신 Wireguard 로 업체의 물리 머신 하나하나를 zrh1 클러스터에 연결했다.
   • 각 머신을 새 신원, 새 인증서, 새 저장 데이터 암호화 키로 다시 깔았고, 복구를 앞당기려고 캐시를 버렸다.
   • 팀 일부가 데이터셋을 더 분산된 방식으로 복제해 머신을 다시 까는 작업을 앞당겼다.
   • 준비된 머신을 묶음으로 새 리전에 넣고, 충분히 모이자 리전을 컴퓨트 풀에 다시 넣었다.
   • 두 번째 장애에서 워크로드를 zrh1 밖으로 돌렸다.
   • 실패하던 컨트롤 플레인 노드의 핵심 상태를 더 큰 노드로 복제하고, 새 노드가 같은 IP 주소로 옛 노드의 역할을 넘겨받게 했다.

   후속 조치

   • 장애 동안 실행된 모든 인스턴스의 요금을 고객에게 크레딧으로 환급했다.
   • 비슷한 상황이 다시 와도 고객에게 영향을 주지 않도록 백업 리전과 대안을 만든다.

   교훈

   비결정적인 네트워크 드롭은 재시도에 가려져서 SLO 기반 모니터링으로 긴 시간을 봐야 영향이 드러난다. 핵심 인프라의 문제를 직접 고칠 수단을 갖고 있어야 한다. 큰 장애 직후에는 같은 종류의 원인에 매이기 쉽다. 이번 두 번째 장애는 전혀 다른 종류였다. 미리 해 둔 모의 위기 훈련 덕분에 대응을 바로 체계적으로 시작할 수 있었다.

   사례 보기
2. IL-0193 GCP SSD 영구 디스크 장애로 Cassandra 파드가 볼륨을 붙이지 못했고, OrderedReady 정책 때문에 나머지 파드도 다시 뜨지 못한 데다 Metrictank 가 바뀐 Cassandra IP 로 다시 연결하지 못해, Grafana Cloud Graphite 쿼리 일부가 최대 23시간 실패했다.

   Grafana Labs2019

   증상

   Metrictank 인스턴스 일부가 쓰기 큐를 비우지 못한다는 알림이 왔다. Metrictank 가 Cassandra 에 쓰지 못하고 있다는 뜻이었다.

   오류율 상승노드 NotReady파드 Pending서비스 중단

   촉발

   GCP SSD 영구 디스크의 성능이 크게 떨어져 많은 I/O 가 오랫동안 실패했고, 그 때문에 노드가 자동으로 재부팅됐다.

   원인

   클라우드 제공자 장애

   구성 요소

   영구 볼륨과 스테이트풀셋애플리케이션 데이터베이스노드 루트 디스크

   기여 요인

   장애 중첩미패치 알려진 버그미검증 가정

   감지

   팀은 Metrictank 쓰기 인스턴스가 쓰기 큐를 비우지 못한다는 알림을 받고 장애를 알았다. Metrictank 가 대부분의 쿼리를 메모리에서 계속 처리해서 오류율은 아주 천천히 올라갔기 때문에, 이 알림이 없었다면 발견이 훨씬 늦었을 것이다.

   조치

   • 새 노드라면 디스크를 붙일 수 있을 것이라 보고 클러스터의 컴퓨트 노드를 늘렸지만 효과가 없었다.
   • GCP 장애가 풀린 뒤 Cassandra StatefulSet 을 지우고 Pod Management Policy 를 바꿔 다시 만들었다. 파드 하나를 빼고 모두 떠서 Cassandra 클러스터가 정상으로 돌아왔다.
   • 긴 장애 동안 데이터를 잃지 않도록 Kafka 토픽 보존 기간을 늘렸다.
   • Metrictank 재시작이 CPU 부족으로 느려지지 않도록 클러스터에 노드를 임시로 더 붙였다.
   • 모든 Metrictank 인스턴스를 재시작해 새 Cassandra IP 로 연결되게 했다. 재시작은 20시간 넘게 걸렸다.

   후속 조치

   • 모든 Cassandra IP 가 바뀌면 Metrictank 가 다시 연결하지 못하는 버그를 고쳤다. 연결이 죽은 것을 감지하면 gocql 연결을 새로 만든다.
   • 쓰기 큐가 가득 찬 상태에서 새 데이터가 들어오면 생기던 교착을 고쳤다. 내부 자료 구조 하나를 잠금으로 보호하는 대신 atomic 연산으로 갱신한다.

   교훈

   받은 데이터를 처리하기 전에 쓰기 선행 로그인 Kafka 에 먼저 저장해 둔 덕분에, Cassandra 를 되살린 뒤 그동안 받은 데이터를 모두 처리해 저장할 수 있었다. Kafka 가 SSD 가 아닌 디스크를 쓴 것은 운이 좋았다. 그렇지 않았다면 Kafka 도 Cassandra 와 같은 장애를 겪었을 수 있다. 23시간 동안 파라과이, 알바니아, 호주에 있는 세 사람이 시간대를 나눠 대응했다. 두 버그를 고친 지금은 같은 상황이 와도 복구가 23시간이 아니라 3시간 안에 끝날 것으로 본다. 오래 미룬 문제도 새로 보면 생각보다 간단히 풀릴 수 있다. 장애가 주말에 나서 고객 부하가 대부분 캐시 데이터를 읽는 알림 쿼리뿐이었던 것도 운이 좋았다.

   사례 보기
3. IL-0014 GKE 를 1.12.5-gke.10 으로 올리는 중 노드 풀 업그레이드가 멈추고 인그레스와 HPA 가 망가졌다

   loveholidays2019

   증상

   미뤄 둔 GKE 업그레이드를 하던 저녁, 마스터는 문제없이 올라갔지만 노드 풀 업그레이드가 예상보다 훨씬 오래 걸렸다. 노드가 14개이고 노드당 5분쯤 걸리는 클러스터도 한 시간 넘게 걸렸고, 일부 노드는 드레인에 15분 넘게 걸렸다. emptyDir 를 쓰는 파드와 5분에서 10분짜리 terminationGracePeriodSeconds 가 드레인을 늦췄다.

   업그레이드 정체파드 Pending노드 증설 실패서비스 중단오토스케일러 오동작

   촉발

   마이그레이션에 쫓겨 미뤄 둔 업그레이드로 운영 클러스터를 1.10.X 에서 1.12.5-gke.10 으로 올렸다. 구글은 3월 14일 GKE 릴리스 노트에서, 이 버전으로 올린 마스터의 오류율이 높아진다는 보고가 있어 새 클러스터와 마스터 업그레이드에서 이 버전을 빼는 중이라고 밝혔다. 그런데도 3월 19일에 이 버전을 고를 수 있었다.

   원인

   클라우드 제공자 장애

   구성 요소

   GKE 컨트롤 플레인노드 풀클러스터 오토스케일러인그레스 컨트롤러수평 파드 오토스케일러

   기여 요인

   스테이징 불일치장애 중첩초기 신호 무시

   감지

   업그레이드하던 엔지니어가 드레인이 느리고 노드 풀 업그레이드가 멈추고 파드가 Pending 에 머무는 것을 직접 보았다. 인그레스 장애는 업그레이드 뒤에 드러났고, 로그로 원인을 찾지 못해 구글 지원팀에 물어 알려진 버그라는 것을 알았다. HPA 이상은 업그레이드 다음 날 발견했다.

   조치

   • 노드 풀의 노드 목록을 뽑아 kubectl drain 에 --ignore-daemonsets --delete-local-data 를 주어 노드를 미리 드레인했다.
   • 노드 풀에 해당하는 관리형 인스턴스 그룹을 찾아 gcloud compute instance-groups managed delete-instances 로 멈춘 인스턴스를 지웠다.
   • gcloud container operations list 로 operationType: UPGRADE_NODES, status: RUNNING 인 작업을 찾아 gcloud beta container operations cancel 로 멈춘 노드 풀 업그레이드를 취소했다.
   • 동작을 멈춘 내부 인그레스 대신 한동안 port-forward 로 접근했다.
   • HPA 가 이상해진 배포에서 활성 레플리카셋이 두 개면 오래된 레플리카셋을 천천히 줄였고, 하나면 더미 환경 변수를 바꿔 다시 배포했다.

   후속 조치

   • HorizontalPodAutoscaler 가 최대치의 70% 와 100% 에 닿으면 Alertmanager, Prometheus, Slack 으로 경보를 보내게 했다.
   • 배포에 활성 레플리카셋 두 개가 30분 동안 남아 있을 때와 60분 동안 남아 있을 때 경보를 보내게 했다.
   • 임의로 크게 잡은 종료 유예 시간을 다시 따져 본다.
   • 클러스터를 업그레이드하기 전에 GKE 릴리스 노트를 먼저 확인한다.
   • 운영이 아닌 환경에는 자동 업그레이드를 쓰고, 운영 환경은 클러스터를 수동으로 업그레이드하고 노드는 자동 업그레이드를 쓴다.
   • 사전 검증 환경을 이름까지 운영과 최대한 똑같이 맞춘다.

   교훈

   클러스터를 업그레이드하기 전에는 GKE 릴리스 노트를 먼저 봐야 한다. 운영이 아닌 환경에는 자동 업그레이드를 써서 영향을 먼저 겪고, 운영에는 수동 클러스터 업그레이드와 자동 노드 업그레이드를 섞어 예측 가능성과 유지 부담 사이에서 균형을 잡는다. 사전 검증 환경은 이름까지 운영과 같게 둬야 한다. 노드 풀 업그레이드 시간은 노드 수와 드레인 시간에 달려 있다. emptyDir 를 쓰는 파드에 safe-to-evict 어노테이션을 달고, 지나치게 긴 종료 유예 시간을 다시 따져 보고, PodDisruptionBudget 을 두면 드레인이 빨라진다.

   사례 보기

원인별1