{"id":"IL-0280","org":"New Relic","date":"2021-07-29","docs":[],"title":{"en":"Kafka brokers in many New Relic cells ran out of disk, leaving US data collection and alerting unusable for hours","ko":"New Relic US 리전의 여러 NRDB 셀에서 Kafka 브로커가 디스크 부족으로 잇따라 멈춰 고객이 몇 시간 동안 데이터 수집과 알림을 쓸 수 없었다"},"domain":["database"],"impact":{"scope":"Data collection and alerting were unusable for many customers for multiple hours; Kafka brokers failed across many NRDB cells and data processing was widely disrupted","users":"many customers in the US region","region":"US region"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Cell isolation is the strongest protection against a widespread disruption, and emergency tools have to respect it just as normal operations do. Emergency response tools must be safe to use in chaotic situations without losing their ability to work. Engineers' attention is limited, so incident response processes and alerts need regular review to direct it at the most important signal.","ko":"셀 격리는 넓은 장애를 막는 가장 강한 보호 수단이다. 평소 운영뿐 아니라 긴급 도구도 이 격리를 지켜야 한다. 긴급 대응 도구는 혼란스러운 상황에서도 안전하게 쓸 수 있어야 하고, 그러면서도 필요한 기능은 빠짐없이 갖춰야 한다. 사람의 주의력은 한정되어 있으므로 장애 대응 절차와 알림을 계속 다시 따져 엔지니어의 주의가 가장 급한 신호로 가게 해야 한다."},"related":[],"sources":[{"url":"https://newrelic.com/blog/best-practices/new-relic-reliability-incident-learning","kind":"blog","archived":"https://web.archive.org/web/20250815220403/https://newrelic.com/blog/best-practices/new-relic-reliability-incident-learning"}],"summary":{"en":"NRDB, New Relic's telemetry data platform, is built from isolated cells. Each cell runs a Kafka cluster, an internet-facing ingestion service, data pipeline services and an NRDB cluster, so that a failure in one cell reaches only a share of customers. Kafka carries all customer data through each stage of the pipeline and buffers it when a stage slows down. A broker that becomes unresponsive without leaving the cluster must be restarted, or rebuilt on a new instance attached to the existing storage; this normally happens automatically, and when the automation fails it is triggered by hand. Infrastructure is managed as code: normal changes roll out through CI/CD pipelines to one cell, then some, then all, and a separate set of tools built on the same infrastructure lets engineers act quickly during incidents.\n\nOn the morning of 29 July 2021 a Kafka broker in one cell became unresponsive. Engineers started a manual restart at the same time as the automated one, which kept the cluster degraded longer and blurred the cause. To keep the growing backlog from being lost, responders extended Kafka retention with an emergency tool. The increase was larger than usual, and because Kafka retention is normally kept the same across the environment, the tool applied it to every cell. In earlier incidents troubleshooting had finished and the emergency retention had been reverted long before it caused trouble, but this time the unclear root cause and the longer recovery led the team to keep it in place. Over the next hours broker disks filled, brokers failed in a few cells and then in many, and the low-disk alert was lost among unrelated warnings. Data collection and alerting were unusable for many customers in the US region for multiple hours, and recovery was slow even after the disk space problem was resolved.\n\nNew Relic listed five safety layers that failed. The emergency tool was deliberately simple and gave no warning that a large retention increase could be dangerous. An engineer used the wrong settings in a high-stress situation, with a tool that had been used dozens of times without a problem and therefore seemed safe. Fast troubleshooting had always kept extended retention from reaching a critical level, and this time the investigation took longer. The disk space alert was missed. Retention changes bypassed cell isolation because they applied automatically to all cells of the same type.","ko":"2021년 7월 29일 아침, New Relic 의 텔레메트리 데이터 플랫폼인 NRDB 의 한 셀에서 Kafka 브로커가 응답하지 않았다. NRDB 는 셀마다 Kafka 클러스터, 인터넷으로 데이터를 받는 수집 서비스, 데이터 파이프라인 서비스, NRDB 클러스터를 따로 두고 셀끼리 격리하는 구조다. 최근 자동 복구가 제대로 돌지 않은 일이 몇 번 있었던 터라 엔지니어링 팀은 수동으로 재시작을 걸었다. 그런데 같은 시각 자동 복구도 이미 돌고 있었다. 두 작업은 결국 무사히 끝났지만 서로 부딪혀 클러스터가 예상보다 오래 성능 저하 상태에 있었고, 원인을 파악하기도 어려워졌다.\n\n그동안 처리하지 못한 데이터가 쌓이자 대응 엔지니어는 셀이 회복되기 전에 오래된 데이터가 지워지지 않도록 장애 대응 도구로 Kafka 데이터 보존 기간을 늘렸다. 평소보다 큰 폭의 변경이었다. 예전에는 문제 해결이 빨라 긴급 조치를 일찍 되돌렸지만, 이번에는 원인이 불확실하고 복구가 길어져 긴급 조치를 그대로 둔 채 분석을 이어 갔다. 인프라 자동화는 Kafka 보존 설정을 셀마다 같게 유지하므로 이 변경은 문제가 난 셀뿐 아니라 같은 종류의 모든 셀에 적용됐다. 그 뒤 몇 시간에 걸쳐 브로커 디스크가 천천히 찼다. 디스크 부족 알림이 관계없는 다른 경고들과 겹쳐 엔지니어들은 이 알림을 놓쳤다.\n\n브로커 장애는 몇 셀에서 시작해 점점 더 많은 셀로 번져 데이터 처리 시스템 전반에 장애가 났고, US 리전의 많은 고객이 몇 시간 동안 데이터 수집과 알림을 쓸 수 없었다. 디스크 공간 문제를 해결한 뒤에도 Kafka 문제가 넓게 퍼져 있어 복구가 느렸다. New Relic 은 안전장치 다섯 겹이 실패했다고 정리했다. 첫째, 도구가 큰 보존 기간 증가를 경고 없이 허용했다. 둘째, 엔지니어가 설정 값을 잘못 골랐다. 셋째, 평소에는 문제를 빨리 해결해 늘린 보존 기간이 위험한 수준에 닿은 적이 없었으므로 이 조치가 안전해 보였다. 넷째, 디스크 알림을 놓쳤다. 다섯째, 보존 변경이 같은 종류의 모든 셀에 자동으로 적용되어 셀 격리를 우회했다."},"trigger":{"en":"Responders used an incident response tool to extend Kafka data retention for the degraded cell so that its backlog would not be lost. The retention increase was larger than usual, and the tool applied it to all cells of the same type, not only the affected one.","ko":"엔지니어가 응답하지 않는 Kafka 브로커를 수동으로 재시작했는데, 같은 시각 자동 복구도 돌아 클러스터가 오래 성능 저하 상태에 머물렀다. 엔지니어는 밀린 데이터를 지키려고 장애 대응 도구로 Kafka 데이터 보존 기간을 크게 늘렸고, 이 변경이 문제가 난 셀뿐 아니라 모든 셀에 적용됐다."},"severity":"unknown","symptoms":["node-disk-full","throughput-degraded","monitoring-down"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"Engineers saw a Kafka broker in one cell become unresponsive on the morning of 29 July. Later a monitoring alert warned that disk space was running low, but it fired together with unrelated warnings from several other systems and was missed.","ko":"7월 29일 아침 엔지니어링 팀이 한 셀의 Kafka 브로커가 응답하지 않는 것을 봤다. 나중에 디스크 여유 공간이 줄어들 때 모니터링 시스템이 알림을 보냈지만, 같은 시각 다른 여러 시스템이 관계없는 경고를 내고 있어 엔지니어들은 이 알림을 놓쳤다."},"components":["message-broker"],"root_cause":"human-operation","remediation":[{"text":{"en":"Restarted the unresponsive Kafka broker by hand, while the automated restart was also running","ko":"엔지니어링 팀이 응답하지 않는 Kafka 브로커를 수동으로 재시작했다. 같은 시각 자동 복구도 돌았고, 두 작업 모두 결국 무사히 끝났다."}},{"text":{"en":"Resolved the disk space problem on the Kafka brokers, after which service recovered slowly","ko":"브로커의 디스크 공간 문제를 해결했다. 그 뒤에도 Kafka 문제가 여러 셀에 넓게 퍼져 있어 서비스 복구에 시간이 걸렸다."}}],"action_items":[],"contributing":["manual-action-worsened","no-staged-rollout","alert-noise","assumption-unverified"],"recurrence_of":null,"symptoms_text":{"en":"On 29 July 2021, data collection and alerting in New Relic's US region became unusable for many customers for several hours. It began with one unresponsive Kafka broker in a single cell of NRDB, New Relic's telemetry data platform, and over the following hours Kafka brokers in more and more cells failed as their disks filled up.\n\nEvery NRDB cell has its own Kafka cluster, which carries all customer data through the processing, evaluation and storage stages and holds data back when one stage slows down. A broker that stops responding but stays in the cluster stalls the pipeline data queued behind it. While the first cell was degraded, a backlog of unprocessed data built up in it.\n\nAfter responders extended Kafka data retention to keep that backlog from being lost, the broker disks filled slowly over the next few hours. Brokers failed first in a few cells, then in many more, and data processing was disrupted across the platform. Once the disk space problem was fixed, service still came back slowly because the Kafka failures were so widespread.\n\nThe automatic broker remediation had recently failed to trigger in similar cases, so engineers restarted the unresponsive broker by hand. The automated restart had in fact started at the same moment. Both finished safely, but the two competing processes kept the cluster degraded for longer than expected and confused the team about the real cause. A monitoring alert for low disk space did fire, but it arrived together with unrelated warnings from several other systems and was missed.","ko":"한 셀의 Kafka 브로커가 응답하지 않았다. 몇 시간 뒤 여러 셀의 Kafka 브로커 디스크가 차면서 브로커가 하나둘 멈췄고, US 리전의 많은 고객이 데이터 수집과 알림을 쓸 수 없었다.\n\n응답하지 않는 브로커를 다시 띄우는 동안 클러스터는 예상보다 오래 성능이 떨어진 상태에 머물렀고, 처리하지 못한 데이터가 밀려 쌓였다. 수동 재시작과 자동 복구가 동시에 돌아 엔지니어들은 실제 원인을 가려내기 어려웠다.\n\n디스크 여유 공간이 줄어들자 모니터링 시스템이 알림을 보냈다. 같은 시각 다른 여러 시스템이 관계없는 경고를 내고 있었고, 엔지니어들은 이 알림을 놓쳤다.\n\n브로커 장애는 처음 몇 셀에서 시작해 점점 더 많은 셀로 번졌고 데이터 처리 시스템 전반에 장애가 났다. 디스크 공간 문제를 해결한 뒤에도 Kafka 문제가 넓게 퍼져 있어 서비스가 느리게 돌아왔다."},"updated_at":"2026-11-14T12:33:53.464321Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0280","org_slug":"new-relic"}