사례2건

2건 중 1~2번째

1. IL-0353 미국 서부 에지의 fly-proxy 가 과부하에 빠져 요청이 수백 밀리초에서 몇 초씩 밀렸다

   Fly.io2026

   증상

   미국 서부 리전에서, 처음에는 주로 SJC 에서 에지가 반복해서 흔들렸다. 로그와 지표에서는 fly-proxy 가 처리 중인 요청에 필요한 항목만 읽어 오는 lazy loader 의 지연이 500 ms 에서 몇 초까지 높게 나왔다. 새 요청도 그만큼 더 기다린 뒤에야 처리됐다.

   지연 시간 증가

   원인

   용량 한계

   구성 요소

   CDN 과 엣지 네트워크서비스 디스커버리

   기여 요인

   용량 계획 부재한계 미인지장애 중첩

   감지

   Fly.io 는 미국 서부 리전에서, 처음에는 주로 SJC 에서 에지가 흔들리는 것을 알아챘다. 로그와 지표에서 lazy loader 지연이 500 ms 에서 몇 초까지 높게 나왔다.

   조치

   • Corrosion 에 상태가 아주 큰 앱을 원인으로 보고 임시 완화책을 넣은 뒤 SJC 에 프록시를 배포했다. 잠시 나아졌지만 새 프로세스가 워밍업을 마치자 지연이 다시 치솟았다.
   • 서버 몇 대가 빠져 용량이 모자란 SJC 에서 Anycast 트래픽을 LAX 로 옮겼다. 처음에는 나아졌지만 얼마 뒤 LAX 도 버거워했다.
   • Airtime 의 대역폭 한도를 낮췄다. softirq CPU 사용률과 호스트 load average 는 내려갔지만 lazy loader 질의는 계속 느렸다.
   • 프록시를 재시작하면서 종료를 기다리던 프록시 프로세스를 모두 강제로 죽여 lazy loader 문제를 풀었다. 이것으로 첫 고비가 끝났다.

   후속 조치

   • 앞으로 몇 주에서 몇 달 사이에 에지 용량을 크게 늘린다.
   • 프록시 인스턴스가 여럿 함께 떠 있게 만든 버그를 고쳤다.
   • Airtime 이 돌고 있는 프록시가 기대한 활성 인스턴스가 아닐 때는 당분간 훨씬 엄격한 한도를 쓰도록 바꿨다.
   • lazy loader 의 로드 셰딩 동작을 고쳐 요청 처리 지연의 최대값에 합리적인 상한이 생기게 했다.
   • 프록시 메모리 안 서비스 카탈로그를 샤드로 나누고 더 잘게 나눈 락으로 바꾼다. 이 전환이 장애를 더 내지 않도록 Antithesis 같은 테스트를 함께 쓴다.
   • Airtime 이 프록시만이 아니라 시스템 전체 부하에 맞춰 반응하도록 다시 만든다. 프록시 프로세스가 여럿 떠 있거나 같은 호스트의 다른 프로세스가 대역폭 여유를 쓸 때도 안전장치가 되게 한다.
   • 프록시가 기대한 구성으로 돌지 않을 때를 더 잘 감시하는 방법을 찾는다.

   사례 보기
2. IL-0275 Kafka 브로커들이 네트워크 한계에 닿아 줄줄이 쓰러지면서 Parse.ly 의 데이터 처리가 멈추고 대시보드에 몇 시간 동안 새 데이터가 나오지 않았다

   Parse.ly2015

   증상

   2015년 3월 26일 목요일 밤, 첫 장애가 나자 PagerDuty 가 한밤중에 온콜 엔지니어를 깨웠다. Munin, Sentry, Pingdom 같은 모니터링 도구에서 장애 보고가 쏟아졌고, Graphite 그래프에도 장애가 보였다. 고객 사이트는 JavaScript 코드를 계속 불러왔지만 분석 데이터가 실시간 처리 스트림으로 흘러 들어오지 않았고, 대시보드에 새 데이터가 나오지 않았다.

   서비스 중단DNS 조회 실패

   촉발

   2015년 3월 27일 금요일 데이터 양이 한계를 넘어 Kafka 브로커들이 운영체제 네트워크 한계에 닿았고, 한 대가 쓰러지자 나머지가 차례로 쓰러졌다. 그 뒤 클러스터를 넓히려고 넣은 새 브로커들이 잘못된 호스트 이름으로 들어왔다.

   원인

   용량 한계

   구성 요소

   메시지 브로커서비스 디스커버리

   기여 요인

   모니터링 사각지대한계 미인지여유 용량 부재수동 조치 악화

   감지

   Munin, Sentry, Pingdom 같은 모니터링 도구에서 장애 보고가 쏟아졌고 Graphite 그래프에서도 확인했다. 첫 장애 때 PagerDuty 가 한밤중에 온콜 엔지니어를 깨웠다.

   조치

   • Kafka 클러스터를 넓히려고 노드를 몇 대 더했다.
   • 새 Kafka 노드에 올바른 설정을 넣고 클러스터에 배포했다.
   • Apache Storm 으로 하위 컨슈머 시스템을 모두 천천히 다시 켜고, 쌓인 데이터를 다시 처리했다.
   • Amazon S3 에 보관한 원시 데이터로 모든 고객 계정에 데이터를 다시 채우기 시작했다.

   교훈

   호스트와 운영체제의 한계까지 생각하면 장애를 피할 수 있는 시스템은 없다. CPU 와 디스크 I/O 는 장비 상태를 잘 보여 주지만, 서서히 늘어나는 네트워크 사용률은 더 해롭고 지켜보기도 어렵다. CPU 는 100% 의 뜻이 분명하지만 네트워크 사용률 100% 는 대부분의 노드에서 뜻이 분명하지 않고, 특히 VM 이 호스트를 나눠 쓰는 클라우드에서 그렇다. 원시 데이터 보관을 웹 서버 로그, 일반 파일, Amazon S3 업로드처럼 단순한 방식으로 하고 실시간 처리 스트림과 완전히 떼어 둔 덕분에 Parse.ly 는 영구 데이터 손실을 걱정하지 않아도 됐다. 기계 한두 대가 아니라 서브시스템 전체가 꺼져 하위 시스템이 손쓸 수 없게 되는 연쇄 장애 상황을 더 깊이 생각해야 한다.

   사례 보기

원인별1