사례2건
2건 중 1~2번째
- 증상
자동 모니터링이 오류 증가를 잡아 사고 대응이 시작됐다. 이슈와 풀 리퀘스트의 페이지와 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 을 쓰도록 바꾼다.
- 교훈
장애를 해결하는 방법은 원인을 분석하다 보면 쉽게 보일 때가 많다. 그러나 원인을 정확히 확인하지 않으면 잠재적인 위험을 안은 채 서비스를 운영하게 된다. 우아한형제들은 장애 해결을 최우선으로 다루면서도, 재발을 막으려고 근본 원인을 찾아내는 과정을 중요하게 여긴다.
이 2건에서 가장 많이 나오는 구성 요소: 온프레미스 로드 밸런서, NAT 게이트웨이. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.