그래프
사례3건
3건 중 1~3번째
- 증상
2월 9일 데이터 가용성 문제일 수 있다는 첫 티켓이 들어왔다. 2월 10일 상태 페이지는 쿼리 문제를 조사 중이며 최근 데이터 일부가 쿼리 응답에 나오지 않는다고 알렸다.
- 촉발
2월 9일 아주 큰 파티션의 압축을 개선하려는 코드 변경을 prod101-us-east-1 에 배포했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
2월 9일 데이터 가용성 문제일 수 있다는 첫 티켓이 들어와 조사를 시작했다. 2월 10일 티켓이 더 들어온 뒤 근본 원인을 찾았다.
- 조치
- 2월 10일 압축 변경을 롤백해 더 번지지 않게 했다.
- 최근 데이터를 클러스터의 쓰기를 모두 기록한 Kafka 로그에서 먼저 되살렸다.
- 2월 17일 과거 데이터를 더 효율적으로 복원하도록 복원 절차를 고쳤다.
- 과거 데이터를 TSM 스냅숏에서 복원했다.
- 실시간 쓰기와 쿼리를 방해하지 않도록 클러스터를 켠 채로 조금씩 복원했다.
- 후속 조치
- 압축기처럼 중요한 스토리지 구성 요소를 바꾸는 변경의 테스트 범위를 넓히고, 운영 규모의 작업량을 더 잘 반영하는 테스트 시나리오를 더한다.
- 압축 과정의 안전장치를 강화해 실패를 찾아내고 안전하게 처리하게 한다.
- 대규모 복원 중에 TTBR 이 높아지거나 쿼리가 느려질 가능성을 줄이도록 복원 작업 흐름과 운영 절차를 검토한다.
- 클러스터 전체 복원이 빨라지도록 백업과 복원 전략을 다시 본다.
- 증상
하쿠나 서비스의 API latency 가 특정 시간에 주기적으로 치솟았다. APM 의 Dependency 별 Latency 분석에서 병목은 Redis 였다.
- 촉발
가용 메모리가 부족한 상태에서, 하루 한 번 primary 노드에서 도는 ElastiCache 백업이 forkless 방식으로 실행됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
특정 시간에 주기적으로 치솟는 API latency 를 그래프에서 보았고, APM 의 Dependency 별 Latency 분석으로 병목이 Redis 임을 알아냈다.
- 조치
- ElastiCache 백업을 primary 노드가 아니라 secondary 노드에서 실행하도록 바꿨다.
- TTL 없이 저장되던 데이터에 TTL 을 걸어 저장하도록 코드를 고쳤다.
- Redis Hash CrudRepository 를 쓰던 곳을 RedisTemplate 으로 다시 구현한 CustomRepository 로 바꿨다.
- 이미 쌓여 있던 필요 없는 데이터를 지우는 스크립트를 실행했다.
- 교훈
백엔드 팀은 Redis 운영과 모니터링에 미흡한 부분이 있었다고 돌아봤다. 데이터 사이에 관계가 있거나 값으로 검색해야 하면 관계형 데이터베이스를 쓰고, 영속성이 필요한 데이터는 되도록 Redis 가 아닌 on-disk 기반 저장소에 둔다. ElastiCache Snapshot 을 만들어야 하면 가용 메모리를 50% 이상으로 유지한다. DEL collection 처럼 O(n) 인 명령 때문에 운영 Redis 가 멈추지 않게 조심한다. 애플리케이션과 데이터베이스 사이에 불필요한 I/O 가 없는지도 주기적으로 확인한다. Spring Data Redis Repository 는 secondary index 를 프레임워크가 관리해 주므로, TTL 이 필요 없고 쿼리 성능이 많이 요구되는 업무에서는 좋은 선택지가 될 수 있다.
IL-021043초 네트워크 단절 뒤 MySQL 프라이머리가 미국 서부로 넘어가 GitHub.com 이 24시간 11분 동안 느려지고 오래된 데이터를 보여 줬다GitHub2018- 증상
2018년 10월 21일 22:54 UTC 에 내부 모니터링 시스템이 여러 시스템에서 장애가 났다는 알림을 쏟아내기 시작했다. 23:02 UTC 에 첫 대응 팀은 여러 데이터베이스 클러스터의 토폴로지가 예상하지 못한 상태라는 것을 확인했다.
- 촉발
10월 21일 22:52 UTC 에 고장 난 100G 광 장비를 교체하는 정기 유지보수 작업 중 미국 동부 네트워크 허브와 동부 주 데이터센터 사이의 연결이 끊겼다. 연결은 43초 만에 돌아왔다.
- 원인
- 구성 요소
- 기여 요인
- 감지
22:54 UTC 에 내부 모니터링 시스템이 알림을 내기 시작해 여러 엔지니어가 알림을 분류했다. 23:02 UTC 에 첫 대응 팀이 Orchestrator API 를 조회해 복제 토폴로지에 서부 데이터센터 서버만 남은 것을 확인했다.
- 조치
- 23:07 UTC 에 내부 배포 도구를 수동으로 잠가 더는 변경이 들어오지 않게 했다.
- 푸시 같은 메타데이터를 쓰는 작업을 멈추려고 웹훅 전송과 GitHub Pages 빌드를 일시 중지했다.
- 10월 22일 06:51 UTC 까지 여러 클러스터를 미국 동부 데이터센터에서 백업으로 복원했고, 복원된 서버는 서부에서 새 데이터를 복제받기 시작했다.
- 외부 저장소에서 내려받는 처리량 한계를 피하려고 서부 데이터센터에서 직접 복원하는 방법을 찾았다.
- 11:12 UTC 에 모든 데이터베이스 프라이머리를 다시 미국 동부에 세웠다.
- 미국 동부 퍼블릭 클라우드에 MySQL 읽기 복제본을 추가로 띄워 읽기 요청을 더 많은 서버로 나눴고, 복제본 전체의 사용률이 내려가 복제가 따라잡았다.
- 복제본이 맞춰진 뒤 16:24 UTC 에 원래 토폴로지로 페일오버했다.
- 밀린 웹훅 이벤트와 Pages 빌드를 처리했다. 웹훅 페이로드 약 200,000건이 내부 TTL 을 넘겨 버려진 것을 발견하자 처리를 멈추고 TTL 을 당분간 늘리는 변경을 배포했다.
- 후속 조치
- 각 클러스터에서 서부로 복제되지 않은 쓰기를 담은 MySQL 바이너리 로그를 분석해, 자동으로 맞출 수 있는 쓰기와 사용자에게 연락해야 하는 쓰기를 가린다.
- GitHub Pages 빌드가 멈춘 상황에서도 공지 글을 낼 수 있게 한다.
- 장애 중 복구 예상 시간을 더 정확하게 알린다.
- Orchestrator 설정을 고쳐 데이터베이스 프라이머리가 리전 경계를 넘어 승격되지 않게 한다.
- 녹색, 노란색, 빨간색 세 단계만 있던 상태 표시를 새 상태 보고 방식으로 옮겨 플랫폼 구성 요소마다 상태를 보여 준다.
- 여러 데이터센터에서 트래픽을 받는 active/active/active 구성으로 옮기는 일을 앞당겨, 시설 단위 N+1 이중화로 데이터센터 하나가 통째로 망가져도 사용자에게 영향이 없게 한다.
- 시스템이 기대는 가정을 더 적극적으로 시험한다.
- 장애 시나리오를 사용자에게 닿기 전에 검증하는 관행을 들이고, 장애 주입과 카오스 엔지니어링 도구에 투자한다.
- 교훈
GitHub 은 Orchestrator 가 설정대로 움직였지만 애플리케이션 계층은 그 토폴로지 변경을 견디지 못했다고 봤다. 리전 안의 리더 선출은 대체로 안전하지만, 갑자기 생긴 대륙 간 지연이 이번 장애를 키운 큰 요인이었다. 자동 페일오버 설정은 애플리케이션이 기대하는 것과 맞춰야 한다. GitHub 은 이만큼 복잡한 서비스 체계에서는 운영 통제를 조이거나 대응을 빠르게 하는 것만으로는 안정성을 지킬 수 없다고 판단했다. 그래서 가정을 더 적극적으로 시험하고, 장애 시나리오를 사용자에게 닿기 전에 검증하기로 했다. 복구 예상 시간은 모든 변수를 고려하지 못해 틀렸다.
이 3건에서 가장 많이 나오는 구성 요소: 데이터베이스 백업과 스냅숏, 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.