그래프
사례3건
3건 중 1~3번째
- 증상
자동 모니터링이 오류 증가를 잡아 사고 대응이 시작됐다. 이슈와 풀 리퀘스트의 페이지와 API 가 오류를 내거나 느리게 응답했고, 같은 데이터센터의 로드 밸런서를 지나는 다른 서비스들도 오류와 지연을 보였다.
- 촉발
트래픽이 새 최고치를 찍으면서 한 데이터센터의 로드 밸런서가 한계를 넘었다. 서비스 메시 사이드카 하나가 동시 처리 한도에 닿았는데도 확장되지 않았다.
- 원인
- 구성 요소
- 기여 요인
- 감지
자동 모니터링이 오류 증가를 잡아 사고 대응이 시작됐다. 영향받은 제품은 공개 상태 페이지에 degraded 로 표시됐다.
- 조치
- 트래픽 일부를 다른 데이터센터로 옮기기 시작했다.
- 부담을 덜려고 게이트웨이의 재시도를 줄였다.
- 포화된 노드의 로드 밸런서 프로세스를 멈췄다.
- 재시도를 일으키는 요청 가운데 가장 영향을 많이 받은 내부 엔드포인트로 가는 요청을 막았다. 이 조치와 로드 밸런서 프로세스 중지로 서비스 전반이 곧바로 회복됐다.
- 클라이언트 재시도가 트래픽을 부풀려 인증 오류가 남아 있었다. 엔지니어들은 트래픽을 천천히 다시 올리면서 이 오류를 가라앉혔다.
- 후속 조치
- 오토스케일링 정책이 호스트 서비스만이 아니라 서비스 메시 사이드카의 동시 처리 수와 용량도 따지도록 고친다.
- 영향받은 서비스 전반에서 서비스 메시의 요청 한도, 동시 처리 한도, 스케일링 한도를 점검한다.
- 일부 구간의 성능 저하가 더 넓은 과부하로 커지지 않도록 게이트웨이와 클라이언트 전반의 재시도와 백오프 한도를 다시 살핀다.
- 사고 동안 인증 트래픽을 부풀린 클라이언트 재시도 동작을 고친다.
- 로드 밸런서 용량 모니터링을 개선한다.
- 리전 페일오버 안전장치를 강화한다.
- 교훈
GitHub 는 핵심 약점을 두 가지로 봤다. 서비스 메시 사이드카가 확장되지 않은 것과 재시도 동작이다. 클라이언트에 충분한 제한이 없어서 일부 구간의 성능 저하가 더 넓은 과부하로 커지는 것을 막지 못했다.
- 증상
2026-08-06 15:05 UTC 부터 GitHub Actions 워크플로 실행이 시작하지 못하거나 도중에 실패했고, 일부 Actions REST API 요청이 오류를 냈다. 일부 고객은 워크플로에서 예상하지 못한 rate limiting 을 겪었다.
- 촉발
이벤트를 처리하고 Actions 작업을 만드는 Actions 내부 서비스에 일상 배포를 했다. 배포로 파드가 교체되는 동안 남은 용량이 포화됐다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 용량을 늘렸고, 처음 무너진 서비스들은 17:00 에 회복했다.
- 시스템이 회복할 수 있게 웹훅으로 들어오는 작업을 줄였다. 한때 웹훅의 약 15% 만 처리했다.
- 밀린 이벤트를 처리할 용량을 늘렸다.
- 러너가 유효하지 않은 작업을 되풀이해 가져가려 하지 않도록 하는 변경을 배포했다.
- 작업을 가져가지 못하던 자체 호스트 러너를 위한 수정을 배포하고 조금씩 켰다.
- 완화 작업에 도움이 되도록 GitHub Enterprise Importer 마이그레이션을 멈췄다.
- 웹훅으로 시작하는 Actions 워크플로를 전체 처리량으로 되돌렸다.
- 완화 조치 하나 때문에 오프라인으로 남은 Actions Runner Controller 러너는 손으로 복구했고, 그 변경은 나중에 롤백했다.
- 재시도도 취소도 되지 않는 작업을 고객이 정리할 수 있는 CLI 와 UI 방법을 GitHub 커뮤니티 토론 글로 공유했다.
- 후속 조치
- 영향받은 서비스의 배포 안전장치와 용량 안전장치를 개선한다.
- 이번 장애에 앞서 나타난 조건을 잡아내도록 모니터링을 강화한다.
- 장애가 나도 큐에 쌓인 작업과 러너 배정이 버티고 빨리 복구되도록 개선한다.
- 다음 Actions Runner 와 Actions Runner Controller 릴리스에 자동 복구를 넣어 손으로 하는 조치가 필요 없게 한다.
- 대규모 Actions 장애에서 연쇄 장애가 번질 위험을 줄이고 복구를 앞당기는 개선을 더 한다.
- 증상
2022년 3월 16일 14:09 UTC, 최대 부하 시간대에 mysql1 데이터베이스의 부하가 늘면서 데이터베이스 프록시가 최대 연결 수에 닿았다. GitHub 의 모든 쓰기 작업이 동작하지 않았다.
- 촉발
최대 부하 시간대에 공용 MySQL 클러스터 mysql1 의 부하가 늘어 데이터베이스 프록시가 최대 연결 수에 닿았다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 정상인 복제본으로 페일오버해 3월 16일 장애에서 복구했다.
- 3월 17일 미리 한 페일오버 뒤 새 주 노드에 생긴 연결 문제를 풀려고 연결을 재설정했다.
- 3월 17일 장애 중에 부하 패턴을 찾아 인덱스를 추가해 주된 성능 문제를 고쳤다.
- 3월 22일 클라이언트 연결이 실패하자 다시 주 노드를 페일오버해 복구했다.
- 3월 23일 같은 부하 특성으로 클라이언트 연결이 실패하자 다시 주 노드를 페일오버해 복구했다.
- 3월 23일 부하를 줄이려고 웹훅 트래픽을 제한했다.
- 후속 조치
- 다른 대책을 더 찾는 동안 최대 부하 시간대에 웹훅 트래픽 제한을 계속 써서 같은 장애가 다시 나지 않게 한다.
- 최대 부하 시간대의 mysql1 부하 패턴을 점검하고, 그 결과에 따라 성능 수정을 차례로 한다.
- 부하를 줄이고 페일오버 시간을 줄이려고 mysql1 의 트래픽을 다른 데이터베이스로 옮긴다.
- 변경 관리 절차를 검토한다. 특히 운영 환경에 부하가 높을 때의 모니터링과 변경을 살핀다.
- 플랫폼 성장에 맞춰 데이터베이스 샤딩과 하드웨어 확장을 비롯한 인프라 확장을 이어 간다.
이 3건에서 가장 많이 나오는 구성 요소: CI 시스템, 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.
원인별1
용량 한계3건
- 조직