사례2건

2건 중 1~2번째

1. IL-0262 한 데이터센터의 로드 밸런서가 과부하에 걸려 GitHub 의 인증 경로와 이 데이터센터를 지나는 여러 서비스가 오류와 느린 응답을 냈다

   GitHub2026

   증상

   자동 모니터링이 오류 증가를 잡아 사고 대응이 시작됐다. 이슈와 풀 리퀘스트의 페이지와 API 가 오류를 내거나 느리게 응답했고, 같은 데이터센터의 로드 밸런서를 지나는 다른 서비스들도 오류와 지연을 보였다.

   오류율 상승지연 시간 증가

   촉발

   트래픽이 새 최고치를 찍으면서 한 데이터센터의 로드 밸런서가 한계를 넘었다. 서비스 메시 사이드카 하나가 동시 처리 한도에 닿았는데도 확장되지 않았다.

   원인

   용량 한계

   구성 요소

   온프레미스 로드 밸런서서비스 메시

   기여 요인

   재시도 폭주

   감지

   자동 모니터링이 오류 증가를 잡아 사고 대응이 시작됐다. 영향받은 제품은 공개 상태 페이지에 degraded 로 표시됐다.

   조치

   • 트래픽 일부를 다른 데이터센터로 옮기기 시작했다.
   • 부담을 덜려고 게이트웨이의 재시도를 줄였다.
   • 포화된 노드의 로드 밸런서 프로세스를 멈췄다.
   • 재시도를 일으키는 요청 가운데 가장 영향을 많이 받은 내부 엔드포인트로 가는 요청을 막았다. 이 조치와 로드 밸런서 프로세스 중지로 서비스 전반이 곧바로 회복됐다.
   • 클라이언트 재시도가 트래픽을 부풀려 인증 오류가 남아 있었다. 엔지니어들은 트래픽을 천천히 다시 올리면서 이 오류를 가라앉혔다.

   후속 조치

   • 오토스케일링 정책이 호스트 서비스만이 아니라 서비스 메시 사이드카의 동시 처리 수와 용량도 따지도록 고친다.
   • 영향받은 서비스 전반에서 서비스 메시의 요청 한도, 동시 처리 한도, 스케일링 한도를 점검한다.
   • 일부 구간의 성능 저하가 더 넓은 과부하로 커지지 않도록 게이트웨이와 클라이언트 전반의 재시도와 백오프 한도를 다시 살핀다.
   • 사고 동안 인증 트래픽을 부풀린 클라이언트 재시도 동작을 고친다.
   • 로드 밸런서 용량 모니터링을 개선한다.
   • 리전 페일오버 안전장치를 강화한다.

   교훈

   GitHub 는 핵심 약점을 두 가지로 봤다. 서비스 메시 사이드카가 확장되지 않은 것과 재시도 동작이다. 클라이언트에 충분한 제한이 없어서 일부 구간의 성능 저하가 더 넓은 과부하로 커지는 것을 막지 못했다.

   사례 보기
2. IL-0256 하드웨어 로드 밸런서가 거듭 죽고 대기 장비로 넘어간 뒤 라우터가 동기화하지 못해 Basecamp 전체가 이틀 연속 열리지 않았다

   37signals2020

   증상

   2020년 9월 1일 화요일 Central Time 9:51am 부터 10:08am 까지, UTC 로는 14:51–15:08 의 17분 동안 Basecamp 가 아예 열리지 않았다. 아무것도 동작하지 않는 것처럼 보였고, 다시 열린 뒤에는 모든 것이 정상으로 보였다.

   서비스 중단링크 플래핑지연 시간 증가

   촉발

   2020년 9월 1일 데이터센터 사이 네트워크 회선이 끊긴 것을 복구하는 도중 하드웨어 로드 밸런서 하나가 죽었다. 9월 2일에는 Virginia 데이터센터의 주 로드 밸런서와 보조 로드 밸런서가 차례로 죽었다.

   원인

   소프트웨어 결함

   구성 요소

   온프레미스 로드 밸런서백본망

   기여 요인

   장애 중첩여유 용량 부재

   조치

   • 9월 1일 라우터가 새 로드 밸런서와 자동으로 동기화하지 못하자 손으로 개입해 바로잡았다.
   • 9월 2일 라우터가 동기화하지 못하는 같은 문제가 다시 나자 이번에도 손으로 개입해 고쳤다.

   후속 조치

   • 로드 밸런서 공급사와 함께 장애 원인을 끝까지 밝히고, 1차 평가에서 나온 버그 수정을 적용한다.
   • 하드웨어 로드 밸런서를 교체한다.
   • 데이터센터 사이 이중 네트워크 경로를 다시 깔아 회선이 실제로 다른 경로를 지나게 하고, 네트워크 공급사 사이의 숨은 의존을 없앤다.
   • 비상 대책으로 하드웨어 로드 밸런서에서 소프트웨어 로드 밸런서로 옮기는 것을 검토한다. 하드웨어는 교체에 며칠이 걸리지만 소프트웨어는 몇 분이면 배포할 수 있다.
   • 비상 대책으로 로드 밸런서 구성을 분산해 장애 하나의 영향을 줄이는 것을 검토한다.
   • 시스템의 복원력, 취약함, 위험을 평가하고 평가 과정 자체도 검토한다.

   교훈

   Basecamp 는 여러 겹의 이중화와 복원력을 갖추고 운영 시스템에서 큰 장애 대응을 연습해 왔지만 이번 사고들은 잡지 못했다. 모든 사고를 잡을 수는 없지만, 연쇄 장애가 예상하지 못한 취약함과 어려운 복구 경로를 드러내는 일에는 대비할 수 있다.

   사례 보기

원인별2