IL-0251 Slack · 2020-05-12networkingaws

HAProxy 가 낡은 백엔드 목록에 묶여 일부 webapp 서버에만 요청을 보내면서 Slack 이 HTTP 503 오류를 냈다

그날 아침 8시 30분 무렵 설정 변경 배포가 오래된 성능 버그를 건드려 데이터베이스 부하가 크게 늘었다. 이 변경은 비율을 정해 조금씩 켜는 기능 플래그였기 때문에 금방 찾아 롤백할 수 있었고, 고객이 영향을 받은 시간은 3분이었다. 그사이 데이터베이스 요청이 늦어져 webapp 워커가 포화됐고, 자동 확장이 webapp 인스턴스를 75% 늘려 사상 가장 많은 수가 됐다.

Slack 에서는 4계층 로드 밸런서 뒤의 HAProxy 들이 webapp 계층으로 요청을 나눈다. 서비스 디스커버리는 Consul 이고, consul-template 이 정상 webapp 백엔드 목록을 만든다. HAProxy 를 자주 리로드하면 프로세스가 너무 많아지므로, Slack 이 만든 haproxy-server-state-management 가 그 목록을 읽어 HAProxy Runtime API 로 서버 상태를 바꾼다. HAProxy 에는 가용 영역마다 N 개의 백엔드 슬롯이 정의돼 있고 가용 영역이 M 개라서 모두 N * M 개다. 아침 사고 뒤 webapp 인스턴스가 N * M 개를 조금 넘었다. 슬롯을 얻지 못한 몇 대는 트래픽을 받지 못했지만, 처리 용량이 넉넉해서 문제가 되지 않았다.

문제는 haproxy-server-state-management 의 버그였다. 이 프로그램은 사라진 인스턴스의 슬롯을 비우기 전에 늘 새 인스턴스의 슬롯부터 찾았다. 빈 슬롯이 없자 프로그램이 도중에 실패하고 끝나 버렸다. 그 뒤로 돌고 있는 HAProxy 의 상태가 더 이상 갱신되지 않았다. 하루 동안 webapp 이 늘고 줄면서 HAProxy 의 백엔드 목록은 점점 낡아 대부분 이미 없어진 서버를 가리켰다. 미국 업무 시간이 끝나 webapp 계층이 줄기 시작하자 남은 오래된 서버로는 요청을 감당하지 못해, 태평양 시간 오후 4시 45분부터 503 이 났다. 원인을 안 뒤 HAProxy 를 순차 재시작해 금방 복구했다. 이 상황을 잡을 알림이 있었지만 제대로 동작하지 않았다. 시스템이 오래 바뀌지 않아 엔지니어들이 모니터링을 들여다볼 일이 적었고, 그래서 알림이 고장 난 것을 아무도 몰랐다.

심각도: –
영향 범위: Slack requests through the HAProxy tier failed with HTTP 503 errors from 4:45pm Pacific
영향 사용자: –
지역: –
감지까지: –
복구까지: –

증상

2020년 5월 12일 태평양 시간 오후 4시 45분 무렵, Slack 이 평소보다 많은 HTTP 503 오류를 내고 있다는 알림이 왔다. 사용자에게 보이는 장애가 이때 시작됐다.

webapp 담당 온콜 엔지니어가 첫 조치로 webapp 서버 수를 손으로 늘렸지만 전혀 나아지지 않았다. 서버 수를 늘려도 전혀 나아지지 않는 경우는 드물었다.

곧 webapp 서버 가운데 일부만 부하가 몰리고 나머지는 한가하다는 것이 보였다. 팀은 webapp 성능과 로드 밸런서 계층을 나눠 조사했고, 몇 분 뒤 원인을 찾았다.

대부분의 HAProxy 는 아침부터 떠 있던 webapp 서버에만 요청을 보낼 수 있었고, 이 서버들은 이제 전체의 소수였다. 새로 띄운 몇 대의 HAProxy 만 올바른 백엔드 목록을 갖고 있었다. 대부분은 여덟 시간 넘게 떠 있던 인스턴스라, 슬롯이 다 찬 채 갱신되지 않은 백엔드 상태에 묶여 있었다.

증상 오류율 상승 부하 불균형 오래된 엔드포인트 라우팅