[가상면접 사례로 배우는 대규모 시스템 설계기초] 처리율 제한 장치

이게 뭔데 필요할까?

1. DOS 공격과 같은 Denial Of Service 라고 외부에서 엄청 많이 요청해서 자원을 고갈시키는 공격을 방지할 수 있는 수단이다.
2. 서드파티의 API (지도 API 등) 를 이용할 경우 사용료를 제한할 수 있다.
3. 봇 같은 불필요한 트래픽을 줄여서 서버 부하를 줄일 수 있다.

 

이 처리율 제한 장치는 어떻게 구축되어 사용될까?

클라이언트쪽에 구축하거나 미들웨어에 구축하거나 서버쪽에 구축할 수 있다.
이 위치는 기술 스택이나 도메인에 따라 변경될 수 있다.
처리율 제한 서비스를 직접 만드는 것은 어렵기 때문에 인력이 충분하지 않다면 상용 서비스를 쓰는 것이 바람직하다.

 

처리율 제한 장치는 어떻게 동작하는가?

 

5가지 알고리즘을 도메인 상황에 맞게 적용한다고 한다.

1. 토큰 버킷
2. 누출 버킷
3. 고정 윈도우 카운터
4. 이동 윈도우 로그
5. 이동 윈도우 카운터

실생활 예시로 비교

 

 

토큰 버킷

어린이 용돈 시스템과 비슷하다. 매주 일정 금액을 받고, 필요할 때 모아둔 돈을 한 번에 많이 쓸 수 있다. 큰 장난감을 사기 위해 용돈을 몇 주간 모았다가 한 번에 사용하는 것처럼, 토큰 버킷은 트래픽이 적을 때 토큰을 모아두었다가 트래픽이 많을 때 사용할 수 있다.

 

aws 도 토큰 버킷을 활용한다고 한다.

 

 

누출 버킷

물이 일정한 속도로만 빠져나가는 수도꼭지와 같다. 입구로 물이 많이 들어와도 출구는 항상 같은 속도로만 물을 내보낸다. 이처럼 누출 버킷은 시스템에 얼마나 많은 요청이 들어오든 항상 일정한 속도로만 처리한다.

토큰 버킷은 일시적인 트래픽 급증에 유연하게 대응할 수 있어 사용자 경험이 좋지만, 누출 버킷은 시스템에 일정한 부하를 보장하여 안정성을 높이는 데 더 효과적이다.

 

 

고정 윈도우 카운터

급식실에서 "1시간에 30명만 들어갈 수 있다"라는 규칙이 있다. 

1시부터 2시까지 30명이 들어가면, 2시가 되기 전까지는 더 이상 들어갈 수 없고 2시가 되면 다시 30명을 받는다.

근데 1시 50분에 20명이 있다면 2시에는 다시 30명을 받기 때문에 급식실의 규칙인 30명을 넘는 순간이 생긴다.

 

 

이동 로그 윈도우

급식실에서 "지난 10분 동안 15명만 들어갈 수 있어요"라는 규칙이 있다. 

선생님이 누가 언제 들어갔는지 정확히 기록한다. 새 학생이 오면, 지난 10분 동안 몇 명이 들어갔는지 확인하고 15명 미만이면 들어갈 수 있다.

이렇게 하면 고정 윈도우 카운터에서 발생헀던 문제를 해결할 수 있다. 하지만 문제는 선생님이 기록해야 하기에 부담이 있다.

 

 

이동 윈도우 카운터

급식실에서 1분 단위로 몇 명이 들어갔는지 기록한다. "지난 5분 동안 20명만 들어갈 수 있다"라는 규칙이 있을 때,

1:05에 들어가려면 1:00부터 1:04까지의 학생 수를 확인해서 20명 미만이면 들어갈 수 있다.

 

 

고정 윈도우 카운터와 이동 로그 윈도우, 이동 윈도우 카운터의 메모리 사용량 비교

이동 윈도우 로그의 메모리 사용
이동 윈도우 로그는 각 요청의 정확한 타임스탬프를 모두 저장해야 한다. 예를 들어 1분 동안 1,000개의 요청이 들어오면, 1,000개의 타임스탬프를 모두 메모리에 저장해야 한다. 요청이 많을수록 저장해야 할 데이터가 계속 증가하므로 메모리 사용량이 크다.

고정 윈도우 카운터의 메모리 사용
고정 윈도우 카운터는 하나의 카운터와 윈도우의 시작 시간만 저장하므로 메모리 사용이 적다. 그러나 윈도우 경계에서 트래픽 집중 문제가 있고, 정확한 시간 제한을 구현하기 어렵다.

이동 윈도우 카운터의 메모리 사용
이동 윈도우 카운터는 여러 작은 시간 단위(버킷)별 카운터만 저장한다. 예를 들어 5분 윈도우를 1분 단위로 나누면 5개의 카운터만 저장하면 된다. 각 카운터는 해당 시간 단위 동안 들어온 요청의 수만 기록하므로, 요청이 많아져도 메모리 사용량은 증가하지 않는다.

 

처리율 제한 장치를 운영할 때 발생할 수 있는 문제

처리율 제한 장치는 분산 환경일 때 경쟁 조건과 동기화 문제가 있다.

 

 

경쟁 조건

경쟁은 뮤텍스같은 락을 사용하면 해결 가능하지만 성능 문제를 야기하니까

루아스크립트나 레디스 sorted set을 활용해서 문제를 해결한다고 한다.

 

 

동기화 문제

 

각 처리율 계산기가 카운터나 로그를 들고있으면 웹은 무상태를 유지해야하기에 만약 다른 처리율 제한기로 요청이 가게 된다면 문제가 될 수 있음.

따라서 외부에 기록하고 여러 처리율 계산기가 같이 바라보도록 해야하는데
RDB는 느리니까 인메모리 캐시인 레디스를 활용하면 좋다.

 

처리율 제한 장치를 운영할 때 필요한 것

 

성능 최적화

는 엣지 서버를 활용해서 지리적으로 더 가까운 서버에서 처리율을 제한하도록 하는 것이다.

 

 

모니터링

처리율 제한 장치에 적용한 알고리즘이 적합한지 확인을 하는 것이다.
예를 들어 이벤트로 트래픽이 급증할 때는 토큰 버킷 알고리즘을 채택하는 것이 효율적이다.

 

 

요약

• 처리율 제한 장치를 쓰면 DoS 공격과 경제적인 이점과 불필요한 트래픽을 막아 서버의 부하를 줄일 수 있다.
• 처리율 제한 장치는 5가지 알고리즘을 도메인 상황에 맞게 적용하여 트래픽을 관리한다.
• 분산 환경일 때 경쟁 조건과 동기화 문제에 대해 고려해야 한다.
• 처리율 제한 장치를 운영할 때는 성능 최적화를 위해 엣지 서버를 활용하고 적절한 알고리즘으로 처리하고 있는지 모니터링을 해야 한다.

-