사례24건

24건 중 14~18번째

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-0500 UToronto JupyterHub 의 데이터베이스 디스크가 가득 차서 로그인과 서버 시작이 500 오류로 실패했다

   2i2c2022

   증상

   UToronto JupyterHub 에서 새로 로그인하거나 서버를 시작하려는 사용자가 500 오류를 받았다. 이미 로그인해 있던 사용자는 계속 허브를 쓸 수 있었다.

   오류율 상승영구 볼륨 가득 참

   촉발

   hub 로그가 hub 의 sqlite 데이터베이스와 같은 10G 디스크에 쌓였고, 아주 커진 로그 파일이 디스크를 다 채웠다.

   원인

   용량 한계

   구성 요소

   데이터베이스영구 볼륨과 스테이트풀셋JupyterHub

   기여 요인

   한계 경보 부재

   감지

   경보가 없었다. 사용자가 오후 7:13 에 [email protected] 로 로그인이 안 된다는 메일을 보내 알게 됐다.

   조치

   • 디스크가 가득 차 로그 파일을 제자리에서 압축할 수 없어서, hub 파드 안에서 gzip < jupyterhub.log > /tmp/jupyterhub.log.gz 로 /tmp 에 압축했다.
   • 파드를 재시작하면 /tmp 의 압축 파일도 사라지므로 kubectl cp 로 압축 파일을 로컬에 먼저 복사했다.
   • 로그를 어떻게 할지 정할 시간을 벌려고 kubectl -n prod edit pvc hub-db-dir 로 hub 데이터베이스 디스크를 10G 에서 60G 로 늘렸다. 크기 조정에도 파드 재시작이 필요해서 로그를 복사한 뒤의 재시작 한 번으로 함께 반영했다.
   • hub 파드를 재시작했다. hub 가 더 큰 디스크로 다시 뜨면서 서비스가 돌아왔다.

   후속 조치

   • hub 로그를 hub 데이터베이스와 같은 디스크에 두지 않는다.
   • Grafana 에 JupyterHub 데이터베이스 디스크의 남은 공간을 보여 주는 그래프를 더한다.
   • 오류율이 오르면 경보를 보낸다. 이 작업은 진행 중이고 2i2c 의 4분기 목표다.

   교훈

   쿠버네티스의 동적 볼륨 크기 조정은 손을 많이 대지 않고도 바로 동작했다. 이 위험은 마이그레이션 때 이미 짚었지만 끝까지 챙기는 절차가 없었다. 2i2c 는 그 뒤로 절차가 많이 나아졌다고 적었다. 경보가 없어서 사람이 알려 줄 때까지 기다려야 했다.

   사례 보기
4. 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 설정 탓인지는 아직 조사해야 했다.

   사례 보기
5. IL-0462 GKE 위 MySQL 파드 일부가 시작과 종료에 오래 걸려 KateSQL 인스턴스 교체가 느려졌다

   Shopify2021

   증상

   KateSQL 의 인스턴스 교체 작업에서 MySQL 파드 생성 시간이 10분에서 30분까지 들쭉날쭉했다. 일부 MySQL 파드는 데이터가 같은 다른 파드보다 시작과 종료가 훨씬 느렸고, 설정 변경이나 업그레이드 같은 유지 보수 때 MySQL 인스턴스를 빨리 교체하기 어려워졌다.

   느린 파드 시작·종료지연 시간 증가

   원인

   소프트웨어 결함

   구성 요소

   리눅스 커널노드 운영체제 이미지데이터베이스

   기여 요인

   미패치 알려진 버그

   감지

   KateSQL 인스턴스 교체 작업에서 MySQL 파드 생성 시간이 10분에서 30분까지 들쭉날쭉한 것을 보고 알았다.

   조치

   • 옛 노드를 cordon 하고, KateSQL 인스턴스 교체로 MySQL 파드를 새 노드로 옮기며 GKE 오토스케일러가 노드를 늘리게 한 뒤, 옛 노드를 drain 해 클러스터를 줄였다. 새 MySQL 파드의 성능이 좋아졌다.
   • `echo 1 | sudo tee /sys/fs/cgroup/memory/kubepods/memory.force_empty` 로 kubepods cgroup 이 죽은 cgroup 을 비우게 해 메모리 cgroup 수를 약 1800개로 줄였다. 재시작한 MySQL 파드는 80G 버퍼 풀을 5초 만에 초기화했다.
   • GKE 1.18 로 새 GKE 클러스터를 만들어 새 MySQL 파드를 그 클러스터에 띄웠다. 몇 주 동안 버퍼 풀 초기화 시간과 질의 성능이 고르게 유지됐다.

   교훈

   이번 조사는 Shopify 데이터베이스 플랫폼 그룹이 한 조사 가운데 가장 오래 걸린 축에 들었다. 문제의 성격, 재현의 어려움, 따를 만한 정해진 방법이 전혀 없었다는 점 때문에 근본 원인을 찾는 데 오래 걸렸다. 그래도 문제를 풀 방법은 여러 가지가 있었다.

   사례 보기

원인별7