IL-0256 37signals · 2020-09-01networking
하드웨어 로드 밸런서가 거듭 죽고 대기 장비로 넘어간 뒤 라우터가 동기화하지 못해 Basecamp 전체가 이틀 연속 열리지 않았다
Basecamp 는 이중으로 둔 두 데이터센터를 독립된 네트워크 회선 두 개로 잇는다. 로드 밸런서는 인터넷 트래픽을 Basecamp 서버로 보내는 하드웨어 장비다. 9월 1일 화요일 네트워크 회선이 다시 끊겨 Basecamp 3 의 Campfire 채팅과 Pings 가 멈췄고, 이를 복구하는 도중 로드 밸런서 하나가 죽었다. 대기 로드 밸런서가 바로 넘겨받았지만 네트워크 라우터가 새 로드 밸런서와 자동으로 동기화하지 못했고, 손으로 개입해야 해서 장애가 길어졌다. Basecamp 는 17분 동안 아예 열리지 않았다.
9월 2일 수요일 아침 일찍 Virginia 데이터센터의 주 로드 밸런서가 다시 죽었고, 보조 로드 밸런서로 넘어가는 장애 조치는 예상대로 됐다. 오전 늦게 보조 로드 밸런서도 죽어 이전 주 장비로 되돌아가면서, 라우터가 동기화하지 못하는 전날의 문제가 다시 났다. 이번에도 손으로 고쳤다. Basecamp 는 15분 동안 열리지 않았고 그 뒤 몇 시간 동안 채팅이 느렸다. Basecamp 는 로드 밸런서 공급사와 함께 장애 원인을 찾았고, 1차 평가와 버그 수정을 받았다. Basecamp 는 하드웨어 로드 밸런서를 한계까지 써 왔고, 세 번의 장애 가운데 하나에서는 트래픽 과부하가 주요 요인이었다고 밝혔다.
- 심각도
- –
- 영향 범위
- All of Basecamp could not be loaded for 17 minutes on 1 September and 15 minutes on 2 September; Campfire chats and Pings were down on 1 September and slow for hours after 2 September
- 영향 사용자
- –
- 지역
- –
- 감지까지
- –
- 복구까지
- –
증상
2020년 9월 1일 화요일 Central Time 9:51am 부터 10:08am 까지, UTC 로는 14:51–15:08 의 17분 동안 Basecamp 가 아예 열리지 않았다. 아무것도 동작하지 않는 것처럼 보였고, 다시 열린 뒤에는 모든 것이 정상으로 보였다.
그날은 데이터센터 사이 네트워크 회선이 먼저 끊기면서 Basecamp 3 의 Campfire 채팅과 Pings 가 또 멈췄다. 이를 복구하는 도중 로드 밸런서 하나가 죽었다. 대기 로드 밸런서가 곧바로 넘겨받았지만, 네트워크 라우터가 새 로드 밸런서와 자동으로 동기화하지 못했다.
9월 2일 수요일 Central Time 10:50am 부터 11:05am 까지, UTC 로는 15:50–16:05 의 15분 동안 Basecamp 가 다시 열리지 않았다. 다시 열린 뒤에도 채팅 메시지가 몇 시간 동안 느렸다.
9월 2일에는 아침 일찍 Virginia 데이터센터의 주 로드 밸런서가 다시 죽어 보조 로드 밸런서로 넘어갔다. 이 장애 조치는 예상대로 됐다. 그날 오전 늦게 보조 로드 밸런서도 죽어 이전 주 장비로 되돌아갔다. 그러자 라우터가 로드 밸런서와 동기화하지 못하는 전날의 문제가 다시 났다.
원인
원인 소프트웨어 결함
- 촉발
- 2020년 9월 1일 데이터센터 사이 네트워크 회선이 끊긴 것을 복구하는 도중 하드웨어 로드 밸런서 하나가 죽었다. 9월 2일에는 Virginia 데이터센터의 주 로드 밸런서와 보조 로드 밸런서가 차례로 죽었다.
감지
–
조치
- 9월 1일 라우터가 새 로드 밸런서와 자동으로 동기화하지 못하자 손으로 개입해 바로잡았다.
- 9월 2일 라우터가 동기화하지 못하는 같은 문제가 다시 나자 이번에도 손으로 개입해 고쳤다.
후속 조치
- 로드 밸런서 공급사와 함께 장애 원인을 끝까지 밝히고, 1차 평가에서 나온 버그 수정을 적용한다.
- 하드웨어 로드 밸런서를 교체한다.
- 데이터센터 사이 이중 네트워크 경로를 다시 깔아 회선이 실제로 다른 경로를 지나게 하고, 네트워크 공급사 사이의 숨은 의존을 없앤다.
- 비상 대책으로 하드웨어 로드 밸런서에서 소프트웨어 로드 밸런서로 옮기는 것을 검토한다. 하드웨어는 교체에 며칠이 걸리지만 소프트웨어는 몇 분이면 배포할 수 있다.
- 비상 대책으로 로드 밸런서 구성을 분산해 장애 하나의 영향을 줄이는 것을 검토한다.
- 시스템의 복원력, 취약함, 위험을 평가하고 평가 과정 자체도 검토한다.
교훈
Basecamp 는 여러 겹의 이중화와 복원력을 갖추고 운영 시스템에서 큰 장애 대응을 연습해 왔지만 이번 사고들은 잡지 못했다. 모든 사고를 잡을 수는 없지만, 연쇄 장애가 예상하지 못한 취약함과 어려운 복구 경로를 드러내는 일에는 대비할 수 있다.
출처
관련 사례
같은 원인 · 공통 백본망
IL-0222유지보수 자동화가 여러 위치의 네트워크 제어 평면 작업을 한꺼번에 내려 미국 Google Cloud 리전의 네트워크가 심하게 혼잡해졌다.Google Cloud · 2019같은 원인 · 공통 백본망
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0256
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0256/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.