대용량 요청 시 해결 방안
1억명의 이용자에게 알림을 보내야하는 상황을 가정을 해보자.
고려사항
1. 한 번에 많은 요청 시 서버다운 발생
2. 불필요한 비용 발생으로 효율적인 환경 x
해결방안
- Leaky Bucket
- Token Bucket
- Sliding Window Counter
1. Leaky Bucket
- 네트워크로 가는 데이터의 양을 일정하게 유지를 하고 트레픽 체증을 일정하게 유지한다.
- 일정 용량의 Bucket을 정해놓고 그 안에 담긴 데이터는 일정한 속도로 떨어진다.
- 데이터가 Bucket의 용량을 초과하게 되면 버리게 된다.
- 입력 속도 > 출력 속도 : Bucket에서 누적 발생
- 누적 > 버킷 용량 : 오버플로 발생, 데이터 패킷 손실
2. Token Bucket
- 일시적으로 많은 트래픽이 와도 토큰이 있다면 처리가 가능하다.
- 토큰 손실 처리를 통해 평균 처리 속도를 제한할 수 있다.
- 즉, 평균 유입 속도를 제한하고 처리 패킷 손실없이 특정 수준의 버스트 요청을 허용할 수 있다.
- 토큰은 정해진 비율로 버킷에 넣는다.
- 버킷은 최대 N개의 토큰을 저장하며, 버킷이 가득차면 새로 추가된 토큰은 삭제되거나 거부된다.
- 요청이 들어오면 큐에 들어가며 요청을 처리하기 위해서는 토큰 버킷의 토큰을 필요로 한다.
- 토큰을 보유한 후에 요청이 처리되고 처리된 후에 토큰은 삭제된다.
- 토큰이 배치되는 속도를 기반으로 액세스 속도를 제어한다.
- 전송 횟수를 누적할 수 있으며, 버킷이 가득차면 패킷 손실 없이 토큰이 손실된다.
3. Sliding Window Counter
- Fixed Window Counter 의 경계 문제와 Sliding Window Log의 로그 보관 비용 등의 문제점을 보완할 수 있는 알고리즘.
- 분당 10건의 처리에서 1분안에 9건, 1분과 2분 사이에는 5건이 온다고 가정.
- 1분 15초에 요청이 왔는데 1분 15초 지점은 1분과 2분 사이에서 25% 지점, 이전 기간은 1 - 0.25 = 75% 비율로 계산
- 9 * 0.75 + 5 = 14.75 > 10 으로 한도를 초과했기 때문에 요청은 거부된된다.
- 즉, 이전 window와 현재 window의 비율값을 계산된 합이 처리 건수를 초과하면 거부된다.
- 만약 1분 30초 시점에 요청이온다면 9 * 0.5 + 5 = 9.5 < 10 이므로 요청이 처리된다.
- 비율이 소수점으로 나오게 된다면 정확도가 떨어질 수는 있으나, Fixed Window Counter와 Sliding Window Log의 문제점을 개선한다.
Limit Algorithm 선택
- 서비스가 트래픽 체증에 민감하지않다면 Token Bucket, 그 외에는 Fixed Winow나 Sliding Window
- 기본적으로 서비스 인프라 트래픽을 수용할 수 없는 지점에 도달했을 때 Limit을 적용해야한다.
- 외부 서비스에 영향을 최소화하는 노력(동일한 API는 Limit에 걸리지 않는 높은 상한선) 을 한 다음 Limit을 적용하는 것이 좋다.
- API 응답에 요청 정보와 남은 정보 등 트래픽이 초과했을 떄 오류값 등을 명확히 정의해야한다.
'Java' 카테고리의 다른 글
String str = ""; 과 String str = new String(""); (0) | 2022.11.06 |
---|---|
Static (정적) (0) | 2022.04.02 |
제네릭 타입소거 (Generic type Erasure) (0) | 2021.11.07 |
자바의 컴파일 과정 (0) | 2021.10.31 |
[JAVA] Wrapper Class와 일급 컬렉션 (0) | 2021.10.17 |