사례22건

22건 중 1~5번째

1. IL-0246 Cilium 에이전트가 엔드포인트를 만들지 못해 빅데이터 쿠버네티스 노드에서 새 파드가 뜨지 못했다

   Adyen2026

   증상

   Adyen 의 운영 빅데이터 쿠버네티스 클러스터에서 새 파드가 네트워크 설정 단계에서 타임아웃으로 실패했다. 한 파드가 실패하면 같은 노드에 뜨려는 다른 파드도 모두 타임아웃을 냈다.

   파드 ContainerCreating 정체

   촉발

   몇 달 전 Helm 차트에 cilium_bpf_map_dynamic_size_ratio: 0.0050 을 설정해, 2TB RAM 노드의 TCP 연결 추적 테이블 최대 크기가 기본값의 두 배인 16,777,216 개가 됐다. 이 큰 테이블이 연결 추적 가비지 컬렉션의 주기 자동 조정과 맞물려, 연결이 적던 노드에 무거운 데이터 작업이 올라오면 만료된 항목이 몇 시간 동안 쌓였다.

   원인

   설정 변경

   구성 요소

   Cilium

   기여 요인

   늦게 드러난 변경기본 설정 방치재시도 폭주한계 경보 부재

   조치

   • Cilium 설정에 conntrackGCInterval: 60s 를 넣어 가비지 컬렉션 주기가 자동으로 늘어나지 않게 고정했다. 오전 9:00 에 적용해 10:00 에 DaemonSet 배포를 마쳤고, 연결 추적 테이블 크기와 엔드포인트 API 처리 시간이 정상으로 돌아왔다.

   후속 조치

   • 워크로드가 동적으로 바뀌는 Cilium 환경에서는 conntrackGCInterval: 60s 설정과 함께, 가비지 컬렉션 시간 cilium_datapath_conntrack_gc_duration_seconds 와 테이블 크기 cilium_datapath_conntrack_gc_entries 에 미리 알림을 건다. 이 장애 때 가비지 컬렉션 시간은 1초에서 80초로 뛰었고 테이블에는 대부분 만료된 항목 700만 개가 있었다.

   교훈

   규모에 맞춰 바꾼 값은 트래픽이 늘면서 몇 달 뒤에야 전체 영향을 드러낼 수 있다. 512GB 노드를 위해 바꾼 bpf_map_dynamic_size_ratio 는 처음 문제를 풀었지만, 2TB 노드에서 커진 테이블이 가비지 컬렉션 주기 자동 조정과 맞물렸다. 로그는 증상만 보여 줬고, 원인은 프로파일링과 추적으로 컨테이너 런타임, CNI 플러그인, Cilium 에이전트, 리눅스 커널까지 훑어야 보였다. 실제 숫자로 어림셈을 하자 전체 흐름을 이해하기 전에 원인을 짚을 수 있었다. 자동 조정 알고리즘에는 한계가 있어야 한다. Cilium 의 주기 자동 조정은 오래 연결이 적다가 파드 하나로 연결이 크게 늘어나는 노드나, 5% 가 아주 큰 수가 되는 큰 테이블을 고려하지 않았다. 최대 12시간이라는 주기도 이 작업에는 너무 길었다. 타임아웃은 호출한 쪽만 보호할 뿐 작업을 멈추지 않는다. 필요하면 작업을 취소하는 처리를 명시적으로 넣어야 한다. 연결 추적 상태는 핵심 운영 지표로 다뤄야 하고, 한가한 시간의 CPU 절약을 위해 바쁜 시간의 파드 생성 타임아웃을 감수해서는 안 된다.

   사례 보기
2. IL-0512 xPRO 의 쿠버네티스 APISIX 오리진 인증서가 갱신되지 못하고 만료되어 xpro.mit.edu 가 한 시간 동안 503 을 냈다

   MIT Open Learning2026sev1

   증상

   2026-06-03 오후 3시 38분 EDT 에 xPRO 운영 CMS 와 xPRO 본 애플리케이션이 503 을 낸다는 알림이 함께 울렸다. 공개 사이트 https://xpro.mit.edu 에 고객이 제대로 접속하지 못했다.

   서비스 중단TLS 인증서 오류

   촉발

   cert-manager 가 2026-05-04 에 xpro-web.odl.mit.edu 인증서의 갱신 구간에 들어가 DNS-01 검증을 시작했다. 이 검증이 Fastly 가 만든 _acme-challenge.xpro-web.odl.mit.edu CNAME 과 부딪혀 끝나지 못했고, 기존 오리진 인증서가 2026-06-03 오후 3시 29분 EDT 에 만료됐다.

   원인

   설정 변경

   구성 요소

   cert-managerCDN 과 엣지 네트워크DNS 서버와 레코드

   기여 요인

   설정 테스트 부재모니터링 사각지대늦게 드러난 변경

   감지

   오후 3시 38분 EDT 에 xPRO 운영 CMS 와 xPRO 본 사이트가 503 을 낸다는 알림이 울렸다. 인증서가 만료된 지 9분 뒤였다.

   조치

   • 오래된 cert-manager 자원을 지우고 다시 만들어 cert-manager 가 백엔드 오리진의 새 인증서를 발급하게 했다. 이것으로 서비스가 돌아왔다.

   후속 조치

   • OpenEdX 가 아닌 xPRO 의 Fastly TLS 구독에서 백엔드 오리진 도메인을 뺐다.
   • src/ol_infrastructure/applications/xpro 의 Production 스택에 Pulumi 변경을 배포했다.
   • Fastly 의 검증 CNAME 을 뺀 뒤, xpro 네임스페이스에 있는 OpenEdX 가 아닌 xPRO 인증서를 cert-manager 로 직접 갱신하거나 cert-manager 가 저절로 갱신하게 했다.
   • cert-manager 가 관리하는 오리진 도메인이 Fastly TLS 구독에 들어가지 못하게 막는 테스트나 정책 검사를 넣는 방안을 검토한다.
   • cert-manager 의 CertificateRequest 와 Order 가 실패하면 더 일찍 알림을 보내, 인증서가 만료되기 전에 오래된 ACME 실패를 찾는 방안을 검토한다.

   교훈

   이 장애는 처음에 cert-manager 의 ACME 갱신 실패로 이해됐다. 그 이해는 맞았지만 모자랐고, 빠진 진단은 Fastly 가 cert-manager 의 몫인 백엔드 오리진 도메인의 검증까지 관리하도록 설정돼 있었다는 점이었다. 갱신 실패를 일찍 잡지 못한 것은 cert-manager 가 관리하는 백엔드 오리진 도메인이 Fastly TLS 구독에 들어가면 안 된다는 것을 검사하는 장치나 테스트가 없었기 때문이다. 팀은 TLS 인증서와 DNS 검증 레코드를 누가 맡는지 경계를 분명히 정하고 그 경계를 지키는 장치를 둬야 한다고 정리했다. 특히 TLS 자동화를 설정할 때 Fastly 의 공개 프런트엔드 도메인과 쿠버네티스 APISIX 백엔드 오리진 도메인을 바꿔 써도 되는 같은 서비스 도메인으로 다루면 안 된다.

   사례 보기
3. IL-0435 Aurora MySQL 이 OOM 을 피하려고 커넥션을 끊고 쿼리를 거부해 애플리케이션 오류율이 올랐다

   CyberAgent2026

   증상

   어느 날 갑자기 애플리케이션 오류율이 나빠졌다는 알림이 울렸다. 그 시간대 Aurora MySQL RDS 인스턴스의 오류 로그에는, Aurora MySQL 이 메모리 부족으로 OOM 이 나는 것을 피하려고 커넥션을 끊고 쿼리를 거부한 기록이 남아 있었다.

   오류율 상승메모리 압박

   촉발

   FreeableMemory 가 내려가기 시작한 날의 애플리케이션 릴리스에서 쿠버네티스 CronJob 으로 매분 도는 배치 처리가 더해졌다.

   원인

   용량 한계

   구성 요소

   데이터베이스잡과 크론잡

   기여 요인

   기본 설정 방치늦게 드러난 변경

   감지

   애플리케이션 오류율이 나빠졌다는 알림이 울렸다.

   조치

   • Aurora MySQL 파라미터 그룹에서 Performance Schema 를 자동 관리를 뜻하는 0 에서 수동 관리를 뜻하는 1 로 바꾸고, 기본값 -1 로 무제한이던 관련 파라미터 두 개에 상한 100 을 두었다. 적용에는 RDS 인스턴스 재시작이 필요했고, 이 조치로 FreeableMemory 감소와 SwapUsage 발생이 멈췄다.

   교훈

   시스템 알림이 울렸는데 DB 부하 지표가 조용하면 Performance Schema 가 불어난 것도 의심해야 한다. 상한을 둔 두 파라미터는 기본값이 무제한이라 이번처럼 기록이 계속 쌓였다. 상한을 두면 퍼포먼스 인사이트의 호스트별 집계에서 상한을 넘은 호스트의 정보가 빠지는 단점이 있다. 애플리케이션과 Aurora MySQL 사이에 RDS Proxy 를 두어 DB 에 접속하는 HOST 를 일정하게 유지하는 방법도 있다.

   사례 보기
4. IL-0098 ingress-nginx 에서 nginx-ingress 로 옮긴 뒤 같은 호스트를 나눠 쓰는 인그레스들의 동작이 바뀌어 cert-manager 가 새 TLS 인증서를 받지 못했다.

   2i2c2026

   증상

   새 허브를 띄우려 했는데 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 얼마 전 다른 허브에서도 같은 일이 있었다.

   요청 오라우팅배포 실패

   촉발

   nginx-ingress 로 옮긴 클러스터에서 새 TLS 인증서가 필요한 허브를 새로 배포했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러cert-manager

   기여 요인

   늦게 드러난 변경

   감지

   새 허브를 띄우다 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 전날 다른 허브에서도 같은 현상을 봤기 때문에 엔지니어가 웹사이트에서 장애를 직접 선언했다.

   조치

   • TLS 가 필요한 인그레스 객체에 어노테이션을 달아 cert-manager 가 edit-in-place 방식으로 인그레스를 고칠 수 있게 했다.

   후속 조치

   • 후속 작업을 2i2c-org/infrastructure 이슈 8016 으로 남겼다.
   • 후속 작업을 2i2c-org/infrastructure 이슈 3278 로 남겼다.

   교훈

   인그레스 컨트롤러를 바꾸면 같은 호스트를 나눠 쓰는 인그레스들 사이의 우선순위가 바뀔 수 있고, cert-manager 의 ACME 임시 인그레스처럼 그 동작에 기대는 구성 요소가 깨진다. 이 문제는 새 인증서가 필요한 배포에서 드러났다. 2i2c 는 내부 클러스터를 시험하면서 이 원인을 이미 알고 있었고, cert-manager 설정을 고치는 일도 빨랐다.

   사례 보기
5. IL-0405 AWS Load Balancer Controller 의 webhook 인증서가 만료돼 US·Canada 지역의 BSEE SaaS 인스턴스가 전부 멈췄다

   PortSwigger2026

   증상

   US 와 Canada 지역 고객이 BSEE SaaS 인스턴스의 Web UI 에 들어가지 못했고 스캔도 시작하지 못했다. 엔지니어는 고객이 지원 창구로 알려 온 뒤에야 장애를 알았다.

   서비스 중단TLS 인증서 오류

   촉발

   PortSwigger 는 2025년 11월 28일 AWS Load Balancer Controller 를 v1.14.1 에서 v1.16.0 으로 올렸다. v1.15.0 의 Helm 차트가 인증서를 관리하는 방식을 바꿨고, 이 업그레이드 뒤에 소유자가 사라진 webhook 용 TLS Secret 이 남았다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러어드미션 웹훅cert-managerHelm컨피그맵과 시크릿클라우드 로드 밸런서

   기여 요인

   늦게 드러난 변경모니터링 사각지대

   감지

   엔지니어는 고객이 지원 창구로 신고한 뒤에야 장애를 알았다. 신고는 2026년 1월 12일 09:52 UTC 에 들어왔고, 영향이 시작되고 23시간 52분이 지난 때였다.

   조치

   • US 와 Canada 클러스터에서 소유자가 사라진 aws-load-balancer-tls Secret 을 지웠다.
   • Helm 으로 AWS Load Balancer Controller 설정을 다시 배포했다.
   • 인증서가 새로 만들어졌는지, webhook 이 제대로 동작하는지 확인했다.

   후속 조치

   • 모든 클러스터에서 소유자인 Certificate 리소스가 사라진 Secret 을 찾아 정리한다.
   • SaaS 클러스터마다 외부 프로브가 애플리케이션에 접속할 수 있는지 확인하고, 접속하지 못하면 알림을 보내게 한다.

   사례 보기

원인별6