사례25건

25건 중 1~5번째

1. IL-0071 작은 파일이 4만 개 넘게 든 단일 스테이지 이미지의 containerd 스냅샷이 쌓여 워커 노드의 inode 가 디스크보다 빠르게 소진되고 있었다

   Onkar Raghunath Shelke2026

   증상

   워커 노드 한 대에서 NodeFilesystemFilesFillingUp 알림이 울려 담당자가 호출됐다. inode 가 바닥날 추세라는 알림이었다.

   노드 디스크 가득 참

   촉발

   단일 스테이지로 빌드한 이미지에 소스, 빌드 결과물, 개발 의존성까지 포함한 node_modules 전체가 들어갔고, 새 레이어 다이제스트가 생길 때마다 노드에 새 스냅샷이 풀렸다.

   원인

   용량 한계

   구성 요소

   노드 루트 디스크kubelet컨테이너 런타임

   기여 요인

   기본 설정 방치모니터링 사각지대한계 미인지

   감지

   node_exporter mixin 에 들어 있는 NodeFilesystemFilesFillingUp 알림이 inode 사용률 67% 에서 울렸다. predict_linear 로 inode 가 바닥날 시점을 예측하는 추세 알림이다.

   후속 조치

   • 멀티 스테이지 Dockerfile 로 바꿔, 한 스테이지에서 의존성을 설치하고 빌드한 뒤 최종 이미지에는 nginx:alpine 위에 컴파일된 결과물만 넣는다.
   • 추세 알림과 별도로 루트 파일 시스템의 inode 사용률이 0.80 을 넘으면 울리는 고정 기준 알림을 for: 30m 으로 둔다.
   • 노드마다 inode 사용률에서 디스크 사용률을 뺀 값을 큰 순서로 보여 주는 Prometheus 쿼리를 대시보드에 둔다.
   • 노드에 이미 쌓인 오래된 스냅샷은 crictl rmi --prune 으로 어떤 컨테이너도 쓰지 않는 이미지를 지워 정리한다.

   교훈

   kubelet 의 백그라운드 정리는 바이트를 기준으로 돈다. 용량보다 파일 수가 먼저 차는 워크로드에는 미리 손쓸 장치가 없다. kubelet 은 inode 가 5% 남았을 때 파드 축출로 처음 개입한다. 파드 축출은 노드를 지키는 마지막 수단일 뿐 해결책이 아니다. ext4 의 inode 수는 포맷할 때 정해진다. 작은 파일이 많으면 디스크가 넉넉해도 inode 가 먼저 바닥난다. 추세 알림은 증가가 잠시 멈추면 조용해진다. kubelet 의 95% eviction 지점보다 한참 앞에서 울리는 고정 기준 알림을 함께 둔다. node_modules 뿐 아니라 Python virtualenv, 벤더링한 PHP 패키지, Ruby gem 처럼 작은 파일이 많은 의존성 트리를 담은 이미지는 모두 같은 문제를 일으킨다.

   사례 보기
2. IL-0448 Job 파드가 15분 넘게 걸리는 LLM 에이전트 요청의 응답을 일정 확률로 받지 못하고 계속 기다렸다

   Uzabase2026

   증상

   클라이언트인 Job 파드가 LLM 에이전트에 경영 과제 추출을 요청하면 일정 확률로 응답이 돌아오지 않았다. 응답이 오지 않는 요청에 뚜렷한 규칙이 보이지 않아 조사가 초반에 막혔다.

   간헐적 타임아웃

   촉발

   LLM 에이전트가 리뷰를 여러 번 되풀이해 응답에 15분 넘게 걸렸고, 그동안 TCP 커넥션에 패킷이 오가지 않았다.

   원인

   DNS·네트워크 장애

   구성 요소

   kube-proxy

   기여 요인

   기본 설정 방치한계 미인지

   감지

   팀은 클라이언트 로그에서 Job 파드의 요청 일부에 응답이 돌아오지 않는 것을 확인했다.

   조치

   • Python 으로 쓴 클라이언트에서 httpx 의 소켓 옵션으로 SO_KEEPALIVE 를 켜고 TCP_KEEPIDLE 60, TCP_KEEPINTVL 30, TCP_KEEPCNT 3 을 설정해, 커넥션 유지용 패킷을 주기적으로 보내게 했다.

   교훈

   소프트웨어 엔지니어는 애플리케이션에만 관심을 두기 쉽지만 네트워크와 인프라 지식도 갖춰야 한다. AI 애플리케이션이 흔해지면서 응답까지 오래 걸리는 경우가 늘어날 것이므로, 원인을 알 수 없는 네트워크 오류가 나면 이 설정을 떠올릴 만하다.

   사례 보기
3. IL-0155 NYC1 의 일부 DOKS 클러스터에서 공유 CPU 노드 위의 CoreDNS 때문에 DNS 가 간헐적으로 실패하고 NodeNotReady 가 났다

   DigitalOcean2026

   증상

   2026-07-09 20:31 UTC 에 DigitalOcean 은 NYC1 리전의 쿠버네티스 배포에 문제가 있다고 알렸다. 사용자의 애플리케이션 워크로드에서 간헐적인 DNS 실패와 NodeNotReady 이벤트가 나타날 수 있다고 했다.

   DNS 조회 실패간헐적 타임아웃노드 NotReady

   원인

   용량 한계

   구성 요소

   CoreDNS노드 풀

   기여 요인

   한계 미인지

   교훈

   CoreDNS 는 지연에 민감하므로 공유 CPU 노드가 아닌 전용 CPU 노드 풀에서 돌리고, 복제본을 충분히 둔다.

   사례 보기
4. IL-0499 세션 서버가 대량으로 내려간 뒤 음성 통화 라우팅 서비스가 과부하로 멈춰 음성·영상 통화가 세 시간 넘게 연결되지 않았다

   Discord2026

   증상

   2026년 3월 25일 12:13 PDT부터 15:30 PDT까지 Discord 의 음성·영상 기능이 크게 망가졌다. 사용자 대부분이 통화를 시작하거나 참여하지 못했고, 통화 상태에는 “Awaiting Endpoint” 메시지가 떴다.

   서비스 중단

   촉발

   Elixir 서비스를 쿠버네티스로 옮기던 중, 주말 CPU 사용률을 낮추려고 sessions 서비스 파드의 CPU 와 메모리를 늘리고 파드 수를 그만큼 줄이는 변경을 배포했다. 레플리카 수가 줄자 쿠버네티스가 첫 번째 존의 파드 50% 를 종료했고, 진행 중인 다른 작업을 기다리는 안전 검사 때문에 핸드오프가 시작되기 전에 종료 유예 시간이 끝났다.

   원인

   설정 변경

   구성 요소

   파드 종료 처리코디네이션 키-값 저장소데이터베이스 프록시와 커넥션 풀러

   기여 요인

   재시도 폭주한계 미인지

   조치

   • 13:43 PDT까지 calls, streams, guilds 서비스에 낮은 syncer 생성 제한을 넣고 voice syncers 클러스터를 다시 재시작했다. 막히는 supervisor 가 gun supervisor 로 바뀌면서 인스턴스들이 etcd 등록을 유지했고 일부 syncer 의 RPC 를 SFU 로 보냈다.
   • 인스턴스를 골라 하나씩 다시 재시작했고, 14:03에 재시작한 인스턴스 2-3 처럼 일부 인스턴스가 완전히 회복했다.
   • 인스턴스 15대를 추가로 올려 voice syncers 클러스터의 용량을 두 배로 늘렸다. 새 인스턴스들은 메일박스 대기열 문제 없이 syncer 를 받았고, 인스턴스당 syncer 수가 절반이 됐다.
   • 14:26에 마지막으로 막혀 있던 인스턴스를 재시작해 두 배로 늘어난 클러스터가 완전히 정상이 됐다.

   후속 조치

   • Elixir 워크로드용 validating admission webhook 을 쿠버네티스 클러스터에 넣어, 파드가 프로세스를 다 넘기기 전에는 워크로드를 줄이는 업데이트를 거부한다.
   • 부하 테스트 뒤 Holster.Pool 의 supervisor 를 PartitionSupervisor 로 바꿔, 연결 풀 요청을 독립된 여러 supervisor 에 나누고 나가는 연결을 동시에 만들거나 꺼낼 수 있게 했다.
   • gun 연결 프로세스의 생명주기 관리를 그 프로세스를 만드는 Holster.Pool 로 옮겨 gun 연결 supervisor 를 아예 쓰지 않게 했다.
   • voice syncers 를 호출하는 상위 서비스의 속도 제한을 다시 조정해 더 정확히 걸리게 했다. 필요하면 로드 셰딩 도구로 이 제한을 강제로 적용해 voice syncer 를 다시 만들게 할 수도 있다.
   • voice syncers 의 엔드포인트 선택에 새 속도 제한을 넣고 조정해, 나가는 연결 생성을 제한하는 수단을 하나 더 뒀다.
   • HTTP 연결 풀링 메일박스에 감시를 더해 언제 문제가 되고 언제 아닌지 더 분명히 알 수 있게 했다.
   • 서비스 디스커버리 등록과 voice syncer 에서 SFU 로 가는 RPC 트래픽의 계측과 로그를 전부 검토하고 넓혔다.
   • 메일박스 상태 합계 같은 간접 지표 대신, 모든 서비스에서 가장 중요한 프로세스를 직접 감시하도록 넓혀 간다.
   • 더 많은 워크로드를 쿠버네티스로 옮겨, VM 을 손으로 준비하는 대신 명령 하나로 파드를 늘릴 수 있게 한다.
   • A/V 인프라의 컨트롤 플레인 서비스를 여러 리전에 수평 확장해 신뢰성과 리전 장애 내성을 얻고, 나가는 연결 급증을 전 세계에 고르게 흩는다.

   교훈

   충분히 큰 트래픽 급증은 시스템 어딘가의 병목을 찾아낸다. 이전의 큰 부하 장애에서는 여러 ScyllaDB 데이터베이스가 복구를 막았지만, 이번에는 데이터베이스가 잘 버텼고 병목이 음성 서비스로 옮겨 갔다. 용량 한계를 만나면 공급을 늘리거나 수요를 줄이는 두 길이 있고, Discord 는 장애 대응과 사후 조치를 정할 때 이 질문을 분명히 던진다. 장애 중에는 쓸 수 있는 도구를 알아야 한다. Elixir 와 BEAM 가상 머신에서는 어떤 프로세스의 상태든 꺼내 볼 수 있고 핫패치로 관측을 더할 수도 있다. 분산 시스템에서는 장애 모드를 따져야 한다. Elixir 프로세스는 메시지를 하나씩 처리하므로 바쁜 프로세스의 핵심 루프가 느려지면 서비스와 사용자 경험이 함께 나빠진다. Discord 는 사후 검토에서 장애를 어떻게 피할지뿐 아니라 일어난 뒤 어떻게 더 빨리 풀지도 물었고, 복구 시간을 줄이면 관계없는 장애에서도 더 빨리 회복할 수 있다고 봤다.

   사례 보기
5. 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 이 시작된 시점 사이에 시간이 벌어져 원인을 찾기가 늦어진다. 트래픽이 더 늘면 스케일업만으로는 같은 문제가 되풀이될 수 있어 근본적인 재발 방지가 필요하다고 봤다.

   사례 보기

원인별7