{"id":"IL-0220","org":"Slack","date":"2021-01-04","docs":[],"title":{"en":"An overloaded AWS Transit Gateway dropped packets on 4 January 2021, and Slack's web tier saturated and went down","ko":"연휴 뒤 첫 업무일에 AWS Transit Gateway 가 패킷을 버려 Slack 웹 계층이 포화되고 Slack 을 한동안 쓸 수 없었다."},"domain":["aws","networking"],"impact":{"scope":"Slack messaging and its web tier: rising errors, then Slack unavailable, then degraded with higher latency and errors until the network recovered at 10:40am PST","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Monitoring has to stay as independent as possible of the infrastructure it watches, or it fails when it is needed most. Here the dashboard and alerting services failed because they ran in a different VPC from their databases and so depended on the Transit Gateways. provision-service had been load tested before, but this event exceeded the earlier scale-ups.","ko":"모니터링은 사용자 서비스가 정상인지 아는 수단이자 진단의 핵심 도구다. 그래서 Slack 은 모니터링 도구를 Slack 인프라에서 최대한 떼어 두려 했다. 그런데 대시보드와 알림 서비스가 백엔드 데이터베이스와 다른 VPC 에 있어 TGW 에 의존했고, 가장 필요한 순간에 함께 멈췄다. provision-service 는 예전에 부하 테스트를 했지만 이번 증설은 그때의 규모를 넘었다."},"related":[],"sources":[{"url":"https://slack.engineering/slacks-outage-on-january-4th-2021/","kind":"blog","archived":null}],"summary":{"en":"Slack runs its services in separate AWS accounts and dedicated VPCs and links the VPCs through AWS Transit Gateways (TGWs) used as hubs. TGWs are managed by AWS and are meant to scale without any action from the customer. On 4 January 2021 one of Slack's TGWs became overloaded and dropped packets. Slack's dashboard and alerting services ran in a different VPC from their backend databases, so they depended on the TGWs and failed with them. At the 7am PST mini-peak the network problems saturated the web tier and Slack became unavailable.\n\nThe web tier scales on CPU utilisation and on the use of Apache worker threads. Before 7:00am PST the threads spent more time waiting on the network, CPU utilisation dropped and automation downscaled the web tier; then thread use rose as the network got worse and automation tried to add 1,200 servers between 7:01am and 7:15am PST. provision-service talked to internal Slack systems and AWS APIs over the same degraded network, used more resources than usual, and under the load of so many simultaneous instances hit the Linux open files limit and an AWS quota limit. Most new instances were not fully provisioned, the broken instances reached the autoscaling-group size limits, and no new dashboard service instances could be provisioned either. Responders disabled the downscaling, cleared up the broken instances and repaired provision-service. Once provision-service was working again around 8:15am PST, healthy instances entered service, and by 9:15am PST Slack was degraded rather than down. The load balancers' panic mode, which spreads requests across all instances when many fail health checks, together with retries and circuit breaking, kept requests served. It still took an hour to provision enough instances to bring error rates down to a low level, because the unhealthy network meant more instances than usual were needed and each took longer to provision.\n\nAWS engineers, alerted to the packet drops by AWS's own internal monitoring, increased the TGW capacity manually. By 10:40am PST that change had rolled out across all Availability Zones, and the network, error rates and latency returned to normal.","ko":"2021-01-04 은 많은 사람에게 새해 첫 업무일이었다. Slack 은 서비스를 별도 AWS 계정과 전용 VPC 로 나눠 운영하고, VPC 들을 AWS Transit Gateway 로 잇는다. 줄여서 TGW 라고 부르는 이 게이트웨이는 AWS 가 관리하며 사용자가 신경 쓰지 않아도 확장되도록 만들어졌다. 연휴 뒤 첫 월요일에는 클라이언트 캐시가 비어 있다. 그래서 Slack 트래픽은 하룻밤 새 한 해 중 가장 조용한 시기에서 가장 바쁜 날 가운데 하나로 바뀐다. 이날 TGW 하나가 충분히 빨리 늘지 못해 과부하가 걸렸고 패킷을 버렸다.\n\n미주 지역 오전에 외부 모니터링이 오류율 상승을 알렸고 곧 대시보드와 알림 서비스가 멈췄다. 이 서비스는 백엔드 데이터베이스와 다른 VPC 에서 돌아 TGW 에 의존하고 있었다. PST 오전 7시의 작은 트래픽 정점과 패킷 손실이 겹쳐 웹 계층이 포화됐고 Slack 을 쓸 수 없게 됐다. 웹 계층은 네트워크 대기로 CPU 사용률이 떨어지자 처음에는 축소됐고, 곧 Apache 워커 스레드 사용률이 올라 PST 오전 7시 1분부터 7시 15분 사이에 서버 1,200대를 더하려 했다. provision-service 는 똑같이 나빠진 네트워크를 거쳐 내부 시스템과 AWS API 를 호출하다가 Linux 열린 파일 수 한도와 AWS 쿼터 한도에 걸렸다. 그래서 새 인스턴스 대부분이 서비스에 들어가지 못했고 오토스케일링 그룹 크기 한도에 닿았다.\n\n팀은 자동 축소를 끄고, 고장 난 인스턴스를 정리하고, provision-service 를 고쳤다. PST 오전 8시 15분쯤 provision-service 가 다시 돌자 정상 인스턴스가 서비스에 들어왔다. 로드 밸런서에서는 헬스 체크 실패가 여전히 많았다. panic mode 는 많은 인스턴스가 헬스 체크에 실패할 때 모든 인스턴스로 요청을 나누는 동작이다. 이 panic mode 와 재시도, 서킷 브레이킹 덕분에 오전 9시 15분쯤 Slack 은 멈춘 상태에서 느려진 상태로 바뀌었다. 네트워크가 아직 나빠 평소보다 많은 인스턴스가 필요했고 프로비저닝도 오래 걸려, 오류율을 낮출 만큼 인스턴스를 갖추는 데 한 시간이 걸렸다. AWS 엔지니어는 내부 모니터링으로 패킷 드롭을 알아채고 TGW 용량을 손으로 늘렸다. PST 오전 10시 40분에 이 변경이 모든 가용 영역에 반영되며 네트워크와 오류율, 지연이 정상으로 돌아왔다."},"trigger":{"en":"On the first working day after the holidays, Slack's traffic went from the quietest time of the year to one of its biggest days overnight, with cold client caches pulling more data than usual, and one of Slack's AWS Transit Gateways did not scale fast enough for it.","ko":"연휴 동안 트래픽이 낮다가 연휴 뒤 첫 월요일에 클라이언트 캐시가 비어 평소보다 많은 데이터를 내려받으면서 트래픽이 하룻밤 새 크게 늘었다. Slack 의 VPC 들을 잇는 AWS Transit Gateway 하나가 이 증가를 따라 충분히 빨리 늘지 못해 과부하가 걸리고 패킷을 버렸다."},"severity":"unknown","symptoms":["high-error-rate","monitoring-down","packet-loss","service-unavailable","autoscaler-scale-up-failed","file-descriptor-exhaustion","cloud-api-rate-limited"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"An external monitoring service paged Slack when error rates started creeping up during the Americas' morning. AWS engineers were separately alerted to the packet drops by AWS's internal monitoring.","ko":"미주 지역 오전에 외부 모니터링 서비스가 오류율이 오르고 있다며 호출했다. 조사 초기에 대시보드와 알림 서비스가 멈춰, 그 뒤로는 내부 콘솔, 상태 페이지, 명령줄 도구, 로그와 지표 백엔드 직접 조회로 상황을 봤다. TGW 의 패킷 드롭은 AWS 내부 모니터링이 AWS 엔지니어에게 알렸다."},"components":["interconnect","capacity-manager"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"Disabled automated downscaling of the web tier to keep serving capacity and allow investigation","ko":"조사를 돕고 서빙 용량을 지키려고 웹 계층의 자동 축소를 껐다."}},{"text":{"en":"Cleared up the broken, partly provisioned instances that filled the autoscaling groups","ko":"일부 대응자가 프로비저닝을 끝내지 못한 채 오토스케일링 그룹 크기 한도를 채우던 고장 난 인스턴스를 정리했다."}},{"text":{"en":"Repaired provision-service so new web tier instances could be provisioned and enter service","ko":"provision-service 를 고쳐 PST 오전 8시 15분쯤 다시 돌게 했고, 그때부터 정상 인스턴스가 서비스에 들어오기 시작했다."}},{"text":{"en":"AWS engineers increased the Transit Gateway capacity manually across all Availability Zones","ko":"AWS 엔지니어가 내부 모니터링으로 패킷 드롭을 알아채고 Slack 의 TGW 용량을 손으로 늘렸다. PST 오전 10시 40분에 모든 가용 영역에 반영되자 네트워크가 정상으로 돌아왔다."}}],"action_items":[{"text":{"en":"AWS reviews its Transit Gateway scaling algorithms for large packet-per-second increases","ko":"AWS 가 사고 후속 절차로 초당 패킷 수가 크게 늘 때의 TGW 스케일링 알고리즘을 검토한다."}},{"text":{"en":"Request a preemptive upscaling of the Transit Gateways at the end of the next holiday season","ko":"다음 연휴 시즌이 끝날 무렵 TGW 를 미리 증설해 달라고 요청하도록 Slack 리마인더를 걸어 둔다."}},{"text":{"en":"Run the dashboard service instances in the same VPC as their database to remove the Transit Gateway dependency","ko":"대시보드 서비스 인스턴스를 데이터베이스와 같은 VPC 에서 돌려 TGW 의존을 없앤다."}},{"text":{"en":"Load test provision-service regularly","ko":"provision-service 를 정기적으로 부하 테스트해 남은 확장 문제가 없는지 확인한다."}},{"text":{"en":"Reevaluate health-checking and autoscaling configurations so they cannot overload provision-service again","ko":"큰 네트워크 장애 같은 극단적인 상황에서도 provision-service 가 다시 과부하되지 않도록 헬스 체크와 오토스케일링 설정을 다시 검토한다."}}],"contributing":["circular-dependency","automation-amplified"],"recurrence_of":null,"symptoms_text":{"en":"During the Americas' morning of 4 January 2021, an external monitoring service paged Slack because error rates were creeping up. While the investigation was starting, Slack's own dashboarding and alerting service became unavailable, so responders had to work without their usual dashboards and alerts.\n\nThe infrastructure looked generally up, but there were signs of widespread network degradation, which Slack escalated to AWS. At 6.57am PST 99% of Slack messages were being sent successfully, against a usual success rate above 99.999%. Responders worked from internal consoles, status pages, command line tools, the logging infrastructure and direct queries to the metrics backends.\n\nAt the 7am PST mini-peak, when reminders and other automation send messages at the top of the hour, the network problems and the load saturated the web tier. Packet loss grew as load increased, calls from the web tier to its backends became much slower, and Slack became unavailable. Automation marked instances that could not reach their backends as unhealthy and tried to replace them, and the autoscaling system downscaled the web tier, so engineers investigating on those instances had their SSH sessions cut off as the instances were deprovisioned.\n\nThe web tier scales on CPU utilisation and on the use of Apache worker threads. Before 7:00am PST threads spent more time waiting on the network, CPU utilisation dropped and some automated downscaling followed; then thread use rose as the network got worse. Responders first rolled back some changes pushed out that day, which turned out not to be the cause. The automated scale-up of 1,200 servers between 7:01am and 7:15am PST did not add serving capacity: provision-service, which configures and tests new instances, hit the Linux open files limit and an AWS quota limit, most new instances were never fully provisioned, and the broken instances filled the autoscaling groups up to their size limits. No new dashboard service instances could be provisioned either, because provision-service was overloaded. The load balancing tier showed an extremely high rate of health check failures to the web application instances.","ko":"미주 지역 오전에 외부 모니터링 서비스가 오류율이 조금씩 오르고 있다며 호출했다. 조사를 막 시작했을 때 사내 대시보드와 알림 서비스까지 먹통이 됐다.\n\nPST 오전 6시 57분에 메시지 전송 성공률은 99% 였다. 평소에는 99.999% 를 넘는 값이다. 인프라는 대체로 떠 있었지만 네트워크 전반이 나빠졌다는 징후가 보였다.\n\nSlack 에는 매시 정각과 30분마다 알림과 자동화가 메시지를 보내는 작은 정점이 있다. PST 오전 7시의 정점이 네트워크 문제와 겹치자 웹 계층이 포화됐다. 부하가 오를수록 패킷 손실이 늘었고, 웹 계층에서 백엔드로 가는 호출의 지연이 크게 늘어 웹 계층의 시스템 자원이 바닥났다. 이때 Slack 을 쓸 수 없게 됐다.\n\n같은 무렵 자동화가 백엔드에 닿지 못하는 인스턴스를 비정상으로 표시하고 새 인스턴스로 바꾸려 했다. 오토스케일링은 웹 계층을 축소했다. 대시보드가 없어 운영 인스턴스에 SSH 로 들어가 조사하던 대응자들은 인스턴스가 회수되면서 세션이 갑자기 끊겼다.\n\n웹 계층은 CPU 사용률과 Apache 워커 스레드 사용률을 기준으로 확장한다. 스레드가 네트워크를 기다리는 시간이 늘자 CPU 사용률이 떨어져 먼저 축소가 일어났다. 곧 스레드 사용률이 오르자 오토스케일링은 PST 오전 7시 1분부터 7시 15분 사이에 웹 계층에 서버 1,200대를 더하려 했다.\n\n증설은 뜻대로 되지 않았다. 인스턴스를 설정하고 시험하는 provision-service 가 Linux 열린 파일 수 한도와 AWS 쿼터 한도에 걸렸다. 새로 만든 인스턴스 대부분이 프로비저닝을 마치지 못해 트래픽을 받지 못했고, 고장 난 인스턴스가 쌓여 오토스케일링 그룹 크기 한도에 닿았다. provision-service 가 과부하 상태여서 대시보드 서비스 인스턴스도 새로 띄우지 못했다. 로드 밸런싱 계층에서는 웹 애플리케이션 인스턴스의 헬스 체크 실패율이 매우 높게 나타났다.\n\n팀은 원인을 좁히려고 그날 배포한 변경 몇 개를 바로 롤백했지만, 그 변경들은 원인이 아니었다. 대시보드 없이 내부 콘솔, 상태 페이지, 명령줄 도구, 로그 인프라를 쓰고 지표 백엔드를 직접 조회하며 조사했다. 넓은 범위의 네트워크 저하가 보여 AWS 에 에스컬레이션했다."},"updated_at":"2026-11-14T05:53:43.307199Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0220","org_slug":"slack"}