초과 응답과 클라이언트 협조

429 와 함께 다시 시도할 시각까지의 초를 담습니다.

거절만 돌려주면 클라이언트는 곧바로 다시 옵니다. 실패하면 재시도하도록 만들어져 있기 때문입니다. 요청 수가 줄지 않으므로 제한 장치가 부하를 키웁니다.

그리고 클라이언트 쪽에서 그 시각을 조금씩 흩뿌려야 합니다. 한쪽만 있으면 알려 준 시각에 다시 몰립니다.

흔한 실수: 429 와 503 을 섞어 쓰는 것. 429 는 "당신이 한도를 넘었다" 이고 503 은 "서버가 버겁다" 입니다. 뜻이 다르면 클라이언트가 할 일도 다릅니다. 429 를 서버 문제로 받아들인 클라이언트는 속도를 줄이지 않고 계속 막힙니다.

모든 응답에 한도, 남은 횟수, 초기화 시각을 담습니다. 성공 응답에도 담습니다.

거절된 뒤에 알려 주면 이미 늦습니다. 미리 보이면 잘 만든 클라이언트가 스스로 속도를 줄이고, 그러면 거절 자체가 줄어듭니다.

흔한 실수: 남은 횟수를 알려 주려고 판정 외에 조회를 한 번 더 하는 것. 판정할 때 이미 값을 알고 있으므로 그 값을 그대로 응답에 담으면 추가 왕복이 없습니다. 어림 방식이면 어림값 기준으로 알려 주고, 그 사실을 문서에 적습니다.

개수만 세거나 표본만 남깁니다. 판정 경로에 무거운 기록을 붙이지 않습니다.

어느 키가 얼마나 거절되는지 모르면 한도가 적절한지 판단할 수 없습니다. 그런데 남용이 심할 때 가장 많이 실행되는 경로가 거절 경로입니다.

키별 거절 개수는 정수 하나로 센다
자세한 기록은 표본만 남긴다

막는 일이 비싸지면 막는 것 자체가 공격 수단이 됩니다. 이 원칙은 요청 시각을 저장하는 방식에서도 같았습니다.

흔한 실수: 거절할 때마다 경고 알림을 보내는 것. 남용 한 번에 알림 수천 개가 오고, 정작 중요한 알림이 그 안에 묻힙니다. 알림은 거절 비율이 평소와 크게 달라질 때 한 번 보냅니다.

한도, 창의 길이, 초과 시 응답, 권장 재시도 방식을 적습니다.

이것이 없으면 클라이언트를 만드는 사람이 우리 한도를 알 방법이 시행착오뿐입니다. 막히면서 배우게 되고, 그 과정이 우리 부하로 돌아옵니다.

한도가 무엇을 기준으로 세는지(키인지 사용자인지)
창이 얼마이고 언제 초기화되는지
초과 시 어떤 응답이 오는지
어떻게 다시 시도하기를 권하는지

처리율 제한은 서버 기능이 아니라 서버와 클라이언트의 약속입니다. 약속을 적어 두지 않으면 절반만 만든 것입니다.

흔한 실수: 한도를 조용히 바꾸는 것. 한도를 낮추는 변경은 정상 사용자의 코드를 깨뜨립니다. 미리 알리고, 가능하면 먼저 재기만 하는 기간을 두고 넘는 키에 개별로 알립니다.