GitHub 가용성에 대한 업데이트

• 최근 두 차례 장애 이후 GitHub는 가용성을 최우선에 두고, 급증한 개발 워크로드와 agentic development workflows에 맞춰 인프라와 구조를 다시 손보고 있음
• pull request 하나도 Git 저장소, Actions, 검색, 알림, 권한, webhooks, APIs, 백그라운드 작업, 캐시, 데이터베이스까지 넓게 연결돼 있어, 작은 비효율이 커지면 큐 적체와 의존성 전파로 이어질 수 있음
• 단기적으로는 webhooks의 백엔드 이전, 사용자 세션 캐시 재설계, 인증·권한 부여 흐름 조정, Azure 기반 컴퓨트 확대로 병목과 데이터베이스 부하를 줄이는 데 집중 중임
• 장기적으로는 핵심 서비스 격리, 단일 장애점 축소, Ruby monolith 일부의 Go 이전, public cloud 전환과 multi cloud 경로 확보를 통해 회복력과 유연성을 높이고 있음
• 4월 23일 merge queue 회귀와 4월 27일 Elasticsearch 과부하 모두 데이터 손실은 없었고, GitHub는 status page에 availability 수치를 넣고 작은 장애까지 공개 범위를 넓히며 투명성도 함께 강화 중임

가용성 대응 배경

• GitHub는 최근 두 차례 장애 이후 가용성과 신뢰성 개선 작업 현황을 정리함
• 2025년 10월부터 용량 10배 확대 계획을 실행했으며, 2026년 2월에는 현재 규모의 30배를 전제로 설계해야 할 필요가 분명해짐
• 소프트웨어 개발 방식 변화가 주요 배경이며, 2025년 하반기 이후 agentic development workflows가 급격히 가속됨
• 저장소 생성, pull request 활동, API 사용량, 자동화, 대형 저장소 워크로드가 모두 빠르게 증가 중임

확장 과정에서 드러난 구조적 부담

• pull request 하나가 Git 저장소, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, databases까지 함께 건드릴 수 있음
• 높은 규모에서는 작은 비효율도 누적돼 큐 적체, 캐시 미스의 데이터베이스 부하 전환, 인덱스 지연, 재시도 트래픽 증폭, 느린 의존성의 다중 제품 영향으로 이어질 수 있음
• 우선순위는 가용성 우선, 그다음 용량, 그다음 신규 기능으로 정리됨
• 불필요한 작업 감소, 캐시 개선, 핵심 서비스 격리, 단일 장애점 제거, 성능 민감 경로의 전용 시스템 이전을 병행 중임
• 한 서브시스템에 압력이 걸려도 전체가 무너지지 않도록 숨은 결합도 축소와 blast radius 제한, graceful degradation 확보가 핵심 과제가 됨

현재 진행 중인 개선 작업

• 단기적으로는 예상보다 빠르게 드러난 병목 해소에 집중함
• webhooks를 MySQL 밖의 다른 백엔드로 이동했고, 사용자 세션 캐시를 재설계했으며, 인증·권한 부여 흐름도 다시 손봐 데이터베이스 부하를 크게 줄임
• Azure 이전을 활용해 더 많은 컴퓨트 자원도 확보함
• 이후에는 git과 GitHub Actions 같은 핵심 서비스 격리와 단일 장애점 축소에 집중함
• 의존성과 트래픽 계층을 세밀하게 분석해 무엇을 분리해야 하는지 파악했고, 각종 공격이 정상 트래픽에 미치는 영향을 최소화하는 방향으로 위험도 순서에 따라 조치함
• 성능이나 규모에 민감한 코드 일부를 Ruby monolith에서 Go로 이전하는 작업도 가속함
• 기존의 소규모 자체 데이터센터에서 public cloud로 옮기는 작업을 진행하던 중, 더 장기적으로는 multi cloud 경로도 함께 추진하기 시작함
• 이 장기 조치는 앞으로 필요한 회복력, 낮은 지연 시간, 유연성을 확보하는 데 필요함

대형 저장소와 merge queue 대응

• 저장소 수 증가보다 더 어려운 확장 과제로 대형 monorepo 증가를 꼽음
• 최근 3개월 동안 git 시스템과 pull request 경험 양쪽에서 이 추세에 대응하는 투자를 크게 늘림
• 더 높은 효율과 확장성을 위한 새 API 설계 관련 작업도 진행 중이며, 별도 블로그 글로 공개할 예정임
• 하루 수천 건의 pull request가 발생하는 저장소에 중요하다는 점에서 merge queue 작업 최적화에도 투자함

최근 장애 1: 4월 23일 merge queue 문제

• 4월 23일에는 pull request의 merge queue 동작 회귀가 발생함
• squash merge 방식을 쓰는 merge queue에서, merge group에 pull request가 둘 이상 포함되면 잘못된 merge commit이 생성됨
• 영향받은 경우 이후 병합이 앞서 병합된 pull request와 기존 커밋의 변경을 의도치 않게 되돌리는 상태로 이어짐
• 영향 구간 동안 658개 저장소와 2,092개 pull request가 영향을 받음
• 초기 수치는 보수적으로 잡았기 때문에 처음 공유한 수치가 이보다 약간 높았음
• merge queue 밖에서 병합된 pull request에는 영향이 없었고, merge 또는 rebase 방식을 쓰는 merge queue 그룹도 영향받지 않음
• 데이터 손실은 없었음. 모든 커밋은 Git에 저장된 상태로 남아 있었음
• 다만 영향받은 저장소의 기본 브랜치 상태는 잘못됐고, 모든 저장소를 자동으로 안전하게 복구할 수는 없었음
• incident root cause analysis: 추가 세부 사항을 볼 수 있음
• 이번 장애로 여러 프로세스 실패가 드러났고, 같은 종류의 문제가 재발하지 않도록 해당 프로세스를 바꾸는 중임

최근 장애 2: 4월 27일 검색 관련 문제

• 4월 27일에는 여러 검색 기반 경험을 담당하는 Elasticsearch 서브시스템 장애가 발생함
• 영향 범위에는 pull requests, issues, projects의 일부 검색 기반 UI가 포함됨
• 근본 원인 분석은 아직 마무리 중이며 곧 공개될 예정임
• 현재까지 파악된 바로는 클러스터가 과부하 상태가 됐고, 그 결과 검색 결과를 반환하지 못하게 됨
• 과부하 원인으로는 botnet attack일 가능성도 열려 있지만, 근본 원인 분석은 아직 완료되지 않음
• 데이터 손실은 없었고, Git 작업과 APIs는 영향받지 않음
• 다만 검색에 의존하는 UI 일부는 결과를 전혀 표시하지 못해 큰 혼란을 일으킴
• 이 시스템은 단일 장애점을 없애기 위한 완전한 격리가 아직 끝나지 않은 영역이었고, 그전까지는 다른 영역의 위험 우선순위가 더 높았음
• 같은 방식의 의존성 분석과 blast radius 축소 작업을 적용해 이런 실패의 가능성과 영향을 줄이는 중임

장애 투명성 강화

• 장애 중 고객이 더 큰 투명성을 원한다는 점이 분명해짐
• 최근 GitHub status page를 업데이트해 availability 수치를 포함하도록 바꿈
  • 관련 업데이트
• 큰 장애뿐 아니라 작은 장애도 status에 올리기로 했으며, 사용자가 문제가 자기 측인지 GitHub 측인지 추측하지 않도록 하려는 목적임
• 장애 분류 방식도 계속 개선 중이며, 규모와 범위를 더 쉽게 이해할 수 있게 만드는 중임
• 장애 중 고객이 신호를 공유하고 문제를 보고하는 방식도 더 낫게 만드는 작업을 함께 진행 중임

앞으로의 약속

• GitHub는 가용성 개선, 회복력 확대, 미래 소프트웨어 개발 규모에 맞는 확장, 더 투명한 커뮤니케이션을 약속함
• 4월 23일 장애의 영향 저장소 수는 2026년 4월 28일 기준으로 업데이트됨