사례18건

18건 중 11~15번째

1. IL-0145 Australia East 의 전압 강하로 냉각기가 멈춰 데이터 홀 장비가 꺼지면서, 영역 중복이 아닌 AKS 작업 큐 데이터베이스가 내려가 두 리전의 AKS 생성, 수정, 삭제 작업이 막혔다

   Microsoft Azure2023

   증상

   2023년 8월 30일 10시 30분 UTC 무렵부터 Australia East 리전에서 Azure, Microsoft 365, Power Platform 서비스에 접근하거나 쓰는 데 문제가 생겼다. AKS 에서는 리소스 공급자를 거치는 생성, 조회, 수정, 삭제 작업과 스케일링이 실패했다.

   컨트롤 플레인 무응답오류율 상승서비스 중단

   촉발

   8월 30일 08시 41분 UTC, Australia East 의 영향받은 가용 영역에서 약 18마일 떨어진 전력 설비에 낙뢰가 떨어져 전압 강하가 일어났다. 이 전압 강하로 여러 데이터센터의 냉각 시스템에 있는 냉각기가 멈췄다.

   원인

   클라우드 제공자 장애

   구성 요소

   AKS 컨트롤 플레인애플리케이션 데이터베이스

   기여 요인

   단일 장애점과도한 영향 범위

   감지

   10시 47분 UTC Cosmos DB 영향이 모니터링에 잡혔고, 10시 48분 첫 자동 공지가 Azure Service Health 로 나갔다. 11시 30분 공개 Azure 상태 페이지에 첫 공지가 올라갔고, 11시 36분 Australia East 의 모든 구독에 포털 공지를 보냈다.

   조치

   • 11시 34분 UTC 냉수 온도를 낮추려고 영향받은 데이터 홀의 남은 네트워크, 컴퓨트, 스토리지 장비를 원격으로 내렸다.
   • 12시 12분 UTC 재시작이 막혔던 냉각기 다섯 대를 손으로 다시 켰다.
   • 데이터 홀 안전 점검을 마친 뒤 장비에 단계적으로 전원을 넣어 15시 10분 UTC 모든 장비의 전원을 복구했다.
   • AKS 작업 큐로 쓰는 SQL Database 가 복구되자 다른 조치 없이도 AKS 작업이 되살아났다.

   후속 조치

   • AKS 팀은 작업 큐로 쓰는 SQL Database 데이터베이스를 모두 영역 중복으로 즉시 전환한다. 완료 목표는 2023년 9월이다.
   • AKS 팀은 리전을 넘나드는 SQL Database 큐 사용을 모두 영역 중복 Service Bus 큐로 바꾼다. 완료 목표는 2023년 9월이다.
   • 가용 영역의 부하가 조금씩 늘면서 냉각기 운전 구성이 냉각기 관리 시스템의 타이밍 결함에 취약해져 있었다. 전압 변동 뒤 재시작에 실패하지 않도록 냉각기 관리 시스템의 제어 타이밍 로직을 바꿨다.
   • 여러 냉각기가 한꺼번에 멈췄을 때 손으로 재시작하는 비상 운영 절차에서, 재시작 순서를 냉각기가 붙어 있는 차례가 아니라 데이터 홀 부하를 기준으로 정하도록 바꿨다. 냉각을 모두 되살리는 동안 모든 데이터 홀이 일부라도 냉각을 받아 열 폭주가 늦춰지게 하려는 것이다.
   • 냉각기 관리 시스템을 바꾸기 전까지의 임시 조치로 데이터센터 기술자 인원을 늘려 수동 재시작 절차를 바로 실행할 수 있게 했다.
   • 스토리지 팀은 대규모 복구 과정을 최적화한다. 장애 중에 빨리 판단할 수 있도록 판단에 쓰는 데이터를 늘리고, 더 빨리 실행할 수 있도록 문제 해결 가이드를 고친다. 완료 목표는 2023년 12월이다.
   • Azure Service Fabric 팀은 SQL Database 테넌트 링 복구의 신뢰성을 높인다. 완료 목표는 2023년 12월이다.
   • SQL Database 팀은 자동 장애 조치 그룹의 발동 기준을 검토해 장애 조치가 기대한 시간 안에 일어나게 한다. 완료 목표는 2023년 10월이다.
   • SQL Database 팀은 데이터베이스를 대량으로 옮길 수 있도록 내부 도구를 개선한다. 완료 목표는 2023년 12월이다.
   • Cosmos DB 팀은 단일 리전 쓰기 계정의 서비스 관리형 장애 조치를 최적화해 복구 시간을 줄인다. 완료 목표는 2023년 11월이다.
   • ARM 팀은 스토리지 계층을 차세대 영역 중복 구조로 옮기는 작업을 마친다. 완료 목표는 2023년 12월이다.
   • 장애 관리 팀은 장비 전원을 내려야 하는 상황에 맞춰 준비 태세, 절차, 플레이북을 강화하는 방법을 찾는다. 완료 목표는 2023년 10월이다.

   교훈

   AKS 컨트롤 플레인의 기반 인프라를 여러 가용 영역에 나눠 두어도, 생성, 조회, 수정, 삭제 작업이 거치는 작업 큐 데이터베이스가 영역 중복이 아니면 한 영역의 장애가 리전 전체의 AKS 작업을 멈춘다. 다른 리전이 같은 데이터베이스에 기대고 있으면 장애가 그 리전까지 번진다. 이미 돌고 있는 워크로드는 영향을 받지 않았을 것으로 Microsoft 는 보았지만, 스케일링처럼 리소스 공급자를 거쳐야 하는 일은 모두 막혔다. 영역 중복 스토리지, 그리고 영역 복원력이나 다중 리전 쓰기를 켠 Cosmos DB 계정은 이번 장애에서도 계속 동작했고, 영역 중복 SQL Database 도 프록시 모드로 연결한 일부 고객을 빼면 중단이 없었다.

   사례 보기
2. IL-0207 로컬 개발 환경에서 돌린 작업이 운영 컨텍스트로 넘어가 Kubernetes 클러스터의 Consul 릴리스를 통째로 지웠고, Patroni 가 무너져 GitLab.com 전체가 5XX 오류를 냈다.

   GitLab2022

   증상

   모니터링과 알림이 곧바로 울렸다. 알림 하나는 Patroni 페일오버를 가리켰다. GitLab.com 으로 가는 트래픽은 모두 5XX 오류로 끝났다.

   서비스 중단오류율 상승리소스 삭제

   촉발

   엔지니어가 로컬 개발 환경에서 사내 도구로 일상적인 작업을 돌렸다. 로컬 배포나 롤백 도중 컨텍스트가 로컬 개발에서 운영으로 바뀌었고, 이때 잘 알려진 오픈소스 도구가 예상하지 못한 동작을 해 운영 환경에 변경이 들어갔다.

   원인

   운영 실수

   구성 요소

   애플리케이션 데이터베이스

   기여 요인

   파괴적 변경 보호 장치 부재

   감지

   모니터링과 알림 인프라가 곧바로 경보를 보냈다. 팀은 Consul 클러스터가 내려가 Patroni 클러스터에 영향을 주자마자 큰 장애가 난 것을 알았고, 근본 원인도 몇 분 안에 찾았다.

   조치

   • 지워진 Consul 릴리스를 운영에 다시 적용했다. Consul 클러스터가 올라오자 데이터베이스 클러스터가 회복했다.

   후속 조치

   • Kubernetes 배포 방식을 개선해 로컬 환경에서 운영 환경을 대상으로 위험한 배포 작업이 돌아갈 가능성을 줄인다. 개념 검증은 reliability 이슈 16875 에서 진행한다.
   • Teleport 를 Kubernetes 클러스터와 연동한다. 이렇게 하면 SRE 에게 기본으로 읽기 전용 역할을 줄 수 있어 실수로 운영 환경을 바꿀 위험이 줄어든다.

   교훈

   로컬 개발 환경에서 운영 클러스터에 접근할 수 있으면 도구가 컨텍스트를 예상과 다르게 바꾸는 순간 일상 작업이 운영 장애가 된다. GitLab 은 Kubernetes 배포 방식을 개선하고, Teleport 로 SRE 의 기본 권한을 읽기 전용으로 둘 수 있게 하면 이런 위험이 크게 줄어든다고 봤다. 알림과 원인 파악은 빨랐다. 지워진 릴리스를 다시 배포하는 데는 손으로 해야 할 일이 있었지만 비교적 빨리 끝났다.

   사례 보기
3. IL-0206 GKE 파드 안의 Consul 에이전트가 메모리 급증으로 거듭 OOM kill 되어 Rails 파드가 데이터베이스 복제본을 찾지 못했고, 모든 쿼리가 primary 로 몰려 GitLab.com 이 느려졌다.

   GitLab2022

   증상

   2022-04-25 15:13 UTC 에 engwan 이 Slack 에서 Sidekiq Apdex 하락으로 장애를 선언했다. Apdex 는 목표 시간 안에 끝난 작업의 비율로 만족도를 나타내는 지표다. 사용자는 사이트가 간헐적으로 느려지는 것을 겪었고, 파이프라인 생성이나 가져오기와 내보내기 같은 비동기 작업이 평소보다 오래 걸렸다.

   지연 시간 증가데이터베이스 과부하OOMKilled오류율 상승

   촉발

   GKE 파드 안의 Consul 에이전트가 특정 상황에서 메모리를 갑자기 많이 요구했고, 쓸 수 있는 메모리가 없어 Consul 프로세스가 죽었다. 당시 파드 메모리 한도는 500MB 였다.

   원인

   용량 한계

   구성 요소

   컨테이너 메모리 한도서비스 디스커버리애플리케이션 데이터베이스

   기여 요인

   –

   감지

   2022-04-25 15:13 UTC 에 engwan 이 Slack 에서 Sidekiq Apdex 하락으로 장애를 선언했다. 다음 날 01:21 UTC 에는 모니터링이 오류율 상승을 잡았고, 01:26 에 cindy 가 장애를 다시 선언했다.

   조치

   • 16:13 에 gitlab 데이터베이스 사용자의 연결 한도를 올리고 main pgbouncer 의 백엔드 풀을 늘리는 방안을 세웠고, 17:26 에 msmiley 가 변경을 적용해 17:47 에 적용을 확인했다.
   • 임시 조치로 파드 메모리 한도를 500MB 에서 1GB 로 올려 Consul 에이전트가 메모리 급증 때도 계속 돌 수 있게 했다.

   후속 조치

   • 메모리 한도를 1GB 로 올린 것으로 충분한지 GKE 파드의 Consul 에이전트를 지켜본다.
   • Consul 의 메모리 수요 급증을 조사해 하드 메모리 한도를 올리는 것 말고 개선할 방법이 있는지 찾는다.

   교훈

   파드 안에서 함께 도는 Consul 에이전트의 메모리 한도가 모자라자 서비스 디스커버리가 끊겼고, 그 영향이 데이터베이스 primary 포화와 사이트 전체의 지연으로 번졌다. 처음 의심한 pgbouncer 풀 변경과 다음 날 별개로 보였던 오류율 상승이 모두 같은 원인으로 이어졌다. 메모리 한도를 올린 것은 임시 조치였고, Consul 의 메모리 급증이 정상 동작인지 GitLab 설정 탓인지는 아직 조사해야 했다.

   사례 보기
4. 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 하나가 죽을 때 동시에 잃는 노드 수가 안전 마진을 넘을 수 있다. 차트를 깔끔하게 만드는 것보다 반복적이더라도 확실하게 토폴로지를 설정하는 쪽이 낫다. 클라우드 업체를 믿기보다 스스로 할 수 있는 최대한의 대비를 해 두어야 한다.

   사례 보기
5. IL-0196 Redis Operator 로 레플리카를 늘리면서 메모리 한도를 낮추자 데이터를 가진 유일한 Redis 파드가 재시작됐고, Sentinel 이 빈 레플리카를 마스터로 올려 데이터가 모두 지워졌다.

   Palark2020

   증상

   RedisFailover 리소스에 바뀐 설정을 적용하자 고객 웹사이트의 가장 큰 Redis 데이터베이스에서 데이터가 모두 사라졌다. 이 데이터베이스는 TTL 없이 영속 저장소로도 쓰였고, .rdb 스냅숏이 5 Gb 를 넘었다. 서비스가 멈췄고 백업에서 데이터를 복원해야 했다.

   데이터 유실서비스 중단

   촉발

   RedisFailover 리소스에서 Redis 레플리카 수를 1에서 2로 늘리면서, 같은 변경으로 컨테이너의 메모리 requests 와 limits 를 22 GB 에서 19 GB 로 낮췄다.

   원인

   소프트웨어 결함

   구성 요소

   애플리케이션 데이터베이스영구 볼륨과 스테이트풀셋컨테이너 메모리 한도

   기여 요인

   단계적 배포 부재단일 장애점미검증 가정

   조치

   • 미리 준비해 둔 백업에서 Redis 데이터를 복원했다.

   후속 조치

   • 레디니스 프로브 문제를 Redis Operator 이슈로 올렸고, 개발자들에게서 받은 수정을 시험해 통과를 확인했다.
   • 상황 분석을 마친 뒤 Spotahome Redis Operator 를 계속 쓸지 다시 검토한다.
   • Redis 데이터베이스를 정리하고, 불필요한 키를 만든 애플리케이션 코드를 고친다.
   • Redis 의 내장 클러스터링과 샤딩을 검토한다.

   교훈

   핵심 인프라를 쿠버네티스 오퍼레이터로 관리할 때는 그 오퍼레이터가 얼마나 성숙하고 검증됐는지 따져 봐야 한다. 레플리카 수와 리소스 값을 한 번에 바꾸면 롤링 업데이트가 예상하지 못한 순서로 파드를 재시작할 수 있다. 레디니스 프로브가 ping 만 보면 복제가 끝나지 않은 빈 인스턴스도 준비됐다고 판단한다. Redis 클러스터를 바꾸기 전에는 반드시 dump.rdb 파일을 백업해야 한다.

   사례 보기

원인별8