읽을때 마다 새로운 지식을 알게되는 책이지만, 다음 챕터로 넘어 갈수록 너무 어려워져서 손이가지 않는 책으로 최대한 많이 이해하고 완독을 목표로 정리를 하기위해서 글을 작성하게 되었다.
처음에는 2부 부터 읽다가 왜 1을 읽지 않느냐는 질문을 받고 1부를 읽게되었고 1부 부터 읽는게 필수라고 할정도로 난이도 차이가 있다.
잘근잘근 씹어먹듯, 많은 지식을 남길 수 있도록 열심히 정리해보자!
가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 예스24
처리율 제한장치?
-> 클라이언트 or 서비스가 보내는 트래픽의 처리율 (rate)를 제어하기 위한 장치
API의 요청횟수가 제한장치에 정의된 임계치를 넘어서면 추가로 도달한, 모든 호출은 처리가 중단된다.
처리율 제한장치의 구성의 장점
- DOS 공격에 의한 자원 고갈을 방지
- 비용에 대한 절감
- 서버의 수를 줄일 수 있고, 우선 순위 API 에 더 많은 할당이 가능하다.
- 서버 과부하를 막을 수 있다.
처리율 제한장치를 어디에 구성해야할까?
클라이언트 측
- 안정성이 떨어지는 선택이다. 위변조가 가능하고 모든 클라이언트에 대한 구현도 어렵다.
서버 / 미들웨어
- 서버 프로그램 내부에 구현하는 방법
- 미들웨어 (API Gateway) 로 구성하는 방법
서버 / 미들웨어는 두 방법에서의 정답은 존재하지 않는다. 우선 순위와 목표에 따라 다르게 선택하면 된다.
처리율 제한 알고리즘
1. 토큰 버킷 알고리즘
토큰 생성 시간(토큰 공급률) 과 버킷 크기에 대한 인자를 사용하는 방식이다.
해당 알고리즘에 대한 자세한 설명은 다음과 같다.
- 사전에 설정된 양의 토큰으로 주기적으로 컨테이너가 채워진다.
- 주기가 되었더라도, 컨테이너의 설정 양보다 토큰양이 많으면 토큰은 제거된다.
- 요청당 하나의 토큰을 사용하여 토큰을 제거한다.
- 컨테이너에 처리가능한 토큰이 없다면 해당 요청은 버려진다.
- 일정시간이 지나면 다시 토큰이 채워진다.
그림으로 설명하면 다음과 같다.
버킷 컨테이너를 두는 기준을 어디에 둘 것 인가하는 사용 서비스에 따라 결정하면 된다.
- 통상적으로는 API 엔드포인트마다 버킷 컨테이너를 나눌수 있다.
- IP 주소별로 제한량을 두어야한다면 IP 주소별로
- 시스템 처리율을 제한하고 싶다면 모든 요청이 하나의 버킷을 공유하도록 설정한다.
장점
- 구현이 쉽고 메모리 측면이 효율적이 장점이 있다.
- 짧은 시간에 집중되는 트래픽(burst of traffic)도 처리가능하다. 버킷에 남은 토큰이 있다면,
단점 - 버킷 크기와 토큰 공급률 인자를 적절하게 튜닝하는 일은 까다로운 일
-> 토큰 버킷을 기반으로 서비스 안에 시스템을 구현했다. 다만 서비스 pod 각각 버킷을 갖고있어 해당하는 부분을 튜닝하기 어려운 부분이 있었다.
2. 누출 버킷 알고리즘 (leaky bucket)
해당 알고리즘은 토큰 버킷 알고리즘과 비슷하나 요청 처리율이 고정되어 있다는 것이 달랐다.
FIFO의 큐와 버킷 크기 - 큐 사이즈 / 처리율(outflow rate) 의 인자 값으로 구성되이 있다.
정리하면 다음과 같다.
1. 요청이 도착하면 큐가 가득차있는지 확인하고 자리가 있다면 큐에 요청을 추가
2. 큐가 가득차 있으면 새 요청을 버림
3. 지정된 시간마다 큐 요청을 꺼내 버린다.
장점
- 큐의 크기를 제한하여 메모리의 효율성이 있다.
- 고정 처리율로 장정된 출력이 필요한 경우 좋다.
단점 - 단시간에 트래픽이 몰린다면,오래된 요청이 쌓이고 최신 요청은 버려진다.
- 두개의 인자값을 튜닝하기 어렵다.
다음에 계속..
