{"id":"IL-0296","org":"Transloadit","date":"2016-05-30","docs":[],"title":{"en":"Transloadit's us-east Redis cluster lost queued jobs and heartbeats, raising WORKER_JOB_ERROR errors for 81 customers","ko":"Transloadit 의 us-east 리전 Redis 클러스터가 대역폭에 막혀 작업과 하트비트를 잃었다"},"domain":["database","aws"],"impact":{"scope":"Job queueing and heartbeats between Uploaders and Drones in the us-east region; slower Assemblies and some that could not be replayed","users":"81 customers","region":"us-east"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"To handle more traffic Transloadit had to use fewer Redis nodes, not more: each added replica multiplied the replication traffic from the single leader that takes every write, so scaling up the number of nodes was the wrong call. Bandwidth had not been among the monitored Redis metrics.","ko":"Redis 노드를 늘린 것은 잘못된 판단이었다. 모든 쓰기를 리더 한 대가 받는 구조에서는 노드가 늘수록 리더가 복제로 내보낼 트래픽이 늘어, 더 많은 트래픽을 감당하려면 노드를 오히려 줄여야 했다. 잃은 데이터를 다시 넣을 수 있으므로 팀은 복제가 꼭 필요한지 다시 따져 봤다. 지표는 이미 많이 지켜보고 있었지만 알림을 제대로 걸 수 있는 지표는 몇 개뿐이어서, 고른 지표가 모자랐을 수 있다. 대역폭도 빠져 있었다. 쓰기를 받는 Redis 노드가 하나뿐이면 replica 를 줄이거나 노드를 키워도 시간을 조금 벌 뿐이고, 성장을 버티려면 트래픽을 나눠야 한다."},"related":[],"sources":[{"url":"https://transloadit.com/blog/2016/05/redis-problems/","kind":"blog","archived":"https://web.archive.org/web/20260618051606/https://transloadit.com/blog/2016/05/redis-problems/"}],"summary":{"en":"Transloadit queues Jobs and passes heartbeats between Uploaders and Drones through a regional Redis cluster on AWS Elasticache. HLS splits large videos into many small fragments and can mean a thousand times more metadata for each video, and a steep rise in HLS traffic, combined with more Drones being online, saturated the network bandwidth of the 3 node us-east cluster. Jobs and heartbeats were lost and 81 customers were affected. Transloadit found no change to its own code or infrastructure that explained the sudden saturation.\n\nAs a stopgap the team re-added lost messages and relaxed heartbeat monitoring, which made Assemblies take longer. A wider investigation found that Redis was not on the latest version, which fixed several bugs including some marked as data loss fixes, so Redis was upgraded; an audit of the client library found no problems; and monitoring, metrics and alerts were extended. Once bandwidth throttling was clear, the cluster was doubled to six nodes and then grown to nine, which made it worse: every write went to the leader, which now had to replicate it to eight nodes instead of two, four times the outgoing traffic, for data that is write-heavy and deleted soon after it is written. Because missing data can be re-added and Elasticache requires replication for automatic failover, the team cut the read replicas down to one, and traffic, failure rates and Assembly times dropped immediately.\n\nAfterwards Transloadit added logging and alarms for approaching saturation, capped how far Drones scale up in each region, and began adding sharding per Uploader on top of the existing sharding per region, because a single Redis node accepting all writes could not carry further growth.","ko":"Transloadit 의 Uploader 는 파일을 받아 Assembly 를 조율하고 Drone 은 인코딩 작업을 실행한다. 둘은 리전별 Redis 클러스터의 Job 대기열과 하트비트로 이어져 있다. WORKER_JOB_ERROR 가 늘었다는 신고가 들어오자 팀은 Twitter 와 transloaditstatus.com 에 알리고 조사했다. us-east 리전 Redis 클러스터에서 Job 과 하트비트가 사라지고 있었다. 먼저 잃은 메시지를 다시 넣고 하트비트 감시를 느슨하게 하는 임시 조치를 했다. 이 조치는 증상만 막을 뿐이었고 Assembly 실행 시간도 늘었다. 팀은 놓친 Redis 패치를 찾아 최신 안정 버전으로 올렸고, 클라이언트 라이브러리를 전부 점검했으며, 모니터링과 지표, 알림, 로그를 보강했다. 쓰던 Redis 버전에는 [FIX] Fixed data loss 로 표시된 버그를 포함해 여러 버그가 남아 있었고, 클라이언트 라이브러리에서는 문제를 찾지 못했다. 대역폭은 지켜보지 않았는데, 노드 세 대의 네트워크 카드가 모두 포화돼 있었다.\n\n대역폭 제한에 걸린 것을 알고 클러스터를 여섯 대로 늘려 읽기 처리량이 약 6Gbit/s 가 되기를 기대했지만, 클러스터는 곧 다시 포화됐다. 세 대를 더 붙이자 더 나빠졌고, 리더 혼자 약 4Gbit/s 를 내보내고 있었다. 원인은 복제였다. 모든 쓰기가 리더로 가고, 리더는 쓴 데이터를 replica 둘이 아니라 여덟 대에 동기화해야 해서 일과 나가는 트래픽이 네 배가 됐다. 데이터는 쓰기가 많고 금방 쓸모가 없어지는 성격이라 복사한 뒤 곧 다시 지워야 했다. 잃은 데이터를 다시 넣을 수 있으니 팀은 복제가 꼭 필요한지 다시 따져 봤다. AWS ElastiCache 에서는 자동 장애 조치를 쓰려면 복제가 필수라서 읽기 replica 를 하나로 줄였다. 로그에서 트래픽과 실패율이 바로 떨어졌고 Assembly 도 다시 빨라졌다.\n\n갑작스러운 포화를 설명할 코드나 인프라 변경은 찾지 못했지만, HLS 트래픽이 가파르게 늘었다. HLS 는 큰 영상을 작은 조각 여러 개로 나누기 때문에 영상 하나에 오가는 메타데이터가 천 배까지 늘 수 있다. 여기에 Drone 을 더 많이 띄울 수 있게 되면서 중앙 노드가 바빠졌고, 두 변화가 겹쳐 병목이 드러났다. 팀은 Redis 노드를 늘린 것이 잘못된 판단이었다고 밝혔다. 그사이 리전마다 Drone 확장에 상한을 두었고, 리전별 샤딩에 더해 Uploader 별 샤딩을 준비했다. 크게 영향받은 고객에게는 일주일 무료 서비스를 제안했다."},"trigger":{"en":"A steep increase in HLS traffic, together with more Drones online processing the same volume faster, which put more load on the central Redis nodes.","ko":"HLS 트래픽이 가파르게 늘었고, 같은 양을 더 빨리 처리하려고 Drone 을 더 많이 띄울 수 있게 되면서 중앙 노드가 바빠졌다. 이를 설명할 코드나 인프라 변경은 찾지 못했고, 이 두 변화가 겹쳐 Redis 병목이 드러났다."},"severity":"unknown","symptoms":["high-error-rate","high-latency","uneven-load"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Reports of an increased number of WORKER_JOB_ERROR errors.","ko":"WORKER_JOB_ERROR 오류가 늘었다는 신고가 들어와 문제를 알았다. 모니터링은 Redis 명령 수, 연결 수, 스왑 사용량을 보고 있었지만 대역폭은 보지 않아 포화를 잡지 못했다."},"components":["cache","database-replication"],"root_cause":"capacity","remediation":[{"text":{"en":"Re-added lost messages and relaxed heartbeat monitoring as a stopgap","ko":"잃은 메시지를 다시 넣고 하트비트 감시를 느슨하게 하는 임시 조치를 했다. 증상만 막는 조치였고 Assembly 실행 시간이 늘었다."}},{"text":{"en":"Upgraded Redis to the latest stable version","ko":"놓친 Redis 패치가 있는지 확인하고 Redis 를 최신 안정 버전으로 올렸다."}},{"text":{"en":"Doubled the Redis cluster to six nodes and then added three more, which made it worse","ko":"대역폭 제한에 걸린 것을 알고 Redis 클러스터를 두 배인 여섯 대로 늘렸다. 곧 다시 포화되자 세 대를 더 붙였지만 상황은 더 나빠졌다."}},{"text":{"en":"Brought the number of read replicas down to one, which cut traffic and failure rates","ko":"읽기 replica 를 하나로 줄였다. 트래픽과 실패율이 바로 떨어졌고 Assembly 가 다시 빨라졌다."}},{"text":{"en":"Capped how far Drones scale up in each region","ko":"리전마다 Drone 확장에 상한을 두었다. 큰 배치 가져오기는 시간이 더 걸릴 수 있지만 시스템은 안정을 유지한다고 밝혔다."}}],"action_items":[{"text":{"en":"Add logging and alarms for approaching saturation","ko":"포화 수준에 다시 가까워지면 알 수 있도록 로그와 알림을 더 둔다."}},{"text":{"en":"Find ways to decentralise the traffic between the Redis nodes and the Drones and Uploaders","ko":"Redis 노드와 Drone, Uploader 사이의 트래픽을 한곳에 몰리지 않게 나눌 방법을 찾는다."}},{"text":{"en":"Add sharding per Uploader on top of the sharding per region","ko":"이미 하고 있는 리전별 샤딩에 더해 Uploader 별 샤딩을 추가한다."}}],"contributing":["monitoring-blind-spot","assumption-unverified","manual-action-worsened"],"recurrence_of":null,"symptoms_text":{"en":"Reports came in of more WORKER_JOB_ERROR errors, which tell Transloadit there is a communication problem between its Uploaders, the machines that receive files and orchestrate Assemblies, and its Drones, the machines that run encoding tasks. Many Assemblies became much slower because retries with exponential back-off kicked in, and a few could not be replayed.\n\nLogs and debugging showed that Jobs queued in the us-east regional Redis cluster were being lost, along with the heartbeats between Uploaders and Drones that let a Job move to another Drone when its Drone stops sending them. Redis commands, connections and swap usage were monitored, but bandwidth was not, and saturating the network cards of a 3 node cluster had seemed unlikely; on a closer look that was exactly what was happening.\n\nDoubling the cluster to six nodes raised bandwidth use at once, but it quickly reached new saturation points and many Assemblies stayed slow. Adding three more nodes made things worse: the cluster leader alone was sending about 4Gbit/s of outgoing traffic, more than Amazon advertises as possible, while traffic on the other Redis nodes stayed within limits, even though reads should have been spread across the whole cluster.","ko":"WORKER_JOB_ERROR 오류가 늘었다는 신고가 들어왔다. 이 오류는 파일을 받아 Assembly 를 조율하는 Uploader 와 인코딩을 실행하는 Drone 사이의 통신에 문제가 있다는 뜻이다.\n\n재시도 덕분에 Assembly 대부분은 데이터 손실 없이 다시 실행할 수 있었지만, 몇몇은 다시 실행되지 않았고 많은 Assembly 가 지수 백오프 재시도 때문에 훨씬 느려졌다. 고객 81곳이 영향을 받았다.\n\n로그를 뒤지고 코드를 디버깅해 보니 us-east 리전 Redis 클러스터에 넣은 Job 이 사라지고 있었고, Uploader 와 Drone 사이의 하트비트도 사라지고 있었다. 시스템은 하트비트를 지켜보다가 Drone 이 하트비트를 멈추면 그 Job 을 다른 Drone 에 넘긴다.\n\nRedis 명령 수, 연결 수, 스왑 사용량은 보고 있었지만 대역폭은 보지 않았다. 미국의 Redis 클러스터는 노드 세 대였고 그 네트워크 카드를 모두 채울 리 없다고 여겼지만, 실제로는 세 대 모두 대역폭이 가득 차 있었다.\n\n클러스터를 여섯 대로 늘리자 대역폭 사용량은 바로 늘었지만 곧 다시 포화됐고 Assembly 는 여전히 느렸다. 세 대를 더 붙이자 상황이 더 나빠졌다. 바깥으로 나가는 트래픽 대부분을 클러스터 리더가 내보내고 있었고, 리더는 약 4Gbit/s 로 Amazon 이 안내하는 한도보다 많은 트래픽을 내보낸 반면 다른 노드의 트래픽은 한도 안에 있었다."},"updated_at":"2026-11-14T12:33:55.097860Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0296","org_slug":"transloadit"}