사례51건

51건 중 4~8번째

1. IL-0137 60노드 B200 학습 클러스터에서 노드들의 작은 랜덤 I/O 가 VAST 스토리지의 메타데이터 서비스를 포화시켜 학습 초기화가 8시간 넘게 걸렸다

   Lablup Inc2026

   증상

   60노드 B200 학습 구성을 운영 규모로 늘리자 VAST 스토리지에서 학습을 초기화하는 단계가 몇 분이 아니라 8시간 넘게 걸렸다. 그동안 처리량은 이론상 한계보다 훨씬 낮게 머물렀다. 2~4노드 규모로 한 초기 검증에서는 큰 문제가 없었다.

   처리량 저하

   촉발

   학습 구성을 2~4노드 시험 규모에서 60노드 운영 규모로 늘렸다.

   원인

   용량 한계

   구성 요소

   공유 네트워크 파일 시스템

   기여 요인

   스테이징 불일치모니터링 사각지대

   감지

   운영 규모로 늘린 뒤 학습 초기화가 몇 분이 아니라 8시간 넘게 걸리면서 드러났다. 애플리케이션 로그로는 초기화 지연만 보였다. 원인은 다섯 조직이 함께 쓰는 모니터링 파이프라인에서 애플리케이션, 스케줄러, 네트워크, 스토리지 지표를 같은 타임라인에 맞춰 본 뒤에야 찾았다.

   조치

   • 애플리케이션 쪽에서 Arrow 파일을 rank 별로 나누는 파일 샤딩을 적용했다.
   • 스토리지 쪽에서 동기 rm/unlink 대신 비동기 삭제를 쓰도록 바꿨다.
   • readahead 설정을 조정했다.

   교훈

   2~4노드 규모에서 본 성능 특성으로는 60노드에서 어떻게 동작할지 예측할 수 없었다. 이런 스토리지와 메타데이터 병목은 운영 규모에서만 드러나므로 작은 규모의 사전 시험으로는 찾기 어렵다. 이 규모에서는 한 팀이 따로 하는 모니터링만으로 근본 원인을 찾을 수 없었고, 조직 경계를 넘어 지표를 공유하는 파이프라인이 있어야 했다. GPU 용량을 늘리면서 그에 맞는 스토리지 처리 경로를 갖추지 않으면 운영 규모에서만 보이는 급격한 성능 저하가 생긴다.

   사례 보기
2. IL-0181 외부 커뮤니티 게시글로 트래픽이 몰려 상품 API 파드가 CPU limit 1코어에서 스로틀링되면서 상품 조회 페이지가 매우 느려졌다

   Kevin2026

   증상

   운영 중인 이커머스 플랫폼의 응답이 갑자기 느려졌다. 상품 조회 페이지가 특히 심했고, 사용자들에게서 "페이지가 안 열린다"는 문의가 들어왔다.

   CPU 스로틀링지연 시간 증가

   촉발

   외부 커뮤니티인 뽐뿌에 플랫폼 링크가 담긴 게시글이 올라와 짧은 시간에 많은 사용자가 몰렸고, 이 사용자들이 상품 조회 API 를 집중적으로 호출했다.

   원인

   용량 한계

   구성 요소

   컨테이너 CPU 한도수평 파드 오토스케일러

   기여 요인

   모니터링 사각지대

   감지

   사용자에게서 "페이지가 안 열린다"는 문의가 들어와 장애를 알았다. 대시보드의 파드 상태는 정상이었고, 네임스페이스 CPU 사용량과 CPU 메트릭을 직접 보고서야 CPU 스로틀링을 확인했다.

   조치

   • HPA 의 minReplicas 를 5에서 10으로 늘렸다.
   • Deployment 의 CPU limit 을 1코어에서 2코어로 올렸다.

   후속 조치

   • CPU limit 을 무작정 높이면 노드 자원을 과하게 차지할 수 있으므로, 모니터링하면서 적정 수준으로 계속 조정한다.

   교훈

   글쓴이는 예측 가능한 이벤트성 트래픽까지는 받아낼 수 있게 설정해 뒀다고 생각했다. 그러나 외부 커뮤니티 게시글 하나로 트래픽이 폭증하자 그동안 문제없던 리소스 설정이 순식간에 병목이 됐다. CPU 스로틀링은 파드 상태와 로그에 드러나지 않아서 파드 목록이 아니라 CPU 메트릭을 봐야 찾을 수 있었다. 글쓴이는 대규모 트래픽에 미리 대비한 경험이 부족했다고 돌아보고, 트래픽 패턴이 바뀔 때의 대비와 리소스 설정을 더 고민하기로 했다.

   사례 보기
3. IL-0129 SmolLM3 사전 학습에서 공유 Weka 스토리지가 데이터셋 샤드를 S3 로 내보내고 Nanotron 데이터로더의 인덱스가 스텝마다 커지면서, 학습을 시작한 지 몇 시간 만에 처리량이 거듭 급락했다.

   Hugging Face2025

   증상

   Hugging Face 팀은 SmolLM3 본 학습을 시작했다. 48개 노드의 H100 GPU 384개로 11T 토큰을 학습하는 일정이었다. 시작하고 몇 시간 안에 처리량이 가파르게 떨어졌고, 이런 급락이 여러 번 되풀이됐다. 처리량은 학습 중 초당 처리하는 토큰 수다. 처리량이 50% 떨어지면 한 달짜리 학습이 두 달짜리가 된다.

   처리량 저하

   촉발

   팀은 약 24 TB 전체 데이터셋을 여러 팀이 함께 쓰는 Weka 스토리지에 두고, 11T 토큰에 맞춘 실제 스텝 수로 본 학습을 시작했다.

   원인

   용량 한계

   구성 요소

   공유 네트워크 파일 시스템학습 데이터 로더

   기여 요인

   장애 중첩스테이징 불일치미검증 가정

   감지

   팀은 학습 중 초당 토큰 처리량을 기록하고 있었다. 학습을 시작하고 몇 시간 안에 이 값이 급락하는 것이 보였다. SmolLM3 에서 기대한 처리량은 초당 13,500에서 14,000 토큰이었다. 팀은 처리량이 이 범위를 계속 벗어나면 위험 신호로 보았다. 그리고 노드 모니터링 지표에서 처리량이 떨어진 시점과 디스크 읽기 지연이 급증한 시점이 겹치는 것을 보고 스토리지를 원인으로 짚었다.

   조치

   • 데이터셋을 Weka 에서 빼서 각 노드의 로컬 NVMe RAID 스크래치 스토리지에 올렸다.
   • 교체한 노드에 데이터를 채울 때 S3 에서 s5cmd 로 24 TB 를 받으면 3시간이 걸렸다. 그래서 같은 데이터센터의 정상 노드에서 fpsync 로 복사해 1.5시간으로 줄였다.
   • 데이터셋을 미리 올려 둔 예비 노드 하나를 Slurm 예약에 넣어 두고, 노드가 죽으면 바로 예비 노드로 바꿨다.
   • 노드 하나에서도 급락을 재현해 하드웨어를 원인에서 뺐고, 약 3M 스텝과 32k 스텝으로 각각 돌려 원인을 스텝 수로 좁혔다.
   • Nanotron 의 nanosets 데이터로더를 SmolLM2 에서 쓰던 TokenizedBytes 데이터로더로 바꿔 넣자 급락이 사라졌다.
   • TokenizedBytes 로 바꾼 뒤 손실이 거칠어진 문제를 고치려고, 토큰화된 시퀀스를 에포크마다 다른 시드로 오프라인에서 미리 섞었다. 이 작업에 약 1시간이 걸렸다.

   교훈

   마감이 급할 때는 자기 구현을 디버깅하는 것보다 검증된 해법이나 빠른 우회책을 가져오는 편이 빠를 수 있다. 팀은 nanosets 의 인덱스 구현을 고치는 대신 TokenizedBytes 데이터로더를 가져왔다. 손실 문제도 데이터로더에 손대지 않고 오프라인에서 시퀀스를 미리 섞어 풀었다. 다만 임시방편을 너무 많이 쓰면 유지보수와 최적화가 어려운 누더기 시스템이 된다. 팀은 어블레이션과 본 학습 사이에 무엇이 바뀌었는지 정확히 알고 있었기 때문에 데이터셋 크기, 스텝 수, 하드웨어 상태를 하나씩 지워 가며 원인을 좁힐 수 있었다. 두 번째 문제는 처리량이 안정됐던 SmolLM2 의 데이터로더를 대규모로 검증하지 않은 데이터로더로 바꾸면서 생겼다.

   사례 보기
4. IL-0100 노드가 파드의 CPU 요청에 비해 작아 CPU 가 포화되면서 PostHog 기능 플래그 서비스에 열흘 사이 장애가 세 번 났다.

   PostHog2025

   증상

   2025-10-21 21:45 UTC, 타임아웃 오류를 줄이려는 배포 직후 자동 모니터링이 기능 플래그 서비스의 오류율 상승을 잡았다. 2분 만에 롤백했지만 오류율은 내려가지 않았고, US 데이터센터에서 평가 요청의 약 38% 가 오류를 냈다.

   노드 CPU 고부하오류율 상승지연 시간 증가컨테이너 재시작 반복데이터베이스 과부하

   촉발

   10월 21일에는 증상만 고치려던 타임아웃 처리 배포가 장애를 일으켰다. 28일에는 플래그 서비스와 무관한 일상 배포가 파드 롤아웃을 일으켰고, 이 롤아웃이 장애로 이어졌다. 24일에는 로드밸런서 뒤에서 모든 트래픽을 IP 하나에서 온 것으로 본 레이트 리밋 배포가 장애를 일으켰다.

   원인

   용량 한계

   구성 요소

   노드 풀파드 스케줄링과 배치인메모리 캐시애플리케이션 데이터베이스

   기여 요인

   한계 경보 부재재시도 폭주롤백 무효단일 장애점단계적 배포 부재스테이징 불일치

   감지

   21일에는 배포 2분 뒤 자동 모니터링이 오류율 상승을 잡았고, 28일에는 온콜이 높은 오류 수 경보를 받았다. PostHog 는 대부분의 경우 2분 안에 감지했다고 정리했다. 24일에는 429 오류 경보가 없어서 18:10 UTC 부터 들어온 고객 신고로 알았고, 감지까지 62분이 걸렸다. CPU 경보가 아예 없어서 공통 원인인 CPU 포화는 오래 드러나지 않았고, 29일에서 30일 사이 장애는 7시간 넘게 이어졌다.

   조치

   • 10월 21일 타임아웃 처리를 바꾼 배포를 2분 안에 롤백했지만 오류는 멈추지 않았다.
   • 10월 21일 23:00 UTC 부터 연결과 Redis 쓰기를 조절해 23:28 UTC 에 서비스를 복구했다.
   • 10월 28일 롤아웃을 멈추고 US 플래그 파드를 0개로 줄여 Redis 가 회복되기를 기다린 뒤, 파드를 차례로 다시 올렸다.
   • 10월 30일 00:03 UTC 에 하드웨어 변경을 롤백해 오류는 대부분 가라앉혔지만 지연은 남았다.
   • 파드 리소스 요청을 늘리고 쿠버네티스 플릿 크기를 조정해 노드당 파드 수를 줄였다.
   • 로드밸런서와 서비스 사이 Envoy 재시도에 한도를 걸었다.
   • 데이터베이스 연결 타임아웃과 다른 중요한 설정을 런타임 설정으로 옮기고, 타임아웃 값을 피크 부하에 맞게 늘렸다.
   • 노드마다, 파드마다 CPU 사용률이 80% 를 5분 동안 넘으면 온콜을 호출하는 CPU 경보를 추가했다.

   후속 조치

   • 플래그, 수집, 인프라 팀 엔지니어로 전담 팀을 꾸려 애플리케이션과 인프라 전체를 살피고 남은 병목을 찾는다.
   • 플래그 서비스의 Redis 를 본 애플리케이션의 Redis 와 분리하는 방안을 검토한다.
   • ArgoCD 동기화를 다시 켜기 전에 플래그 서비스 차트 설정을 ArgoCD 의 현재 값에 맞추고, 배포 전략과 Redis 전략을 정한다.
   • 플래그 관련 코드의 필수 코드 오너를 기능 플래그 팀으로 정한다.
   • 중요한 플래그 지표와 런북 링크를 한데 모은 대시보드를 만들고, 기능 플래그 런북을 고친다.
   • 기존 서비스 지표와 인프라 지표에 빠져 있는 경보를 추가한다.
   • readiness 검사가 liveness 검사를 그대로 따라 하지 않고, 데이터베이스에 ping 을 보내는 식으로 부하가 걸렸을 때 약해졌던 의존성을 확인하게 바꾼다.
   • 캐시 채우기 작업에 레이트 리밋을 걸어 Redis 에 감당하지 못할 만큼 작업이 몰리지 않게 한다.
   • 연결 풀을 모니터링해 풀이 바닥에 가까워지면 자동으로 요청을 조절하고, 동시 연결 수에 상한을 둔다.
   • 운영 규모의 부하 시험 체계를 만든다.
   • 점진적 롤아웃 기반을 만들어 배포가 미치는 범위를 줄인다.
   • Postgres 에서 Redis 로 가는 데이터 흐름을 문서로 정리하고, 데이터 전송이 한꺼번에 몰릴 때 쓸 런북을 만든다.

   교훈

   가장 큰 교훈은 CPU 크기 산정이었다. 노드가 파드 요청에 비해 작으면 노드 하나에 파드가 너무 많이 몰리고, CPU 포화가 과도한 병렬 처리, 연결 풀 고갈, 느린 쿼리처럼 서로 다른 모습으로 나타난다. 증상만 고친 수정 때문에 21일의 장애가 28일에 되풀이됐다. PostHog 는 CPU 를 넉넉히 받은 파드를 적은 수로 돌리는 편이 낫다고 정리했다. 기능 플래그 서비스와 본 애플리케이션이 Redis 를 같이 쓰면 한쪽 과부하가 다른 쪽을 쓰러뜨리는 단일 장애 지점이 된다. CPU 지표는 처음부터 경보로 걸어야 하고, Postgres 에서 Redis 로 가는 전송 급증도 경보 대상이다. 재시도, 캐시 채우기, 연결 생성에 한도가 없으면 장애가 커진다. 과부하 패턴은 운영 트래픽에서만 드러났으므로 부하 시험이 필요하고, 중요한 설정은 배포 없이 바꿀 수 있어야 한다.

   사례 보기
5. IL-0048 대형 EKS 클러스터에서 CoreDNS 가 VPC DNS 리졸버로 보내는 질의가 링크 로컬 트래픽의 초당 1024 패킷 한도에 걸려 DNS 조회가 간헐적으로 타임아웃됐다.

   unknown2025

   증상

   처음 들어온 보고는 CI 가 간헐적으로 실패한다는 것이었다. 실패는 tensorstore 안에서 났고, 오류는 ./tensorstore/util/result.h:420: Status not ok: status(): UNAVAILABLE: CURL error Could not resolve hostname: Could not resolve host: company-bucket.s3.amazonaws.com 이었다.

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

   촉발

   호스트 네트워크를 쓰는 시스템 관리용 파드가 몇 초마다 sudo 명령을 실행했다. sudo 는 기본 설정에서 실행할 때마다 노드 자신의 호스트 이름을 조회했다. 파드의 resolv.conf 에 있는 ndots:5 와 검색 도메인 네 개 때문에 이 조회 하나가 A 와 AAAA 를 합쳐 질의 열 번이 됐고, CoreDNS 캐시에 걸리지 않은 질의가 VPC DNS 리졸버로 몰렸다.

   원인

   용량 한계

   구성 요소

   CoreDNS클라이언트 쪽 DNS 리졸버와 캐시VPC DNS 리졸버

   기여 요인

   한계 미인지기본 설정 방치

   감지

   CI 가 간헐적으로 실패한다는 보고가 시작이었다. tensorstore 가 company-bucket.s3.amazonaws.com 의 DNS 조회에 실패했다는 오류를 냈다. 글쓴이는 kubectl logs 로 CoreDNS 파드 로그를 뒤져 i/o timeout 오류를 찾았다.

   조치

   • 컨테이너 이미지에 /etc/sudoers.d/00-no-fqdn 파일로 Defaults !fqdn 을 넣어 sudo 가 호스트 이름을 조회하지 않게 했다.

   교훈

   EC2 에서 링크 로컬 주소로 가는 VPC DNS 질의에는 초당 1024 패킷의 한도가 있다. 한도를 넘은 UDP 패킷은 버려지는데, 보낸 쪽은 이를 알 수 없다. 노드에서 ethtool -S eth0 | grep linklocal_allowance_exceeded 로 이 한도에 걸렸는지 볼 수 있다. ndots:5 와 검색 도메인 때문에 FQDN 이 아닌 이름 하나가 질의 다섯 번이 되고, AAAA 까지 물으면 열 번이 된다. sudo 는 기본 설정에서 실행할 때마다 호스트 이름을 조회하므로, sudo 를 자주 부르는 파드는 DNS 트래픽을 많이 만든다.

   사례 보기

원인별1