GitHub 8월 서비스 저하 사고 다섯 건

GitHub가 9월 10일 새로 낸 8월 가용성 보고서는 당시 서비스를 저하시킨 사고를 다섯 건으로 집계했습니다. GitHub는 가용성을 먼저, 용량을 다음, 기능을 마지막에 두고 Azure 이전과 용량 보강, 재시도·자동 확장·장애 조치 체계를 개선하겠다고 밝혔습니다.

인증과 공유 인프라에서 장애가 번졌다

GitHub 설명에 따르면 8월 6일 Actions 사고는 정기 배포로 한 사이트의 용량이 잠시 줄어든 뒤 트래픽이 다른 사이트로 몰리면서 시작됐습니다. 서비스 메시 사이드카가 CPU와 메모리 한계에 닿아 캐시·DNS·API 오류가 연쇄적으로 발생했고, 잠재돼 있던 작업 할당 재시도 버그가 복구를 늦췄습니다.

8월 17일에는 피크 트래픽이 한 데이터센터의 로드 밸런서를 압박하고 사이드카가 제때 확장되지 않으면서 공용 인증이 흔들렸다고 GitHub는 설명했습니다. 이슈와 풀 리퀘스트, API, Actions, Copilot 등이 영향을 받았고 클라이언트 재시도 버그는 인증 엔드포인트로 향하는 트래픽을 더 키웠습니다. 8월 26일에는 한계에 가까웠던 공유 데이터베이스에 이벤트가 몰렸지만 초기에 부하를 줄일 자동 회로 차단기가 없어 수동으로 스로틀링을 조정했습니다.

멈춘 실행과 늦게 나타난 결과

10시간 42분 이어진 8월 6일 사고에서는 일부 이벤트를 자동 재생할 수 없어 다시 실행해야 했습니다. 8월 26일에는 밀린 Actions 실행이 대체로 백로그 해소 뒤 시작됐지만, 초기의 일부 실행은 새로 시작해야 했다고 GitHub는 밝혔습니다.

8월 20일 Copilot Cloud Agent 사고는 9시간 54분 동안 이어졌습니다. GitHub에 따르면 공급자 측 지역 장애가 작업 상태와 결과를 담는 관리형 데이터베이스에 영향을 줬습니다. 작업 자체는 완료돼 유실되지 않았지만 표시가 늦어졌고, 최소 54개 조직에서 비정상적으로 큰 지연이 나타났으며 분당 측정 활동 기준 영향은 최대 37.5%였습니다. 8월 27일에는 외부 모델 공급자의 성능 저하로 Kimi K3 요청의 절반 이상이 한때 실패했지만, 다른 모델과 Auto 라우팅은 영향을 받지 않아 재시도하거나 모델을 바꾸면 성공할 수 있었습니다.

Azure 이전과 단기 용량 확보

GitHub는 대응 우선순위를 가용성, 용량, 기능 순으로 두고 아키텍처 투자와 Azure 이전을 진행한다고 밝혔습니다. 8월 11일에는 처음으로 Azure에서 프로덕션 MySQL 주 서버를 가동했고, 전환 중 고객 영향 없이 클라이언트가 관찰한 쓰기 영향도 최소였다고 설명했습니다. 같은 방식을 8월 27일 두 개 주 서버에 더 적용했으며, 이전된 서비스의 읽기 트래픽은 Azure에서 최대 60.4%, 모놀리스 읽기는 64.3%, Git 읽기는 54%에 도달했습니다.

또 GitHub는 Actions 작업 33%를 여유 용량이 있는 클러스터로 돌려 캐시 CPU 피크를 98%에서 80%로 낮추고 약 3개월의 여유를 확보했다고 밝혔습니다. 다만 이를 최종 해결책이 아닌 단기 억제책으로 규정했습니다. 재시도와 자동 확장, 회로 차단기, 공급자 장애 조치 체계도 개선 대상으로 제시했습니다.