GitHub 가용성에 대한 업데이트

최근 두 가지 사건을 고려하여 GitHub 의 가용성에 대해 업데이트를 하고자 합니다. 이 두 사건은 모두 용납될 수 없으며, 이로 인해 발생한 영향에 대해 사과드립니다. 이에 대한 세부 사항을 공유하고, 신뢰성을 개선하기 위해 무엇을 했는지 그리고 무엇을 하고 있는지 설명하고자 합니다.

우리는 2025 년 10 월부터 GitHub 의 용량을 10 배로 늘리는 계획을 실행하기 시작하여 신뢰성과 장애 조치 (failover) 를 크게 개선하는 것을 목표로 했습니다. 2026 년 2 월까지 현재 규모의 30 배가 필요한 미래를 위한 설계를 해야 함이 명확해졌습니다.

주된 동인은 소프트웨어 구축 방식의 급격한 변화입니다. 2025 년 12 월 하반기 이후 에이전틱 개발 워크플로 (agentic development workflows) 가 급격히 가속화되었습니다. 거의 모든 지표에서 방향은 이미 명확합니다: 리포지토리 생성, 풀 리퀘스트 활동, API 사용량, 자동화, 대용량 리포지토리 작업량이 모두 빠르게 성장하고 있습니다.

이 지수적 성장은 한 번에 하나의 시스템만 스트레스를 받지 않습니다. 하나의 풀 리퀘스트는 Git 저장소, 병합 가능성 검사, 브랜치 보호, GitHub Actions, 검색, 알림, 권한, 웹훅, API, 백그라운드 작업, 캐시, 데이터베이스 등을 모두 접촉할 수 있습니다. 고 규모에서 작은 비효율은 누적됩니다: 큐가 깊어지고, 캐시 미스가 데이터베이스 부하로 이어지며, 인덱스가 뒤처지고, 재시도가 트래픽을 증폭시키며, 하나의 느린 의존성이 여러 제품 경험에 영향을 줄 수 있습니다.

우리의 우선순위는 명확합니다: 가용성 (availability) 이 먼저이며, 다음으로 용량 (capacity), 그다음 새로운 기능입니다. 불필요한 작업을 줄이고, 캐싱을 개선하며, 핵심 서비스를 격리하고, 단일 고장 지점 (single points of failure) 을 제거하고, 성능에 민감한 경로를 이러한 워크로드를 위한 시스템으로 이동시키고 있습니다. 이는 분산 시스템 작업입니다: 숨겨진 결합도를 줄이고, 폭발 반경 (blast radius) 을 제한하며, 하나의 하위 시스템이 압력을 받을 때 GitHub 가 부드럽게 저하되도록 만드는 것입니다. 우리는 빠르게 진전을 이루고 있지만, 이 사건들은 아직 해야 할 일이 남아있음을 보여주는 예시입니다.

우리가 하고 있는 일

단기적으로는 웹훅을 다른 백엔드 (MySQL 에서) 로 이동하고, 사용자 세션 캐시를 재설계하여 인증 및 권한 부여 흐름을 다시 설계하여 데이터베이스 부하를 크게 줄이는 등 예상보다 빠르게 나타나는 다양한 병목 현상을 해결해야 했습니다. 또한 Azure 로의 마이그레이션을 활용하여 훨씬 더 많은 컴퓨팅 자원을 구축했습니다.

다음으로 우리는 Git 과 GitHub Actions 와 같은 핵심 서비스를 다른 워크로드에서 격리하고, 단일 고장 지점을 최소화하여 폭발 반경을 최소화하는 데 집중했습니다. 이 작업은 의존성과 트래픽의 다른 계층을 신중하게 분석하여 무엇을 분리해야 하는지 이해하고, 다양한 공격으로부터 합법적인 트래픽에 미치는 영향을 최소화하는 방법을 파악하는 것으로 시작되었습니다. 그런 다음 위험도에 따라 순서대로 해결했습니다. 마찬가지로, Ruby 모놀리식 아키텍처에서 성능이나 규모에 민감한 코드를 Go 로 마이그레이션하는 일부를 가속화했습니다.

우리는 이미 작은 커스텀 데이터 센터에서 퍼블릭 클라우드로의 마이그레이션을 진행 중이었으나, 멀티 클라우드 (multi cloud) 로의 경로를 위한 작업을 시작했습니다. 이 장기적인 조치는 미래에 필요한 수준의 복원력, 저 지연 시간, 유연성을 달성하는 데 필수적입니다.

GitHub 의 리포지토리 수는 이전보다 빠르게 증가하고 있지만, 훨씬 더 어려운 확장 과제는 대형 모노레포 (large monorepos) 의 등장입니다. 지난 3 개월 동안 우리는 Git 시스템과 풀 리퀘스트 경험 내에서 이 트렌드에 대응하기 위해 막대한 투자를 해왔습니다.

우리는 곧 수행한 광범위한 작업과 더 큰 효율성과 규모를 위한 새로운 API 설계에 대해 설명하는 별도의 블로그 게시물을 발표할 예정입니다. 이 작업의 일환으로, 하루에 수천 개의 풀 리퀘스트가 있는 리포지토리에 핵심적인 병합 큐 (merge queue) 운영을 최적화하는 데 투자했습니다.

최근 사건

최근 두 가지 사건은 원인과 영향이 달랐지만, 모두 가용성, 격리, 폭발 반경 감소를 더 중시하게 된 이유를 반영합니다.

4 월 23 일 병합 큐 사건

4 월 23 일, 풀 리퀘스트에서 병합 큐 운영에 영향을 미치는 회귀 (regression) 가 발생했습니다.

풀 리퀘스