처리율 제한장치

처리율 제한 장치는 정해진 시간 안에 허용된 요청 수를 넘는 트래픽을 제한하는 장치입니다. API 서버 앞에서 과도한 호출을 막아 자원 고갈을 예방합니다. 또한 외부 API 호출 비용, 서버 증설 비용, 장애 전파 위험을 줄이는 역할도 합니다.

정답은 하나로 고정되지 않지만, 실무에서는 처리율 제한 장치를 API 서버 내부 코드가 아니라 서버 앞단의 별도 미들웨어나 API 게이트웨이 계층에 두는 방식이 많이 쓰입니다. 클라이언트 측 제한은 우회 가능성이 높고, API 서버 내부 제한은 서비스별로 중복 구현될 수 있습니다. 게이트웨이나 앞단 미들웨어에 두면 요청이 API 서버에 도달하기 전에 공통 지점에서 통제할 수 있어 서버 부하를 줄이고 운영과 확장이 쉬워집니다.

대표 알고리즘은 토큰 버킷, 누출 버킷, 고정 윈도 카운터, 이동 윈도 로그, 이동 윈도 카운터입니다. 각 알고리즘은 정확도, 메모리 사용량, 순간 트래픽 허용 여부, 구현 난이도에서 차이가 있습니다.

토큰 버킷은 미리 쌓인 토큰이 있으면 순간적으로 몰린 요청도 어느 정도 허용하는 방식입니다. 누출 버킷은 요청을 줄 세운 뒤 일정한 속도로 내보내 백엔드 처리율을 안정적으로 유지하는 방식입니다. 고정 윈도 카운터는 정해진 시간 구간마다 요청 수를 세는 단순한 방식이지만, 구간 경계에서는 제한이 느슨해질 수 있습니다. 이동 윈도 로그는 최근 시간 범위 안의 요청 기록을 모두 세어 정확하게 제한하는 방식입니다. 이동 윈도 카운터는 현재 구간과 직전 구간 일부를 함께 반영해 더 적은 메모리로 요청 수를 추정하는 방식입니다.

면접에서는 하나만 암기하기보다 트래픽 특성에 맞춰 선택 근거를 설명하는 것이 중요합니다.

상세 설계에는 제한 규칙 저장 방식, 카운터 저장소, 요청 제한 시 처리 방식, HTTP 응답 헤더, 분산 환경 동작 방식이 포함되어야 합니다. 개략 설계가 요청 흐름을 보여준다면, 상세 설계는 실제로 어떤 값을 어디에 저장하고 어떻게 갱신할지 설명합니다. 특히 처리율 제한 장치는 매 요청마다 실행되므로 저장소 접근과 연산이 빠르고 원자적이어야 합니다.

분산 환경에서는 여러 서버와 스레드가 같은 사용자나 같은 IP의 카운터를 동시에 읽고 갱신할 수 있습니다. 이때 경쟁 조건이 생기면 실제 요청 수보다 카운터가 작게 저장되어 제한이 뚫릴 수 있습니다. 또한 요청이 매번 다른 제한 장치로 전달되면 각 장치가 서로의 상태를 몰라 정확한 판단을 하지 못합니다.

먼저 제한 기준과 규모를 질문해 요구사항을 확정하고, 그다음 미들웨어 또는 API 게이트웨이 기반 구조를 제안하는 흐름이 좋습니다. 알고리즘은 트래픽 특성에 맞춰 선택하고, Redis 같은 중앙 저장소로 카운터를 공유한다고 설명합니다. 마지막으로 경쟁 조건, 장애 내성, 모니터링, HTTP 429 응답까지 언급하면 설계 완성도가 높아집니다.