Addressing GitHub’s recent availability issues

Context

급격한 트래픽 증가(클라이언트 앱의 API 호출이 10배 이상 증가)로 인해 사용자 인증 및 설정 데이터를 담당하는 코어 데이터베이스 클러스터가 과부하 상태에 빠졌습니다. 사용자 설정 캐시 TTL을 12시간에서 2시간으로 변경한 후 동시에 새로운 클라이언트 버전이 배포되면서 읽기·쓰기 부하가 복합적으로 증가했습니다. 서비스 간 아키텍처 결합도가 높아 한 서비스의 장애가 다른 중요 서비스로 전파되었으며, 정상적인 트래픽과 문제 있는 클라이언트의 요청을 구분할 수 있는 세밀한 제어 메커니즘이 부족했습니다.

Technical Solution

• 사용자 설정 데이터 저장소 재설계: 단순함을 위해 선택한 기존 아키텍처에서 데이터 크기가 바이트 수준에서 킬로바이트 수준으로 증가한 문제를 파악하고 저장소 구조 개선
• 부하 흘리기(load shedding) 메커니즘 강화: 네트워크 스택의 상위 계층에서 문제 있는 클라이언트의 트래픽을 식별하고 차단할 수 있도록 더욱 세밀한 제어 스위치 도입
• 서비스 간 아키텍처 결합도 감소: 특정 서비스의 장애가 인증 및 사용자 관리에 의존하는 다른 서비스로 cascade되는 현상 방지
• Redis 클러스터 자동 장애 조치(failover) 프로세스 검증: 장애 조치 실행 시 클러스터가 쓰기 가능한 primary 상태를 유지하도록 잠복된 설정 문제 수정
• 프로덕션 환경에서의 장애 조치 드라이 런(dry run) 절차 강화: 실제 장애 시나리오에 대한 사전 검증으로 latent 설정 이슈 조기 발견

Impact

아티클에 정량적 수치가 명시되지 않았습니다.

Key Takeaway

급격한 성장 단계의 시스템에서는 초기 설계(단순함)와 현재 규모(킬로바이트 데이터) 간의 괴리를 주기적으로 점검하고, 프로덕션 환경에서 장애 조치 절차를 실제로 실행하여 설정 오류나 미검증 코드 경로를 사전에 발견해야 합니다.