사례4건

4건 중 1~4번째

1. IL-0581 이구위크 첫날 Redis 커넥션이 실패하며 29CM 상품 전시 서버의 파드가 다운되고 Netty 이벤트 루프가 포화됐다

   MUSINSA2025

   증상

   이구위크가 시작되고 얼마 지나지 않아 검색 결과와 상품 리스팅 같은 전시 도메인을 맡은 서버에 이상 징후가 나타났다. 파드 일부가 다운되어 트래픽을 받지 못했고, 남은 파드도 처리할 수 있는 양을 넘어 Netty 이벤트 루프가 포화됐다.

   프로브 실패간헐적 연결 실패지연 시간 증가

   촉발

   2025년 11월 3일 29CM 최대 규모의 블랙프라이데이 행사인 이구위크가 시작되면서 트래픽이 몰렸다.

   원인

   용량 한계

   구성 요소

   인메모리 캐시라이브니스·레디니스 프로브

   기여 요인

   한계 미인지모니터링 사각지대의존성에 묶인 헬스 체크

   감지

   팀은 이구위크가 시작되고 얼마 지나지 않아 전시 서버의 파드 일부가 다운되고 Netty 이벤트 루프가 포화된 것을 보고 이상을 알아챘다. 원인을 분석하던 중 Redis 헬스체크 실패 로그를 보고 네트워크 지표에서 대역폭 초과를 찾았다.

   조치

   • 원인을 찾은 즉시 Redis 노드를 cache.r7g.large 에서 기본 대역폭이 1.875Gbps 로 약 2배인 cache.r7g.2xlarge 로 스케일업했다.

   후속 조치

   • 네트워크 In/Out 대역폭의 초과 여부를 실시간으로 볼 수 있게 모니터링 대시보드를 강화했다. 주요 지표는 aws.elasticache.network_bytes_in, aws.elasticache.network_bytes_out, aws.elasticache.network_bandwidth_in_allowance_exceeded, aws.elasticache.network_bandwidth_out_allowance_exceeded, aws.elasticache.traffic_management_active 다.
   • 네트워크 대역폭이 임계치를 넘으면 곧바로 알림이 오도록 Datadog Alert 를 연동했다.
   • 응답이 자주 바뀌지 않는 데이터를 중심으로 Redis 하나에 기대던 구조를 Caffeine 로컬 캐시, Redis 원격 캐시, DB 로 이어지는 캐시 계층 구조로 바꿨다.
   • Redis 네트워크 대역폭 사용량을 줄이려고 CPU 사용량이 적고 압축과 해제가 빠른 Snappy 로 캐시 데이터를 압축하는 방안을 검토한다.
   • JSON 으로 저장하던 캐시 데이터를 Protocol Buffers 형식으로 바꾸는 방안을 검토한다. 팀이 캐싱 중인 Item Document 데이터로 재 본 결과, Snappy 압축과 protobuf 를 함께 쓰면 용량을 약 73% 줄일 수 있을 것으로 예상됐다.
   • 캐시 구조 개선, 모니터링 고도화, 읽기 분리 적용으로 기술 부채를 해소했고, 이를 바탕으로 트래픽 증가에 대비한 아키텍처 개선을 진행한다.

   교훈

   CPU 와 Memory 지표만으로는 Redis 대역폭 초과를 알아채기 어려웠고, 팀은 네트워크 관점의 모니터링이 필요하다는 것을 다시 느꼈다. 버스트 크레딧 구간이 있으면 Baseline 을 넘은 시점과 Throttling 이 시작된 시점 사이에 시간이 벌어져 원인을 찾기가 늦어진다. 트래픽이 더 늘면 스케일업만으로는 같은 문제가 되풀이될 수 있어 근본적인 재발 방지가 필요하다고 봤다.

   사례 보기
2. IL-0445 EKS 로 옮기던 레거시 시스템에서 conntrack 테이블이 넘쳐 연결이 끊겼고, 이어 CoreDNS 파드가 축출될 때와 node-local-dns 를 넣은 뒤에 DNS 오류가 났다

   Chatwork2021

   증상

   Route53 가중치로 EC2 와 EKS 를 함께 돌리며 레거시 시스템을 옮기던 중, 일정 비율이 넘는 요청을 EKS 쪽으로 보내자 서비스가 갑자기 불안정해졌다. 일부 노드에서 conntrack 테이블이 한계를 넘어 애플리케이션으로 가는 연결이 드롭되고 있었다.

   간헐적 연결 실패DNS 조회 실패간헐적 타임아웃부하 불균형

   촉발

   첫 번째 불안정은 Route53 가중치로 EKS 쪽에 보내는 요청 비율을 일정 이상으로 올리면서 시작됐다. 두 번째 불안정은 문서에 나온 매니페스트로 force_tcp 를 쓰는 node-local-dns 를 운영 환경에 apply 하면서 시작됐다.

   원인

   용량 한계

   구성 요소

   conntrack 테이블CoreDNSkube-proxy클라이언트 쪽 DNS 리졸버와 캐시VPC DNS 리졸버

   기여 요인

   기본 설정 방치스테이징 불일치한계 미인지

   조치

   • conntrack 상한이 기본값과 다른 값으로 설정되어 있었고 그 값은 kube-proxy 가 정하고 있었다. 팀은 kube-proxy 설정에서 conntrack 의 maxPerCore 를 늘렸다.
   • EKS 에 빠져 있던 dns-autoscaler 를 넣었다. CoreDNS 파드가 어느 정도 늘자 서비스가 크게 안정됐다.
   • CoreDNS 파드가 축출될 때 나던 DNS 오류를 없애려고 각 노드에 DaemonSet 으로 실행되는 node-local-dns 를 넣었다.
   • node-local-dns 설정에서 force_tcp 를 빼고 prefer_udp 로 바꾸자 DNS 가 안정됐다.

   교훈

   EKS 에서 DNS 를 안정시킨 것은 dns-autoscaler 를 넣은 것과, force_tcp 없이 node-local-dns 를 넣은 것 두 가지였다. node-local-dns 를 쓸 때는 eksctl 로 kubelet 의 DNS 대상을 바꿀 필요가 없고, kube-dns 를 그대로 두면 된다. node-local-dns 를 업데이트하는 동안처럼 잠시 쓸 수 없을 때는 dummy device 덕에 애플리케이션의 DNS 요청이 CoreDNS 로 바로 가므로 클러스터 전체의 가용성이 오른다. DNS 가 불안정하면 조회가 막혀 파드가 쓸데없이 늘어나므로, 파드 수를 알맞게 유지하는 데도 DNS 안정이 중요하다.

   사례 보기
3. IL-0012 CPU limit 과 커널 CFS 쿼터 버그로 파드가 과하게 스로틀링돼 헬스 체크가 실패하고 애플리케이션이 멈췄다

   Omio2020

   증상

   Omio 는 6개월 동안 원인을 알 수 없는 멈춤을 겪었다. 애플리케이션이 멈추거나 헬스 체크에 응답하지 않았고, 네트워크 연결이 끊겼다.

   CPU 스로틀링프로브 실패오류율 상승지연 시간 증가간헐적 타임아웃간헐적 연결 실패

   촉발

   쿠버네티스는 CPU limit 을 커널 CFS 의 쿼터로 구현한다. 주기는 100ms 이고, limit 2코어는 주기마다 CPU 시간 200ms 가 된다. 스레드 10개가 동시에 돌면 20ms 만에 쿼터를 다 쓰고, 남은 80ms 동안 파드의 모든 스레드가 멈춘다. 여기에 커널 CFS 스케줄러의 알려진 버그가 불필요한 스로틀링을 일으켜, 컨테이너가 허용된 쿼터를 다 쓰기도 전에 스로틀링됐다.

   원인

   소프트웨어 결함

   구성 요소

   컨테이너 CPU 한도리눅스 커널kubelet

   기여 요인

   한계 미인지모니터링 사각지대미패치 알려진 버그

   감지

   팀은 6개월 동안 애플리케이션이 멈추거나 헬스 체크에 응답하지 않는 현상을 겪었지만, 쿠버네티스가 cgroup 지표를 내보내지 않아 스로틀링을 바로 알아채지 못했다. 파드 안에서 /sys/fs/cgroup/cpu/cpu.stat 의 nr_throttled 와 throttled_time 을 읽어 스로틀링 비율을 확인했다.

   조치

   • 버그를 고친 최신 커널이 모든 클러스터에 배포될 때까지 CPU limit 을 껐다.

   후속 조치

   • CFS 쿼터 버그를 고친 최신 커널을 모든 클러스터에 배포한다.
   • 사용률, 포화도, 오류를 보는 USE 지표와 함께 API 지연과 오류율을 지켜보며 결과가 기대한 대로인지 확인한다.

   교훈

   CFS 쿼터 버그가 고쳐지지 않은 커널을 쓴다면 쿠버네티스에서 CPU limit 을 없애거나 kubelet 에서 CFS 쿼터를 끄는 편이 낫다. CPU request 와 limit 은 설정이 비슷해 보여도 구현이 전혀 다르다. CPU 스로틀링은 쿠버네티스 기본 지표에 드러나지 않으므로 cpu.stat 을 직접 확인해야 한다. limit 을 끄면 최적화되지 않은 애플리케이션이 노드의 CPU 를 독차지할 수 있으니, JVM, Go, Node 런타임을 미리 튜닝해 둬야 한다.

   사례 보기
4. IL-0013 노드 RAM 을 절반으로 줄이자 conntrack 테이블이 가득 차 집계 서비스에 연결 리셋과 오류가 늘었다

   loveholidays2020

   증상

   서비스 구조를 바꾸고 노드 풀 크기를 조정하고 하위 서비스를 샤딩한 직후, 집계 서비스에 여러 연결 문제가 생기고 오류율이 올라갔다.

   연결 리셋오류율 상승간헐적 연결 실패

   촉발

   집계 서비스가 도는 노드의 RAM 을 절반으로 줄였고, 하위 서비스를 샤딩하면서 추적해야 할 연결 수는 두 배가 됐다. conntrack_max 는 노드 RAM 에 비례하므로 노드가 추적할 수 있는 연결 수는 줄고 추적할 연결은 늘었다.

   원인

   용량 한계

   구성 요소

   conntrack 테이블kube-proxy노드 풀HAProxy

   기여 요인

   한계 미인지용량 계획 부재한계 경보 부재

   감지

   팀은 먼저 서비스의 연결 문제와 오류율 상승을 알아챘다. HAProxy 가 보고하는 연결 리셋 오류가 계속 늘었고, 팀은 node_nf_conntrack_entries 를 node_nf_conntrack_entries_limit 과 겹쳐 보고 일부 노드의 conntrack 테이블이 바닥난 것을 확인했다.

   조치

   • 집계 서비스를 RAM 이 더 큰 노드에 배치했다.
   • 노드 하나에 뜨는 집계 서비스 파드 수를 제한했다.

   후속 조치

   • conntrack 사용률이 75% 를 넘으면 경보가 가도록 Prometheus 쿼리 (node_nf_conntrack_entries / on (pod) node_nf_conntrack_entries_limit / on (pod) group_right kube_pod_info) > 0.75 로 경보 규칙을 만들었다.

   교훈

   쿠버네티스 노드의 conntrack_max 는 노드 RAM 에 비례해 정해진다. 부하가 큰 애플리케이션은 특히 작은 노드에서 conntrack_max 를 쉽게 넘겨 연결 리셋과 타임아웃을 일으킨다. 노드를 작게 바꾸면 추적할 수 있는 연결 수도 함께 줄어든다. conntrack 사용률은 지표로 보고 경보를 걸어 둬야 한다.

   사례 보기

원인별2