API 처리 장치의 장점
- DoS (Denial of Service) 공격 방지
- 비용 절감
- 서버 과부하를 막는다.
시스템 설계 4단계 접근법을 적용해보자
1단계 문제 이해 및 설계 범위 확정
요구사항
- 설정된 처리율을 초과하는 요청은 정확하게 제한한다
- 낮은 응닫시간 : 이 처리율 제한 장치는 HTTP 응답시간에 나쁜 영향을 주어서는 곤란하다.
- 적은 메모리
- 분산형 처리율 제한 : 하나의 처리율 제한 장치를 여러 서버나 프로세스에 공유할 수 있어야 한다.
- 예외 처리 : 요청이 제한되었을 때는 그 사실을 사용자에게 분명하게 보여주어야 한다.
- 높은 결함 감내성 : 제한 장치에 장애가 생기더라도 전체 시스템에 영향을 주어서는 안 된다.
2단계 개략적 설계안 제시 및 동의 구하기
처리율 장치의 위치
- 클라이언트 측
- 위변조가 가능하여 권장하지 않는다.
- 서버 측
- 중앙화해서 관리한다.
- 미들웨어
- MSA 인 경우, 처리율 제한 장치는 보통 API Gateway 에 구현한다.
- API Gateway: 처리율 제한, SSL 종단, 사용자 인증, IP 허용 목록 관리 등
요약하면
- 현재 기술 스택이 서버 측에 기능 구현이 가능한지 점검
- 상황에 맞는 알고리즘 사용, 만약 제3 사업자가 제공하는 API Gateway 를 사용한다면 선택지는 제한이 될 수 있다.
- MSA 에 기반하고 있다면 인증, IP 허용 같은 기능을 이미 API Gateway 에 적용했을 수 있다. 그러면 처리율 제한도 API Gateway 에 포함하는 것이 좋다.
- 충분한 인력이 없다면 상용 솔루션도 고려해보는 것이 좋다.
가능한 알고리즘
토큰 버킷 알고리즘
- 토큰이 주기적으로 채워진다.
- 각 요청이 처리될 때마다 하나의 토큰을 사용한다.
- 토큰이 없다면 해당 요청은 버려진다.
- 많은 기업들이 보편적으로 사용하는 알고리즘
- 통상적으로 API 엔드포인트마다 별도의 버킷을 둔다.
- IP 주소별로 처리율 제한을 적용해야 한다면 IP 주소마다 버킷을 하나씩 할당해야 한다.
- 시스템의 처리율을 초당 10,000 개 요청으로 제한한다면, 모든 요청이 하나의 버킷을 공유하도록 해야 한다.
장점
- 구현이 쉬움
- 메모리 효율적
- 짧은 시간에 집중 되는 트래픽도 잘 처리
단점
- 버킷 크기 & 토큰 공급률 두 개의 인자를 필요로하는 알고리즘이기 때문에 적절하게 튜닝하는 것이 어렵다.
🤔 왜 이런 알고리즘이 나왔을까?
DB에 테이블에 count하는 방법도 있지 않을까?! 비즈니스 로직이 redis에도 들어가야 하고, db에 부하가 걸린다.
내가 이것을 도입할 만큼, 사용자의 속도가 나오지 않는지 고민해야한다. 오버엔지니어링이 아닐까 고민하면서 적용해야한다.
이것이 가장 나은 선택인가?
🤔 사용자마다 버킷이 부여된다. 만약 더 이상 접속하지 않는 사용자의 경우, 어떻게 처리해야 할까?
리프레시 토큰, 세션(마지막 로그인) 이 오래된 경우, 버킷을 없애버린다.
예) 휴먼계정으로 전환한다.
누출 버킷 알고리즘
- 요청이 들어오면 큐가 가득 차 있는지 체크한다.
- 빈 자리가 있다면 큐에 요청을 추가한다.
- 만약 큐가 가득 차 있다면 요청은 버린다.
- 지정된 시간마다 큐에서 요청을 꺼내어 처리한다.
- 토큰 버킷 알고리즘과 비슷하지만, 요청 처리율이 고정되어 있다는 점이 다르다.
- 큐에서 1초에 1개씩 꺼내!
- 보통 FIFO 큐로 구현한다.
장점
- 큐의 크기 제한 -> 메모리 효율적 사용
- 고정된 처리율을 가지고 있어 안정적 출력 (stable outflow rate) 이 필요한 경우 적합
단점
- 단기간에 많은 트래픽이 몰리는 경우 최신 요청들이 버려지게 될 수 있음
- 토큰 버킷 알고리즘처럼 튜닝이 어렵다. (버킷 크기 & 처리율)
🤔 우리 서버는 2000개의 트래픽을 받을 수 있는데, 다른 서버에서 1000개가 제한이다.
이럴 때, 사용해라!
문제는 우리가 느리게 보내고 싶지 않을 때도 보내야해...
이상적인 방법, 트래픽을 보면서 조절한다. 서킷브레이커...?
고정 윈도 카운터 알고리즘
- 타임라인을 고정된 간격의 window 로 나누고, 각 윈도우마다 카운터를 붙인다.
- 요청 접수 -> 카운터 + 1
- 카운터가 임게치에 도달하면 새로운 요청은 버려진다.
장점
- 메모리 효율이 좋다.
- 이해하기 쉽다.
- Window 가 닫히는 시점에 카운터를 초기화하는 방식은 특정한 트래픽 패턴을 처리하기에 적합하다.
단점
- Window 경계 부근에 트래픽이 몰리면 설정한 임게치를 초과할 수 있다.
이동 윈도 로깅 알고리즘
- 타임스탬프를 추적하는 알고리즘이다.
- 타임스탬프 데이터는 보통 레디스의 sorted set 같은 캐시에 보관
- 새 요청이 오면 만료된 타임스탬프는 제거
- 로그의 크기가 허용치보다 같거나 작으면 시스템에 전달
- 허용치보다 크면 처리 거부
장점
- 처리율 제한 메커니즘이 매우 정교하다.
- 어느 순간의 윈도를 보더라도 처리율 한도를 넘지 않는다.
단점
- 거부된 요청의 타임스탬프도 보관하기 때문에 메모리를 많이 사용한다.
이동 윈도 카운터 알고리즘
- 고정 윈도 카운터 + 이동 윈도 로깅
- 현재 1분간의 요청 수 + 직전 1분간의 요청 수 X 이동 윈도와 직전 1분이 겹치는 비율
장점
- 이전 시간대의 평균 처리율에 따라 현재 윈도의 상태를 계산하므로 짧은 시간에 몰리는 트래픽 대응에 용이하다.
- 메모리 효율이 좋다.
단점
- 직전 시간대에 도착한 요청이 균등하게 분포되어 있다고 가정
- 따라서 추정치를 계산하기 때문에 100% 정확하지는 않다.
- 하지만 클라우드플레어에서 수행한 실험에 의하면 오탐은 0.003% 에 불과했다고한다.
3단계 상세 설계
처리율 제한 규칙
- 처리율 한도 초과 트래픽 처리
HTTP 429 응답 (Too many requests): 어떤 요청이 한도 제한에 걸릴때 응답
경우에 따라서 한도 제한에 걸린 메시지를 나중에 처리하기 위해 큐에 보관할 수 있다. - 처리율 제한 장치가 사용하는 HTTP 헤더
클라이언트가 자기 요청이 처리율 제한에 걸리고 있는지에 대한 정보를 아래 HTTP 헤더를 통해 전달한다.
- X-Ratelimit-Remaining: 윈도 내에 남은 처리 가능 요청의 수
- X-Ratelimit-Limit: 매 윈도마다 클라이언트가 전송할 수 있는 요청의 수
- X-Ratelimit-Retry-After: 한도 제한에 걸리지 않으려면 몇 초 뒤에 요청을 다시 보내야 하는지 알림
🤔 헤더 앞에 X가 왜 붙일까?
커스텀한 헤더는 앞에 X를 붙인다. 잘못사용해도 내가 책임안져.
분산 환경에서의 처리율 제한 장치의 구현
- 경쟁 조건 (race condition)
이슈
경쟁 이슈가 발생하는 동작
해결 방법
레디스에서 카운터의 값을 읽는다.
counter +1 의 값이 임계치를 넘는지 본다.
넘지 않는다면 레디스에 보관된 카운터 값을 1만큼 증가시킨다.
- 참고: https://engineering.classdojo.com/blog/2015/02/06/rolling-rate-limiter/
- 책에서는 레디스 sorted set 을 사용하면 문제를 해결할 수 있다고 말하고 있다.
참고문헌을 보면 sorted set 에 특별한 기능이 있어서 경쟁 이슈를 해결하는 것은 아니였으며, 로직의 문제였다. - 좀 더 간단한 예제로 이래 첨부한 이미지를 참고
- 동기화
이슈
여러대의 처리율 제한 장치를 사용할 경우 요창이 분산될 수 있다.
해결 방법
Sticky session 을 사용하여 같은 클라이언트로부터의 요청은 항상 같은 처리율 제한 장치로 보낼 수 있도록 할 수 있다.
- 성능 최적화
이슈
지연시간
해결 방법
지연시간을 줄이기 위해 사용자의 트래픽을 가장 가까운 Edge 서버로 전달하여 지연시간을 줄인다.
4단계 마무리
경성 또는 연성 처리율 제한
- 경성 처리율 제한 : 요청의 개수는 임계치를 절대 넘어설 수 없다.
다양한 계층에서의 처리율 제한
- 애플리케이션 계층(7번 계층)에서의 처리율 제한 외에도 다른 계층에서 제어
ex) Iptables를 사용하여 IP 주소에 처리율 제한을 적용
처리율 제한을 회피하는 방법
- 클라이언트 측 캐시를 사용하여 API 호출 횟수 줄이기
- 예외나 에러를 처리하는 코드를 도입하여, 클라이언트가 예외적 상황으로부터 우아하게 복구될 수 있도록 한다.
- 서버가 죽어서 안 되는건지, 요청이 많아서 안 되는 건지 클라에서 알 수 있도록 하자.
- 에러를 받았을 때, 재처리 / 재시도 할 수 있도록 한다. 우아하게 서킷 브레이커 사용하자.
- 서버를 지켜줄 수 있다. 우리 서버 지켜!
- 재시도 로직을 구현할 때는 충분한 백오프 시간을 두도록 한다.
기록을 통한 성장을