Incident Library

IL-0255 37signals · 2020-08-28networkingdatabase

데이터센터 사이 메트로 회선이 잠깐 끊긴 뒤 Redis 레플리카가 재동기화 루프에 빠져 BC3 가 느려지고 채팅이 멈췄다

Basecamp 는 Ashburn 의 주 데이터센터와 Chicago 의 데이터센터 사이에 이중 메트로 회선을 둔다. 기존 공급사가 인수되면서 새 공급사로 바꿨고, 몇 주 동안 두 공급사를 나란히 쓴 뒤 6월 말에 완전히 옮겼다.

8월 28일 금요일 11:59AM CDT 에 메트로 회선이 짧게 끊긴 뒤 BC3 응답이 계속 느렸고 채팅과 Pings 가 멈췄다. 채팅 재연결이 네트워크에 과부하를 걸었다. 운영 팀은 Cable 서비스를 두 번 재시작했지만 소용이 없었고, 로드 밸런서 계층에서 채팅을 꺼서 나머지 BC3 를 안정시켰다. 그 뒤 Redis DB 인스턴스 하나의 알림을 따라가 대기 서버의 레플리카가 재동기화 루프에 빠져 주 노드를 느리게 하는 것을 찾았다. 레플리카의 Redis 를 재시작하자 곧바로 나아졌고 BC3 는 곧 정상으로 돌아왔다. 레플리카의 재동기화 루프는 문서화된 우회 방법이 있는 알려진 Redis 문제였다. 운영 리더는 그 설정 변경을 할 일 목록에 올렸지만, 담당자를 분명히 정하지 않았고 서둘러 끝내지도 못했다.

사고 뒤 남은 질문은 이중 회선 하나가 30초 끊긴 것으로 어떻게 BC3 가 멈추느냐였다. Basecamp 는 로그에서 두 회선이 모두 짧게 끊긴 것을 확인하고 공급사들에 물었다. 공급사들의 첫 답은 BGP 설정이 최적이 아니라는 내용이었지만, 그것으로는 두 회선이 함께 끊긴 이유를 다 설명하지 못했다. 9월 1일 같은 끊김이 다시 났을 때 공급사들이 실시간으로 지켜보면서, 두 메트로 회선이 펜실베이니아에서 같은 물리 경로를 지나고 그곳의 광케이블 절단이 영향을 줬다는 것이 드러났다. Basecamp 도 공급사들도 몰랐던 일이었다.

심각도
–
영향 범위
BC3: slow responses throughout, and chats and pings not working
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

2020년 8월 28일 금요일 11:59AM CDT 에 PagerDuty, Nagios, Prometheus 에서 알림이 쏟아졌다. 모니터링에는 새 메트로 회선이 20~30초쯤 끊긴 것이 보였고, 네트워크가 돌아온 뒤에도 BC3 응답이 계속 느렸다.

이어서 채팅과 Pings 가 전혀 동작하지 않는 것이 보였다. 채팅 재연결이 네트워크에 과부하를 걸어 BC3 전체를 느리게 하고 있었다.

팀은 문제가 채팅에 있다고 보고 Cable 서비스를 재시작했지만 연결 문제는 풀리지 않았다. 로드 밸런서 계층에서 채팅을 끄자 BC3 의 다른 서비스는 안정됐다. Cable 을 다시 재시작해도 효과가 없었다.

상황이 진정되자 Redis DB 인스턴스 하나에 알림이 계속 떠 있는 것이 보였다. DB 가 죽은 것은 아니어서 처음에는 이 경고를 지나쳤다. 명령줄로 확인해도 응답이 왔다. 더 살펴보니 대기 서버에 복제 오류가 있었고, 레플리카가 재동기화 루프에 갇혀 있었다. 이 루프가 자원을 계속 빼앗아 주 노드를 느리게 했고, Redis 는 모니터링 검사에만 겨우 응답할 만큼 느려져 있었다.

사고 뒤 로그를 보니 이중으로 둔 메트로 회선 두 개가 모두 짧게 끊겼었다.

증상 링크 플래핑지연 시간 증가복제 지연

원인

원인 의존성 장애

구성 요소 백본망BGP 라우팅인메모리 캐시데이터베이스 복제
기여 요인 단일 장애점재시도 폭주잡음에 묻힌 신호
촉발
2020년 8월 28일 11:59AM CDT 에 Ashburn 의 주 데이터센터와 Chicago 데이터센터를 잇는 이중 메트로 회선이 짧게 끊겼다. 모니터링에는 새 회선이 20~30초 끊긴 것만 보였지만, 로그에서는 두 회선이 모두 잠깐씩 끊긴 것이 드러났다.

감지

PagerDuty, Nagios, Prometheus 에서 알림이 쏟아졌다. Redis 문제는 상황이 진정된 뒤 Redis DB 인스턴스 하나에 계속 떠 있던 알림을 보고 찾았다.

조치

후속 조치

교훈

이중화를 계획하고 실제 시험을 늘려 왔지만 충분하지 않았고, 특히 최대 부하에서는 안전하다는 착각을 하고 있었다. 데이터센터 사이로 부하를 옮기거나 이중 회선 사이를 오가는 일은 문제없이 돼야 한다. 그렇지 않다면 팀 전체가 준비된 통제된 상황에서 그 사실을 알아야 한다. 장애에서 나온 후속 조치는 목록에 더하는 데서 그치지 말고 더 급하게 처리해야 한다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 백본망, BGP 라우팅, 인메모리 캐시. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.