▲

GitHub 가용성에 대한 업데이트

 (github.blog)
2P by GN⁺ 21시간전 | ★ favorite | 댓글 2개
  • 최근 두 차례 장애 이후 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일 기준으로 업데이트됨

함께 보면 좋은 글 β

▲
xguru 4시간전  [-]

에러가 너무 많이 나니 급하게 아예 공지를 한거군요.
근데 너무 늦은거 아닌가 하는 생각이..
이미 에러가 너무 많이 나서 다들 이탈한다고 얘기중인데요 ㅠ

답변달기
▲
GN⁺ 21시간전  [-]
Hacker News 의견들

  • GitHub는 올해 들어서만도 수십 차례 장애를 냈고, 작년보다도 가용성과 신뢰성이 눈에 띄게 나빠졌음
    이 정도면 대시보드와 히트맵이 돌 정도로 심각하고, HN이나 Reddit 같은 곳에서 GitHub 불안정성이 밈이 될 수준까지 왔다고 봄
    그런데도 우선순위가 "availability, capacity, new features"라고 말하는 건 현실 인식이 너무 느슨함
    지금 우선순위는 1, 2, 3 전부 availability여야 하고, 최소 6개월은 다른 얘기 꺼내지 말고 그것만 고쳐야 함

  • 6개월 전에는 Azure 이전이 최우선이라며 기능 개발을 미루겠다고 하더니, 지금은 또 가용성이 최우선이라고 하니 앞뒤가 잘 안 맞음
    당시엔 AI와 Copilot 수요 때문에 버지니아 데이터센터 용량 제약이 "existential"하다고 했는데, 아직도 같은 문제로 비틀거리는 걸 보면 더 황당함
    기능 개발이 미뤄졌다면서도 매주 새 기능과 UI 변경은 계속 나오고, 얼마 전에도 이슈 단일 뷰를 바꿨음
    Microsoft 정도 자원을 가진 회사가 이렇게 계속 같은 데서 발목 잡히는 건 믿기 어려울 정도고, 인기 있는 개발자 서비스를 사들여 전부 같은 플랫폼으로 옮기는 전략도 불안해 보임

    • 이건 너무 악의적으로 해석하는 느낌도 있음
      큰 엔지니어링 조직에서는 우선순위가 배타적이지 않고, 핵심 우선순위에 직접 기여하지 못하는 팀은 다른 기능 작업을 계속할 수도 있음
    • 그 single issues view 변경은 성능 완화를 위한 패닉성 해킹에 가까웠음
      https://news.ycombinator.com/item?id=47912521
    • Azure 이전이 오히려 가용성 문제를 더 악화시켰을 가능성도 충분함
      전용 하드웨어가 클라우드보다 예측 가능성이 높고, "Azure로 가지 말고 랙 몇 개 더 사자" 같은 판단은 GitHub 경영진 선에서 결정할 수 없는 일이었을 수도 있음
    • 지난 5년간 기능 변경이 전혀 없었어도 아무도 화내지 않았을 텐데, 굳이 계속 뜯어고치고 있음
      GitHub는 5분마다 재설계할 사이트가 아니고, 관리자들이 자기 존재 이유를 증명하려고 새 기능을 위한 새 기능을 밀어붙이는 것처럼 보일 때가 있음
      그 결과 더 많이 망가뜨릴수록 오히려 사용자를 끌어들이는 데 역효과가 남
      검색도 크게 너프됐고, Google 검색이나 YouTube처럼 왜 멀쩡하던 검색을 다들 계속 망가뜨리는지 모르겠음
      게다가 Microsoft는 거의 버려진 듯한 Azure DevOps도 있고 GitHub도 있는데, 둘 다 특히 티켓 시스템이 싫음
      Jira 프로젝트마다 설정이 제각각이라 질렸는데도, 이제는 "차라리 Jira가 그립다"는 말까지 나오게 됨

  • 저 글은 정색하고 읽기 어렵다는 느낌임
    숫자만 크게 올려놓은 라벨 없는 그래프, 실제 체감과 맞지 않는 우선순위, 그리고 지난 12개월의 끔찍한 업타임을 제대로 인정하지 않는 태도가 너무 거슬림

    • 그래프가 아주 최악은 아님
      왼쪽 아래 축 라벨이 없긴 해도, 2023→2024→2025→2026으로 성장 속도가 매우 빠르다는 핵심은 전달됨
      2026 초·말쯤에는 이전 3년을 합친 것보다 더 큰 성장을 말하는 것처럼 읽히고, 축 숫자를 몰라도 대략의 추세는 볼 수 있음
      선형 그래프라는 가정은 필요하지만, 문맥상 그 정도 가정은 무리 없어 보임
      계획보다 훨씬 큰 성장을 겪는 회사라면 용량 문제가 생길 수밖에 없고, 이제는 하드웨어만 더 넣는 수준을 넘어 백엔드 효율화가 필요해 보임
      적어놓은 목표들도 대체로 그쪽을 겨냥하고 있음
    • 숫자는 여기에도 더 있음
      https://x.com/kdaigle/status/2040164759836778878
      지금 성장이 지수적이라는 걸 못 믿는 건지, 아니면 연간 10배 성장도 별로 안 어렵다고 보는 건지 모르겠음
    • 인수 후 6년 내내 그랬다고 봐야 할지도 모름
      https://damrnelson.github.io/github-historical-uptime/
    • 요약하면 300단어쯤 되는 "우리가 듣고 있다" 메시지로 보임
    • 이런 식의 꾸밈 그래프는 많은 클라이언트가 다 비슷하게 씀

  • "multi cloud 경로를 시작했다"는 문장을 보면, Microsoft가 Azure만으로는 원하는 수준의 신뢰성을 못 뽑는다고 사실상 인정한 것처럼 들림

    • 꽤 치명적인 시그널처럼 보이고, Azure를 써본 입장에선 충분히 납득도 감
    • 이건 다운타임 때 돈을 잃는 엔터프라이즈 고객을 겨냥한 대응 같기도 함
      유지율 방어에는 도움이 될 수 있음
    • 저 정도 규모의 복잡한 시스템이라면 단일 공급자 의존을 피하는 게 상식적이기도 함
    • 예전에 여기서 Dave Cutler의 Azure 비전이 우선순위, 압박, 관리 때문에 훼손됐다는 글을 본 기억이 있음
      원래는 사람 개입이 거의 없는 운영을 지향했는데, 지금은 누가 랙이나 VM에 시리얼 붙여 직접 건드리는 식이 일상적인 절차라는 얘기였음
      지금은 링크를 못 찾겠지만
    • Show HN은 올리는 시간대가 생각보다 중요함
      월~목 오전 9~11시 Pacific에 가장 적극적인 독자가 많고, 주말은 경쟁은 적지만 참여도도 낮음

  • GitHub CTO가 Codepath.org 이사회에도 있고, 거기 설명이 "첫 번째 AI-native 세대의 엔지니어, CTO, 창업자를 만든다"는 식이라면, 어디가 문제인지 대충 감이 옴

  • 체감상 GitHub 안정성이 많이 나빴고, 최근엔 웹에서 보여주는 데이터조차 믿기 어려움
    어제부터 나와 동료 몇 명이 여러 저장소에서 PR 목록이 불완전하게 보이는 걸 확인했음
    예를 들어 https://github.com/gap-system/gap/pulls에서는 탭엔 "Pull requests 78"이라고 나오는데, 목록 뷰에는 "35 open"만 보임
    78이 맞는 숫자인 건 gh pr list로도 확인되는데도 https://www.githubstatus.com은 여전히 "all systems operational"이라고 표시함

    • 내 프로젝트들 중 상당수는 최근 6일간 닫힌 PR이 하나도 안 보임
      CLI로는 목록이 나오는데, 검색을 거치는 웹 경로에서는 전부 사라짐
      지원팀도 이 이슈를 인정하긴 했지만 그 뒤로 조용하고, 상태 페이지에도 27일의 아마 관련 있어 보이는 이슈 말고는 아무것도 없음
      일부 저장소에서는 중간에 해결된 듯하지만, 여전히 여러 org와 repo에서 계속 재현됨
      https://github.com/orgs/community/discussions/193388
    • 나도 같은 현상을 봤고, status page에는 여전히 안 올라와 있음
      빠진 PR은 브랜치 페이지를 뒤져서 겨우 찾았음
    • 이건 확장성 때문에 추정 쿼리를 써서 100% 정확하지 않은 결과를 반환하게 만든 해킹일 가능성이 커 보임
      완전한 버그라기보다, 인프라 부하를 줄이려고 제품 관점에서 아주 나쁜 선택을 했을 수도 있음

  • 지난 몇 년간의 새 repo/issues/commits 데이터를 공개한 건 그래도 흥미로웠음
    다들 바깥에서 짐작하던 대로, 에이전트들이 GitHub에 갑작스럽고 큰 추가 부하를 주고 있다는 걸 확인시켜 줌
    이미 거대한 사용자 기반을 서비스하면서도 스타트업처럼 지수 성장하는 셈이라 표적이 될 수밖에 없고, 조직이 빠르게 움직이기도 쉽지 않을 것 같음
    반대로 인재, 인프라, 자금은 스타트업보다 훨씬 많다는 점도 있음

    • 무슨 데이터를 말하는지 모르겠음
      라벨 없는 그래프 하나와 현재 피크 숫자만 있을 뿐임

  • 저 그래프들은 도대체 뭘 해놓은 건지 모르겠고, 거의 아티스트의 인상화처럼 보임
    커밋 그래프를 보면 왜 큰 계단이 생긴 뒤 완만하게 꺼지는지, 왜 그 계단이 일정한 지점에서 발생하지 않는지, 왜 더 큰 점프가 때로는 더 작은 기울기를 가지는지 설명이 안 됨
    다른 그래프들은 또 전혀 다른 형태로 움직여서 더 이상함

    • 전형적인 PowerPoint 그래프라서 그럼
      실제 데이터나 데이터의 의미를 보여주기보다 그냥 "뭔가가 오른다"만 전달하는 용도임

  • federated forges가 결국 미래라고 봄
    저장소는 각자 sovereign infra에 호스팅하고, 전역 ID와 federated metadata 이슈·PR 등을 얹는 구조가 맞아 보임
    이런 전역 인덱스는 띄우기도 쉬워서 가용성이 큰 걱정거리가 아니게 만들 수 있고, 우리도 그 방향으로 작업 중임

    • 아이디어는 귀엽지만, 대부분은 직접 호스팅하고 싶어 하지 않음
      결국 제3자 호스팅을 쓰게 되면 1~3개의 큰 사업자가 다시 등장할 가능성이 큼
      그리고 가용성 문제를 피하려고 셀프호스팅해도, 의존성이 GitHub 같은 대형 서비스에 걸려 있으면 그쪽 장애는 여전히 피할 수 없음
      그래서 현실적 해법은 지금과 마찬가지로 쓰는 걸 전부 프록시하거나 미러링하는 쪽임
    • 사실 이미 그렇게 할 수는 있음
      GitHub, Codeberg, 셀프호스트에 같은 repo를 두고 메인 브랜치 일관성만 관리하면 됨
      그다음부터는 어디서든 업데이트할 수 있고, README에 링크만 잘 걸어두면 됨
    • 코딩 에이전트들이 깊은 VCS 통합을 할 때 GitHub를 기본값으로 두지 않았으면 좋겠음
      decent API나 webhook만 제공하는 다른 forge를 연결해서 같은 편의성을 얻을 수 있다면 전부 셀프호스트로 가고 싶음
      에이전트 쪽에서도 인터페이스를 열어줘야겠지만, 플러그인 구조라면 GitHub 의존성을 떼어내고 나머지는 MCP나 skills로 처리할 수 있을 것 같음
    • 좋은 아이디어고, 우리 사이트의 LLM 생성 콘텐츠도 이것으로 대체하고 싶음
      나는 큰 러너는 셀프호스팅해도 괜찮아서 최근 Codeberg로 옮겼고, 작은 cron 작업은 Codeberg가 제공하는 러너를 씀
      거긴 이런 용도로 lazy runner까지 있음
    • 처음 들어보는 개념인데, 가입해서 한번 써볼 생각임

  • 지금 하는 일은 이거처럼 보임
    토큰 보조금은 충분한 학습 데이터를 빨아들였고 agentic junkies 비즈니스도 이제 플라이휠을 굴릴 만큼 커졌으니 끊고, 손실 유도 상품은 정리하겠다는 것 같음
    https://news.ycombinator.com/item?id=47923357

답변달기