2026년 8월 17일부터 18일에 걸쳐 GitHub에서 전 세계 규모의 장애가 발생하여 GitHub.com과 GitHub Actions, GitHub Copilot 등 다수의 서비스를 이용하기 어려워졌습니다. GitHub는 8월 20일에 조사 결과를 발표하고, 과거 최고 수준의 트래픽에 대해 미국 중부 데이터센터에 있는 중요 인프라가 처리 능력을 확장하지 못해 장애가 연쇄적으로 확산되었다고 설명했습니다. The August 17 outage, and the work ahead - The GitHub Blog https://github.blog/news-insights/company-news/the-august-17-outage-and-the-work-ahead/ 장애는 일본 시간 기준 8월 17일 22시 28분경부터 8월 18일 6시 15분까지 7시간 47분에 걸쳐 지속되었습니다. 피크 시에는 웹 기능과 API에서 약 20%, 아카이브와 리포지토리의 원시 콘텐츠 다운로드에서는 약 50%의 오류가 발생했습니다. Issues와 Pull Requests, Actions, Copilot에 더해 인증 기능까지 영향이 확산되었습니다. GitHub가 전 세계에서 다운 - GIGAZINE
GitHub의 조사에 따르면 장애의 계기는 트래픽이 과거 최고 수준에 도달한 것이었습니다. 미국 중부 데이터센터에서는 서비스 간 통신을 중개하는 'Istio'의 사이드카라고 불리는 보조 컴포넌트가 동시 처리 수 상한에 도달했습니다. 하지만 자동으로 처리 능력을 늘리는 메커니즘이 본체 측 서비스의 상태만을 모니터링하고 있어 사이드카의 처리 상한을 고려하지 못했기 때문에 필요한 확장이 이루어지지 않았습니다. 용량 부족은 다른 설비로까지 파급되었습니다. 최종적으로 통신을 분배하는 4대의 'HAProxy'가 통신 처리 상한에 도달하여 GitHub 내부의 인증 경로에서 지연과 오류가 발생했습니다. 인증 기능은 다수의 GitHub 서비스에서 이용되기 때문에 GitHub.com과 Actions 등 넓은 범위로 장애가 연쇄되는 결과가 되었다는 것입니다.
또한 복구를 더욱 어렵게 만든 것은 통신에 실패했을 때 자동으로 통신을 재시도하는 '재시도'였습니다. 장애 발생 중에 대량의 재시도가 이루어지면서 내부 로드 밸런서에 대한 부하가 증가했을 뿐만 아니라, Visual Studio Code(VS Code)에는 GitHub Copilot 인증에 실패하면 대량의 재시도를 발생시키는 잠재적인 결함이 존재하고 있었습니다. Copilot의 인증 토큰을 처리하는 서비스에 대한 액세스는 평소 초당 7,000~9,000건에서 초당 7만~10만건까지 급증하여 Copilot의 복구가 다른 서비스보다 늦어지는 원인이 되었다고 합니다. GitHub는 8월 17일 장애에 대해 코드나 설정 변경이 직접적인 원인이었던 것은 아니며 "근본적으로는 용량 부족이었다"고 설명하고 있습니다. GitHub에서는 이용량 자체가 급증하고 있으며, 월간 커밋 수는 2026년 4월 14억 건에서 29억 건으로 약 4개월 만에 배로 증가했습니다. 아래 그림은 GitHub 이용 상황 추이를 나타낸 그래프입니다. 2023년 이후 1개월당 머지된 Pull Request, 신규 리포지토리, 커밋은 모두 급증하고 있으며, 2026년 8월에는 머지된 Pull Request가 약 1억 3,000만 건, 커밋이 약 29억 건, 신규 리포지토리가 약 2,400만 건에 달했습니다.
급증하는 이용량에 대응하기 위해 GitHub는 이전부터 인프라 증강을 추진해 왔습니다. 지금까지 300만 개 이상의 CPU 코어와 120PB의 고속 스토리지를 추가하고, 네트워크 용량도 대폭 증강했습니다. 기존 데이터센터에서는 이용 가능한 전력 범위 내에서 하드웨어를 증설하는 한편, Microsoft Azure로의 이전도 가속화하고 있습니다. 2026년 5월 시점에서 GitHub 전체 처리량에서 Azure가 차지하는 비율은 12%였으나, 이미 약 58%까지 증가했다고 합니다. Git 작업에 대해서도 약 절반을 Azure가 처리하고 있습니다. 인프라 확장은 GitHub Actions의 잡 실행 수 증가도 뒷받침하고 있으며, 2026년 초에는 수천만 건 규모였던 Actions 실행 수는 8월에는 1억 1,540만 건까지 증가했습니다.
GitHub는 거대한 리포지토리를 다룰 때의 성능 향상도 추진하고 있습니다. 거대한 리포지토리에서는 다수의 개발자나 시스템이 동시에 데이터를 읽어내기 때문에, 이용자가 늘어나도 읽기 처리를 효율적으로 늘릴 수 있는 구조가 필요합니다. GitHub는 Azure 인프라와 추가된 처리 능력을 활용해 대규모 리포지토리에 대한 대응을 진행하고 있으며, 높은 병렬도로 "git fetch"를 실행했을 경우의 처리 능력을 보여주는 그래프도 공개했습니다. GitHub는 다음 단계로 "읽기 측 수에 따라 처리 능력을 선형적으로 늘릴 수 있는 아키텍처를 도입하고, 우선 최대 규모의 리포지토리부터 단계적으로 전개할 예정"이라고 밝히며, 아래 그림의 그래프를 공개했습니다. 그래프에서는 왼쪽 예시에서 초당 약 1,000회 부근에 처리량이 머무르고 있는 반면, 오른쪽에서는 처리량이 단계적으로 증가해 초당 약 1,800회까지 늘어나고 있습니다.
GitHub는 처리 용량을 늘리는 것 외에도, 서비스 간 통신에서 재시도할 수 있는 양에 상한을 두어 대량의 재시도로 인해 부하가 더욱 증가하는 "재시도 스톰"을 방지하는 메커니즘을 도입하는 한편, 자동 확장 설정과 로드 밸런서의 용량 모니터링, VS Code의 재시도 동작 등도 재검토할 예정입니다. 중요한 시스템 간의 의존성을 줄이고, 일부 장애가 GitHub 전체로 확산되기 어렵게 하는 노력도 추진하겠다고 하고 있습니다. 또한, 시스템 변경의 속도나 복잡성에 기존 운용 방식이 따라가지 못했다고 하며 테스트와 안전한 배포, 모니터링, 알림 강화도 추진할 것이라고 합니다. GitHub 최고기술책임자(CTO)인 블라디미르 페도로프 씨는 급속한 이용량 증가는 시스템에 걸리고 있는 부하를 설명하는 것이기는 하지만, 장애에 대한 변명이 되지는 않는다고 설명했습니다. GitHub는 플랫폼 확장과 신뢰성 향상을 추진하여 이용자로부터의 신뢰를 되찾아가겠다고 밝혔습니다.
원문 보기 | 출처: Gigazine