04장 처리율 제한 장치 설계 비교

[ghlnh]

책에 나온 설계 범위 및 요구사항

1. 설정된 처리율을 초과하는 요청은 정확하게 제한한다.
2. 낮은 응답시간: HTTP 응답시간에 나쁜 영향을 주어서는 곤란하다
3. 가능한 한 적은 메모리를 써야 한다.
4. 분산율 처리율 제한: 하나의 처리율 제한 장치를 여러 서버나 프로세스에 공유할 수 있어야 한다.
5. 예외 처리: 요청이 제한 되었을 때는 그 사실을 사용자에게 분명하게 보여줘야 한다.
6. 높은 결함 감내성: 제한 장치에 장애가 생기더라도 전체 시스템에 영향을 주면 안된다.
7. 서버 측 API를 위한 처리율 제한 장치이다.
8. 다양한 형태의 제어 규칙을 정의할 수 있도록 하는 유연한 시스템이어야 한다.
9. 대규모 요청을 처리할 수 있어야 한다.

토큰 버킷 알고리즘&멤캐시드 VS 이동 윈도 카운터 알고리즘&레디스

[ghlnh]

처리율 제한 장치 A: 토큰 버킷 알고리즘과 멤캐시드

토큰 버킷 알고리즘 설정된 처리율을 초과하는 요청은 효과적으로 제한 요청은 토큰이 있을 때만 처리되며, 토큰은 일정 시간 간격으로 생성 토큰의 생성과 소비가 일정하여 예측 가능한 트래픽 제어가 가능

멤캐시드 데이터 저장소 고속 캐싱 서비스로 메모리에 데이터를 저장하여 빠른 액세스가 가능 대규모 분산 시스템에 적합하며, 여러 서버 간에 공유 가능

처리율 제한 장치 B: 이동 윈도 카운터 알고리즘과 레디스

이동 윈도 카운터 알고리즘 최근 시간 동안의 요청 수를 계산하여 처리율을 제한→ 시간 윈도 내에서의 요청 수를 통해 유연하게 제어 높은 변동성의 트래픽에 효과적으로 대응가능

레디스 데이터 저장소 고성능 키-값 저장 데이터베이스로, 복잡한 데이터 구조를 메모리 내에 저장 레디스의 내장 기능을 이용해 원자성을 보장하고, 실패에 대한 복원력이 높음

비교

1. 정확한 제한:

   • 토큰 버킷 알고리즘(A)은 버킷에 토큰을 미리 채워두고, 요청이 들어올 때마다 토큰을 소비하는 방식으로 정확한 처리율 제한이 가능
   • 이동윈도 카운터 알고리즘(B)은 일정 시간 동안의 요청 수를 카운트하여 제한하므로, 약간의 오차가 발생 ⇒ 토큰 버킷 알고리즘(A)이 더 정확한 제한이 가능

2. 메모리 사용:

   • 멤캐시드(A)는 간단한 데이터 구조를 빠르게 액세스하는 데 유리, 레디스(B)에 비해 적은 메모리를 사용

   • 레디스는 보다 복잡한 데이터 처리와 분산 처리에서 강점

     ⇒메모리 사용 최소화가 중요하다면 멤캐시드(A)가 유리

3. 분산 처리:

   • 레디스(B)는 분산 환경에서 사용하기에 적합한 데이터 저장소로, 여러 서버나 프로세스에서 공유 가능

   • 멤캐시드(A)도 분산 캐시로 사용 가능하지만, 레디스만큼 강력한 분산 기능을 제공X

     ⇒레디스(B)가 분산 처리 면에서 더 유리

4. 응답 시간과 결함 감내성:

   • 레디스는 멤캐시드에 비해 복잡한 연산이 가능하며, 내장된 내결함성 기능으로 서비스의 중단 없이 처리율 제한을 지속 가능

     ⇒레디스(B)가 유리

5. 유연성과 대규모 요청 처리:

   • 레디스(B)는 다양한 데이터 구조와 스크립팅, 트랜잭션 등의 고급 기능을 제공하여 보다 유연한 제어가 가능
   • 멤캐시드(A)도 대규모 요청 처리가 가능하지만, 레디스에 비해 확장성이 다소 낮음

   ⇒레디스(B)가 대규모 요청 처리 면에서 더 유리

결론

토큰 버킷 알고리즘을 사용하는 처리율 제한 장치 A는 정확한 제한과 메모리 사용량 면에서 우수하지만, 분산 처리와 대규모 요청 처리 면에서는 이동윈도 카운터 알고리즘을 사용하는 처리율 제한 장치 B가 더 적합해 보임. 따라서 주어진 요구사항을 고려할 때, 레디스 데이터 저장소를 사용하는 이동윈도 카운터 알고리즘 기반의 처리율 제한 장치 B가 더 적합하다고 판단

[ghlnh]

[Cache] Redis vs. Memcached https://chrisjune-13837.medium.com/redis-vs-memcached-10e796ddd717