Reddit

GitHub Actions is down once again

GitHub Actions에서 워크플로 처리·상태 업데이트 지연 발생

GitHub Status에는 10월 19일 Actions 워크플로 처리와 상태 업데이트, 웹훅 전달 지연이 기록돼 있습니다. 10월 7일에는 데이터베이스 라우팅 설정 오류로 두 차례 장애가 발생했고, GitHub는 잘못된 설정이 적용된 경로와 재발 방지책을 공개했습니다.

에디터 노트

10월 7일 두 차례 장애는 단순한 러너 문제보다 데이터베이스 설정 관리와 유지보수 자동화가 함께 실패한 사례입니다. 오래된 서버 기록을 가진 장비가 리더가 됐고, 중단 조치 뒤에도 별도 자동화가 그 장비를 다시 리더로 올렸습니다. GitHub가 공개한 대책은 기록 검증, 잘못된 설정 거부, 이상 장비의 신속한 제외로 원인에 직접 대응합니다. Reddit에서 말하는 셀프 호스팅 러너도 웹훅과 작업 전달이 GitHub에 의존하면 장애 영향을 피하지 못합니다. 따라서 러너를 직접 운영하는 것만으로 Actions 전체의 의존성이 사라지지는 않습니다. 다만 이 토론의 불만은 여러 날짜의 장애와 지연을 한데 묶고 있으며, 댓글만으로 반복 장애의 빈도나 전체 가동률을 확정할 수는 없습니다. 상태 페이지의 '정상' 표기와 사용자가 겪은 지연 사이에 차이가 있다는 지적도 있지만, 게시된 기록에는 10월 19일 지연이 명시돼 있습니다.

AI 요약

GitHub Status는 현재 모든 시스템이 정상이라고 표시하지만, 과거 장애 기록에는 10월 19일 Actions 워크플로 처리와 GitHub Pages 배포, Actions 실행에서 발생한 웹훅 전달 및 상태 업데이트 지연이 남아 있습니다. 10월 12일에는 알림 전달 파이프라인의 비효율적인 데이터베이스 쿼리가 샤드 데이터베이스 복제본의 여유 용량을 줄여 Issues, Pull Requests, Projects, Actions 요청에 영향을 줬습니다. GitHub는 해당 쿼리를 실행하던 코드 경로를 수정하고 데이터베이스 계층의 복원력을 개선하겠다고 밝혔습니다.

10월 7일 장애의 원인과 대응

GitHub 설명에 따르면 내부 서비스가 데이터베이스 서버의 쓰기 요청 라우팅 설정을 관리합니다. 정기 유지보수 중 새 장비 한 대가 이미 퇴역한 서버가 기록된 오래된 데이터를 불러왔고, 해당 장비가 리더가 되면서 존재하지 않는 데이터베이스 서버로 쓰기 요청을 보냈습니다. 올바른 설정을 가진 기존 장비가 쿼럼 리더가 된 뒤 장애가 끝났지만, 첫 장애 뒤 자동 유지보수를 중단했는데도 별도 자동화 작업이 중단 설정을 따르지 않아 같은 장비가 다시 리더가 됐습니다. GitHub는 두 번째 장애 뒤 장비를 종료하고 제거했으며, 자동화가 중단 설정을 따르도록 수정했다고 밝혔습니다.

첫 번째 장애에서는 웹 및 API 요청의 5.6%가 실패했고 최고치는 8.9%였습니다. 1만 2천 곳이 넘는 조직이 요청 실패를 겪었고 Git 인증 요청은 최대 26%, Actions 워크플로 실행은 17%가 인프라 오류로 실패했습니다. 두 번째 장애에서는 웹 및 API 요청의 6.2%가 실패해 최고 9.3%에 이르렀으며 1만 1천 곳이 넘는 조직이 영향을 받았습니다. Git 인증 요청은 최대 25%, Actions 실행은 19%가 실패했습니다. 데이터 손실은 없었고 복구 뒤 재시도한 작업은 성공했다고 GitHub는 설명했습니다.

재발 방지책으로 퇴역 서버 기록을 새 장비 추가 전에 지우고, 기록 검증을 마치기 전에는 새 장비가 리더가 되지 못하게 하겠다고 밝혔습니다. 존재하지 않는 서버를 가리키는 설정을 거부하고 마지막으로 정상 확인된 설정을 유지하는 방안도 제시했습니다. 장애 장비를 더 빠르게 서비스에서 제외하고 설정 변경을 몇 초 안에 감지하도록 경보를 추가할 계획입니다. 10월 6일에는 온프레미스 데이터센터와 클라우드 지역 데이터베이스 서비스 일부 사이의 네트워크 장애로 문제가 발생했습니다. GitHub는 정상 지역으로 데이터베이스 트래픽을 옮겨 대응했으며 지역 간 장애 조치와 지연 감지 경보를 개선하겠다고 했습니다.

Reddit 반응

  • @u/bmrobin — 여러 CI 도구를 써봤고, 작동할 때는 GitHub Actions가 가장 마음에 듭니다. 하지만 셀프 호스팅 러너를 써도 중단이 생기는 점은 정말 답답합니다.
    • @u/WeirdIndividualGuy — GitHub Actions의 셀프 호스팅은 완전히 셀프 호스팅이 아니라는 점을 알리는 글입니다. 그렇지 않다면 GitHub Actions 장애가 자체 호스팅 CI에 영향을 주지 않을 테니까요.
    • @u/G12356789s — 우리 회사는 GitLab에서 GitHub로 옮기는 방안을 검토 중입니다. 저는 GitLab CI 러너와 자체 호스팅 방식이 마음에 드는데, Actions에서 특별히 마음에 드는 점이 무엇인가요?
    • @u/riickdiickulous — GitLab을 쓰던 회사에서 GitHub를 쓰는 회사로 옮겼는데, 뭐든 해서라도 GitLab으로 돌아가고 싶습니다. GitHub는 형편없습니다.
  • @u/ao_zame — 방금 모든 것을 셀프 호스팅 Forgejo 인스턴스로 옮겨서 다행입니다.
    • @u/_mattmc3_ — 우리도 비슷하게 옮겼고 만족합니다. Forgejo Actions는 대부분 GitHub Actions와 호환되지만 GitHub가 제공한 보조 액션 저장소 몇 개는 포크하거나 다시 작성해야 했습니다. 부족한 점은 제대로 된 Projects API입니다.
  • @u/First_Inspection_478 — 셀프 호스팅 러너도 웹훅이 중단되면 영향을 받는 경우가 많습니다.
    • @u/NotUniqueOrSpecial — 작업을 러너에게 전달하는 과정이 문제라면 그걸로 해결되지 않습니다.
  • @u/SanJJ_1 — 오늘은 왜 상태가 전부 초록색으로 표시되나요? 이런 장애 현황판은 완전히 가짜 같네요.
    • @u/spongeloaf — 예쁜 초록색 막대가 커밋을 올릴 때마다 PR 페이지가 5분씩 멈추는 일을 전부 반영하는 것 같지는 않네요.
  • @u/targrimm — 7초 걸리는 액션 하나를 실행하는 데 38분을 기다렸습니다.
  • @u/ClocktowerGnome — GitHub Actions는 가동률이 99.65%라서 신뢰도를 나타내는 9가 하나도 없습니다.
    • @u/ImAStupidFace — GitHub Actions를 비판하는 데는 동의하지만, 99.65%에 있는 9의 개수는 다시 세어야겠네요.
  • @u/AutomateAway — 의사 진료를 받으러 왔는데, 회사에 돌아가면 CI/CD가 전부 멈춰 있을 거라고 예상합니다.

원문: GitHub Status / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗