사례17건

17건 중 1~5번째

1. IL-0102 배포와 워커 오토스케일링 폭주가 겹치자 크기를 고정해 둔 CoreDNS 가 메모리 한도를 넘겨 재시작된 뒤 회복하지 못했고, Buildkite 사이트 전체가 약 30분 멈췄다.

   Buildkite2026

   증상

   22:47 UTC 부터 Buildkite 웹 화면, REST API, Agent API, 작업 큐, 알림이 한꺼번에 장애를 겪었다. 모든 고객이 웹 화면이나 REST API 로 새 빌드를 만들 수 없었고, 작업 배정이 늦어졌다.

   서비스 중단DNS 조회 실패OOMKilled오토스케일러 오동작

   촉발

   22:44 UTC 에 애플리케이션을 배포하면서 파드가 한꺼번에 늘어 이미 떠 있던 노드의 여유 용량이 바닥났다. 같은 시각 알림 워커를 비롯한 백그라운드 워커들도 확장하려 했고, 노드 공급이 늦어지자 확장 지표가 그대로인 채 파드를 계속 더 요청했다. 이 워커들의 최대 레플리카 수는 평소보다 높게 잡혀 있었다.

   원인

   용량 한계

   구성 요소

   CoreDNS컨테이너 메모리 한도수평 파드 오토스케일러노드 풀

   기여 요인

   여유 용량 부재자동화 증폭재시도 폭주모니터링 사각지대

   감지

   장애는 22:47 UTC 에 시작됐고, Buildkite 는 22:55 UTC 에 문제를 조사 중이라고 상태 페이지에 처음 알렸다. 23:05 UTC 에는 사이트 전체 장애를 조사 중이라고 올렸다. CoreDNS 쿼리 처리 시간은 클러스터가 커지면서 늘고 있었지만, 핵심 모니터링 쿼리의 결함과 쿼리량 모니터링 부족 때문에 장애 전에는 이를 알아채지 못했다.

   조치

   • 추가 애플리케이션 배포를 멈췄다.
   • CoreDNS 파드를 3개에서 12개로 늘렸다.
   • CoreDNS 파드마다 메모리 한도를 512 MiB 에서 2 GiB 로 올렸다.
   • CoreDNS 를 돌리는 시스템 노드 풀을 늘렸다.

   후속 조치

   • CoreDNS 파드를 3개에서 12개로 늘리고, 파드당 메모리 한도를 512 MiB 에서 2 GiB 로 올리고, 이 파드들을 돌릴 시스템 노드 풀을 넓혔다.
   • EKS 관리형 CoreDNS 오토스케일링을 켠다. 검증한 최소 레플리카 수를 정하고, 레플리카를 여러 노드와 가용 영역에 나눠 둘 만큼 용량을 확보한다.
   • CoreDNS 쿼리 처리 시간, 쿼리량, 고루틴 증가, 메모리 압박, OOM 재시작, 사용 가능한 레플리카 수에 직접 알림을 건다. 장기 추세도 용량 계획에 넣어 지켜본다.
   • 클러스터에 꼭 필요한 다른 서비스도 살핀다. 검증된 용량, 직접 알림, 장애 도메인 분산이 없는 서비스, 그리고 안전한 오토스케일링도 문서로 정한 고정 여유분도 없는 서비스를 찾아 고친다.

   교훈

   크기를 고정해 둔 CoreDNS 는 클러스터가 커지고 변경 속도가 빨라지면 한순간에 무너질 수 있다. 나중에 낮출 생각으로 높게 잡아 둔 워커의 최대 레플리카 수는 노드 공급이 늦어질 때 오토스케일링 폭주를 막지 못했다. 모니터링 쿼리에 결함이 있고 쿼리량을 제대로 감시하지 않아 장기 추세가 보이지 않았다. 클러스터 핵심 서비스는 급격한 저하와 여유분 감소를 둘 다 직접 감시해야 한다.

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

   사례 보기
3. IL-0067 Redis 마스터의 50Mi 영구 볼륨이 가득 차 AOF 가 깨졌고, Redis 파드가 크래시 루프에 빠져 Klamm 운영 서비스가 멈췄다

   BC Government2025sev1

   증상

   2025년 7월 9일 OpenShift 위의 Klamm 캐시 Redis 클러스터가 멈췄다. Redis 로그에는 "Fail to fsync the AOF file: No space left on device" 오류가 남았다. AOF 는 Redis 가 쓰기 명령을 차례로 덧붙여 저장하는 파일이다.

   서비스 중단컨테이너 재시작 반복영구 볼륨 가득 참

   촉발

   Klamm Laravel 워커 하나에서 I/O 작업이 예상하지 못하게 급증해 Redis 캐시 요청이 크게 늘었고, AOF 가 빠르게 커지면서 Redis 마스터의 영구 볼륨을 채웠다.

   원인

   용량 한계

   구성 요소

   영구 볼륨과 스테이트풀셋인메모리 캐시

   기여 요인

   용량 계획 부재

   조치

   • Redis 스테이트풀셋과 디플로이먼트를 멈췄다.
   • 깨진 PVC 를 지우고 다시 만들었다. 이 과정에서 Redis 볼륨의 데이터를 잃었다.
   • 스테이트풀셋과 디플로이먼트를 다시 시작했다.

   후속 조치

   • Klamm Redis 캐시 볼륨을 100Mi 로 늘린다.
   • 네임스페이스에 Sysdig 모니터링을 설정한다.
   • Redis 클러스터에서 레플리카 파드를 쓰도록 설정한다.

   사례 보기
4. IL-0080 트래픽이 몰린 GKE 클러스터에서 kube-dns 가 DNS 질의를 감당하지 못해 여러 서비스의 이름 해석이 실패하고 운영 장애로 번졌다.

   Mercari2025sev1

   증상

   Mercari 의 GKE 클러스터에서 여러 서비스가 한꺼번에 DNS 이름 해석에 실패하기 시작했다. 요청은 타임아웃으로 끝났고, 마이크로서비스가 서로 엮여 있어서 실패가 연쇄로 번지며 운영 장애가 됐다. 회사는 이 장애를 Sev1 로 분류했다.

   DNS 조회 실패간헐적 타임아웃서비스 중단

   촉발

   피크 시간대에 클러스터가 처리하는 초당 요청 수가 크게 늘면서 DNS 질의가 소수의 kube-dns 파드로 몰렸다.

   원인

   용량 한계

   구성 요소

   kube-dns

   기여 요인

   캐시 부재단일 장애점

   감지

   피크 시간대에 NXDOMAIN, 잘린 응답, "failed to refresh DNS cache" 오류가 반복되는 것을 보고 kube-dns 가 한계에 이르렀다는 것을 알았다.

   조치

   • Platform 팀만 내부 시험용으로 쓰는 Laboratory GKE 클러스터에 nodeAffinity 를 걸어 NodeLocal DNSCache 를 배포하고, 전체 워크로드에 영향을 주지 않은 채 효과를 측정했다.
   • 노드 풀에 레이블을 붙여 NodeLocal DNSCache 파드가 뜰 수 있게 하는 방식으로 Dev 와 Prod 환경 전체에 점진적으로 배포했다.

   교훈

   트래픽이 많은 쿠버네티스 클러스터에서는 DNS 를 최적화하는 일이 중요하다. 모든 파드가 몇 개의 kube-dns 파드에 기대는 구조는 피크 시간대에 장애 지점이 됐고, 노드 단위 캐시를 두자 DNS 트래픽과 오류가 크게 줄었다.

   사례 보기
5. IL-0082 EKS 노드 교체 중 CoreDNS 파드 하나가 종료되자 남은 CoreDNS 파드가 늘어난 부하를 버티지 못해 DNS 조회가 느려지고 타임아웃이 났다.

   RebelMouse2025

   증상

   2025년 5월 19일 13:42 UTC 에 RebelMouse 모니터링 도구가 오류율 상승과 서비스 성능 저하를 잡아냈다.

   DNS 조회 실패지연 시간 증가오류율 상승서비스 중단

   촉발

   보안 패치를 적용하는 정기 EKS 노드 교체 중에 계획된 EC2 인스턴스 종료가 자동으로 실행됐고, 그 인스턴스에서 돌던 CoreDNS 파드 하나도 함께 종료됐다.

   원인

   용량 한계

   구성 요소

   CoreDNS노드 풀

   기여 요인

   피크 시간 변경

   감지

   13:42 UTC 에 RebelMouse 모니터링 도구가 오류율 상승과 서비스 성능 저하를 잡아냈다. 노드 교체를 시작한 지 27분 뒤였다. 기술팀은 2분 뒤인 13:44 UTC 에 조사를 시작했다.

   조치

   • 영향을 받은 CoreDNS 파드를 새 EC2 인스턴스로 다시 스케줄했다.
   • CoreDNS 디플로이먼트를 스케일 업해 레플리카 수를 늘리고, 부하가 모든 파드에 고르게 나뉘게 했다.

   후속 조치

   • 부하가 몰리는 시간대에 CoreDNS 파드가 예기치 않게 종료되지 않도록 스케일 인 보호 장치를 넣는다.
   • CoreDNS 파드의 수직 확장이 제대로 되도록 CoreDNS 설정을 다시 살펴본다.
   • CoreDNS 디플로이먼트가 최대 부하를 감당할 만큼 준비돼 있는지 정기적으로 용량을 점검한다.

   사례 보기

원인별1