GitHub가 월간 커밋 74억 건에 맞춰 인프라를 늘렸다

월간 커밋 74억 건에 맞춰 GitHub가 인프라를 키웠습니다. 올해 중앙처리장치(CPU) 코어 400만 개와 고속 저장공간 160페타바이트를 추가했습니다. GitHub는 에이전트 수요가 급증의 큰 원인이라고 설명합니다. 장애가 반복된 서비스에서 제가 오래 붙드는 대목은 증설 규모와 함께 플랫폼 구조도 손본다는 점입니다. 증설 숫자만으로 이용자가 겪는 멈춤이 줄었다고 단정할 수는 없습니다.

GitHub는 데이터베이스 부하와 GitHub Actions 처리 비용을 낮췄습니다. 하지만 지역 이전 지연과 9월 데이터베이스·Copilot 코드 리뷰 장애도 겪었습니다. 그 경험은 이번 증설을 읽을 때 처리 용량과 실제 안정성을 따로 보게 합니다.

반가운 점은 지금 늘어난 자원과 앞으로 바꿀 구조를 함께 내놓았다는 것입니다. GitHub는 GitHub Actions용 연산 용량과 네트워크 용량 50Tb/s를 추가했습니다. 컴퓨팅과 저장공간을 분리하는 계획도 다시 밝혔습니다. 급증하는 작업을 받아내려는 대응이 서버 증설에서 저장 방식까지 넓어집니다.

회사 내부 벤치마크에서 새 구조는 쓰기 처리량(write throughput)을 최대 35배 높일 수 있는 것으로 나왔습니다. 최대 35배는 내부 시험값이며, 실제 서비스의 대기시간이나 장애가 같은 폭으로 개선됐다는 뜻은 아닙니다. GitHub는 자체 데이터센터 용량이 부족해 Azure와 그 서비스를 활용하는 것이 사실상 유일한 선택이었다고 설명합니다. 이 대목에서 제게 남는 것은 증설의 크기만이 아니라, 자체 데이터센터 바깥의 Azure까지 동원해야 했다는 점입니다.

GitHub Actions를 쓰신다면 비슷한 작업을 돌린 최근 실행의 대기시간을 이전 기록과 비교해 보십시오. 대기시간이 꾸준히 짧아졌다면 용량 확장이 내 작업에도 닿은 신호이고, 그대로라면 아직 체감 변화가 없는 것입니다.

GitHub Actions가 느려지거나 실패할 때, 평소 어떤 기록부터 확인하십니까?