사례3건

3건 중 1~3번째

1. IL-0356 Railway 에 호스팅된 모든 도메인으로 오는 새 연결이 5분 동안 HTTP 404 를 받았다

   Railway2026

   증상

   2026-09-30 07:35 UTC 무렵부터 Railway 에 호스팅된 모든 도메인이 새 연결에 HTTP 404 not found 를 냈다. 경로 조회가 실패하기 시작하자 곧바로 내부 알림이 울려 당직 대응팀이 소집됐다.

   서비스 중단DNS 조회 실패

   촉발

   07:29 에 병합된 라우팅 제어 플레인 변경을 배포할 때, 파이프라인 설정의 오류로 스키마 변경 파이프라인과 새 라우팅 서비스 배포 파이프라인이 동시에 돌았다. 두 파이프라인이 경쟁하다가 새 라우팅 서비스가 스키마 변경보다 먼저 모든 리전에 올라왔다.

   원인

   배포 결함

   구성 요소

   네트워크 컨트롤 플레인데이터베이스CI 시스템

   기여 요인

   안전하지 않은 실패 동작단계적 배포 부재과도한 영향 범위

   감지

   경로 조회가 실패하기 시작하자 곧바로 내부 알림이 울려 당직 대응팀이 소집됐다.

   조치

   • CI 시스템이 스키마 변경을 적용했고, 라우팅 서비스가 조회를 재시도하면서 도메인 라우팅이 곧바로 정상으로 돌아왔다.

   후속 조치

   • 배포 파이프라인을 하나로 합쳐 마이그레이션 롤아웃이 차례대로 돌게 하고, 병합 전에 배포 순서와 피해 범위를 검사한다.
   • 블루/그린 롤아웃에서 바이너리마다 작성 당시의 스키마 버전을 검증하고, 맞는 데이터베이스 스키마가 갖춰질 때까지 서비스가 운영에 올라가지 않게 한다.
   • 새 구성 요소인 분산 제어 플레인에 리전별 샤드 단위 롤아웃을 더해 앞으로는 피해를 샤드 안에 가둔다.

   사례 보기
2. IL-0367 Central 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 이 더 잘 버티게 한다.

   사례 보기
3. IL-0506 UC Berkeley DataHub 의 JupyterHub sqlite 데이터베이스가 빈 데이터베이스로 덮어써져 로그인이 실패하고 홈 디렉터리가 비어 보이고 다른 사용자로 로그인되는 문제가 났다

   UC Berkeley2017

   증상

   새벽 1시쯤 DataHub 에 로그인하려는 사용자가 프록시 오류를 받았다. hub 파드는 떠 있었지만 로그가 sqlite 오류로 가득했다.

   서비스 중단데이터 유실요청 오라우팅

   촉발

   엔지니어가 앞서 난 400 오류를 디버깅하려고 hub 파드 안에서 sqlite3 를 다시 열고, 데이터베이스를 ATTACH 하지 않은 채 .save jupyterhub.sqlite 를 실행했다. 이 명령이 JupyterHub 데이터베이스 파일을 빈 데이터베이스로 덮어썼다.

   원인

   운영 실수

   구성 요소

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

   기여 요인

   파괴적 변경 보호 장치 부재안전하지 않은 실패 동작수동 조치 악화

   감지

   새벽 1시쯤 DataHub 가 다운됐다는 신고가 들어왔다. 1:12 에는 한 사용자가 로그인은 되지만 노트북이 모두 사라졌다고 알렸다.

   조치

   • hub 파드의 replicas 를 0으로 줄여 hub 를 내렸다.
   • 쿠버네티스 PVC 를 사용자 id 와 다시 짝지어 JupyterHub sqlite 데이터베이스를 다시 만들었다. PVC 이름에 정리된 사용자 이름과 사용자 id 가 들어 있어서 할 수 있었다.
   • 처음 넣은 가짜 cookie_id 값을 null 로 바꾸고, sqlite 파일을 DataHub 에 다시 붙였다.
   • 모든 사용자를 로그아웃시키려고 hub 파드의 /srv/jupyterhub/jupyterhub_cookie_secret 을 바꿨다. 끝 근처 한 글자를 바꿨을 때는 효과가 없었고, 앞쪽 한 글자를 바꾸고 재시작하자 모두 로그아웃됐다.
   • 사용자 파드를 모두 지워 모든 사용자를 확실히 로그아웃시켰다.
   • 모든 사용자의 cookie_id 를 채우는 스크립트를 돌렸고, 메모리에 남은 오래된 캐시를 없애려고 hub 를 재시작한 뒤 사용자 파드를 다시 모두 지웠다.
   • 이름에 '.' 이 들어간 새 사용자를 지우고, 이름에 '-' 가 있는 모든 사용자의 '-' 를 '.' 으로 바꾸는 스크립트를 돌렸다.

   후속 조치

   • JupyterHub 가 cookie secret 의 일정 길이만 쓰고 나머지를 버려서, 로그아웃시키려고 값을 바꿀 때 혼란이 생긴다는 문제를 JupyterHub 에 보고한다.
   • users 테이블의 cookie_id 열에 UNIQUE 와 NOT NULL 제약을 두자고 JupyterHub 에 제안한다.
   • 데이터베이스가 지워져도 파드와 PVC 이름이 그대로 남도록, 이름에 사용자 id 대신 사용자 이름 해시를 쓰는 기능을 KubeSpawner 에 요청한다.
   • 사용자 테이블의 id 를 Google 인증이 주는 'id' 와 같게 두어, 처음 로그인한 때와 상관없이 사용자 id 가 바뀌지 않게 하는 기능을 OAuthenticator 에 요청한다.
   • 관리형 MySQL 서비스인 Google Cloud SQL 로 옮긴다.
   • 데이터베이스를 정기적으로 백업하고 그 백업을 시험한다.
   • 해야 할 일과 하지 말아야 할 일을 담은 운영 FAQ 를 쓰기 시작한다.
   • 모니터링과 호출 체계를 개선한다.
   • 에스컬레이션 절차를 분명하게 문서로 남긴다.

   사례 보기

원인별3