가상 면접 사례로 배우는 대규모 시스템 설계 기초 4장

---

🏗️ 1. 개요

🔹 처리율 제한 장치(Rate Limiting)는 클라이언트 또는 서비스가 보내는 트래픽을 제어하는 장치다.
🔹 API 요청 횟수가 설정된 임계치를 초과하면 추가 요청이 거부된다.

📌 주요 목적
✅ DoS(서비스 거부) 공격 방지 – 악의적인 트래픽이 서버 자원을 소모하지 않도록 막음.
✅ 비용 절감 – 서버 자원을 낭비하지 않고, 우선순위가 높은 API에 더 많은 자원을 배정 가능.
✅ 서버 과부하 방지 – 봇 트래픽 및 잘못된 사용자 요청을 필터링하여 성능 유지.

---

⚙️ 2. 설계 시 고려 사항

📍 (1) 제한 장치 배치 – 어디에 둘 것인가?

• 🔹 서버 측 배치 → API 서버에서 직접 처리율 제한을 수행.
  • ✔️ 요청 처리의 유연성이 높음.
  • ❌ 개별 서버 부하 증가.
• 🔹 게이트웨이 배치 → API Gateway(Nginx, Kong 등)에서 처리.
  • ✔️ 전반적인 트래픽 관리 용이.
  • ❌ 특정 알고리즘 선택에 제한이 있을 수 있음.

⚠️ 정답은 없음!
→ 현재 사용하는 기술 스택, 엔지니어링 리소스, 비즈니스 목표에 따라 결정해야 함.

---

📍 (2) 설계 지침

📌 효율적인 처리율 제한을 위해 고려할 사항
✅ 기술 스택 점검 – 현재 사용하는 프로그래밍 언어 및 캐시 시스템(예: Redis)과의 호환성 확인.
✅ 적절한 알고리즘 선택 – 서버 vs. 게이트웨이 배치에 따라 사용 가능한 알고리즘이 달라질 수 있음.
✅ API Gateway 활용 여부 – 이미 게이트웨이를 사용 중이라면 처리율 제한 기능을 포함하는 것이 합리적.
✅ 직접 구현 vs. Managed API 사용 – 자체 구현이 어려우면 클라우드 API(예: AWS API Gateway의 Rate Limiting)를 활용하는 것도 방법.

---

🔄 3. 처리율 제한 알고리즘

📌 다양한 알고리즘이 있으며, 각각 장단점이 존재함

🎯 (1) 토큰 버킷 (Token Bucket)

🪣 설명

• 일정 간격으로 토큰이 버킷에 추가되며, 요청이 올 때마다 토큰을 소비하는 방식.
• 토큰이 부족하면 요청이 거부됨.

✅ 장점
✔️ 간단하고 구현이 쉬움.
✔️ 버스트 트래픽 처리 가능 – 요청이 몰려도 미리 저장된 토큰이 있으면 처리 가능.

❌ 단점
⚠️ 버킷 크기와 토큰 공급률 조정이 어렵다 – 트래픽 패턴에 따라 최적의 값 설정이 중요함.

---

📦 (2) 누출 버킷 (Leaky Bucket)

🚰 설명

• FIFO(선입선출) 큐를 활용해 일정한 속도로 요청을 처리하는 방식.
• 큐가 가득 차면 새로운 요청은 거부됨.

✅ 장점
✔️ 메모리 효율적.
✔️ 일정한 속도로 요청을 처리해 서버 부하가 급격히 증가하지 않음.

❌ 단점
⚠️ 트래픽 급증 시 최신 요청이 손실될 가능성 있음 – 오래된 요청이 큐에 쌓여서 최신 요청이 처리되지 못할 수도 있음.

---

📊 (3) 고정 윈도 카운터 (Fixed Window Counter)

📆 설명

• 시간을 일정 간격(Window)으로 나누고 카운터를 증가시키는 방식.
• 카운터가 설정된 임계치를 초과하면 해당 윈도우 내에서 추가 요청이 거부됨.

✅ 장점
✔️ 간단하고 메모리 효율적.
✔️ 특정 트래픽 패턴을 처리하기에 적합.

❌ 단점
⚠️ 윈도우 경계에서 트래픽이 몰릴 경우 임계치를 초과할 수 있음 – 순간적인 부하를 허용할 수 있음.

---

📝 (4) 이동 윈도 로깅 (Sliding Window Logging)

📜 설명

• 요청 타임스탬프를 저장하고 최신 요청이 들어올 때마다 만료된 타임스탬프를 제거하는 방식.

✅ 장점
✔️ 정교한 트래픽 제어 가능 – 어느 순간을 기준으로 보더라도 정확한 제한을 적용할 수 있음.

❌ 단점
⚠️ 메모리 사용량 증가 – 모든 요청의 타임스탬프를 저장해야 하므로 부하가 증가할 수 있음.

---

🔄 (5) 슬라이딩 윈도 카운터 (Sliding Window Counter)

📈 설명

• 고정 윈도 카운터와 이동 윈도 로깅의 절충안
• 현재 1분간의 요청 수 + 직전 1분간의 요청 수 * 이동 window 와 직전 1분이 겹치는 비율을 적용.

✅ 장점
✔️ 트래픽 급증에도 효과적으로 대응.
✔️ 메모리 효율이 좋음.

❌ 단점
⚠️ 트래픽 패턴이 균등하게 분포된다고 가정함 – 실제 트래픽 환경에서는 부정확할 수 있음.

---

🏛️ 4. 처리율 제한 아키텍처

📌 일반적인 처리 과정
1️⃣ 클라이언트가 요청을 보냄.
2️⃣ 처리율 제한 미들웨어가 요청을 가로채서 Redis에서 카운터 값을 확인.

• 🚫 임계치를 초과한 경우 → 429 Too Many Requests 응답 반환.
• ✅ 임계치 이하일 경우 → API 서버로 요청 전달 후 카운터 값 증가.

📌 중앙 집중형 데이터 저장소 사용

• 데이터베이스(DB)는 디스크 접근이 느려 비효율적이므로 ❌
• Redis, Memcached 같은 메모리 기반 캐시를 활용하는 것이 일반적 ✅

---

🏢 5. 분산 환경에서의 처리율 제한

📌 💥 문제 1: 경쟁 조건

• 다중 서버에서 동일한 카운터를 조작할 경우 경쟁 조건 발생 가능.
• 🔹 해결책: Redis Lua 스크립트 또는 정렬 집합(Sorted Set) 활용

📌 🔄 문제 2: 동기화 이슈

• 여러 대의 처리율 제한 서버를 사용할 경우 일관성 유지 필요.
• 🔹 해결책: Redis 같은 중앙 집중형 캐시 사용

---

🎯 6. 추가 논의

📌 Hard vs. Soft 처리율 제한

• 🚧 Hard 제한: 임계치를 절대 초과할 수 없음.
• 🌊 Soft 제한: 일시적인 초과를 허용할 수 있음.

📌 처리율 제한 회피 방법
✅ 클라이언트 캐싱 활용해 API 호출 횟수 감소.
✅ 백오프(재시도) 로직 구현 시 충분한 대기 시간 적용.

---

✅ 7. 결론

🚀 처리율 제한 장치는 서버 보호, 비용 절감, 트래픽 관리 측면에서 필수적인 기능!
🔹 요구사항 및 기술 스택에 따라 적절한 알고리즘과 구현 방식을 선택해야 한다.
🔹 Redis 같은 빠른 캐시 시스템을 활용하여 효율적인 트래픽 제어 가능!

---

---

📌 Redis Sorted Set(ZSET)과 경쟁 조건 해결 전략 정리

---

🔹 1. Redis Sorted Set(ZSET)의 개념

• 점수(Score)를 기준으로 자동 정렬되는 집합(Set)
• 주요 연산
  • ZADD: 데이터 추가
  • ZINCRBY: 점수 증가 (원자적 연산)
  • ZRANGE: 점수 순 정렬된 데이터 조회
  • ZREVRANGE: 점수 내림차순 정렬
  • ZREM: 특정 멤버 삭제
  • ZSCORE: 특정 멤버 점수 조회
• 사용 사례
  • 게임 리더보드(Leaderboard)
  • 우선순위 큐(Priority Queue)
  • 타임스탬프 기반 데이터 정렬

---

🔹 2. Redis에서 경쟁 조건 해결 방법

✅ (1) 싱글 스레드 모델 (Single-threaded Execution)

• Redis는 기본적으로 단일 스레드로 동작
• 하나의 명령이 실행되는 동안 다른 명령이 개입할 수 없음 → 경쟁 조건이 기본적으로 방지됨

📌 적용 대상: 단일 Redis 인스턴스 환경

---

✅ (2) 원자적 연산 (Atomic Operations)

• ZADD, ZINCRBY 등의 연산은 원자적으로 실행됨
• 따라서 동시에 여러 클라이언트가 접근해도 데이터 충돌 없이 안전하게 업데이트 가능

📌 적용 대상: 기본적인 데이터 추가/수정

---

✅ (3) WATCH + MULTI/EXEC을 활용한 낙관적 락 (Optimistic Locking)

• WATCH 명령어로 특정 키를 감시 → 값이 변경되면 트랜잭션 취소
• MULTI/EXEC을 사용하여 원자적 트랜잭션 실행

📌 적용 대상: 경쟁 조건이 발생할 가능성이 있는 경우 (예: 동일한 키에 대한 여러 클라이언트의 동시 접근)

📌 예제 (점수 업데이트)

WATCH leaderboard
MULTI
ZINCRBY leaderboard 20 "Alice"
EXEC  # 다른 클라이언트가 변경하지 않았을 경우 실행됨

---

✅ (4) Lua 스크립트 활용 (EVAL, EVALSHA)

• Redis의 Lua 스크립트는 모든 연산을 하나의 원자적 블록으로 실행
• 복잡한 연산을 동시에 실행해도 경쟁 조건을 방지할 수 있음

📌 적용 대상: 여러 개의 연산을 원자적으로 처리해야 할 때

📌 예제 (점수 증가 원자적 실행)

local key = KEYS[1]
local member = ARGV[1]
local increment = tonumber(ARGV[2])

local currentScore = redis.call("ZSCORE", key, member)
if currentScore then
    return redis.call("ZADD", key, currentScore + increment, member)
else
    return redis.call("ZADD", key, increment, member)
end

---

✅ (5) RedLock (분산 락) 활용

• Redis 클러스터 환경에서 동기화 문제를 해결하는 락 알고리즘
• 여러 Redis 인스턴스에서 동시에 락을 획득하고, 과반수 이상이 승인해야 유효한 락으로 간주
• 경쟁 조건이 발생할 가능성이 높은 경우 활용

📌 적용 대상: 여러 Redis 노드에서 동시 접근 방지

📌 예제 (Python Redis-py에서 RedLock 사용)

from redis import Redis
from redis_lock import Lock

redis_client = Redis()
lock = Lock(redis_client, "leaderboard_lock")

if lock.acquire(blocking=True, timeout=5):
    try:
        redis_client.zincrby("leaderboard", 10, "Alice")
    finally:
        lock.release()

---

🔥 정리: 경쟁 조건 해결 방법 비교

전략	설명	적용 대상	장점	단점
싱글 스레드 모델	기본적으로 동시 실행 방지	단일 인스턴스 환경	간단하고 안정적	확장성 제한
원자적 연산	ZADD, ZINCRBY는 원자적으로 실행	기본 데이터 추가/수정	빠름	제한적인 연산
WATCH + MULTI/EXEC	낙관적 락을 활용하여 충돌 방지	충돌 가능성이 높은 데이터 수정	동시성 보장	충돌 시 재시도 필요
Lua 스크립트	복잡한 연산을 원자적으로 처리	복잡한 트랜잭션	원자성 보장	유지보수 어려움
RedLock	분산 환경에서 동기화 보장	Redis 클러스터 환경	강력한 동기화	성능 오버헤드

---

🎯 결론

1. 단일 인스턴스 환경: 기본적으로 Redis는 싱글 스레드 모델과 원자적 연산 덕분에 경쟁 조건이 크게 발생하지 않음.
2. 데이터 충돌이 우려될 때: WATCH + MULTI/EXEC를 사용하여 낙관적 락 적용 가능.
3. 여러 개의 명령을 원자적으로 실행할 때: Lua 스크립트 활용.
4. 분산 환경(클러스터)에서 동기화 필요할 때: RedLock을 사용하여 락 적용.

🚀 Redis의 Sorted Set(ZSET)은 기본적으로 경쟁 조건을 방지할 수 있지만, 확장성이나 데이터 동기화가 중요한 경우 위의 전략을 적절히 조합해야 한다!