GitHub는 2026년 9월 가용성 보고서에서 서비스 성능에 영향을 미친 두 건의 사고와 함께 인프라 재분배 및 데이터베이스의 부하 내성 개선 현황을 공개했다. 회사는 높은 부하나 공유 구성 요소 중 하나의 장애가 발생했을 때 장애 위험을 줄이기 위한 변경 사항을 시행했지만, 복구 작업은 아직 완료되지 않았다고 밝혔다.
10월 7일 기준으로 160개의 프로덕션 서비스 중 120개가 Central US 리전에 배포되었으며, 51개의 핵심 MySQL 데이터베이스 중 13개가 이전되었다. Azure는 기본 GitHub 애플리케이션의 읽기 트래픽 중 65.4%, Git 읽기 트래픽의 48.3%, 스트림 처리 트래픽의 80.2%를 처리했다. 회사는 이 비율이 서로 다른 워크로드에 해당하므로 합산해서는 안 된다고 강조했다.
예정보다 늦어진 인프라 이전 진전
GitHub는 가용 영역 간 용량 불균형으로 인해 9월 11일 Central US에서 배포와 트래픽 증가를 중단했다. 9월 18일 임시 용량을 확보한 후 영구적인 증가 작업을 재개했지만, 장기적인 용량 확보 작업은 여전히 진행 중이며 10월 말까지 사용 가능한 전체 용량을 제공하는 것을 목표로 하고 있다. 회사는 9월 30일까지 모든 프로덕션 서비스를 해당 리전에 배포한다는 야심 찬 목표를 달성하지 못했다.
계획된 데이터베이스 전환 과정에서 자동화된 긴급 조치가 Central US의 데이터베이스 복제본을 분리했고, 이로 인해 해당 지역 고객에게 장애가 발생했다. GitHub는 복구 메커니즘을 개선할 때까지 계획된 인계 작업 중 이 조치를 비활성화했다.
데이터베이스 부하 감소 및 장애 격리
GitHub는 기본 인증 시스템의 테이블 24개를 가장 오래된 공유 데이터베이스에서 분리했고, 그 결과 복제본에서 초당 약 100만 건의 쿼리가 제거되었다. 또한 Issues와 Pull Requests를 지원하는 클러스터의 변경 이력에서 불필요한 레코드 약 9억 8,000만 개를 삭제해 복구 가능한 스토리지 약 1.8테라바이트를 확보했다. 트랜잭션 충돌은 6월 최고치와 비교해 주간 기준 약 77% 감소했다.
샘플에 포함된 Pull Requests 트래픽의 절반은 공유 종속성이 중단되어도 제한된 기능으로 계속 처리될 수 있게 되었다. 데이터베이스 트래픽 라우팅은 급증 시 자동으로 용량을 추가할 수도 있다. 실제로 9월 23일 Pull Requests 활동이 증가했을 때 한 클러스터가 복제본 14개에서 19개로 확장되었다. GitHub는 서비스가 더 광범위한 포화 상태에 도달하기 전에 우선순위가 낮은 요청을 거부할 수 있는 부하 제어 메커니즘도 추가했다.
9월의 두 사고
9월 13일 백그라운드 데이터 정리 작업으로 인해 공유 데이터베이스의 부하가 증가했다. 보호 메커니즘은 복제본 지연을 모니터링했지만, 사용 가능한 연결 한도에 도달한 기본 서버에 누적된 부하는 모니터링하지 않았다. 짧은 쿼리 시간 제한이 없어 요청 처리기가 대기 상태로 남았고, 재시도 루프가 실패한 쓰기 작업을 계속 전송했다. 사고는 1시간 28분 동안 지속되었으며, 내부 부하를 낮추고 해당 작업을 중단한 후 종료되었다.
9월 28일 Copilot 코드 리뷰를 실행하는 서비스의 변경으로 인해 일부 고객에게 댓글이 포함된 전체 버전 대신 제한된 리뷰 결과의 복사본이 전송되었다. 그 결과 풀 리퀘스트에 리뷰가 표시되지 않았는데도 작업이 완료된 것처럼 보였다. 사고는 52분 동안 지속되었고, GitHub는 변경 사항을 되돌려 처리했으며 영향을 받은 리뷰를 고객에게 다시 요청하도록 안내했다.
실질적으로 무엇이 바뀌는가?
두 사고는 용량 개선만으로는 충분하지 않다는 점을 보여준다. 안정성은 장애를 조기에 감지하고, 유용하지 않은 재시도 작업을 중단하며, 출력 결과가 실제로 전달되기 전에 작업을 성공으로 선언하지 않는 데에도 달려 있다. GitHub는 백그라운드 처리 제어를 추가하고, 서비스 시작 동작을 개선하며, Copilot 코드 리뷰 결과의 모니터링과 전달을 강화하고 있다.
GitHub Actions 전용 인프라에서도 개선이 기록되었다. 측정된 Redis 작업은 약 28%, 상대적인 프로세서 사용량은 약 30% 감소했다. 별도의 캐시 계층은 Redis가 사용하는 대역폭을 84%, 평균 응답 시간을 66%, 핵심 재고 요청의 중앙값 응답 시간을 96%, 대기 중인 요청을 95% 줄였다. 아직 해결되지 않은 문제는 회사가 용량 작업을 완료하고 실제 프로덕션 환경에서 공유 종속성 장애가 재발하는 것을 막을 수 있는지와 관련되어 있다.