사례1건

1건 중 1~1번째

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

   GitHub2026

   증상

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

   오류율 상승지연 시간 증가

   촉발

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

   원인

   용량 한계

   구성 요소

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

   기여 요인

   재시도 폭주

   감지

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

   조치

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

   후속 조치

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

   교훈

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

   사례 보기

원인별1