사례4건
4건 중 1~4번째
- 증상
2025년 10월 20일 07시 6분 UTC에 모니터링 시스템이 IAD 리전, 즉 US-East 의 여러 PubNub 서비스에서 오류가 늘었다는 알림을 냈다. 일부 고객은 오류율과 지연이 오르는 것을 겪었다.
- 촉발
IAD 리전에서 클라우드 사업자인 AWS 에 광범위한 인프라 장애가 났다.
- 원인
- 구성 요소
- –
- 기여 요인
- 감지
07시 6분 UTC에 모니터링 시스템이 IAD 리전의 여러 서비스에서 오류가 늘었다는 알림을 냈다.
- 조치
- 리전 장애 조치 절차를 시작해 새 연결을 다른 리전으로 돌렸다.
- 이미 맺어진 연결을 손으로 초기화했다.
- Presence 트래픽을 EU-Central 의 Frankfurt 로 돌렸다.
- 다른 리전에 인프라를 더 띄워 옮겨 온 트래픽을 받아 냈다.
- US-West 에 두 번째 저하가 오자 US-East 리전을 다시 떼어 냈다.
- US-West 의 로드 밸런서 용량을 늘렸다.
- 사업자가 복구를 알린 뒤 US-East 의 안정을 확인하고 23시 48분까지 트래픽 재분배를 마쳤다.
- 후속 조치
- 모든 운영 서비스의 리전 장애 조치 절차를 한곳에 모아, 바로 찾아 쓸 수 있고 빠진 단계가 없게 한다.
- 새 서비스의 절차 문서에 빠진 곳을 메워, 운영에 완전히 들이기 전에 장애 조치 준비를 마친다.
- 장애 중 복구를 어렵게 한 인벤토리 도구와 DNS 이름 해석 문제를 포함해 내부 도구의 문제를 살펴 고친다.
- 증상
2021-12-07 PST 오전 7시 33분부터 us-east-1 에서 새 인스턴스를 띄우거나 기존 인스턴스를 조회하는 EC2 API 의 오류율과 지연이 늘었다. AWS 운영팀은 혼잡이 시작되자 곧바로 실시간 모니터링 데이터를 볼 수 없었다.
- 촉발
PST 오전 7시 30분에 주 AWS 네트워크에서 도는 한 AWS 서비스의 용량을 늘리는 자동 작업이, 내부 네트워크 안의 많은 클라이언트에서 예상하지 못한 동작을 일으켰다. 연결 시도가 한꺼번에 몰려 내부 네트워크와 주 네트워크 사이의 네트워크 장비가 감당하지 못했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
혼잡이 시작되자 운영팀의 실시간 모니터링 데이터가 곧바로 끊겼다. 운영자는 로그를 보고 상황을 파악했고, 처음에는 내부 DNS 오류가 늘어난 것을 찾았다.
- 조치
- 내부 DNS 트래픽을 혼잡한 네트워크 경로에서 옮겼다. PST 오전 9시 28분에 이 작업을 마치자 DNS 해석 오류가 완전히 회복됐지만 혼잡은 남았다.
- 내부 네트워크의 트래픽을 가장 많이 내는 출처를 찾아 전용 네트워크 장비로 분리했다.
- 네트워크 트래픽이 많은 서비스 일부를 껐다. PST 오후 12시 35분에는 EventBridge 이벤트 전달도 껐다.
- 네트워크 용량을 늘렸다. 혼잡은 오후 1시 34분에 크게 나아졌고 오후 2시 22분에 모든 네트워크 장비가 회복됐다.
- 이번 일을 촉발한 확장 작업을 즉시 껐다.
- 후속 조치
- 모든 개선 조치를 배포할 때까지 이번 일을 촉발한 확장 작업을 다시 켜지 않는다.
- 네트워크 클라이언트가 혼잡에서 제대로 back-off 하지 못하게 한 잠재 문제를 고치는 수정을 만들어 2주 안에 배포한다.
- 비슷한 혼잡이 다시 생겨도 영향받을 수 있는 네트워크 장비를 보호하도록 네트워크 설정을 추가한다. 이 설정은 이미 배포했다.
- 내부 네트워크를 쓸 수 없을 때도 API Gateway 서버가 정상으로 남게 하는 완화책을 만들고, 비슷한 일이 생겼을 때 더 빨리 복구하도록 서버 교체 과정을 개선한다.
- 서비스 영향을 더 쉽게 알아볼 수 있는 새 Service Health Dashboard 를 내년 초에 내놓는다.
- 고객과의 소통이 늦어지지 않도록 여러 AWS 리전에서 동시에 도는 새 구조의 지원 시스템을 내놓는다.
- 증상
2020년 11월 25일 5:15 AM PST 에 Kinesis 레코드를 넣고 가져오는 호출의 오류 알람이 울리기 시작했다. Kinesis 를 쓰는 CloudWatch, CloudWatch Events, EventBridge 도 같은 시각부터 오류와 지연을 보였다.
- 촉발
2:44 AM PST 부터 3:47 AM PST 까지 Kinesis 프런트엔드 서버군에 비교적 작은 용량을 더했다. AWS 는 이것이 촉발 요인이었지만 근본 원인은 아니었다고 밝혔다.
- 원인
- 구성 요소
- 기여 요인
- 감지
5:15 AM PST 에 Kinesis 레코드를 넣고 가져오는 호출의 오류 알람이 울리기 시작했고, 팀이 로그를 보기 시작했다.
- 조치
- 조심하려고 다른 오류를 조사하면서 새로 더한 프런트엔드 용량을 빼기 시작했다.
- 재시작을 빠르게 하려고, 프런트엔드 서버가 시작할 때 이웃 프런트엔드 서버 대신 정본 메타데이터 저장소에서 바로 데이터를 받도록 설정을 넣기 시작했다.
- 10:07 AM PST 부터 프런트엔드 서버를 다시 올리며 시간당 수백 대씩 천천히 트래픽을 더했다.
- Cognito 팀은 장애 초기에 용량을 더해 Kinesis 호출을 버퍼링할 여유를 늘렸다.
- 10:15 AM PST 에 Cognito 의 Kinesis 의존을 줄이는 변경을 배포하기 시작했고, 오류율이 내려가기 시작했다.
- 10:36 AM PST 에 엔지니어들이 Lambda 함수 호출 호스트의 메모리 경합을 줄이는 조치를 해서 호출 오류가 풀렸다.
- 의존이 적은 예비 도구로 Service Health Dashboard 에 게시하고, Personal Health Dashboard 로 영향받은 고객에게 직접 알리고, Service Health Dashboard 에 전역 배너 요약을 올려 고객에게 상황을 알렸다.
- 후속 조치
- CPU 와 메모리가 더 큰 서버로 옮겨 서버 수를 줄이고, 서버마다 서버군 안에서 통신하는 데 필요한 스레드 수를 줄인다.
- 서비스의 스레드 사용량에 세밀한 알람을 더한다.
- 운영체제 설정의 스레드 수 한도를 올리는 시험을 마친다.
- 프런트엔드 서버군의 콜드 스타트 시간을 크게 줄이는 변경을 한다.
- 프런트엔드 서버 캐시를 전용 서버군으로 옮긴다.
- CloudWatch 같은 큰 AWS 서비스 몇 개를 따로 나눈 프런트엔드 서버군으로 옮긴다.
- 백엔드에서 한 것처럼 프런트엔드 서버군의 셀 단위 분리를 크게 앞당긴다.
- Cognito 웹 서버가 Kinesis API 오류를 겪어도 버퍼를 다 쓰지 않고 버티도록 고쳤다.
- CloudWatch 로컬 지표 데이터 저장소에 지표 데이터 3시간 치를 보관해, CloudWatch 사용자와 AutoScaling 같은 서비스가 최근 지표를 바로 읽게 한다. US-EAST-1 에는 적용을 마쳤고 앞으로 몇 주 동안 전 세계에 배포한다.
- 지원 엔지니어가 Service Health Dashboard 예비 게시 도구를 정기적으로 훈련받도록 지원 교육을 바꿨다.
- 교훈
프런트엔드 서버마다 유지할 스레드 수는 서버군의 서버 수에 비례하므로, 서버 수를 줄이면 스레드 수에 큰 여유가 생긴다. AWS 에 따르면 셀 단위 분리는 서비스 안에서 장애의 영향을 가두고, shard-map 캐시 같은 구성 요소가 이미 시험하고 운영해 본 범위 안에서 돌게 하는 방법이다. 프런트엔드 서버군의 셀 단위 분리는 진행 중이었지만 일이 커서 아직 끝나지 않았다. AWS 는 이 작업이 끝나면 앞으로 드러날 모르는 확장 한도에도 더 잘 대비할 수 있다고 봤다.
IL-0222유지보수 자동화가 여러 위치의 네트워크 제어 평면 작업을 한꺼번에 내려 미국 Google Cloud 리전의 네트워크가 심하게 혼잡해졌다.Google Cloud2019- 증상
2019-06-02 US/Pacific 11:47~11:49 부터 미국 여러 리전의 Google Cloud 프로젝트에서 패킷 손실이 늘고, 지연이 커지고, 간헐적 오류와 인스턴스 연결 끊김이 나타났다. us-west1 과 유럽, 아시아 리전에는 리전 네트워크 혼잡이 없었다. Google 엔지니어는 장애가 시작되고 2분 뒤 알림을 받았다.
- 촉발
US/Pacific 11:45 에 비교적 드문 유형의 데이터 센터 유지보수 이벤트가 물리 위치 한 곳에서 시작됐다. 자동화 소프트웨어가 내릴 작업 목록에 네트워크 제어 작업을 돌리는 논리 클러스터를 넣었다. 이 클러스터에는 다른 물리 위치의 네트워크 제어 작업도 들어 있어, 여러 위치의 네트워크 제어 평면과 지원 인프라가 한꺼번에 내려갔다.
- 원인
- 구성 요소
- 기여 요인
- 감지
Google 엔지니어는 장애가 시작되고 2분 뒤 알림을 받았고, 가장 심각한 운영 사고에 쓰는 사고 관리 절차를 곧바로 시작했다. 고객용 상태 페이지에는 US/Pacific 12:53 에 첫 공지가 올라왔다.
- 조치
- 혼잡을 줄이려고 덜 중요한 네트워크 트래픽 등급의 우선순위를 낮췄다.
- US/Pacific 13:01 에 근본 원인을 찾고, 유지보수 이벤트를 일으킨 자동화 소프트웨어를 멈췄다.
- 네트워크 제어 평면과 지원 인프라를 위치마다 다시 스케줄해 켰다.
- 제어 평면 인스턴스가 모두 내려가면서 사라진 설정 데이터를 여러 위치에 다시 만들어 배포했다. 새 설정은 14:03 부터 나가기 시작했다.
- Google 안의 여러 팀이 서비스별 완화 조치로 트래픽을 피해 리전 밖으로 돌려 다른 곳에서 계속 서비스했다.
- us-west2, northamerica-northeast1, southamerica-east1 에서 장애 때문에 fail-safe 상태에 들어간 VPN 제어 평면을 손으로 빼냈다. 이 리전의 VPN 게이트웨이는 16:30 에 회복됐다.
- 후속 조치
- 유지보수 때 작업을 내리는 데이터 센터 자동화 소프트웨어를 즉시 멈췄고, 여러 물리 위치에서 동시에 작업을 내리지 않게 하는 안전장치를 갖춘 뒤에만 다시 켠다.
- 클러스터 관리 소프트웨어가 요청의 출처와 상관없이 여러 물리 위치의 작업을 한꺼번에 내리는 요청을 거부하도록 강화한다.
- 네트워크 제어 평면 소프트웨어와 지원 인프라가 이번 사고에 얽힌 유형의 유지보수 요청을 거부하도록 다시 설정한다.
- 위치마다 네트워크 제어 평면이 설정을 영구 저장하게 바꿔, 모든 작업이 내려가도 설정을 다시 만들고 배포할 필요가 없게 한다. 이렇게 하면 복구 시간이 열 배쯤 줄어든다.
- 제어 평면을 잃었을 때 네트워크가 fail static 모드로 더 오래 버티게 해, 사용자 영향 없이 복구할 시간을 충분히 둔다.
- 고객 소통 도구를 포함한 비상 대응 도구와 절차를 검토하고 고치고 시험해, 이번과 같은 네트워크 장애에도 견디게 한다.
- 상시 재해 복구 시험의 범위를 넓혀 이번 장애와 이와 비슷한 수준의 큰 장애를 넣는다.
이 4건에서 가장 많이 나오는 구성 요소: 백본망, BGP 라우팅. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.