Rate Limiting과 백프레셔

한 고객이 전체를 마비시켰다는 것은 격리가 없다는 뜻입니다. 순서대로 넣습니다.

첫 줄이 즉시 효과가 있고, 둘째 줄이 진짜 원인일 때가 많습니다. 요청 수는 적은데 하나하나가 오래 걸리는 경우, 초당 요청 한도로는 못 막습니다. 동시에 처리 중인 건수를 고객사별로 제한해야 워커가 남습니다.

한도를 정할 때는 전체 용량을 고객 수로 나누지 않습니다. 대부분은 한도 근처도 안 쓰므로, 평소 사용량의 몇 배를 한도로 두고 전체 합이 용량을 넘지 않는지만 확인합니다.

거절할 때는 언제 다시 오라고 알려 줘야 합니다. 그 정보가 없으면 상대가 즉시 재시도해서 부하가 더 몰립니다.

흔한 실수: 서버를 증설해서 넘기는 것. 격리가 없으면 늘어난 용량도 같은 고객이 가져갑니다. 나누는 장치가 먼저이고 증설은 그 다음입니다.

고정 윈도우의 경계 문제가 결정적입니다. 분당 100이면, 59초에 100개와 61초에 100개가 통과해 2초 사이에 200개가 들어옵니다. 한도를 건 이유가 순간 부하를 막는 것이었다면 그 목적을 못 지킵니다.

그래서 대개 토큰 버킷을 고릅니다. 평소에 안 쓴 만큼 토큰이 쌓여 짧은 폭주를 허용하고, 그 상한이 버킷 크기로 명확합니다. API 클라이언트의 실제 사용 패턴(평소 조용하다가 배치 때 몰림)과도 맞습니다.

고정 윈도우가 맞는 자리도 있습니다. 정확히 "시간당 N회" 를 계약으로 파는 경우입니다. 과금과 한도가 같은 기준이어야 설명이 쉽습니다.

흔한 실수: 경계 문제를 알면서 "그 정도는 괜찮다" 고 넘기는 것. 클라이언트가 창 경계에 맞춰 몰아 보내도록 스스로 최적화하면, 그 두 배가 매 창마다 반복됩니다.

인스턴스마다 따로 세면 실제 한도는 한도 곱하기 대수가 됩니다. 그래서 카운터를 공유해야 합니다.

공용 저장소가 기본입니다. 원자적 증가와 만료를 한 번에 처리하면 왕복 한 번으로 끝나고, 그 비용은 대개 감당할 만합니다. 스크립트로 증가와 확인을 묶어 원자적으로 처리하는 것이 핵심입니다.

그 저장소가 죽었을 때를 정해야 합니다. 막을 것인가 통과시킬 것인가. 통과시키면 한도가 사라지고, 막으면 전체 서비스가 멈춥니다. 대개는 통과시키되 인스턴스별 보수적 한도로 내려앉는 쪽을 씁니다.

왕복이 부담이면 지역 카운터를 두고 주기적으로 합치는 방식이 있습니다. 정확도를 조금 포기하는 대신 지연이 거의 없습니다. 한도가 과금 기준이 아니라 보호 장치라면 이 거래가 맞습니다.

흔한 실수: 정확도를 위해 요청마다 여러 번 왕복하는 것. 한도 장치가 지연의 원인이 되면 본말이 뒤집힙니다. 보호가 목적이면 약간의 초과는 허용해도 됩니다.

큐는 속도 차이를 흡수하지만 만들어 내지는 못합니다. 들어오는 속도가 처리 속도보다 계속 크면, 큐 길이는 무한히 늘어나고 결국 터집니다.

늘리면 생기는 일입니다.

마지막 줄이 큐를 늘리는 것이 해가 되는 이유입니다. 인증 번호를 5분 뒤에 배달하면 도움이 아니라 혼란입니다.

근본 해결은 셋뿐입니다. 처리 속도를 올리거나, 들어오는 속도를 줄이거나(거절), 일의 양 자체를 줄이는 것입니다. 큐는 순간 몰림을 평탄하게 만드는 용도이지 지속적인 불균형의 해법이 아닙니다.

그래서 큐에는 길이 상한을 둡니다. 상한에 닿으면 거절하고, 그 거절이 앞단으로 전해져 들어오는 속도를 늦추게 만듭니다. 문제를 감추지 않고 드러내는 쪽이 안전합니다.

흔한 실수: 큐가 쌓이는 것을 보고 큐 용량부터 키우는 것. 증상이 잠시 사라지고 문제를 발견하는 시점만 뒤로 밀립니다. 그 사이 밀린 양은 더 커집니다.