깃허브는 8~9월 동안 공유 데이터베이스 부하를 낮추고 장애 격리와 깃허브 액션스의 처리 여력을 개선했지만, 용량 부족과 데이터베이스 장애, 코파일럿 코드 리뷰 결과 누락도 겪었다. 10월 7일 기준 운영 서비스 160개 중 120개가 애저 미국 중부 지역에 배포됐으며, 데이터베이스 이전 목표는 달성하지 못했다.
애저는 깃허브 핵심 애플리케이션 읽기 트래픽의 65.4%, 깃 읽기 트래픽의 48.3%, 스트림 처리 트래픽의 80.2%를 처리했다. 서로 다른 작업의 비율이므로 합산할 수 없다. 가용성 영역별 용량이 고르지 않아 9월 11일 미국 중부 지역의 배포와 트래픽 증가를 일시 중단했고, 임시 조치 뒤 9월 18일 점진적인 트래픽 증가를 재개했다. 모든 운영 서비스를 9월 30일까지 이전하려던 목표는 놓쳤으며, 10월 말까지 사용 가능한 용량을 모두 확보하는 작업을 이어가고 있다.
이전 작업 중 계획된 데이터베이스 장애 조치에서 자동 비상 절차가 미국 중부 지역의 데이터베이스 복제본 연결을 끊어 해당 지역 고객에게 영향을 줬다. 깃허브는 계획된 전환 중에는 이 절차를 비활성화하고 복구 방식을 개선하고 있다.
지역 이전 외에도 인증 핵심 기능의 테이블 24개를 가장 오래된 공유 데이터베이스에서 옮겨 복제본의 초당 쿼리를 약 100만 건 줄였다. 이슈와 풀 리퀘스트를 지원하는 데이터베이스 클러스터에서는 불필요한 편집 기록 약 9억 8,000만 건을 제거해 약 1.8테라바이트의 저장 공간을 회수할 수 있게 했다. 주간 교착 상태는 6월 최고치보다 약 77% 줄었고, 지속적인 정리 작업으로 같은 데이터가 무한히 늘어나는 것을 막고 있다.
풀 리퀘스트 트래픽 표본의 절반은 공유 의존성이 실패해도 제한된 기능으로 계속 처리할 수 있다. 공유 데이터베이스 장애 중에도 일부 읽기 작업이 가능했다. 데이터베이스 트래픽 라우팅은 급증 시 용량을 자동으로 늘리며, 한 그룹은 9월 23일 풀 리퀘스트 활동이 증가하자 인스턴스를 14개에서 19개로 늘렸다. 과부하 제어 기능은 포화가 더 넓게 번지기 전에 우선순위가 낮은 요청을 거부해 중요한 API와 웹 작업을 보호한다.
깃허브 액션스에서는 운영 환경 변경으로 측정된 레디스 작업이 약 28%, 상대 CPU 사용량이 약 30% 줄었다. 별도의 인프라 캐시는 레디스 대역폭을 84%, 평균 응답 시간을 66%, 주요 인벤토리 요청의 중앙값 응답 시간을 96%, 대기 중인 요청을 95% 낮췄다.
9월 장애와 대응
9월 13일에는 백그라운드 데이터 정리 작업이 공유 데이터베이스의 주 서버 부하를 높여 1시간 28분 동안 장애가 이어졌다. 작업은 복제본 지연만 감시하고 주 서버의 부하는 고려하지 않아 연결 한도에 도달할 때까지 계속됐다. 데이터베이스 호출에 빠른 시간 제한이 없었고, 토큰 생성 재시도도 실패한 쓰기를 반복해 복구를 늦췄다. 깃허브는 내부 부하를 줄이고 작업을 멈춰 데이터베이스를 복구했다. 이후 데이터베이스 용량에 맞춘 백그라운드 작업 제어, 불필요한 재시도 감소, 느린 요청의 영향 제한, 서비스 시작 과정 개선을 추진하고 있다.
9월 28일에는 코파일럿 코드 리뷰 서비스 변경으로 일부 고객에게 리뷰 결과의 제한된 사본만 전달돼 52분 동안 리뷰가 누락됐다. 작업이 성공했다고 보고했지만 실제 리뷰 결과는 만들어지지 않았고, 감시 체계 부족으로 30분 넘게 완료되지 않은 리뷰가 경보를 울린 뒤에야 문제가 확인됐다. 변경을 되돌린 뒤 고객에게 영향을 받은 리뷰를 다시 요청하도록 안내했다. 깃허브는 리뷰 전달 보장과 실패한 리뷰의 자동 복구, 더 빠른 알림 및 배포 감시 개선을 진행하고 있다.
깃허브는 8월 6일 액션스 장애와 8월 17일 github.com 장애도 언급하며, 개선은 실제 상황에서 고객 위험을 줄여야 의미가 있다고 밝혔다. 실시간 상태와 사후 보고는 깃허브 상태 페이지에서 확인할 수 있으며, 작업 중인 엔지니어링 내용은 깃허브 블로그 엔지니어링 섹션에 공개된다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요