사례2건
2건 중 1~2번째
- 증상
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 리전에서 동시에 도는 새 구조의 지원 시스템을 내놓는다.
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 모드로 더 오래 버티게 해, 사용자 영향 없이 복구할 시간을 충분히 둔다.
- 고객 소통 도구를 포함한 비상 대응 도구와 절차를 검토하고 고치고 시험해, 이번과 같은 네트워크 장애에도 견디게 한다.
- 상시 재해 복구 시험의 범위를 넓혀 이번 장애와 이와 비슷한 수준의 큰 장애를 넣는다.
이 2건에서 가장 많이 나오는 구성 요소: 백본망, BGP 라우팅. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.