사례3건
3건 중 1~3번째
- 증상
2026-08-06 15:05 UTC 부터 GitHub Actions 워크플로 실행이 시작하지 못하거나 도중에 실패했고, 일부 Actions REST API 요청이 오류를 냈다. 일부 고객은 워크플로에서 예상하지 못한 rate limiting 을 겪었다.
- 촉발
이벤트를 처리하고 Actions 작업을 만드는 Actions 내부 서비스에 일상 배포를 했다. 배포로 파드가 교체되는 동안 남은 용량이 포화됐다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 용량을 늘렸고, 처음 무너진 서비스들은 17:00 에 회복했다.
- 시스템이 회복할 수 있게 웹훅으로 들어오는 작업을 줄였다. 한때 웹훅의 약 15% 만 처리했다.
- 밀린 이벤트를 처리할 용량을 늘렸다.
- 러너가 유효하지 않은 작업을 되풀이해 가져가려 하지 않도록 하는 변경을 배포했다.
- 작업을 가져가지 못하던 자체 호스트 러너를 위한 수정을 배포하고 조금씩 켰다.
- 완화 작업에 도움이 되도록 GitHub Enterprise Importer 마이그레이션을 멈췄다.
- 웹훅으로 시작하는 Actions 워크플로를 전체 처리량으로 되돌렸다.
- 완화 조치 하나 때문에 오프라인으로 남은 Actions Runner Controller 러너는 손으로 복구했고, 그 변경은 나중에 롤백했다.
- 재시도도 취소도 되지 않는 작업을 고객이 정리할 수 있는 CLI 와 UI 방법을 GitHub 커뮤니티 토론 글로 공유했다.
- 후속 조치
- 영향받은 서비스의 배포 안전장치와 용량 안전장치를 개선한다.
- 이번 장애에 앞서 나타난 조건을 잡아내도록 모니터링을 강화한다.
- 장애가 나도 큐에 쌓인 작업과 러너 배정이 버티고 빨리 복구되도록 개선한다.
- 다음 Actions Runner 와 Actions Runner Controller 릴리스에 자동 복구를 넣어 손으로 하는 조치가 필요 없게 한다.
- 대규모 Actions 장애에서 연쇄 장애가 번질 위험을 줄이고 복구를 앞당기는 개선을 더 한다.
- 증상
2026-03-04 에 IONOS Container Registry 고객이 컨테이너 이미지를 푸시하거나 풀할 때 504 Gateway Timeout 오류를 받았다. 레지스트리에 기대는 배포가 막혔다. 상태 페이지에는 09:23 UTC 에 레지스트리의 오류 수가 늘었고 고객이 이미지를 풀하지 못할 수 있다고 처음 올라왔다.
- 촉발
마이그레이션 중 일시적인 용량 제약 때문에 중요한 컨트롤 플레인 구성 요소 둘이 같은 프록시 인스턴스에 놓였다. 직접적인 계기는 그 프록시가 동시 연결 한도에 닿아 새 연결을 받지 않은 것이었다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 12:22 UTC 에 쿠버네티스 팀이 쿠버네티스 컨트롤 플레인 구성 요소 하나의 버전을 롤백하는 완화책을 배포했다.
- 프록시 용량을 더 마련했다.
- 영향받은 컨트롤 플레인 구성 요소를 서로 다른 프록시 인스턴스로 옮겨 부하를 고르게 되돌렸고, 504 오류가 끝났다.
- 후속 조치
- 노드마다 전용 로컬 프록시를 쓰도록 레지스트리와 쿠버네티스 API 사이의 연결을 다시 설계해 공유 프록시 병목을 없앤다. 운영 적용은 2026년 2분기로 잡았다.
- 프록시 연결 사용률이 한도에 다가가기 전에 경고가 울리도록 알림 기준을 조정한다. 2026년 2분기에 끝낼 예정이다.
- 인프라 클러스터를 더 배포하고 기존 레지스트리를 다시 나눠, 어느 클러스터도 안전한 운영 용량을 넘지 않게 한다. 사용량이 늘면 자동화가 부하를 계속 고르게 맞춘다.
- 증상
6월 3일 PagerDuty 알림 파이프라인의 성능이 떨어져 일부 알림이 늦게 갔다. 통합 API 로 보낸 이벤트의 약 3% 를 받지 못했고, 1% 에 못 미치는 일부 알림이 늦게 전달됐다.
- 촉발
6월 3일 Cassandra 클러스터의 노드 하나에서 repair 작업이 평소대로 시작됐고, 그때 걸린 높은 부하와 겹쳤다. 6월 4일에는 팀이 전날 미룬 repair 작업을 손으로 다시 시작했다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 6월 3일 Cassandra 클러스터의 부하를 줄였다.
- 6월 3일 부하를 줄이면서 repair 작업을 멈췄다.
- 클러스터를 안정시키려고 일부 노드 사이의 통신을 끊었고, 그 뒤 정상으로 돌아왔다.
- 6월 4일 알림 파이프라인에서 처리 중이던 데이터를 모두 지웠고, Cassandra 가 바로 회복했다.
- 새로 비운 상태와 데이터를 맞추도록 일부 하위 시스템을 수동으로 손봤다.
- 후속 조치
- 기존 Cassandra 노드를 더 크고 빠른 서버로 수직 확장한다. 6월 4일 이후 이 작업은 이미 끝냈다.
- Cassandra 클러스터를 여러 개로 나누고 작업량을 그 클러스터들에 나눠 싣는다. 부하와 사용 방식에 따라 클러스터를 나누는 작업이 진행 중이다.
- 시스템 부하 기준을 정해 그 기준에 닿으면 기존 Cassandra 클러스터를 미리 수평 확장한다.
- 기존 클러스터와 새 클러스터를 더 최근 버전의 Cassandra 로 업그레이드한다.
- 높은 부하에서도 Cassandra 를 통제할 수 있도록 로드 셰딩 기법을 더 넣는다.
- Cassandra 전문 인력을 사내에 더 둔다.
- 교훈
PagerDuty 는 Cassandra 클러스터의 규모가 모자랐고, 부하와 사용 방식이 서로 다른 너무 많은 서비스가 한 클러스터를 나눠 쓰고 있었다고 밝혔다. 비슷한 문제를 보고 개선을 계획했지만 효율을 기준으로 버전 업그레이드를 먼저 하려 했고, 확장을 먼저 했어야 했다고 적었다.
이 3건에서 가장 많이 나오는 구성 요소: CI 시스템, 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.