사례10건

10건 중 1~5번째

1. IL-0471 GitHub Actions 워크플로 실행이 대량으로 실패하거나 큐에서 오래 기다렸다

   GitHub2026

   증상

   2026-08-06 15:05 UTC 부터 GitHub Actions 워크플로 실행이 시작하지 못하거나 도중에 실패했고, 일부 Actions REST API 요청이 오류를 냈다. 일부 고객은 워크플로에서 예상하지 못한 rate limiting 을 겪었다.

   오류율 상승지연 시간 증가

   촉발

   이벤트를 처리하고 Actions 작업을 만드는 Actions 내부 서비스에 일상 배포를 했다. 배포로 파드가 교체되는 동안 남은 용량이 포화됐다.

   원인

   용량 한계

   구성 요소

   CI 시스템

   기여 요인

   여유 용량 부재과도한 영향 범위수동 조치 악화

   조치

   • 용량을 늘렸고, 처음 무너진 서비스들은 17:00 에 회복했다.
   • 시스템이 회복할 수 있게 웹훅으로 들어오는 작업을 줄였다. 한때 웹훅의 약 15% 만 처리했다.
   • 밀린 이벤트를 처리할 용량을 늘렸다.
   • 러너가 유효하지 않은 작업을 되풀이해 가져가려 하지 않도록 하는 변경을 배포했다.
   • 작업을 가져가지 못하던 자체 호스트 러너를 위한 수정을 배포하고 조금씩 켰다.
   • 완화 작업에 도움이 되도록 GitHub Enterprise Importer 마이그레이션을 멈췄다.
   • 웹훅으로 시작하는 Actions 워크플로를 전체 처리량으로 되돌렸다.
   • 완화 조치 하나 때문에 오프라인으로 남은 Actions Runner Controller 러너는 손으로 복구했고, 그 변경은 나중에 롤백했다.
   • 재시도도 취소도 되지 않는 작업을 고객이 정리할 수 있는 CLI 와 UI 방법을 GitHub 커뮤니티 토론 글로 공유했다.

   후속 조치

   • 영향받은 서비스의 배포 안전장치와 용량 안전장치를 개선한다.
   • 이번 장애에 앞서 나타난 조건을 잡아내도록 모니터링을 강화한다.
   • 장애가 나도 큐에 쌓인 작업과 러너 배정이 버티고 빨리 복구되도록 개선한다.
   • 다음 Actions Runner 와 Actions Runner Controller 릴리스에 자동 복구를 넣어 손으로 하는 조치가 필요 없게 한다.
   • 대규모 Actions 장애에서 연쇄 장애가 번질 위험을 줄이고 복구를 앞당기는 개선을 더 한다.

   사례 보기
2. IL-0464 IONOS 관리형 쿠버네티스의 고객 컨트롤 플레인 일부가 사흘 동안 몇 분씩 되풀이해 끊겼다

   IONOS Cloud2026

   증상

   2026-03-14 부터 고객의 관리형 쿠버네티스 컨트롤 플레인 일부가 주기적으로 응답하지 않았다. 영향받은 클러스터에는 그때마다 몇 분씩 닿을 수 없었고, 배포, 스케일링, 헬스체크처럼 쿠버네티스 API 에 기대는 작업이 제대로 동작하지 않았다. 상태 페이지에는 2026-03-16 08:24 UTC 에 일부 고객이 컨트롤 플레인 연결 문제와 쿠버네티스 기능 저하를 겪을 수 있다고 처음 올라왔다.

   컨트롤 플레인 무응답이미지 풀 실패

   원인

   용량 한계

   구성 요소

   etcd쿠버네티스 API 서버관리형 쿠버네티스 컨트롤 플레인과 제공자 API

   기여 요인

   과도한 영향 범위

   조치

   • 영향받은 데이터베이스 인스턴스를 조각 모음해 인스턴스마다 약 3–4 GiB 를 되찾고 정상 운영 여유를 되돌렸다.
   • 영향받은 인스턴스에서 데이터베이스 컴팩션 주기를 줄였다.
   • 03-16 11:37 UTC 에 쿠버네티스 팀이 영향받은 AI Model Hub 데이터베이스 서비스에 수정을 배포했다.
   • 03-16 19:58 UTC 에 영향받은 모든 클러스터에 마지막 변경을 적용했다.

   후속 조치

   • 데이터베이스 인스턴스별 컨트롤 플레인 상태가 잘 보이도록 모니터링 대시보드를 넓힌다.
   • 데이터가 가장 많은 클러스터를 전용 데이터베이스 백엔드로 옮겨 그 워크로드가 같은 데이터베이스 인스턴스의 다른 클러스터에 주는 영향을 없앤다.
   • 이런 장애가 나면 곧바로 호출 알림이 가서 사람이 제때 개입하도록 알림을 개선한다.
   • 바꾼 컴팩션 주기를 모든 공유 컨트롤 플레인 데이터베이스 인스턴스에 적용한다.
   • 조각화가 쌓이지 않도록 모든 인스턴스에 정해진 일정으로 도는 자동 조각 모음 작업을 둔다.
   • 한곳에 몰리는 위험을 줄이도록 데이터베이스 인스턴스 사이의 클러스터 배치를 다시 맞춘다.
   • 4주 안에 데이터를 지나치게 많이 만드는 클러스터의 고객에게 직접 연락해, 큰 보안 스캔 보고서를 컨트롤 플레인 데이터베이스가 아닌 외부 스토리지 백엔드에 두는 것 같은 워크로드 최적화를 논의한다.
   • 1~3개월 안에 공유 컨트롤 플레인 데이터베이스에 테넌트별 자원 쿼터와 키 개수 한도를 두어, 클러스터 하나가 다른 클러스터에 영향을 주지 못하게 한다.
   • 2026년 2분기부터 공유 컨트롤 플레인을 다시 설계해 전용 데이터베이스 인스턴스를 두고 수직 확장을 개선해 고객 워크로드 사이의 격리를 강화한다.
   • 데이터가 꾸준히 많은 고객을 위해 데이터베이스를 완전히 샤딩하는 방안을 검토한다.
   • 다음 장애의 대응 시간을 줄이도록 데이터베이스 자원 고갈과 복구를 다루는 운영 훈련을 정기적으로 한다.

   사례 보기
3. IL-0350 TXL 클러스터 한 곳의 호스트 네트워크가 끊기고 프로비저닝 대기열이 밀려 여러 서비스가 오래 나빠졌다

   IONOS Cloud2026

   증상

   2026-03-03 11:36 UTC 에 상태 페이지가 TXL 의 모니터링 알림을 조사하고 있다고 알렸다. 정비 중이던 클러스터 한 곳의 호스트가 연결을 잃었고, 고객은 간헐적인 네트워크 서비스 저하나 중단을 겪었다.

   네트워크 도달 불가링크 플래핑서비스 중단

   촉발

   TXL 데이터 센터 클러스터의 고장 난 스위치를 바꾸는 정비로 두 토폴로지 가운데 Topology 2 를 계획대로 껐다. 그동안 남은 Topology 1 에서 스위치 하나의 링크 흔들림이 패브릭 resweep 을 일으켰다.

   원인

   용량 한계

   구성 요소

   InfiniBand 패브릭네트워크 컨트롤 플레인BGP 라우팅NIC·케이블·스위치 포트 링크모델 허브데이터베이스

   기여 요인

   자동화 증폭과도한 영향 범위

   감지

   IONOS Cloud 는 TXL 에서 울린 모니터링 알림으로 장애를 알아챘고, 11:36 UTC 에 상태 페이지에 이 알림을 조사하고 있다고 올렸다.

   조치

   • 문제가 난 컨트롤 플레인을 대기 장비로 전환했다.
   • 멈춘 게이트웨이를 재부팅했다.
   • 예정된 정비 상태에서 Topology 1 을 복구했다.
   • 작업이 밀린 클러스터의 프로비저닝을 잠시 멈췄다. 실행 중인 서비스는 영향이 없었지만 기존 자원의 변경은 다시 켤 때까지 처리되지 않았다.
   • 네트워크 연결이 나아지자 프로비저닝을 다시 켜고 작업 실행을 지켜봤다.
   • DCD 를 받치는 시스템들의 연결을 다시 세워 DCD 서비스를 되살렸다.

   후속 조치

   • 컨트롤 플레인 구성에서 failover 타이머를 덜 민감하게 바꾸고 무거운 sweep 작업을 줄여 전달 테이블의 부하를 낮췄다.
   • 멀티캐스트 그룹 가입 수를 줄여 전달 테이블의 부담을 더 덜었다.
   • 전달 테이블 사용률과 컨트롤 플레인 메모리를 계속 감시해 용량 한도에 닿기 전에 알림이 오게 했다.
   • 네트워크 관리와 데이터 플레인 트래픽이 자원을 다투지 않도록 컨트롤 플레인을 전용 고성능 서버로 옮긴다. 2025년 4분기에 시작했고 2026년 2분기 완료가 목표다.
   • IPv6 구성과 IPoIB 드라이버 설정을 깊이 감사한다. 2026년 2분기 완료가 목표다.
   • 스위치, 게이트웨이, 드라이버를 포함한 인터커넥트 패브릭을 현대화해 복원력과 성능을 높인다. 2026년 3분기 완료가 목표다.
   • 주요 Cloud API 를 잠시 쓸 수 없어도 핵심 신원 서비스가 동작하도록 IAM 정비 절차를 강화했다.
   • IAM 을 전용 플랫폼으로 옮기는 작업을 앞당겨 IAM 이 일반 Managed Kubernetes 클러스터에 기대지 않게 한다. 목표 시점은 2026년 3분기다.
   • DBaaS 와 Managed Kubernetes 에 전용 프로비저닝 공급자를 두어 자가 치유 같은 변경 중에 서비스가 끊기는 일을 줄인다. 목표 시점은 2026년 3분기다.
   • 자가 치유 서비스 때문에 과부하가 나거나 대기열이 끝없이 쌓이지 않도록 프로비저닝 엔진에 자동 서킷 브레이커를 넣는다. 목표 시점은 2026년 1분기다.
   • 프로비저닝 대기열에서 작업 실행과 우선순위를 더 잘 보고 다룰 수 있도록 QoS 를 개선한다.
   • 서비스 사이의 파급을 줄이도록 프로비저닝 대기열의 결합을 푸는 구조 변경을 한다.

   교훈

   IONOS Cloud 는 서비스들이 프로비저닝 대기열로 서로 얽혀 있던 점이 서비스 저하를 길게 만든 핵심 요인이었다고 봤다. 앞으로는 서비스마다 견고하게 만드는 것과 함께 프로비저닝 대기열의 결합을 풀어 이번과 같은 파급을 줄이겠다고 했다. 서비스 사이의 의존도 찾아 풀어서 앞으로의 장애가 미치는 범위를 줄이겠다고 했다.

   사례 보기
4. IL-0110 Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.

   DFDS2024

   증상

   2024-03-13 10:01 UTC 에 쿠버네티스 노드 하나가 NotReady 상태가 됐다. 그때 노드에 잡힌 requests 는 CPU 78%, 메모리 82% 였다. 10:03 에 Slack 으로 알림이 왔고, 10:05 에 알림을 보고 조사를 시작했다.

   노드 NotReady컨테이너 재시작 반복OOMKilled모니터링 중단

   촉발

   Hangfire 로 작업을 실행하는 개발 컨테이너가 Grafana Agent 가 메모리를 많이 쓰고 있던 노드에 배치됐고, 작업이 OOM 으로 실패하며 CrashLoopBackOff 를 반복했다.

   원인

   용량 한계

   구성 요소

   텔레메트리 에이전트컨테이너 메모리 한도데이터베이스

   기여 요인

   과도한 영향 범위리소스 요청과 한도 미설정수동 조치 악화모니터링 사각지대

   감지

   10:03 UTC 에 Slack 으로 알림이 왔고, 10:05 에 알림을 확인하고 조사를 시작했다. 두 번째 노드는 15:03 에 Slack 알림이 왔고 15:09 에 확인했다. 탐지까지 걸린 시간은 4분이었다.

   조치

   • 10:22 에 EC2 인스턴스를 비정상으로 표시해 새 노드를 띄웠다.
   • 10:30 에 NotReady 노드를 cordon 하고 강제로 drain 했고, 10:36 에 그 EC2 인스턴스를 종료했다.
   • 13:02 에 네임스페이스에서 LimitRange 를 지우고 Grafana Agent 파드를 재시작했다.
   • 14시대에 문제의 개발 컨테이너를 0개로 줄였고, 몇 분 뒤 EC2 네트워크 트래픽이 정상으로 돌아왔다.
   • 두 번째 NotReady 뒤 15:15 에 개발 컨테이너를 다시 0개로 줄였고, 15:18 에 새 노드가 추가됐다.
   • 15:19 에 개발 컨테이너를 맡은 팀에 메일을 보냈고, 15:52 에 그 팀이 문제를 확인하고 수정 중이라고 답했다.

   후속 조치

   • grafana-agent 를 모니터링 노드 그룹으로 옮긴다.
   • 클러스터 전체 대역폭이 정해 둔 기준에 닿으면 알림을 보낸다.
   • grafana-agent Helm 차트에 메모리 한도를 걸 수 있는지 조사한다.
   • grafana-agent 의 메모리 사용량을 조사한다.
   • grafana-agent 에 PVC 를 써야 하는지 Grafana 지원팀에 묻는다.
   • 보존 기간을 제한한 채 노드 로그를 Loki 로 보내는 방안을 검토한다.
   • 쿠버네티스 노드 문제를 조사할 때 확인할 자주 쓰는 지표와 로그 쿼리를 위키 페이지로 만든다.

   교훈

   포스트모템에서 나온 후속 조치를 끝까지 챙겨야 한다. CloudWatch 에서 어떤 지표가 쓸모 있는지가 팀에 제대로 공유되지 않아 진단과 조사가 어려웠다.

   사례 보기
5. IL-0070 dask-gateway로 워커를 대량으로 띄우자 노드가 1분 만에 100대 늘었고, Prometheus가 메모리를 거의 다 쓰던 코어 노드에서 hub 파드를 비롯한 중요한 파드들이 축출되거나 재시작됐다

   2i2c2023

   증상

   2023년 2월 1일 leap 클러스터의 prod 허브에서 노드가 대량으로 늘었고, hub 파드가 알 수 없는 이유로 재시작됐다. 사용자 지원 티켓도 들어왔다.

   파드 축출파드 Pending

   촉발

   한 사용자의 dask-gateway 작업이 1분 사이에 dask-worker 노드를 100대쯤 늘렸고, Prometheus 는 노드 200대쯤의 지표 내보내기 대상을 수집하기 시작했다.

   원인

   용량 한계

   구성 요소

   Prometheus노드 풀

   기여 요인

   여유 용량 부재과도한 영향 범위모니터링 사각지대

   감지

   2i2c Freshdesk에 들어온 사용자 지원 티켓 414로 드러났다. 이후 엔지니어가 Grafana와 클러스터의 노드, event를 살폈다. 조사 내용은 같은 날 UTC+1 기준 저녁 8시에서 9시 사이에 이슈에 정리됐다.

   후속 조치

   • basehub에서 hub와 proxy 파드의 CPU와 메모리 요청을 넉넉히 설정한다. 이슈 #2127이다.
   • Grafana의 OOMKiller 대시보드가 제대로 동작하게 고친다. 이슈 #2213이다.
   • LEAP 클라우드 인프라를 공유 노드 구성으로 옮긴다. 이슈 #2209다.
   • ingress-nginx와 Prometheus의 리소스 요청과 한도를 고친다. Prometheus 서버는 메모리 요청을 한도와 같게 맞춘다. 이슈 #2324다.
   • Prometheus가 daskhub 워커 파드를 수집하도록 넣은 설정이 필요한지 다시 본다. 이슈 #2366이다.

   교훈

   Prometheus 서버처럼 메모리를 많이 쓰는 파드가 요청보다 훨씬 많이 쓰면 같은 노드의 중요한 파드가 축출된다. 노드가 한꺼번에 100대 늘면 Prometheus가 수집할 대상도 함께 늘어난다. hub와 proxy처럼 중요한 파드는 실제 사용량보다 요청을 넉넉히 잡아야 축출과 CPU 부족을 피할 수 있다. 쿠버네티스 event는 60분이 지나면 사라지므로, OOMKill 여부를 나중에 확인하려면 따로 기록해 두어야 한다.

   사례 보기

원인별1