Incident Library

IL-0220 Slack · 2021-01-04awsnetworking

연휴 뒤 첫 업무일에 AWS Transit Gateway 가 패킷을 버려 Slack 웹 계층이 포화되고 Slack 을 한동안 쓸 수 없었다.

2021-01-04 은 많은 사람에게 새해 첫 업무일이었다. Slack 은 서비스를 별도 AWS 계정과 전용 VPC 로 나눠 운영하고, VPC 들을 AWS Transit Gateway 로 잇는다. 줄여서 TGW 라고 부르는 이 게이트웨이는 AWS 가 관리하며 사용자가 신경 쓰지 않아도 확장되도록 만들어졌다. 연휴 뒤 첫 월요일에는 클라이언트 캐시가 비어 있다. 그래서 Slack 트래픽은 하룻밤 새 한 해 중 가장 조용한 시기에서 가장 바쁜 날 가운데 하나로 바뀐다. 이날 TGW 하나가 충분히 빨리 늘지 못해 과부하가 걸렸고 패킷을 버렸다.

미주 지역 오전에 외부 모니터링이 오류율 상승을 알렸고 곧 대시보드와 알림 서비스가 멈췄다. 이 서비스는 백엔드 데이터베이스와 다른 VPC 에서 돌아 TGW 에 의존하고 있었다. PST 오전 7시의 작은 트래픽 정점과 패킷 손실이 겹쳐 웹 계층이 포화됐고 Slack 을 쓸 수 없게 됐다. 웹 계층은 네트워크 대기로 CPU 사용률이 떨어지자 처음에는 축소됐고, 곧 Apache 워커 스레드 사용률이 올라 PST 오전 7시 1분부터 7시 15분 사이에 서버 1,200대를 더하려 했다. provision-service 는 똑같이 나빠진 네트워크를 거쳐 내부 시스템과 AWS API 를 호출하다가 Linux 열린 파일 수 한도와 AWS 쿼터 한도에 걸렸다. 그래서 새 인스턴스 대부분이 서비스에 들어가지 못했고 오토스케일링 그룹 크기 한도에 닿았다.

팀은 자동 축소를 끄고, 고장 난 인스턴스를 정리하고, provision-service 를 고쳤다. PST 오전 8시 15분쯤 provision-service 가 다시 돌자 정상 인스턴스가 서비스에 들어왔다. 로드 밸런서에서는 헬스 체크 실패가 여전히 많았다. panic mode 는 많은 인스턴스가 헬스 체크에 실패할 때 모든 인스턴스로 요청을 나누는 동작이다. 이 panic mode 와 재시도, 서킷 브레이킹 덕분에 오전 9시 15분쯤 Slack 은 멈춘 상태에서 느려진 상태로 바뀌었다. 네트워크가 아직 나빠 평소보다 많은 인스턴스가 필요했고 프로비저닝도 오래 걸려, 오류율을 낮출 만큼 인스턴스를 갖추는 데 한 시간이 걸렸다. AWS 엔지니어는 내부 모니터링으로 패킷 드롭을 알아채고 TGW 용량을 손으로 늘렸다. PST 오전 10시 40분에 이 변경이 모든 가용 영역에 반영되며 네트워크와 오류율, 지연이 정상으로 돌아왔다.

심각도
–
영향 범위
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
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

미주 지역 오전에 외부 모니터링 서비스가 오류율이 조금씩 오르고 있다며 호출했다. 조사를 막 시작했을 때 사내 대시보드와 알림 서비스까지 먹통이 됐다.

PST 오전 6시 57분에 메시지 전송 성공률은 99% 였다. 평소에는 99.999% 를 넘는 값이다. 인프라는 대체로 떠 있었지만 네트워크 전반이 나빠졌다는 징후가 보였다.

Slack 에는 매시 정각과 30분마다 알림과 자동화가 메시지를 보내는 작은 정점이 있다. PST 오전 7시의 정점이 네트워크 문제와 겹치자 웹 계층이 포화됐다. 부하가 오를수록 패킷 손실이 늘었고, 웹 계층에서 백엔드로 가는 호출의 지연이 크게 늘어 웹 계층의 시스템 자원이 바닥났다. 이때 Slack 을 쓸 수 없게 됐다.

같은 무렵 자동화가 백엔드에 닿지 못하는 인스턴스를 비정상으로 표시하고 새 인스턴스로 바꾸려 했다. 오토스케일링은 웹 계층을 축소했다. 대시보드가 없어 운영 인스턴스에 SSH 로 들어가 조사하던 대응자들은 인스턴스가 회수되면서 세션이 갑자기 끊겼다.

웹 계층은 CPU 사용률과 Apache 워커 스레드 사용률을 기준으로 확장한다. 스레드가 네트워크를 기다리는 시간이 늘자 CPU 사용률이 떨어져 먼저 축소가 일어났다. 곧 스레드 사용률이 오르자 오토스케일링은 PST 오전 7시 1분부터 7시 15분 사이에 웹 계층에 서버 1,200대를 더하려 했다.

증설은 뜻대로 되지 않았다. 인스턴스를 설정하고 시험하는 provision-service 가 Linux 열린 파일 수 한도와 AWS 쿼터 한도에 걸렸다. 새로 만든 인스턴스 대부분이 프로비저닝을 마치지 못해 트래픽을 받지 못했고, 고장 난 인스턴스가 쌓여 오토스케일링 그룹 크기 한도에 닿았다. provision-service 가 과부하 상태여서 대시보드 서비스 인스턴스도 새로 띄우지 못했다. 로드 밸런싱 계층에서는 웹 애플리케이션 인스턴스의 헬스 체크 실패율이 매우 높게 나타났다.

팀은 원인을 좁히려고 그날 배포한 변경 몇 개를 바로 롤백했지만, 그 변경들은 원인이 아니었다. 대시보드 없이 내부 콘솔, 상태 페이지, 명령줄 도구, 로그 인프라를 쓰고 지표 백엔드를 직접 조회하며 조사했다. 넓은 범위의 네트워크 저하가 보여 AWS 에 에스컬레이션했다.

증상 오류율 상승모니터링 중단패킷 손실서비스 중단노드 증설 실패파일 디스크립터 고갈클라우드 API 호출 한도 소진

원인

원인 클라우드 제공자 장애

구성 요소 트랜짓 게이트웨이와 네트워크 연결 장비자동 용량 관리 시스템
기여 요인 순환 의존자동화 증폭
촉발
연휴 동안 트래픽이 낮다가 연휴 뒤 첫 월요일에 클라이언트 캐시가 비어 평소보다 많은 데이터를 내려받으면서 트래픽이 하룻밤 새 크게 늘었다. Slack 의 VPC 들을 잇는 AWS Transit Gateway 하나가 이 증가를 따라 충분히 빨리 늘지 못해 과부하가 걸리고 패킷을 버렸다.

감지

미주 지역 오전에 외부 모니터링 서비스가 오류율이 오르고 있다며 호출했다. 조사 초기에 대시보드와 알림 서비스가 멈춰, 그 뒤로는 내부 콘솔, 상태 페이지, 명령줄 도구, 로그와 지표 백엔드 직접 조회로 상황을 봤다. TGW 의 패킷 드롭은 AWS 내부 모니터링이 AWS 엔지니어에게 알렸다.

조치

후속 조치

교훈

모니터링은 사용자 서비스가 정상인지 아는 수단이자 진단의 핵심 도구다. 그래서 Slack 은 모니터링 도구를 Slack 인프라에서 최대한 떼어 두려 했다. 그런데 대시보드와 알림 서비스가 백엔드 데이터베이스와 다른 VPC 에 있어 TGW 에 의존했고, 가장 필요한 순간에 함께 멈췄다. provision-service 는 예전에 부하 테스트를 했지만 이번 증설은 그때의 규모를 넘었다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 트랜짓 게이트웨이와 네트워크 연결 장비, 자동 용량 관리 시스템. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.