GitHub에서는 사용자 급증을 원인으로 하는 인프라 장애가 자주 발생하고 있습니다. 최근에는 거의 매일 발생하고 있으며, GitHub의 장애 이력을 기록하는 'Is GitHub Cooked？(GitHub은 끝났나？)'에서 그 빈도를 잘 알 수 있습니다. Is GitHub Cooked?https://isgithubcooked.com/ Is GitHub Cooked？에서는 지난 3개월에 걸친 GitHub의 인시던트 및 다운타임 이력이 시각화되어 있습니다. 인시던트는 '없음', '마이너', '메이저', '크리티컬', '지속 중'의 5가지로, 다운타임은 발생한 길이별로 색상이 구분되어 있습니다. 하나의 사각형이 하루를 나타내는데, 이렇게 보면 거의 매일 장애가 발생하고 있음을 알 수 있습니다.
Is GitHub Cooked？에 따르면, GitHub에서는 2016년 3월 이후 1128건의 인시던트가 발생했으며, 지난 3개월 동안 월평균 24.3건에 달한다고 합니다. 이 6년 동안 인시던트가 발생하지 않은 최장 기간은 8일이며, 가장 많은 인시던트가 발생한 달은 2026년 2월로 37건이었습니다. 2026년 8월 17일에는 대규모 장애가 발생했습니다. 이 날은 GitHub의 장애 발생 보고부터 해결까지 거의 7시간이 걸렸고, 많은 서비스에서 오류 또는 성능 저하가 확인되었습니다. 이 건에 대해 GitHub는 '트래픽이 사상 최고 수준에 도달한 것이 계기였다'고 보고했으며, 월간 커밋 수가 2026년 4월 14억 건에서 8월 29억 건으로 두 배로 증가했다고 덧붙였습니다. GitHub가 약 8시간 다운된 원인이 판명, 급증하는 사용량에 중요한 인프라가 자동 확장되지 못해 장애가 연쇄 발생 - GIGAZINE
AI 기술이 발전함에 따라 GitHub의 이용량도 급증하고 있으며, GitHub는 종종 용량 부족으로 어려움을 겪고 있습니다. 이전에는 GitHub를 운영하는 Microsoft가 해결을 위해 움직이고 있다고 보도된 바 있습니다. GitHub에서 연이어 수십 건의 대규모 장애가 발생하자 Microsoft는 라이벌 AWS에 협력을 요청하게 되었고, AI 주도 성장으로 인프라에 엄청난 부하가 걸리고 있기 때문입니다 - GIGAZINE
참고로, Is GitHub Cooked？와 같은 형식으로 장애를 기록하는 'Red Squares'라는 서비스도 있습니다. GitHub의 지난 1년간 다운타임을 '잔디' 형식으로 시각화하는 'Red Squares' - GIGAZINE
원문 보기 | 출처: Gigazine