GitHub Git 운영 중단

 (githubstatus.com)
2P by GN⁺ | ★ favorite | 댓글 2개
  • 2025년 1월 13일 23:35 UTC~00:24 UTC 동안 GitHub의 모든 Git 작업을 사용할 수 없는 장애가 발생함
  • 원인은 구성 변경이었고, 내부 로드 밸런서가 Git 의존 서비스 간 요청을 드롭하면서 장애로 이어짐
  • GitHub는 문제가 된 구성을 롤백해 장애를 완화함
  • 영향 범위는 Git Operations가 가장 컸고, Actions와 Pages도 성능 저하를 겪음
  • 유사 장애의 탐지와 자동 완화를 앞당기기 위해 모니터링과 배포 관행 개선이 진행 중임

장애 개요

  • 2025년 1월 13일 23:35 UTC부터 00:24 UTC까지 모든 Git 작업이 사용할 수 없는 상태였음
  • 구성 변경 이후 내부 로드 밸런서가 Git이 의존하는 서비스 간 요청을 드롭함
  • GitHub는 해당 구성 변경을 롤백해 장애를 완화함
  • 영향을 받은 구성 요소는 Git Operations, Actions, Pages임

진행 타임라인

  • 23:44 UTC: Git Operations의 가용성 저하 보고를 조사하기 시작함
  • 23:46 UTC: Pages에서 성능 저하가 발생해 조사가 이어짐
  • 23:57 UTC: Actions에서도 성능 저하가 확인됨
  • 00:15 UTC: Git 작업 성능 저하의 원인을 식별했고, Git에 의존하는 다른 GitHub 서비스에도 영향을 줄 수 있다고 판단함
  • 00:28 UTC: 장애가 Resolved 상태가 됐고, GitHub는 탐지 시간과 자동 완화 시간을 줄이기 위해 모니터링과 배포 관행을 개선 중임

함께 보면 좋은 글 β

toughrogrammer   [-]

Github 장애 너무 자주 나요…

답변달기
GN⁺   [-]
Hacker News 의견들

  • 규제 산업에서 일하는데, 외부 감사인과 규제기관이 장기 장애나 제3자 벤더의 강제 종료에 어떻게 대응할지 꽤 강하게 들여다보기 시작함
    기본적인 재해복구/사업연속성 계획을 넘어서고, 최소한 상위 수준의 시나리오 훈련까지 검토함
    https://www.federalregister.gov/documents/2023/06/09/2023-12...
    겉보기에는 관리형 Git 저장소 같은 제품은 비교적 다루기 쉬워 보이지만, 이런 규제 기업들은 접근 관리, 변경 관리, 소프트웨어 개발 생명주기 등에서도 엄청난 감시를 받음
    소프트웨어 규모도 커서 영향 범위가 더 커지고, 자체 호스팅이 전통적인 답이긴 해도 결코 단순한 해법은 아님

    • Git의 좋은 점은 호스팅 서비스 전체가 사라져도 사용자들의 작업 디렉터리에서 필요한 것을 재구성할 수 있다는 것임
      중요한 브랜치들은 어딘가에는 있을 테고, 캐시되지 않은 중요한 통합 브랜치도 다시 만들 수 있음
      수많은 클라우드 서비스 의존성 중에서 Git은 개인적으로 가장 마지막에 걱정할 대상임
    • GitHub를 자체 호스팅한다고 해도 이제 가동시간 유지 책임은 내가 지게 되고, 서비스에 대한 전문성이나 투입 가능한 자원이 GitHub보다 적으니 GitHub Cloud의 가동시간을 맞추기는커녕 넘어서기도 어려움
      강제 종료 문제도 막아주지 않음
      GitHub가 계약을 종료하거나 라이선스 조건을 받아들이기 어렵게 바꾸거나 심지어 폐업하면, 외부 백업을 둔 클라우드 사용보다 나을 게 없음
      오픈소스 솔루션을 자체 호스팅하면 최악의 경우 포크해서 직접 유지보수할 수 있어 위험을 줄일 수는 있지만, 프로젝트가 버려지거나 향후 버전에서 라이선스가 바뀔 위험은 여전히 있음
      자체 호스팅을 하지 말라거나 SaaS가 항상 낫다는 뜻은 아니지만, 이런 문제를 해결하는 마법의 해법은 아님
    • 제3자 벤더 장애에 대비해 자체 호스팅 솔루션을 핫/콜드 백업으로 세우는 게 아니라면, 자체 호스팅이 제3자 벤더 문제를 어떻게 해결하는지 모르겠음
      클라우드에 아웃소싱해서 아낀다는 비용도 인프라를 복제해야 하면 다 사라짐
      하이브리드가 늘 가장 적절해 보였지만, 안전망에 돈 쓰는 걸 낭비로 보는 책임자가 항상 있음
    • 자체 호스팅을 하면 정전이나 자연재해는 어떻게 대비할 건가?
      소프트웨어 신뢰성 문제를 물리 인프라 문제로 바꾸는 셈임
      결국 체인 어딘가에서는 누군가가 그걸 해야 하지만, 그 역할은 깊은 경험이 있고 확신 있는 보장을 줄 수 있는 쪽이 맡는 게 낫다고 봄
    • 매우 엄격한 가동시간 SLA가 있는 거대한 상호 연결 서비스 묶음의 한 부분에서 일하고 있음
      정말 흥미로운 문제이고, 본질적으로 불안정하고 복잡한 시스템을 안정적이고 신뢰할 수 있게 만들기 위해 투입되는 가용성 엔지니어링 자원의 양은 놀라울 정도임
      이런 소프트웨어에서 일하는 느낌을 설명할 때는 이 비유를 좋아함: 이집트 피라미드에 내 개인 벽돌 하나, 혹은 몇 개가 있는 것 같고, 상상할 수 없을 만큼 거대한 전체의 아주 작은 조각이지만, 끌을 비틀어 정확히 맞는, 혹은 틀린 각도로 블록을 치면 이집트의 기초까지 흔들 수 있음

  • 결국 분산된 건 Git뿐이고, 사람들은 편의성 때문에 GitHub에 팔려간 셈임
    Git에 Fossil 같은 분산 버그 추적기와 위키 시스템이 없는 게 아쉬움
    GitHub가 더 많이 장애를 내야 뭔가 바뀔 듯함

    • 사람들은 전문가가 유지보수하는 신뢰 가능하고 쓰기 쉬운 중앙집중형 서비스를 원한다는 걸 매우 분명하게 보여줌
      많은 사용자 전문성을 요구하는 탈중앙 시스템은 선호하지 않음
    • 편의성이라는 게 꽤 많음: 웹에서의 표준 이름과 위치, 접근 정책 강제, 태그·이슈·리뷰·토론이 연결된 풀 리퀘스트 흐름, 정책 강제와 연결된 코드 리뷰, GitHub 수준의 기본적인 이슈 추적, 커밋 검증을 위한 서명 키의 신뢰 저장소, CI/CD 트리거와 실행기, 바이너리 릴리스를 포함한 릴리스 페이지와 다운로드 링크를 안심하고 쓸 수 있는 CDN까지 포함됨
      이건 단순한 분산 버전 추적보다 훨씬 큼
      사실 위 기능들은 Git에만 묶인 것도 아니고 Mercurial이나 Perforce에서도 똑같이 가치 있을 수 있음
      GitHub는 큰 제품이고, 잠재적으로 독립 가능한 여러 제품의 조합에 가까움
      Git과 비교할 게 아니라 Gitea나 BitBucket과 비교해야 하며, 이 모든 것을 합리적으로 탈중앙화할 수는 없지만 상당 부분은 가능함
    • 취미 해커를 제외하고 이런 것들을 직접 설치하고 유지하고 싶어 하는 사람을 알지 못함
      전문 소프트웨어 개발자로서는 그냥 잘 동작하고 믿을 수 있는 도구를 원함
      GitHub 99.99% 가동시간은 의존할 만함
    • 요지는 아니지만, 다행히 Git은 쉽게 확장 가능함
      이 저장소 내부 이슈 추적기는 의외로 기능이 충실함: https://github.com/git-bug/git-bug
      써본 사람 있나?
    • 반론하자면, 아주 가끔 생기는 45분 장애일 뿐임
      독립 설치에서 안정적으로 구성하기 쉽지 않은 많은 기능을 갖춘 중앙집중형 버전 관리 서비스의 편의성에 비하면 아주 작은 비용임

  • 약 2시간 동안 내려갔음
    상태 페이지는 “성능 저하”라고 했지만 실제로는 git@github.com: Permission denied (publickey).가 나왔음
    GitHub가 소통 방법을 몰랐거나 실제 영향 범위를 확신하지 못했던 것 같고, 이건 좋지 않음

    • 상태 페이지는 거의 솔직하지 않음
      회사는 SLA를 지키려고 거짓말을 함
      “성능 저하”나 “일부 고객의 오류율 증가”는 서비스 사용 불가/장애로 해석해야 함
    • 지난 한 시간 정도 SDL3 묶음을 체크아웃하려 했는데 아직도 SDL_ttf에서 실패하고 있음
      fatal: clone of '[https://github.com/libsdl-org/freetype.git](<https://github.com/libsdl-org/freetype.git>;)' into submodule path '~/src/SDL/SDL_ttf/external/freetype' failed
      fetch-pack: unexpected disconnect while reading sideband packet, fatal: early EOF, fatal: fetch-pack: invalid index-pack output
      fatal: clone of '[https://github.com/libsdl-org/harfbuzz.git](<https://github.com/libsdl-org/harfbuzz.git>;)' into submodule path '~/src/SDL/SDL_ttf/external/harfbuzz' failed
      Failed to clone 'external/harfbuzz'. Retry scheduled
      Failed to clone 'external/freetype' a second time, aborting
      “고쳐졌다”는 문제치고는 오류가 너무 많음

  • SSH 지식을 의심하며 미쳐가고 있었고, 다행히 새 키를 만들기 직전에 멈췄음

    • 내 쪽에서는 이미 새 ed25519 키의 자랑스러운 소유자가 됐음
      상태 페이지 업데이트가 충분히 빠르지 않았음
    • 잠깐 해고당하는 줄 알았음
    • 계정이 해킹당해서 SSH 키가 제거된 줄 알았음
      조금 당황한 뒤 키가 아직 있는지 다시 확인했고, 그다음 GitHub 상태 페이지를 보고 진정함
    • 기기에 Homebrew를 설치하려는데 clone 단계가 계속 실패해서 계속 당황했음
      내가 이상한 줄 알았음
    • 지난주에 Windows 11로 업그레이드했는데, 오늘 앞서 알 수 없는 이유로 WSL에서는 SSH가 되지만 호스트 OS에서는 안 됐음
      둘 다 Windows OpenSSH 에이전트가 제공하는 키를 쓰고 있었는데도 그랬음
      그냥 이번 서비스 장애 탓으로 돌리고 내일 잘 되길 바라야겠음

  • 나도 겪고 있음
    내 키에 문제가 생긴 줄 알고 좀 걱정했는데, 키가 아니라 장애였음
    개발자 눈 오는 날 휴일 같은 느낌

    • 오늘은 Git이 내려가고, 코드는 눈 속 고요히 쉬며, 개발자는 논다
    • SSH 인증이 왜 안 되는지 알아내려고 30분쯤 썼음
      SHA256 서명을 비교하고, 내가 제대로 읽고 있는지 의심하고, 머리를 쥐어뜯음
    • 나도 시스템이 망가졌나 싶어서 머리를 긁적이며 원인을 찾고 있었음
    • 젠장, 왜 미국 동부 근무시간에 안 터진 거지?

  • 내가 GitHub 도구를 거의 매일 써서 문제를 더 자주 알아차리는 건지 모르겠지만, 가용성이 별로 좋아 보이지 않음
    Actions가 실패하든, “핵심 업무가 아닌 것”, 즉 Git 작업이든, GitHub 장애 때문에 짜증 나지 않은 달이 과거에 있었는지 기억이 안 남

    • 동의함
      다운타임 비율이 어느 정도인지 궁금함
      대략 한 달에 1시간 정도, 그러니까 1/1000 수준으로 내려가는 것 같음
      업데이트: 엔터프라이즈 고객에게는 분기 기준 99.9% 초과를 약속함 - https://github.com/github/docs/blob/main/content%2Fsite-poli...
    • 제품 전체가 점점 더 불안정하고 조잡해지는 느낌임
      요즘 프런트엔드는 빙하처럼 느리고 페이지 로딩 자체도 자주 문제가 생김
      Actions도 자주 패닉을 일으켜 깨지거나 빙하 같은 속도로 질질 끌고, 사용자 경험도 나빠졌음
      왜 merge-queue 버튼이 없는지 모르겠음
    • 나만 그런지 모르겠지만 GitHub UI는 내가 써본 웹 앱 중 가장 느린 편이라고 확신함

  • GitHub Actions도 저장소를 가져오려 할 때 500 게이트웨이 시간 초과 오류로 실패하고 있음

  • 업데이트: 원인이 확인된 것 같음
    “Git 작업 성능 저하의 원인을 확인했으며, Git에 의존하는 다른 GitHub 서비스에도 영향을 줄 수 있습니다. 복구 작업 중입니다.”

  • 지금이 백업을 설정하거나 미러링 또는 독립 실행 가능한 대안을 살펴보기 좋은 때일지도 모름
    GitLab, Gitea 말고 확인해볼 만한 게 또 있나?

    • 참고로 다음 Gitea 버전, 아마 4월 출시 예정 버전에는 전체 GitHub 미러링 기능이 들어갈 예정임
      미러를 설정하면 몇 분마다 코드, 이슈, 위키, 풀 리퀘스트 등을 가져올 수 있음
      현재 버전은 전체 저장소를 한 번 마이그레이션하거나, 코드만 미러링하고 나머지는 하지 않는 방식만 가능함
    • Forgejo도 고려해볼 만함: https://forgejo.org/
    • 우리에게는 Gitea가 잘 맞음
    • 미러를 두는 게 무슨 의미가 있는지 모르겠음
      주 서비스가 다시 돌아왔을 때 해결하기 어려운 충돌만 생길 것 같음
      예를 들어 편법 없이 같은 서비스에 대해 풀 리퀘스트를 쉽게 병합하거나 같은 CI/CD 코드를 쓸 수 있을지 의심스러움
답변달기