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

처리율 제한 장치 도입 시 장점

• DoS 공격에 의한 자원 고갈 방지 가능
  • ex: 트위터는 3시간 동안 300개의 트윗만 올릴 수 있도록 제한
• 비용 절감 가능
  • 추가 요청에 대한 처리를 제한하면 서버를 많이 두지 않아도됨
  • 우선순위 높은 API에 더 많은 자원 할당 가능
• 서버 과부하 방지
  • bot에서 오는 트래픽이나 잘못된 이용패턴으로 유발된 트래픽을 걸러낼 수 있음

처리율 제한 장치 설계시 고려 사항

1. 처리율 제한 장치의 위치

   • 클라이언트 측: 클라이언트 요청은 쉽게 위/변조가 가능하므로 안정적X
   • 서버측: API서버, 미들웨어(API 게이트웨이)
     • API 게이트웨이: 처리율 제한, SSL 종단, 사용자 인증, IP 허용 목록 관리 등을 지원하는 완전 위탁관리형 서비스(→ 처리율 제한을 지원하는 미들웨어)
   • 고려할 사항
     • 현재 사용중인 프로그래밍 언어, 기술스택
     • 알맞은 처리율 제한 알고리즘
     • 마이크로 서비스, API 게이트웨이 사용 중 → 처리율 제한 기능도 API 게이트웨이에 포함
     • 직접 처리율 제한 장치 구현 시 오래걸림 → 상용 API 게이트웨이 사용 고려

2. 처리율 제한 알고리즘

   • 토큰 버킷 알고리즘
     • 버킷에는 사전 설정된 양의 토큰이 주기적으로 채워짐, 용량이 꽉 차면 추가로 공급된 토큰은 버려짐
     • ex: 버킷의 크기가 4고, 토큰이 1분에 4개 공급된다고 가정 → 처음에 4개가 공급되고, API 요청 받을 때 토큰 1개사용, 1분뒤 4개 공급(3개만 들어가고 1개는 용량때문에 버려짐) → 1분이 지나기전에 API 요청 5회 받으면 4번째 요청까지는 정상적으로 실행. 5번째 요청은 버킷에 토큰이 없으므로 429 Error 반환
       
     • 일반적으로 API 엔드포인트마다 별도의 버킷을 둠
     • 장점
       • 구현이 쉬움
       • 메모리 사용 효율적
       • 짧은 시간에 집중되는 트래픽 처리 가능
     • 단점
       • 버킷 크기와 토큰 공급률을 적절히 정하는 것이 까다로움
   • 누출 버킷 알고리즘
     • 토큰 버킷 알고리즘과 비슷하지만, 요청 처리율이 고정되어 있음. 보통 FIFO 큐로 구현
     • 요청이 도착하면 큐가 가득차있는지 보고, 빈자리가 있으면 요청에 추가, 없으면 버림
     • 지정된 시간마다 요청을 꺼내서 처리
     • 장점
       • 큐의 크기 제한, 메모리 사용 효율적
       • 고정된 처리율 → 안정적 출력이 필요한 경우 적합
     • 단점
       • 단시간에 많은 트래픽이 몰리는 경우 큐에 오래된 요청이 쌓이고, 제때 처리하지 못하면 최신 요청은 버려짐
       • 버킷 크기와 처리율을 적절히 정하는 것이 까다로움
   • 그 외에 고정 윈도 카운터 알고리즘, 이동 윈도 로깅 알고리즘, 이동 윈도 카운터 알고리즘 등이 있다.

   대략적인 아키텍처

   얼마나 많은 요청이 접수되었는지를 알 수 있는 카운터를 단위 별로 두고(사용자, IP 주소, API 엔드포인트, 서비스 단위 등), 카운터의 값이 한도를 넘어서면 요청을 거부하고 아니면 요청을 API 서버로 전달

   → 카운터는 어디에 보관? → Redis같은 in memory 캐시

   상세 과정

   • 클라이언트가 요청을 보내면 처리율 제한 미들웨어 도달
   • 처리율 제한 미들웨어는 제한 규칙, 카운터, 마지막 요청의 타임스탬프 등을 캐시에서 가져옴
   • 가져온 값에 따라 처리율 제한 여부 판단하여, 제한에 걸리지 않았다면 API 서버로 보내고, 제한에 걸렸다면 429 Error를 반환하고 해당 요청을 버리거나 메시지 큐에 저장