사례5건

5건 중 1~5번째

1. IL-0324 External Storage 데이터베이스 클러스터에 과부하가 걸려 mw-api-int, mw-parsoid, mw-jobrunner 의 지연과 데이터베이스 오류가 늘었다

   Wikimedia Foundation2025

   증상

   2025-03-12 10:58 UTC 부터 백엔드 응답 시간이 높다는 알림이 들어왔다. 3월 12일과 13일 이틀 동안 mw-api-int, mw-parsoid, mw-jobrunner 에서 지연이 커지고 데이터베이스 오류가 늘었다. External Storage 클러스터의 부하와 연결 수도 크게 늘었다.

   데이터베이스 과부하지연 시간 증가오류율 상승로그 폭증모니터링 중단

   촉발

   mw-api-int, mw-parsoid, mw-jobrunner 를 PHP 8.1 로 옮기는 예정된 Scap 배포가 장애를 일으켰다. 3월 12일 10:44 UTC 에 1126607[puppet] 과 1126650 [deployment-charts] 를, 3월 13일 11:15 UTC 에 1127476[puppet] 과 1127478[deployment-charts] 를 배포했다.

   원인

   배포 결함

   구성 요소

   데이터베이스인메모리 캐시컨피그맵과 시크릿HelmCI 시스템

   기여 요인

   미검증 가정데워진 캐시에 기댄 구조잡음에 묻힌 신호

   감지

   3월 12일 10:58 UTC 에 백엔드 응답 시간이 높다는 알림이 들어오기 시작했다. 처음 세운 가설은 특정 네트워크나 클라이언트의 많은 트래픽, 잘못 실행된 예약 작업, 자원을 많이 먹는 changeprop-jobqueue 작업이었다. 원인을 가리켰을 MediaWikiMemcachedHighErrorRate 알림은 logstash-prometheus 파이프라인이 밀려 빠지거나 곧바로 회복됐다. 장애 중에는 알림 78개가 울리고 있어서, 그 알림이 울렸더라도 부수 증상으로 보고 넘겼을 가능성이 컸다.

   조치

   • 3월 12일 13:19 UTC 에 cirrus-streaming-updater 의 SUP 병렬도를 낮추는 패치 1126988[deployment-charts] 를 배포했다.
   • 13:33 에 1127000[deployment-charts] 로 changeprop-jobqueue 의 categoryMembershipChange 작업 동시성을 낮췄다.
   • 13:44 에 1126607[puppet] 과 1126650 [deployment-charts] 를 되돌리고 Scap 을 다시 돌렸다.
   • 3월 13일 11:34 UTC 에 changeprop-jobqueue 를 롤링 재시작했다.
   • 11:43 에 mw-api-int 를 롤링 재시작했다.
   • 11:44 에 1127500[deployment-charts] 로 changeprop-jobqueue 의 categorymembership 작업을 껐다.
   • 11:46 에 1127476[puppet] 과 1127478[deployment-charts] 를 되돌렸다.
   • 11:58 에 되돌린 내용을 반영하려고 mw-api-int 를 다시 배포했다.
   • 12:07 에 mw-api-int 의 레플리카 수를 늘렸다.
   • 12:28 에 되돌린 내용을 반영하려고 mw-jobrunner 를 다시 배포했다.
   • 14:06 에 되돌린 내용을 반영하려고 mw-parsoid 를 다시 배포했다.

   후속 조치

   • 장애 때 channel:Memcached 로 보내는 메시지 양을 줄인다.
   • Scap 에 helm 롤백 기능을 넣는다.
   • -Dbuild_mw_container_image:False 로 실행할 때도 Scap 이 helmfile-defaults 를 갱신해야 하는지 검토한다.
   • MediaWiki 이미지에서 envvars.inc 를 뺄지 검토한다.
   • 서로 관련된 구성 요소를 한꺼번에 보여 주고 따라갈 링크를 담은 "Why" 대시보드를 만들지 검토한다.
   • 장애 대응 조율을 개선한다. 누가 무엇을 맡았는지, 누가 대응에 들어오고 나갔는지 장애 조율자가 알 수 있어야 한다. 또 맥락 없는 의견과 대응과 관계없는 논의로 채널이 시끄러워지지 않아야 한다.
   • 장애 중에 MediaWiki 개발자와 연락해 개발자의 관점을 바로 들을 수 있게 한다.

   교훈

   Wikimedia 는 기술적 원인보다, 3월 12일 장애 때부터 MediaWiki 배포 세 곳이 Memcached 클러스터에 닿지 못하고 있다는 것을 알아채지 못한 이유가 더 중요하다고 봤다. 알림에 연결된 대시보드는 무엇이 일어나는지만 보여 줬다. Wikimedia 는 서로 의존하거나 영향을 주는 구성 요소를 함께 보여 주는 대시보드가 있었다면 달랐을 것이라고 적었다. 예를 들어 SQLBlobStore 키는 External Storage 와 바로 이어져 있다. 원인을 가리킬 알림은 곧바로 회복됐다. 그 알림이 울렸더라도 알림 78개 사이에서는 부수 증상으로 봤을 수 있었다. 응답자가 많았지만 누가 무엇을 하는지, 누가 대응에 들어오고 나갔는지 분명하지 않아 장애 조율자가 조율하기 어려웠다. 외부 사용자 영향을 제대로 가늠하지 못해 실제보다 심각하게 여겼다. trace.wikimedia.org 도 장애 중에 쓰지 않았다.

   사례 보기
2. IL-0522 ingress-nginx Helm 차트 패치 업그레이드 뒤 jenkins.io 의 Ingress 가 지워져 사이트가 HTTP/503 을 냄

   Jenkins project2021

   증상

   2021년 11월 18일 11:32 UTC, 한 사용자가 Gitter 채널 jenkinsci/jenkins 에 https://www.jenkins.io/doc/pipeline/steps/ 가 HTTP/503 오류를 낸다고 알렸다. 화면에는 Fastly 의 Varnish 가 내는 "Guru meditation" 메시지가 떴다.

   서비스 중단리소스 삭제

   촉발

   2021년 11월 18일 10:42 UTC 에 nginx Helm 차트를 패치 버전인 4.0.6 에서 4.0.8 로 올리는 배포가 성공했다. 새 버전은 `{}` 같은 Nginx 설정 블록이 든 Ingress 어노테이션을 막는 어드미션 웹훅 규칙을 새로 만들었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러어드미션 웹훅HelmCDN 과 엣지 네트워크

   기여 요인

   미검증 가정캐시로 가려진 장애모니터링 사각지대수동 조치 악화

   감지

   장애가 시작되고 25분 뒤인 11:32 UTC 에 사용자가 Gitter 채널 jenkinsci/jenkins 에 신고해 알았다. origin.jenkins.io 에는 오류를 알릴 모니터링이 없었다.

   조치

   • 13:40 UTC 에 자동화 시스템을 모두 멈춘 채 nginx Helm 차트를 이전 버전 4.0.6 으로 롤백하고, 어드미션 웹훅 구성을 손으로 지워 jenkins.io 를 되살렸다.
   • jenkins-infra/charts 에서 jenkins.io 설정의 금지된 어노테이션을 지웠다.
   • jenkins.io Helm 차트를 nginx 4.0.8 에서 제대로 동작한다고 알려진 마지막 버전으로 올렸다.
   • 필요한 수정을 모두 적용한 뒤 17:11 UTC 에 자동화 시스템이 jenkins.io Helm 차트를 다시 배포해 사이트가 돌아왔고, Fastly 에 모든 페이지의 캐시를 비우게 했다.

   후속 조치

   • 인그레스 컨트롤러를 업데이트할 때는 항상 변경 기록을 깊이 읽고, 적어도 두 사람이 실시간으로 함께 본다.
   • www.origin.jenkins.io 의 장애를 잡아내도록 Datadog 에 이 도메인의 모니터링을 더한다.
   • 이 모니터링은 Host 헤더를 www.jenkins.io 로 보내, Fastly 를 거치는 jenkins.io 로 리디렉션되지 않게 한다.
   • 첫 페이지만이 아니라 pipeline steps 페이지 같은 여러 페이지를 점검 대상에 넣는다.
   • 운영에 배포하기 전에 k3s 로 잠깐 띄웠다 지우는 엔드 투 엔드 시험 환경을 두는 방안을 다음 분기에 검토한다.

   교훈

   인그레스 컨트롤러처럼 민감한 구성 요소는 패치 버전 업그레이드라도 변경 기록을 깊이 확인해야 한다. 원본 호스트인 origin.jenkins.io 를 직접 지켜보는 모니터링이 없으면 CDN 뒤에서 난 오류를 사용자 신고로 처음 알게 된다.

   사례 보기
3. IL-0197 Elasticsearch StatefulSet 을 새 퍼시스턴트 볼륨으로 옮기던 중 빈 볼륨으로 다시 뜬 elasticsearch-0 이 혼자 새 클러스터를 만들어 스플릿 브레인이 났다.

   Palark2021

   증상

   옛 노드 세 개를 하나씩 새 StorageClass 의 볼륨으로 바꾸다가 마지막으로 elasticsearch-0 파드를 지우고 다시 띄웠다. elasticsearch-0 안에서 `_cat/nodes` 를 조회하자 자기 자신 하나만 마스터로 나왔다.

   스플릿 브레인

   촉발

   옛 PVC 와 파드를 지운 뒤 elasticsearch-0 이 새 StorageClass 의 빈 볼륨을 받아 다시 시작했다.

   원인

   운영 실수

   구성 요소

   Elasticsearch 와 OpenSearch영구 볼륨과 스테이트풀셋Helm

   기여 요인

   미검증 가정

   감지

   마지막으로 0번 파드를 교체한 뒤 엔지니어가 elasticsearch-0 과 elasticsearch-1 안에서 각각 `_cat/nodes` 를 조회했다. 두 결과가 서로 다른 노드 목록과 다른 마스터를 보여 스플릿 브레인을 알아챘다.

   조치

   • 데이터를 실시간으로 쓰는 워커의 디플로이먼트 세 개를 0으로 줄여 새 데이터가 갈라진 클러스터로 들어가지 않게 했다.
   • ConfigMap 의 initial_master_nodes 를 elasticsearch-0, elasticsearch-1, elasticsearch-2 로 바꾸고 StatefulSet 에서 cluster.initial_master_nodes 환경 변수를 지웠다.
   • 롤링 업데이트가 도는 동안 디스커버리용 elasticsearch Service 를 YAML 로 저장한 뒤 지우고, 0번 파드의 PVC 도 지웠다.
   • ConfigMap 의 initial_master_nodes 를 elasticsearch-3, elasticsearch-4, elasticsearch-5 로 바꾸고, 0번 파드의 빈 PVC 를 만든 뒤 파드 6개를 모두 지워 다시 띄웠다.
   • 저장해 둔 YAML 로 Service 를 다시 만들었다. 노드 6개가 한 클러스터로 모였고 green 이 아닌 인덱스는 0개였다.

   후속 조치

   • ConfigMap 의 initial_master_nodes 를 원래 값으로 되돌리고 모든 파드를 한 번 더 재시작한다.
   • 모든 샤드를 0, 1, 2번 노드로 옮기고 클러스터를 노드 6개에서 3개로 줄인다.
   • 손으로 바꾼 내용을 모두 저장소에 커밋한다.

   교훈

   운영 데이터를 옮길 때는 설정 오류, 데이터센터 장애, 네트워크 단절처럼 무언가 잘못될 수 있다는 전제로 준비해야 한다. 이번에 쓴 다운타임 없는 절차는 예상하지 못한 문제에 약했다. 팀은 ConfigMap 을 꼼꼼히 확인했지만 Helm 차트 템플릿이 StatefulSet 에 넣는 환경 변수는 보지 않았다. cluster.initial_master_nodes 가 파드 하나로 고정된 상태에서 그 파드가 빈 볼륨으로 다시 뜨면 기존 클러스터에 합류하지 않고 새 클러스터를 만든다.

   사례 보기
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-0518 GKE 위 gitlab.freedesktop.org 의 디스크가 모자라 저장소를 늘리려던 30분 작업이 GitLab 전체의 4시간 장애가 됐다

   freedesktop.org2018

   증상

   9am UTC 조금 넘어 gitlab.freedesktop.org 의 디스크 공간이 위급하다는 것이 분명해졌다. 디스크가 모자라 일부 API 요청이 실패했고, 매일 도는 백업 cron 작업도 같은 이유로 실패하기 시작했다. 관리자는 사람들이 IRC 에서 장애를 말하고 나서야 문제를 알았다.

   영구 볼륨 가득 참오류율 상승서비스 중단

   촉발

   최근 Mesa 포크가 많이 만들어지면서 GitLab 클러스터의 디스크가 거의 찼다. 관리자가 디스크 볼륨을 늘리려고 몇 시간 전에 알린 작업 시간에 GitLab 을 내리고 저장소 업그레이드를 시작했다.

   원인

   용량 한계

   구성 요소

   영구 볼륨과 스테이트풀셋클라우드 블록 스토리지Helm

   기여 요인

   미검증 가정스테이징 불일치모니터링 사각지대피크 시간 변경

   감지

   사람들이 IRC 에서 장애를 말하고 나서야 문제를 알았다. 디스크 사용량이나 API 오류율을 지켜보고 알리는 모니터링은 없었다.

   조치

   • 관리자가 일하던 IP 를 빼고 GitLab 으로 들어오는 트래픽을 모두 버리도록 방화벽 규칙을 고쳤다. 그래서 다른 사람들은 잠깐씩 나는 실패 대신 연결 타임아웃만 봤고, 관리자는 그 시점 뒤의 변경을 잃을 걱정 없이 한 시점의 데이터를 스냅샷으로 뜰 수 있었다.
   • GCS 에 있는 것을 뺀 GitLab 데이터 전부를 손으로 백업했다. 평소의 백업 Rake 작업은 데이터 모으기까지만 돌렸다. tar 를 돌리면 디스크가 넘치므로, tar 출력을 SSH 로 로컬의 안전한 기계에 있는 암호화된 파티션에 흘려보냈다.
   • 모든 데이터 디스크의 스냅샷을 떴다. Kubernetes PersistentVolume 마다 Google Compute Engine 디스크가 있어 손으로 스냅샷을 뜨고 태그를 붙였다.
   • Kubernetes 서비스를 모두 멈추고, 새로 키운 PV 와 옛 디스크 스냅샷을 새 임시 GCE VM 에 함께 붙여 직접 복사한 뒤 VM 을 멈추고 Kubernetes 를 다시 켰다.
   • 첫 복사가 MySQL 하위 디렉터리를 지키지 못해 MySQL 이 빈 데이터베이스를 봤다. 그래서 어긋남을 막으려고 자원을 모두 지우고, 비어 있는 새 볼륨과 새 GCE VM 을 만들어 올바른 디렉터리 구조로 다시 복사했다. 저장소와 사용자 목록이 전과 같은지, UI 일부와 흔한 작업 흐름이 되는지 손으로 확인했다. 다음 날 아침 백업 cron 작업이 또 다른 장애 없이 성공하도록 전체 백업을 백그라운드로 돌렸다.
   • 18:45 UTC 쯤 공개 접근을 되살리고 장애가 끝났다고 알렸다.

   후속 조치

   • 모니터링, 로깅, 알림을 켠다. 이 일은 gitlab.freedesktop.org 의 freedesktop 이슈 8번으로 오래전에 열어 두었고, 이 분야를 아는 사람의 도움을 구한다.
   • 소통을 개선한다. 이번 장애는 급하게 잡혀 IRC 에만 알렸고 메일링 리스트에는 알리지 않았으며, 장애가 길어질 때도 리스트에 알리지 않았다. 이런 일을 훨씬 잘 알리는 방법을 찾는다.
   • Cloud Console 웹 UI 는 페이지 사이 로딩이 길고 이동이 많아 대화형 작업에 거의 쓸 수 없다. 그 대신 콘솔 클라이언트를 실제 상황에서 쓰는 데 익숙해지고, 되도록 콘솔 클라이언트를 쓴다.
   • GitLab 관리자가 한 명뿐인 상태는 지속할 수 없으므로 관리자를 늘린다. 특히 Kubernetes 배포에 익숙한 사람이 있으면 큰 도움이 된다.
   • Omnibus 컨테이너에서 벗어난다. 지금은 gitlab.fd.o 뒤의 모든 서비스가 파드 하나에 있고, 시작할 때 Chef 가 2~3분 동안 파일 시스템을 설정해 변경마다 최소 4~5분 동안 GitLab 전체가 내려간다. GitLab 이 만드는 cloud native 배포로 옮기려면 몇 시간의 장애가 필요하므로 충분히 앞서 알린다.
   • 저장소를 크기를 바꿀 수 있는 볼륨이나 GCS 로 옮긴다. 할 수 있는 만큼 클라우드 스토리지로 옮기고, GCP 에서 Kubernetes 1.11.x 를 쓸 수 있게 되면 디스크를 필요에 따라 커지는 볼륨으로 다시 만든다.

   교훈

   잘못된 것이 많았다. 디스크 사용량이나 API 오류율을 재고 알리는 장치가 없어서 IRC 에서 사람들이 말하고 나서야 알았다. GitLab 관리자가 한 명뿐이라 그 사람이 없으면 다른 사람이 Kubernetes 계정을 만들고 배포를 익히는 데서 시작해야 했고, 그 관리자도 Kubernetes 운영 경험이 비교적 적었다. 백업 크기가 크게 늘었으니 백업이 전보다 오래 걸린다는 것을 미리 알았어야 했고, 그렇지 않더라도 작업 시간을 알리기 전에 시험 작업으로 걸리는 시간을 잴 수 있었다. 오전에 일부 변경을 시험했지만 실제와 똑같은 변경은 시험하지 않았고, 디스크 스냅샷 같은 것은 시험을 더 철저하고 실제에 가깝게 할 수 있었다. 잘된 것도 있었다. 파괴적인 작업을 시작한 뒤로 어느 시점에나 백업이 적어도 세 벌 있어서 데이터를 영영 잃을 위험은 없었다. 다만 그중 일부는 복원 원본으로 쓰려면 받아들일 수 없을 만큼 긴 장애가 필요했다. 데이터의 많은 부분이 GCS 에 있었기 때문에 이번 같은 작업이 필요해지는 시점이 오래 늦춰졌다.

   사례 보기

원인별5