가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 정리 4장 처리율 제한 장치의 설계
가상 면접 사례로 배우는 대규모 시스템 설계 기초 리뷰
가상 면접 사례로 배우는 대규모 시스템 설계 기초
3장 처리율 제한
처리율 제한 장치 설계
몇가지 사례이다.
- 사용자는 초당 2개 이상의 새글을 포스팅할 수 없다.
- 같은 IP로 하루에 10개 이상의 계정을 생성할 수 없다.
- 같은 디바이스로 주당 5회 이상 리워드를 요청할 수 없다. 예시로 든 몇가지 사례는 DoS(Denial of Service) 공격에 의한 자원 고갈을 방지할 수 있다. 대부분 API는 어떤 형태로든 처리율을 제한하는 장치를 갖고 있다. 추가 요청에 대해서는 처리를 중단함으로써 DoS공격을 방지한다.
서버 과부하를 막아 봇에서 오는 트래픽이나 사용자의 잘못된 이용 패턴으로 유발하는 트래픽을 걸러내는데 사용할 수 있다.
1단계 문제 이해 및 설계 범위 확정
처리율 제한 장치를 구현하는 데는 여러 가지 알고리즘을 사용할 수 있는데, 각각의 고유한 장단점을 갖고 있다. 면접관과 소통하면서 어떤 제한 장치를 구현해야 하는지 분명히 해야한다.
책에서 밝히는 몇가지 사례이다.
- 어떤 종류의 처리율 제한 장치를 설계해야 하나요? 클라이언트 측 제한 장치입니까. 아니면 서버 측 제한 장치입니까?
- 어떤 기준에서 API 호출을 제어해야 할까요? IP주소를 사용해야 하나요? 아님 사용자 ID? 아니면 생각하는 다른 어떤 기준이 있습니까?
- 시스템 규모는 어느 정도여야 할까요? 스타트업 정도일까요? 아님 대기업일까요?
- 시스템이 분산 환경에서 동작해야 하나요?
- 이 장치는 독립된 서비스입니까? 아님 APP 코드에 포함될까요?
- 사용자의 요청이 처리율 제한 장치에 의해 걸러진 경우 사용자에게 정확한 그 사실을 알려야 하나요?
2단계 개략적 설계안 제시 및 동의 구하기
기본적인 클라이언트 서버 구조가 무난한다.
처리율 제한 장치는 어디에 둘 것인가?
직관적으로는 장치를 클라이언트 또는 서버 측에 둘 수 있다.
- 클라이언트 : 일반적으로 클라이언ㄴ트는 처리율 제한을 안정적으로 걸 수 있는 장소가 못된다. 클라이언트 요청은 손쉽게 위변조가 가능하기 때문에 통제가 어렵다.
서버 : 여러가지 방법이 있다. API가 위치한 코드에 장치를 두는 방법과 API에 접속하기 전 미들웨어 형식으로 제한 장치를 둘 수 있다. 처리율 제한 알고리즘
토큰 버킷 알고리즘 : 사전에 설정된 양의 토큰이 주기적으로 채워지는 버킷이 있다. 토큰이 꽉 찬 버킷에는 더 이상의 토큰은 추가되지 않는다. 버킷에 만약 토큰이 있다면 사용자 요청과 함께 서버에 전달된다. 하지만 토큰이 없다면 요청은 버려진다. 누출 버킷 알고리즘
토큰 버킷 알고리즘과 비슷하지만 요청 처리율이 고정되어 있다는 점이 다르다. FIFO 형식으로 구현된다. 버킷이 Que형태로 구성이 되며 큐가 가득 차있다면 요청은 버려진다. 큐에 남은 공간이 있다면 가장 마지막에 채워지고 일지정된 시간마다 하나씩 거내어 처리한다. 고정 윈도 카운터 알고리즘
타임라인을 고정된 간격의 윈도로 나누고, 각 윈도마다 카운터를 붙인다. 요청이 접수될 때마다 이 카운터의 값은 1씩 증가한다. 만약 카운터의 값이 사전 설정된 임계치에 도달하면 새로운 윈도우가 열릴 때 까지 버려진다. 이동 윈도 로깅 알고리즘
- 고정 윈도 카운터 알고리즘은 윈도 부근 트래픽이 몰리면 부하가 걸리는 문제점이 있다. 이런 문제점을 해결한다.
요청의 타임 스탬프를 추적한다. 타임 스탬프 데이터는 보통 Redis의 정렬 집합 같은 캐시에 보관한다. 새 요청이 들어오면 타임스탬프는 제거한다. 만료된 타임 스탬프는 그 값이 현재 윈도의 시작 시점보다 오래된 타임스탬프를 의미한다. 새 요청의 타임스탬프 로그를 추가한다. 로그의 크기가 허용치보다 같거나 작으면 요청을 시스템에 전달한다. 그렇지 않은 경우 요청을 거부한다. 이동 윈도 카운터 알고리즘
- 고정윈도카운터 알고리즘 + 이동윈도로깅 알고리즘
개략적인 아키텍처
카운터를 어디에 보관할 것인가? 장치를 어디에 위치할 것인가? 사용자의 정의를 IP주소로 할 것인가? 한도를 넘어선 요청은 어떻게 처리할 것인가? 등등 개략적인 아키텍처를 설계한다.
3단계 상세 설계
개략적인 설계를 통해 아키텍처를 만들었지만 상세한 내용을 알 수 없다.
- 처리율 제한 규칙은 어디에서 만들어지고 저장되는가?
- 제한된 요청은 어떻게 처리되는가?
- … 상세 설계에서는 많은 부분이 고려된다. 단일 시스템의 경우 손 쉽지만 분산 시스템의 경우는 경쟁 조건과 동기화 과정을 생각해야 한다. 또한 서버의 성능 최적화 모니터링 및 유지 보수 계획도 수립해야한다.
마무리
모든 단계를 거치고 나선 이런것까지 고려하면 좋을 듯하다.
- 경성 또는 연성 처리율 제한
- 다양한 계층에서 처리율 제한