그래프
사례6건
6건 중 1~5번째
IL-0367Central US 의 Azure Storage 가 VM 디스크 요청을 거부해 VM 과 그 위의 SQL Database, Cosmos DB 가 멈췄다Microsoft Azure2024- 증상
Central US 리전에서 VM 가용성이 떨어졌고, 그 VM 에 기대는 여러 Azure 서비스에서 연결 실패와 서비스 관리 작업 실패가 났다. 서비스 모니터링은 7월 18일 22:06 UTC 에 VM 가용성 하락을 잡았고, 22:14 UTC 에 Cosmos DB, SQL DB, SQL DB Managed Instance 의 가용성 하락을 잡았다.
- 촉발
일상적인 VM 호스트 변경에 맞춰 스토리지 허용 목록을 새로 만들 때, 목록을 만드는 서버가 네트워크 설정이 바뀐 인프라 파일 서버 일부에 접근하지 못했다. 그래서 VM 호스트 주소 범위 일부가 빠진 목록이 Central US 의 모든 스토리지 스케일 유닛에 배포됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
허용 목록이 Central US 에 배포되는 동안 서비스 모니터링이 VM 가용성 하락을 잡았고, 엔지니어링 팀이 투입됐다. VM 가용성 하락을 잡은 시각은 22:06 UTC 로, 고객 영향이 시작되고 26분 뒤였다. SQL 모니터링은 SQL 을 쓸 수 없게 된 지 1분 안에 비정상 노드와 로그인 실패를 잡았고, 22:14 UTC 에는 모니터링이 Cosmos DB, SQL DB, SQL DB Managed Instance 의 가용성 하락을 잡았다.
- 조치
- 원인을 확인한 뒤 허용 목록 갱신 워크플로를 전 세계에서 멈췄다.
- 23:27 UTC 에 Central US 리전의 모든 배포를 멈췄다.
- 23:35 UTC 에 모든 리전의 컴퓨트 증설 배포를 멈췄다.
- Central US 리전의 모든 스토리지 스케일 유닛의 설정을 고쳐 7월 19일 02:55 UTC 에 스토리지 가용성을 되살렸다.
- 장애 1시간 안에 자동 장애 조치 정책이 있는 SQL 데이터베이스의 장애 조치를 시작했다. geo-secondary 를 새 프라이머리로 올리고 장애 조치 그룹 엔드포인트가 새 프라이머리를 가리키게 했다.
- SQL 게이트웨이 노드를 재시작해 캐시를 새로 고치고, 연결이 올바른 노드로 가게 했다.
- 끝나지 않은 SQL 장애 조치를 강제로 완료했다.
- 영향이 시작된 직후, Central US 에 쓰기 리전이 있는 다중 리전 액티브-패시브 계정을 위해 Cosmos DB 컨트롤 플레인의 장애 조치를 시작했다. 이어 고객 계정을 다른 리전으로 장애 조치했다.
- 일부 계정에서는 고객이 Azure 포털에서 시작한 "graceful switch region" 작업이 Microsoft 가 시작한 서비스 관리 장애 조치를 막고 있었다. 이런 계정에서는 그 작업을 취소했다.
- 일부 계정은 오래 도는 컨트롤 작업이 서비스 메타데이터에 잠금을 잡고 있어 장애 조치가 끝나지 않았다. 이런 계정은 그 잠금을 지워 장애 조치를 강제로 완료했다.
- 장애 조치와 함께, 비정상으로 표시된 Cosmos DB 파티션을 고치는 작업을 따로 진행했다. 이 작업으로 Central US 단일 리전 계정의 가용성을 09:41 UTC 까지 99.9% 넘게 되살렸고, 19:30 UTC 쯤 모든 데이터베이스의 영향을 완화했다.
- 08:51 UTC 부터는 백엔드 노드 수리가 진행되는 대로, Microsoft 가 장애 조치했던 Cosmos DB 계정을 Central US 로 되돌렸다. Central US 를 먼저 읽기 리전으로 추가했고, 쓰기 리전을 다시 Central US 로 옮길지는 고객이 정하게 했다.
- 후속 조치
- 허용 목록을 만드는 워크플로가 원본 정보가 빠진 것을 알아채면 멈추게 고친다.
- 스토리지 요청이 허용 목록 검사에서 거부되면 알림을 보낸다.
- 허용 목록 배포를 가용 영역과 스토리지 종류에 따라 차례로 진행하고, 배포 기간을 24시간으로 늘린다.
- 허용 목록 배포 워크플로에 VM 상태 확인을 더하고, 이상이 보이면 배포를 자동으로 멈춘다.
- Microsoft 가 SQL 장애 조치 그룹의 장애 조치를 시작하는 정책을 다시 검토하고, 고객이 장애 조치를 직접 관리하라는 권고를 다시 알린다.
- Cosmos DB 페일백 워크플로를 고친다. 이 워크플로 때문에 MongoDB API 계정 일부에서 특정 버전의 MongoDB 드라이버가 모든 리전에 연결하지 못했다.
- 프라이빗 엔드포인트가 있는 Cosmos DB 계정이 페일백 뒤 Central US 에 연결하지 못하던 문제를 고쳐, Microsoft 가 페일백을 다시 하지 않아도 되게 한다.
- 스토리지 데이터 플레인 방화벽이 잘못된 허용 목록 배포를 알아채고 마지막으로 정상이던 상태를 계속 쓰게 한다.
- Azure NetApp Files 의 여러 모니터 로직을 고쳐 영향을 주는 이벤트를 제때 잡고 알맞게 분류하게 한다.
- Azure NetApp Files 의 여러 서비스 지표를 더 모니터링해 비슷한 문제를 잡고 관련 이벤트를 더 빨리 서로 연결해 보게 한다.
- SQL 이 쓰는 Service Fabric 클러스터 위치 변경 알림 메커니즘이 부하가 클 때도 믿을 만하게 동작하게 한다.
- SQL 지역 장애 조치 워크플로를 견고하게 만들어 장애 조치가 끝까지 완료되게 한다.
- Cosmos DB 장애 조치의 5%를 늦춘 문제를 없앤다.
- Azure DevOps 의 모든 고객 메타데이터를 알맞은 지리 영역으로 옮겨, 한 장애가 여러 지리 영역에 걸쳐 영향을 주지 않게 한다.
- Azure NetApp Files 의 리전 사이 읽기와 쓰기를 분리해, 이런 종류의 문제가 한 리전 안에서 끝나게 한다.
- Azure NetApp Files 가 저장소에 둔 사용률 데이터에 덜 기대도록 캐시를 쓰는 방안을 검토한다.
- Cosmos DB 다중 리전 액티브-패시브 계정에 파티션 단위 자동 장애 조치를 넣어, 영향받은 파티션을 자동으로 처리하게 한다.
- SQL 과 Cosmos DB 를 위해 Azure Virtual Machines 가 Resilient Ephemeral OS disk 개선을 진행해, 스토리지 장애에도 VM 이 더 잘 버티게 한다.
- 증상
2022-04-11 10:42 UTC 부터 mt1 클러스터에서 Channels 메시지 발행 API 를 11분 동안 거의 쓸 수 없었다. 상태 페이지는 10:44 무렵부터 10:53 무렵까지 MT1 API 요청의 오류율이 올랐다고 알렸다.
- 촉발
엔지니어는 Redis 설정의 복제 버퍼를 키운 것을 반영하려고 mt1 클러스터의 노드를 하나씩 교체하다가, 10:42 UTC 에 마스터 노드를 재시작했다. 장애 조치는 시작됐지만 끝나기 전에 Redis 프로세스가 종료됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
Pusher 는 10:44 UTC 무렵부터 MT1 API 요청의 오류율이 오른 것을 확인하고 상태 페이지에 알렸다.
- 후속 조치
- Redis 종료 스크립트가 노드를 끄기 전에 장애 조치가 끝났고 그 노드가 더는 마스터가 아닌지 확인하도록 고친다.
IL-0289updown.io 의 주 MongoDB 서버가 쿼리에 평소보다 약 200배 느리게 응답해 사이트와 모니터링 데몬이 거의 멈췄는데 자동 페일오버가 일어나지 않았다updown.io2019- 증상
2019년 4월 3일 2:30 am CEST 부터 updown.io 의 주 MongoDB 서버가 쿼리에 평소보다 약 200배 느리게 응답했다. 웹사이트와 모니터링 데몬이 거의 전부 멈췄다.
- 촉발
주 MongoDB 서버의 RAID5 를 이루는 SSD 3개 가운데 하나가 고장 나기 시작해 디스크 I/O 가 크게 느려졌다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
MongoDB 의 자동 페일오버는 하트비트가 계속 빠르게 응답해 문제를 감지하지 못했다. 운영자는 자고 있다가 8:45 am CEST 에야 문제를 알아챘다.
- 조치
- 보조 서버가 넘겨받을 준비가 됐는지 확인한 뒤 주 서버를 강제로 step down 시켰다. 8:56 am CEST 에 웹과 데몬 전체가 돌아왔지만, 보조 서버의 사양이 낮아 성능은 떨어졌다.
- I/O 문제를 일으킨 SSD 를 RAID 어레이에서 빼자 서버가 원래 성능으로 돌아왔다.
- 호스팅 업체에 SSD 교체 일정을 잡는 티켓을 열었다.
- 4월 6일 12:48 pm 에 보조 서버를 더 높은 사양의 서버로 바꿨고, 그 뒤 응답 시간이 정상으로 돌아왔다.
- 후속 조치
- MongoDB 팀이 이 문제를 곧 고칠 것 같지 않아, MongoDB 가 살아 있지만 응답하지 않는 상황을 찾아 자동으로 step down 시키는 스크립트를 만든다.
- 더 조사할 것이 없다고 확인되면 옛 보조 서버를 내리고 지운다.
- 새 보조 서버가 며칠 동안 주 서버 역할을 버틸 수 있는지, clamscan 이 도는 밤까지 포함해 확인한다.
- 주 서버가 정상으로 돌아오면 자동 step down 스크립트를 시험한다.
- updown.io 의 제대로 된 상태 페이지를 만든다.
- MongoDB 가 Storage Node Watchdog 을 커뮤니티 에디션에도 제공하자 이를 켜서 한동안 시험했다. 잘 동작해 직접 만든 스크립트는 지웠다.
IL-0219Postgres 프라이머리의 디스크 어레이가 망가진 뒤 Pacemaker 가 새 프라이머리를 승격하지 못해 GoCardless API 와 대시보드가 1시간 50분 멈췄다GoCardless2017- 증상
2017년 10월 10일 15:09 BST 에 모니터링이 API 와 대시보드가 완전히 멈춘 것을 찾았다. 그동안 들어온 요청은 모두 실패하고 오류를 받았다.
- 촉발
10월 10일 오후 Postgres 프라이머리 노드의 RAID 컨트롤러가 디스크 3개를 동시에 잃어 디스크 어레이가 망가졌다. 거의 같은 때 동기 복제본에서 Postgres 하위 프로세스 하나가 죽었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
15:09 BST 에 모니터링이 API 와 대시보드의 완전한 중단을 찾았고 엔지니어들이 조사를 시작했다.
- 조치
- 15:17 BST 에 디스크 어레이가 망가진 채 켜져 있는 노드를 클러스터에 두지 않으려고 망가진 Postgres 프라이머리 노드의 전원을 껐다. 클러스터는 여전히 새 프라이머리를 승격하지 않았다.
- 15:18 BST 에 Pacemaker 가 Postgres 인스턴스 상태를 다시 파악하게 하려고 crm resource cleanup 으로 오류 횟수를 지웠지만 효과가 없었다.
- Pacemaker 클러스터를 유지보수 모드로 두고 동기 복제본의 recovery.conf 에서 복제본 설정을 지운 뒤 유지보수 모드를 풀어 직접 승격하려 했지만, 매번 원래 recovery.conf 로 돌아갔다.
- 16:18 BST 에 클러스터를 마지막으로 유지보수 모드로 두고 동기 복제본을 프라이머리로 설정해 Postgres 를 직접 띄웠다.
- 클러스터가 유지보수 모드라 가상 IP 를 옮길 수 없었으므로 백엔드 애플리케이션이 새 프라이머리의 실제 IP 주소로 접속하게 다시 설정했다.
- 평소 수준의 이중화를 되찾으려고 세 번째 노드를 비동기 복제본으로 띄웠다.
- Pacemaker 가 유지보수 모드라 자동 페일오버가 없었으므로 인프라 팀이 손으로 관리할 가상 IP 를 하나 더 두어, 프라이머리가 망가지면 동기 복제본을 승격하고 가상 IP 를 직접 옮길 수 있게 했다.
- 디스크 어레이 장애였으므로 생각할 수 있는 모든 시험으로 데이터 무결성을 확인했고 데이터 손상의 증거는 없었다.
- Pacemaker 가 다시 관리하는 새 데이터베이스 클러스터를 만들고, 유지보수 시간을 공지한 뒤 문제없이 옮겼다. 옛 클러스터는 내렸다.
- 후속 조치
- Backup VIP 의 colocation 규칙을 Postgres 프라이머리와의 -INF 선호 대신 복제본과의 INF 선호로 바꿔, 같은 장애 조건에서도 동기 복제본이 승격되게 했다.
- 특정 Postgres 인스턴스로 트래픽을 보내는 가상 IP 를 없애고, 애플리케이션 서버에서 클러스터 상태에 따라 알맞은 노드로 트래픽을 보내는 프록시를 돌려 Pacemaker 가 관리하는 자원 수를 줄인다.
- Postgres 클러스터를 더 거칠게 시험하고, Chaos Monkey 처럼 계속 장애를 주입하는 자동화를 검토한다.
- 장애 대응 훈련인 게임 데이에 임의의 제약을 넣는 방안을 검토한다. 예를 들어 자동화가 실패하고 원인도 찾을 수 없는 상황에서 다른 방법으로 서비스를 되살리게 한다.
- 교훈
GoCardless 는 단순해 보이는 Pacemaker 설정이 매우 이상한 동작을 부를 수 있다는 것을 배웠다. 두 자원이 함께 돌면 안 된다는 규칙과 함께 돌아야 한다는 규칙은 반대말처럼 보이지만, 특정 장애 조건에서는 시스템이 완전히 다르게 움직였다. 프로세스 두 개가 거의 동시에 죽을 때만 드러나는 설정 오류는 기본 시험이나 평소 운영으로는 찾을 수 없고, 장애 주입으로만 드러나는 버그가 있다. 자동화가 2년 동안 장애를 잘 처리하자 그 아래 인프라를 손으로 다루는 기술이 녹슬었다. 런북을 써 두어도 몇 년 뒤에 꺼내 보면 거의 확실히 낡아 있다.
- 증상
2016년 2월 8일 17:45 UTC 에 Google Cloud Platform 의 Redis Cloud 클러스터 us-central1-1-1.gce.garantiadata.com 에서 큰 장애가 났다. 데이터베이스 엔드포인트가 us-central1-1-1.gce.garantiadata.com 으로 끝나는 사용자들이 데이터베이스를 쓰지 못했다.
- 촉발
2016년 2월 8일 17:30 UTC 에 서비스 소프트웨어의 주간 업그레이드가 GCP 클러스터 us-central1-1-1.gce.garantiadata.com 에 처음 배포됐다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 클러스터의 모든 노드를 내리고 종료했다.
- 클러스터의 모든 엔드포인트를 클러스터의 DNS 영역에서 지웠다. DNS 제공자가 삭제 요청을 스로틀링해 남은 항목은 손으로 지웠다.
- 주간 업데이트를 뺀 새 클러스터 노드를 처음부터 만들었다.
- 원래 노드가 쓰던 저장소를 새 노드에 다시 붙여, 영속성이 있는 데이터베이스를 복구할 수 있게 했다.
- 데이터베이스를 모두 띄웠고, 영속성이 있는 데이터베이스는 저장소에서 복구했다.
- 후속 조치
- 이번 같은 장애를 막는 절차를 갖출 때까지 자동 주간 업그레이드를 모두 멈춘다.
- DevOps 코드 배포의 QA 절차를 다시 검증한다.
- DNS 요청이 스로틀링될 때 도구가 이를 처리하도록 개선한다.
이 6건에서 가장 많이 나오는 구성 요소: 데이터베이스 장애 조치 관리자, 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.