GitHub는 8월 17일 플랫폼에 발생해 7시간 47분 동안 지속된 장애가 미국 중부 지역 데이터센터에서 트래픽이 사상 최고 수준에 도달했을 때 핵심 인프라 구성 요소가 확장에 실패하면서 발생했다고 밝혔다. 이로 인한 용량 압박이 여러 시스템으로 확산되면서 github.com, 인증, GitHub Actions, API, 풀 리퀘스트와 이슈, 그리고 Copilot이 영향을 받았으며, 장애의 영향은 전 세계 개발자와 조직으로 확대됐다.
이번 사고는 8월 6일 Actions에서 발생한 장애에 이어 GitHub가 8월에 겪은 두 번째 대규모 사건이다. 회사는 조사 결과 두 사건 모두 코드나 설정 변경과 관련이 없었으며, 핵심 원인은 용량 부족이었다고 설명했다. 수요가 처리 능력의 한계를 넘기 전에 핵심 구성 요소를 확장하지 못했다는 것이다. GitHub에 따르면 월간 푸시 횟수는 4월 14억 건에서 그 이후 29억 건으로 증가했지만, 회사는 사용량 증가가 장애를 방지할 책임을 면제해 주지는 않는다고 인정했다.
서비스는 어떻게 복구됐나?
복구 과정에서는 트래픽을 재라우팅하고, 영향을 받은 인프라를 격리하며, 서비스를 단계적으로 복원해야 했다. 대부분의 GitHub 서비스는 당일에 복구됐지만 일부 Copilot 서비스에는 더 오랜 시간이 걸렸다. 해당 서비스의 오류로 인해 클라이언트 측에서 재시도 루프가 발생했고, 복구 중 트래픽이 증가했다. 이에 팀은 트래픽을 안전하게 재라우팅하기 전에 이러한 동작을 제한해야 했다.
GitHub는 전체 근본 원인 분석 보고서에 상세한 기술 타임라인이 포함될 예정이며, 가용성과 신뢰성을 개선하기 위해 이전에 발표한 약속을 계속 이행하고 있다고 밝혔다.
실제로 무엇이 바뀌나?
GitHub의 계획은 용량 확대, 효율성 향상, 아키텍처 병목 제거에 초점을 맞춘다. 회사는 CPU 코어 300만 개 이상과 고속 스토리지 120페타바이트를 추가했으며, 네트워크 용량도 확대했다고 밝혔다. 또한 현재 데이터센터에서 사용할 수 있는 전력 범위 내에서 가능한 한 많은 하드웨어를 설치하는 동시에 Azure로의 이전을 가속하고 있다.
현재 Azure는 GitHub 플랫폼 부하의 약 58%와 Git 작업의 절반을 처리하고 있으며, 이는 5월 플랫폼 부하의 12%에서 증가한 수치다. 이러한 확장은 GitHub Actions 작업 실행 증가를 지원하는 데에도 도움이 됐다. 회사는 대규모 저장소의 읽기 용량을 읽는 사용자 수에 따라 선형적으로 확장할 수 있는 새로운 아키텍처를 개발하고 있으며, 이론적으로 무제한 읽기 작업을 가능하게 할 예정이다. 이 아키텍처는 가장 큰 모노레포지터리부터 단계적으로 배포를 시작할 계획이다.
장애 범위 축소와 폭풍 방지
GitHub는 확장만으로는 충분하지 않다고 보고 있다. 회사는 가용성을 위해 추가 팀과 자원을 배정했으며, 더욱 강력한 테스트, 더 안전한 배포 절차, 개선된 모니터링, 더욱 효과적인 알림에 투자했다. 또한 핵심 시스템을 격리하고 시스템 간 공유 의존성을 제거해 장애 발생 가능성을 낮추고, 장애가 발생하더라도 그 영향을 줄이고 있다.
회사는 8월 6일과 17일의 사고를 바탕으로 통합된 재시도 제한과 예산을 적용하고, 서비스 간 통신에 가변 시간 제한을 도입해 재시도 폭풍과 연쇄적인 부하를 방지할 예정이다. 또한 갑작스러운 트래픽 급증 중 장애가 발생할 수 있는 구성 요소를 발견하기 위해 우선순위가 낮은 CPU 및 메모리 알림을 재검토하고 있다. 이러한 조치는 소프트웨어를 구축하고 배포하며 운영하는 과정에서 GitHub에 의존하는 개발자와 조직에 직접적으로 중요하다. 플랫폼의 복구는 단순히 서비스를 복원하는 데 그치지 않고, 장애의 재발을 방지하고 장애가 발생했을 때 그 범위를 제한하는 것까지 포함하기 때문이다.