{"id":"IL-0255","org":"37signals","date":"2020-08-28","docs":[],"title":{"en":"Basecamp's two redundant links between data centers dropped together and a Redis replica resync loop stalled chat","ko":"데이터센터 사이 메트로 회선이 잠깐 끊긴 뒤 Redis 레플리카가 재동기화 루프에 빠져 BC3 가 느려지고 채팅이 멈췄다"},"domain":["networking","database"],"impact":{"scope":"BC3: slow responses throughout, and chats and pings not working","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Planned redundancy and live testing had given Basecamp a false sense of security, especially at peak load: moving between redundant network links or shifting load across data centers should work without issue, and Basecamp would rather find out in a controlled test with the full team ready. The follow-up from an outage needs urgency and explicitly cleared time, not just a place on a list.","ko":"이중화를 계획하고 실제 시험을 늘려 왔지만 충분하지 않았고, 특히 최대 부하에서는 안전하다는 착각을 하고 있었다. 데이터센터 사이로 부하를 옮기거나 이중 회선 사이를 오가는 일은 문제없이 돼야 한다. 그렇지 않다면 팀 전체가 준비된 통제된 상황에서 그 사실을 알아야 한다. 장애에서 나온 후속 조치는 목록에 더하는 데서 그치지 말고 더 급하게 처리해야 한다."},"related":[],"sources":[{"url":"https://signalvnoise.com/svn3/inside-a-code-red-network-edition/","kind":"blog","archived":"https://web.archive.org/web/20260824041332/https://signalvnoise.com/svn3/inside-a-code-red-network-edition/"}],"summary":{"en":"Basecamp has redundant metro links between its primary data center in Ashburn, VA and its other data center in Chicago, IL. A few months before the incident it changed networking providers for these links after its previous vendor was acquired, ran the new provider alongside the old one for several weeks, and switched over entirely in late June 2020.\n\nOn 28 August the short loss of connectivity between the data centers led to replication errors on a Redis standby server, and the replica fell into a resynchronization loop that kept taking resources from the primary and made it very slow. Chat reconnections added load that slowed the whole of BC3. The team turned chat off at the load balancer layer to stabilise the rest of BC3, and restarting Redis on the replica brought an immediate improvement, after which BC3 returned to normal. The Redis behaviour was a known issue with a documented workaround that was new to the team; the Ops lead created a todo for the configuration change but did not make sure it was assigned or finished before the next incident.\n\nThe question afterwards was how a 30 second loss of one redundant link could take BC3 down. Logs showed that both links had dropped. The providers first pointed to sub-optimal BGP configuration settings, which did not fully explain the loss of both circuits. When the links dropped again on 1 September, the providers watched it happen and found that both metro links share a physical path in Pennsylvania that was affected by a fiber cut, which surprised Basecamp and the providers alike.","ko":"Basecamp 는 Ashburn 의 주 데이터센터와 Chicago 의 데이터센터 사이에 이중 메트로 회선을 둔다. 기존 공급사가 인수되면서 새 공급사로 바꿨고, 몇 주 동안 두 공급사를 나란히 쓴 뒤 6월 말에 완전히 옮겼다.\n\n8월 28일 금요일 11:59AM CDT 에 메트로 회선이 짧게 끊긴 뒤 BC3 응답이 계속 느렸고 채팅과 Pings 가 멈췄다. 채팅 재연결이 네트워크에 과부하를 걸었다. 운영 팀은 Cable 서비스를 두 번 재시작했지만 소용이 없었고, 로드 밸런서 계층에서 채팅을 꺼서 나머지 BC3 를 안정시켰다. 그 뒤 Redis DB 인스턴스 하나의 알림을 따라가 대기 서버의 레플리카가 재동기화 루프에 빠져 주 노드를 느리게 하는 것을 찾았다. 레플리카의 Redis 를 재시작하자 곧바로 나아졌고 BC3 는 곧 정상으로 돌아왔다. 레플리카의 재동기화 루프는 문서화된 우회 방법이 있는 알려진 Redis 문제였다. 운영 리더는 그 설정 변경을 할 일 목록에 올렸지만, 담당자를 분명히 정하지 않았고 서둘러 끝내지도 못했다.\n\n사고 뒤 남은 질문은 이중 회선 하나가 30초 끊긴 것으로 어떻게 BC3 가 멈추느냐였다. Basecamp 는 로그에서 두 회선이 모두 짧게 끊긴 것을 확인하고 공급사들에 물었다. 공급사들의 첫 답은 BGP 설정이 최적이 아니라는 내용이었지만, 그것으로는 두 회선이 함께 끊긴 이유를 다 설명하지 못했다. 9월 1일 같은 끊김이 다시 났을 때 공급사들이 실시간으로 지켜보면서, 두 메트로 회선이 펜실베이니아에서 같은 물리 경로를 지나고 그곳의 광케이블 절단이 영향을 줬다는 것이 드러났다. Basecamp 도 공급사들도 몰랐던 일이었다."},"trigger":{"en":"Both redundant metro links between Basecamp's Ashburn and Chicago data centers dropped for short periods; monitoring showed the newer link down for about 20-30 seconds.","ko":"2020년 8월 28일 11:59AM CDT 에 Ashburn 의 주 데이터센터와 Chicago 데이터센터를 잇는 이중 메트로 회선이 짧게 끊겼다. 모니터링에는 새 회선이 20~30초 끊긴 것만 보였지만, 로그에서는 두 회선이 모두 잠깐씩 끊긴 것이 드러났다."},"severity":"unknown","symptoms":["link-flapping","high-latency","replication-lag"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"A flood of alerts from PagerDuty, Nagios and Prometheus, with monitoring showing the lost metro link. A lingering alert for one Redis DB instance later pointed to the replication problem.","ko":"PagerDuty, Nagios, Prometheus 에서 알림이 쏟아졌다. Redis 문제는 상황이 진정된 뒤 Redis DB 인스턴스 하나에 계속 떠 있던 알림을 보고 찾았다."},"components":["backbone-network","bgp","cache","database-replication"],"root_cause":"dependency-failure","remediation":[{"text":{"en":"Turned chat off at the load balancer layer so the rest of BC3 could stabilise","ko":"로드 밸런서 계층에서 채팅을 꺼 나머지 BC3 를 안정시켰다."}},{"text":{"en":"Restarted Redis on the replica that was stuck in the resynchronization loop","ko":"레플리카의 Redis 를 재시작했다."}}],"action_items":[{"text":{"en":"Make the documented Redis configuration changes for the known replication issue","ko":"알려진 Redis 문제의 문서화된 우회 방법대로 Redis 서버의 설정을 바꾼다."}},{"text":{"en":"Make concrete plans to remove the shared physical path under the two metro links","ko":"두 메트로 회선이 펜실베이니아에서 같은 물리 경로를 지나는 문제를 없앨 구체적인 계획을 세운다."}},{"text":{"en":"Prove the failover systems in production at peak load","ko":"장애 조치 시스템을 최대 부하 때 운영 환경에서 직접 검증한다."}},{"text":{"en":"Make explicit room for post-incident follow-up work and push other work out","ko":"사고 후속 조치를 할 시간을 명시적으로 비우고, 우선순위를 밝혀 다른 일을 뒤로 미룬다."}}],"contributing":["single-point-of-failure","retry-storm","alert-noise"],"recurrence_of":null,"symptoms_text":{"en":"At 11:59AM CDT on Friday 28 August 2020, Basecamp's Ops team received a flood of alerts from PagerDuty, Nagios and Prometheus. Monitoring showed that the newer of the two metro links between the data centers in Ashburn, VA and Chicago, IL had been lost for about 20-30 seconds, and BC3 kept responding slowly after the link came back.\n\nChats and pings in BC3 then stopped working entirely, and chat reconnections were overloading the network and slowing all of BC3. Because the problem was clearly tied to chat, the team restarted the Cable service, which did not fix the connections. Turning chat off at the load balancer layer let the rest of BC3 settle, but a second Cable restart had no effect.\n\nWhen the alert noise died down, one alert for a single Redis DB instance remained. The team had passed over it at first because the database was not down, and probes from the command line still got answers. Further digging found replication errors on a standby server: its replica was stuck in a resynchronization loop that kept taking resources and slowed the primary so much that it answered little more than monitoring checks.\n\nLogs reviewed after the incident showed that both metro links, not only the newer one, had dropped for short periods.","ko":"2020년 8월 28일 금요일 11:59AM CDT 에 PagerDuty, Nagios, Prometheus 에서 알림이 쏟아졌다. 모니터링에는 새 메트로 회선이 20~30초쯤 끊긴 것이 보였고, 네트워크가 돌아온 뒤에도 BC3 응답이 계속 느렸다.\n\n이어서 채팅과 Pings 가 전혀 동작하지 않는 것이 보였다. 채팅 재연결이 네트워크에 과부하를 걸어 BC3 전체를 느리게 하고 있었다.\n\n팀은 문제가 채팅에 있다고 보고 Cable 서비스를 재시작했지만 연결 문제는 풀리지 않았다. 로드 밸런서 계층에서 채팅을 끄자 BC3 의 다른 서비스는 안정됐다. Cable 을 다시 재시작해도 효과가 없었다.\n\n상황이 진정되자 Redis DB 인스턴스 하나에 알림이 계속 떠 있는 것이 보였다. DB 가 죽은 것은 아니어서 처음에는 이 경고를 지나쳤다. 명령줄로 확인해도 응답이 왔다. 더 살펴보니 대기 서버에 복제 오류가 있었고, 레플리카가 재동기화 루프에 갇혀 있었다. 이 루프가 자원을 계속 빼앗아 주 노드를 느리게 했고, Redis 는 모니터링 검사에만 겨우 응답할 만큼 느려져 있었다.\n\n사고 뒤 로그를 보니 이중으로 둔 메트로 회선 두 개가 모두 짧게 끊겼었다."},"updated_at":"2026-11-14T12:33:50.470860Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0255","org_slug":"37signals"}