사례4건
4건 중 1~4번째
- 증상
자동 모니터링이 오류 증가를 잡아 사고 대응이 시작됐다. 이슈와 풀 리퀘스트의 페이지와 API 가 오류를 내거나 느리게 응답했고, 같은 데이터센터의 로드 밸런서를 지나는 다른 서비스들도 오류와 지연을 보였다.
- 촉발
트래픽이 새 최고치를 찍으면서 한 데이터센터의 로드 밸런서가 한계를 넘었다. 서비스 메시 사이드카 하나가 동시 처리 한도에 닿았는데도 확장되지 않았다.
- 원인
- 구성 요소
- 기여 요인
- 감지
자동 모니터링이 오류 증가를 잡아 사고 대응이 시작됐다. 영향받은 제품은 공개 상태 페이지에 degraded 로 표시됐다.
- 조치
- 트래픽 일부를 다른 데이터센터로 옮기기 시작했다.
- 부담을 덜려고 게이트웨이의 재시도를 줄였다.
- 포화된 노드의 로드 밸런서 프로세스를 멈췄다.
- 재시도를 일으키는 요청 가운데 가장 영향을 많이 받은 내부 엔드포인트로 가는 요청을 막았다. 이 조치와 로드 밸런서 프로세스 중지로 서비스 전반이 곧바로 회복됐다.
- 클라이언트 재시도가 트래픽을 부풀려 인증 오류가 남아 있었다. 엔지니어들은 트래픽을 천천히 다시 올리면서 이 오류를 가라앉혔다.
- 후속 조치
- 오토스케일링 정책이 호스트 서비스만이 아니라 서비스 메시 사이드카의 동시 처리 수와 용량도 따지도록 고친다.
- 영향받은 서비스 전반에서 서비스 메시의 요청 한도, 동시 처리 한도, 스케일링 한도를 점검한다.
- 일부 구간의 성능 저하가 더 넓은 과부하로 커지지 않도록 게이트웨이와 클라이언트 전반의 재시도와 백오프 한도를 다시 살핀다.
- 사고 동안 인증 트래픽을 부풀린 클라이언트 재시도 동작을 고친다.
- 로드 밸런서 용량 모니터링을 개선한다.
- 리전 페일오버 안전장치를 강화한다.
- 교훈
GitHub 는 핵심 약점을 두 가지로 봤다. 서비스 메시 사이드카가 확장되지 않은 것과 재시도 동작이다. 클라이언트에 충분한 제한이 없어서 일부 구간의 성능 저하가 더 넓은 과부하로 커지는 것을 막지 못했다.
- 증상
AWS 에 있는 A 서비스가 온프레미스 환경의 B 서비스로 보내는 API 요청에서 5xx 오류가 늘고 사용자 요청이 실패했다. 같은 때 B 서비스 앞단 L4 의 세션 카운트도 올라갔다.
- 촉발
트래픽이 많은 주말에 connection pool 을 쓰지 않는 A 서비스가 NAT Gateway 를 거쳐 B 서비스로 새 TCP 연결을 계속 열었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
A 서비스의 5xx 오류 증가와 B 서비스의 L4 세션 카운트 증가로 알아챘다.
- 조치
- A 서비스 인스턴스를 늘렸다.
- 5xx 오류와 L4 세션 카운트가 평소 수치로 돌아오지 않자 A 서비스 인스턴스를 교체했다.
- 후속 조치
- A 서비스 팀과 함께 A 서비스가 connection pool 을 쓰도록 바꾼다.
- AWS 와 IDC 사이에서 NAT Gateway 를 쓰는 서비스를 조사해 connection pool 을 쓰도록 바꾼다.
- 교훈
장애를 해결하는 방법은 원인을 분석하다 보면 쉽게 보일 때가 많다. 그러나 원인을 정확히 확인하지 않으면 잠재적인 위험을 안은 채 서비스를 운영하게 된다. 우아한형제들은 장애 해결을 최우선으로 다루면서도, 재발을 막으려고 근본 원인을 찾아내는 과정을 중요하게 여긴다.
- 증상
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 는 여러 겹의 이중화와 복원력을 갖추고 운영 시스템에서 큰 장애 대응을 연습해 왔지만 이번 사고들은 잡지 못했다. 모든 사고를 잡을 수는 없지만, 연쇄 장애가 예상하지 못한 취약함과 어려운 복구 경로를 드러내는 일에는 대비할 수 있다.
IL-0492AWS 연결 문제로 느려진 연결이 연결 한도를 다 차지해 AWS 밖에 있는 Hosted Graphite 로드 밸런서에 새 연결이 붙지 못했다Hosted Graphite2018- 증상
금요일 밤 23:28 UTC에 모니터링이 웹사이트가 간헐적으로 응답하지 않는다고 알렸다. 웹사이트와 그래프 렌더링 API를 주기적으로 확인하는 검사가 타임아웃됐다.
- 촉발
AWS의 us-east1과 us-west2 리전에서 연결 문제가 생겨, 그 리전의 AWS 호스트가 Hosted Graphite 로드 밸런서에 맺은 연결이 끊기지는 않은 채 크게 느려졌다.
- 원인
- 구성 요소
- 기여 요인
- 감지
23:28 UTC에 웹사이트와 그래프 렌더링 API를 주기적으로 확인하는 모니터링 검사가 타임아웃되며 알렸다. 내부와 외부 카나리로 영향받은 수집 경로를 가렸다.
- 후속 조치
- 클라이언트 타임아웃을 더 엄격하게 적용한다.
- 로드 밸런서의 연결 한도를 높인다.
- 로드 밸런서 로그로 만든 활성 연결 수와 ISP별 요청 시간 히트맵을 SRE 팀과 지원 팀이 로드 밸런싱 계층 문제를 살필 때 늘 쓰는 도구로 삼았다.
- 교훈
분산 시스템에서는 한 서비스의 장애가 다른 서비스에 어떻게 영향을 줄지 알기 어렵다. 이번에는 직접으로도 간접으로도 쓰지 않는 사업자의 장애가 AWS 밖에 있는 서비스를 멈췄다. 연결을 끊지는 않고 느리게 만드는 네트워크 문제만으로도 느린 클라이언트가 로드 밸런서의 연결 한도를 다 차지해 다른 모든 클라이언트를 막을 수 있다. 로드 밸런서 로그를 충분히 남겨 두었기 때문에 활성 연결 수와 ISP별 요청 시간을 시각화해 원인을 밝힐 수 있었다.
이 4건에서 가장 많이 나오는 구성 요소: 온프레미스 로드 밸런서, 백본망. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.