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

처리율 제한 장치

특정 시간 동안 네트워크를 통해 전송되는 데이터의 양이나 서비스에 대한 요청 수를 제한하는 장치나 소프트웨어를 의미한다.

API 처리 장치의 장점

• Denial of Service 공격 방지
  • DOS 라고 하며 인터넷이나 네트워크에 연결된 서비스나 서버를 대상으로 공격자가 정상적인 사용자나 시스템이 서비스를 이용하지 못하도록 의도적으로 과부하를 일으키는 사이버 공격을 방지한다. 
• 서비스에 대한 요청 수를 제한하기 때문에 비용이 절감될 수 있다.
  • 서버 과부하를 막는 목적도 있다.

시스템 설계 4단계 접근법을 적용

1단계 문제 이해 및 설계 범위 확정 

요구사항 

• 설정되어 있는 처리율을 초과하는 요청은 제한한다. 
• HTTP 응답시간에 나쁜 영향을 주면 안되니 낮은 응답시간을 전제로 한다.
• 적은 메모리
• 하나의 처리율 제한 장치에서 여러 서버 또는 프로세스에 공유할 수 있어야 한다. 
• 요청이 제한되었을 때 제한된 이유를 사용자에게 분명하게 해야 한다. 
• 제한 장치에 장애가 발생하더라도 전체 시스템에 영향을 주면 안된다. 

2단계 개략적 설계안 제시 및 동의 구하기

처리율 장치의 위치에 대한 고민

• Client
  • 위변조가 가능해서 여기에는 추천하지 않는다. 
  • 서버로 보내는 요청 수를 스스로 제한할 수 있다. 
• Server
  • 중앙에서 관리한다.
  • 서버는 요청 수를 제한할 수 있다.
• Middleware
  • Client 와 Server 사이에 위치한다. 여기서 네트워크 요청과 데이터를 중계한다. 
  • MSA 인 경우는 처리율 제한 장치를 API Gateway에 구현한다. 
    • API Gateway 의 역할은 보통 처리율 제한, 사용자 인증, IP White List 관리 등 이 있다.

처리율 제한장치에 사용될 수 있는 알고리즘

토큰 버킷 알고리즘 

[draw] 삼성폰으로 그려서 올리기

• 토큰을 주기적으로 채워진다.
• 각 요청이 처리될 때 마다 하나의 토큰을 사용한다. 
• 토근이 없으면 해당 요청은 버려진다. 

AWS 와 같은 기업에서도 API Gateway 를 생성할 때 보편적으로 사용하는 알고리즘 이라는 사실을 알 수 있다. 

시스템 처리율이 제한되어 있는 상황에서는 초당 발생한 요청은 하나의 버킷을 공유해야 한다. 

AWS 개발자 안내서에 나온 처리량 향상 목적으로 토큰 버킷 알고리즘을 활용

 

위와 같이 채택되어 있는 이유는 장단점이 있다.

장점 

• 구현이 쉽다. 
• 메모리 사용이 효율적이다.
• 초당 발생되는 트래픽도 잘 처리될 수 있다. (버킷이 공유)

단점

• 버킷 Size, 토큰 공급률 두 개의 인자로 필요로 하는 알고리즘이기 때문에 적절한 튜닝 하는것이 어렵다.
  • Q&A -> 이 알고리즘이 뭐고 왜 버킷 사이즈와 토큰 공급률이 필요한거지? 각 내용에 대한 용어 정의가 필요해보인다. 

 

누출 버킷 알고리즘 

[draw] 삼성 폰으로 그려서 추가하기

• 요청이 들어오면 Queue 가 가득 차 있는지 확인한다. 
• 빈 자리가 있다면 Queue에 요청을 추가하게 된다. 
• Queue 가 가득 차 있다면 요청은 버려진다. 
• 지정된 시간마다 Queue 에서 요청을 꺼내 처리한다. 
• 토큰 버킷 알고리즘이랑 비슷하지만, 처리율이 고정되어 있다는 점에서 차이가 있다. 
  • 예를 들어 큐에서 1초에 1개씩 꺼낼 수 있다는 점
• Queue 는 FIFO 로 구현된다. 

장점

• Queue 의 크기를 제한할 수 있기 때문에 메모리를 효율적으로 사용할 수 있다. 
• 고정된 처리율이 있어서 stable outflow rate (안정적인 출력?) 이 필요한 경우 적합 

단점 

• 단기간에 많은 트래픽이 몰리는 경우 최근 요청들이 버려질 수 있다. 
• 튜닝이 어렵다. (버킷크기 & 처리율)

고정 윈도 카운터 알고리즘

[draw] 삼성 폰으로 그려서 추가하기

• 타임라인을 고정된 간격의 window 로 나누고, 각 window 마다 count 를 추가한다. 
• 요청 접수가 된 경우 count 를 1 추가한다. 
• count 가 임계치에 도달하면 새로운 요청은 버려지게 된다. 

장점

• 메모리 효율이 좋다.
• 명확하다.
• window 가 닫히는 시점에 count 초기화하는 방식은 특정한 트래픽 패턴을 처리하기 적합하다. 

단점

• window 경계 부근에 트래픽이 몰리면 설정한 임계치를 초과할 수 있다. 

3단계 상세 설계

처리율 제한 규칙

1. 처리율 한도 초과 트래픽 처리HTTP 429 응답 (Too many requests): 어떤 요청이 한도 제한에 걸릴때 응답경우에 따라서 한도 제한에 걸린 메시지를 나중에 처리하기 위해 큐에 보관할 수 있다.
2. 처리율 제한 장치가 사용하는 HTTP 헤더클라이언트가 자기 요청이 처리율 제한에 걸리고 있는지에 대한 정보를 아래 HTTP 헤더를 통해 전달한다.

• X-Ratelimit-Remaining: 윈도 내에 남은 처리 가능 요청의 수
• X-Ratelimit-Limit: 매 윈도마다 클라이언트가 전송할 수 있는 요청의 수
• X-Ratelimit-Retry-After: 한도 제한에 걸리지 않으려면 몇 초 뒤에 요청을 다시 보내야 하는지 알림

분산 환경에서의 처리율 제한 장치의 구현

• 경쟁 조건 (race condition)이슈 경쟁 이슈가 발생하는 동작
• 해결 방법 : 레디스에서 카운터의 값을 읽는다.counter +1 의 값이 임계치를 넘는지 본다.넘지 않는다면 레디스에 보관된 카운터 값을 1만큼 증가시킨다.
• 동기화이슈 : 여러대의 처리율 제한 장치를 사용할 경우 요창이 분산될 수 있다.
• 해결방법 : Sticky session 을 사용하여 같은 클라이언트로부터의 요청은 항상 같은 처리율 제한 장치로 보낼 수 있도록 할 수 있다.
• 성능 최적화 이슈 : 지연시간
• 해결방법 : 지연시간을 줄이기 위해 사용자의 트래픽을 가장 가까운 Edge 서버로 전달하여 지연시간을 줄인다.

4단계 마무리

경성 또는 연성 처리율 제한

• 요청의 개수는 임계치를 절대 넘어설 수 없다.

다양한 계층에서의 처리율 제한

• 애플리케이션 계층(7번 계층)에서의 처리율 제한 외에도 다른 계층에서 제어ex) Iptables를 사용하여 IP 주소에 처리율 제한을 적용

처리율 제한을 회피하는 방법

• 클라이언트 측 캐시를 사용하여 API 호출 횟수 줄이기
• 예외나 에러를 처리하는 코드를 도입하여, 클라이언트가 예외적 상황으로부터 우아하게 복구될 수 있도록 한다.
  • 서버가 죽어서 안 되는건지, 요청이 많아서 안 되는 건지 클라에서 알 수 있도록 하자.
  • 에러를 받았을 때, 재처리 / 재시도 할 수 있도록 한다. 우아하게 서킷 브레이커 사용하자.
  • 서버를 지켜줄 수 있다. 우리 서버 지켜!
• 재시도 로직을 구현할 때는 충분한 백오프 시간을 두도록 한다.