네트워크 시스템에서 처리율 제한장치란 클라이언트 또는 서비스가 보내는 트래픽의 처리율을 제어하기 위한 장치다.
HTTP를 예로 들면, 이 장치를 설정하면 특정 기간 내에 전송되는 클라이언트의 요청 횟수를 제한할 수 있다.
- 사용자는 초당 2회 이상 새 글을 쓸 수 없다.
- 같은 IP 주소로는 하루에 10개 이상의 계정을 생성할 수 없다.
- 같은 디바이스로는 주당 5회 이상 리워드를 요청할 수 없다.
처리율 제한 장치를 설정하면 어떤 이득을 얻을 수 있을까?
- DDoS 공격에 의한 자원 고갈을 방지할 수 있다.
- 트위터는 3시간 동안 300개의 트윗만 올릴 수 있도록 제한하고 있다.
- 구글 독스는 사용자당 분당 300회의 read 요청만 허용한다.
- Reverse Proxy를 통한 로드 밸런서, 규칙, IP 차단/허용 목록, 지역 차단 및 속도 제한 등으로 DDoS를 예방하는 것 또한 처리율 제한 장치에 해당한다.
- 비용을 절감한다.
- AWS Lambda는 컴퓨팅 시간과 사용 횟수마다 요금이 부과된다.
리전: 아시아 태평양(서울)
아키텍처 | 시간 | 요청 |
x86 요금 | ㅤ | ㅤ |
처음 6십억GB-초/월 | GB-초당 0.0000166667 USD | 요청 1백만 건당 0.20 USD |
다음 9십억GB-초/월 | GB-초당 0.000015 USD | 요청 1백만 건당 0.20 USD |
다음 150억GB-초/월 | GB-초당 0.0000133334 USD | 요청 1백만 건당 0.20 USD |
Arm 요금 | ㅤ | ㅤ |
처음 75억GB-초/월 | GB-초당 0.0000133334 USD | 요청 1백만 건당 0.20 USD |
다음 112억 5천GB-초/월 | GB-초당 0.0000120001 USD | 요청 1백만 건당 0.20 USD |
다음 187억 5천GB-초/월 | GB-초당 0.0000106667 USD | 요청 1백만 건당 0.20 USD |
- 서버 과부하를 막는다. 트래픽이나 잘못된 이용 패턴으로 유발된 트래픽을 걸러내는데 처리율 제한 장치를 사용 할 수 있다.
1단계 문제 이해 및 설계 범위 확정
처리율 제한 장치를 구현하는 데는 여러 가지 알고리즘을 사용할 수 있다. 어떤 알고리즘을 사용할지는 면접관과의 소통을 통해 명확히 해야 한다.
- Q : 어떤 종류의 처리율 제한 장치를 설계해야 합니까? 어느 사이드에서 사용할 제한 장치입니까? A : 서버 API를 위한 제한 장치
- Q : 어떤 기준을 사용해서 제어해야 합니까? A : 다양한 형태의 제어 규칙을 정희할 수 있는 유연한 시스템
- Q : 시스템 규모는? A : 대규모
- Q : 분산 환경에서 작동합니까? A : 그렇다.
- Q : 독립 서비스입니까, Application의 코드 레벨입니까? A : 면접자의 선택의 영역
- Q : 사용자가 장치에 의해 필터링된다면 Notification이 있어야 합니까? A : 그렇다.
해당 질의 과정을 통한 요구사항은 다음과 같다.
- 설정된 처리율을 초과하는 요청은 정확하게 제한한다.
- 낮은 응답시간(Low Latency): 이 장치가 HTTP 응답 시간에 끼치는 악 영향은 최대한 적어야 한다.
- 가능한 한 적은 메모리를 사용해야 한다.
- 분산형 처리율 제한: 하나의 처리율 제한 장치를 여러 서버나 프로세스가 공유할 수 있어야 한다.
- 예외 처리: 요청이 제한될 때는 사용자에게 분명한 알림이 있어야 한다.
- 높은 결함 감내성: 제한 장치에 장애가 생기더라도 전체 시스템은 정상 동작해야 한다.
2단계 개략적 설계안 제시 및 동의 구하기
- 처리율 제한 장치는 어디에 둘 것인가?
- 서버
- 미들웨어
- Application 내부 구조의 캡슐화, 클라이언트는 서버와 통신하는게 아닌 엔드포인트 API 게이트웨이와 통신한다.
- 엔드포인트 통일을 통한 클라이언트 코드의 단순화
- 여러 서버간 통신에 대한 동적이며 유연한 대처 가능
- 개발 및 배포와 고가용성 등 관리비용
- 특정 API 게이트웨이에서 병목이 일어날 수 있음
- 프로그래밍 언어 / 캐시 등 사용하고 있는 기술 스택을 점검(어떤 언어가 효율적으로 구성할 수 있을지 측정해야 한다.)
- 현재 서비스에 가장 적합한 알고리즘을 찾아야 한다. 제 3자가 제공하는 게이트웨이를 사용하기로 했다면(서드파티) 선택지는 제한될 수 있다.
- 만약 서비스의 설계가 MSA 기반이고, 게이트웨이가 존재한다면 처리율 처리 장치 또한 게이트웨이에 포함시켜야 할 수 있다.
- 처리율 제한 장치를 구현할 리소스가 부족하다면 서드파티 게이트웨이를 사용하는 것이 합리적이다.
클라이언트에 처리율 제한 장치를 두는 것은 안정적으로 두기 힘들다. 위변조가 쉽기 때문이다. 그렇다면 제한 장치를 어디에 두어야 하는가?
서버를 거치기 전, 미들웨어를 중간에 두어 미들웨어를 먼저 거쳐 서버로 요청을 전달하는 방법이 있다.
API Gateway
Microservice Architecture(이하 MSA)에서 언급되는 컴포넌트 중 하나이며, 모든 클라이언트 요청에 대한 end point를 통합하는 서버이다. 마치 프록시 서버처럼 동작한다. 그리고 인증 및 권한, 모니터링, logging 등 추가적인 기능이 있다. 모든 비지니스 로직이 하나의 서버에 존재하는 Monolithic Architecture와 달리 MSA는 도메인별 데이터를 저장하고 도메인별로 하나 이상의 서버가 따로 존재한다. 한 서비스에 한개 이상의 서버가 존재하기 때문에 이 서비스를 사용하는 클라이언트 입장에서는 다수의 end point가 생기게 되며, end point를 변경이 일어났을때, 관리하기가 힘들다. 그래서 MSA 환경에서 서비스에 대한 도메인인 하나로 통합할 수 있는 API GATEWAY가 필요한 것이다. - 우아한 기술 블로그, 배민 API GATEWAY – spring cloud zuul 적용기
요즘은 하나의 스테디 셀러로 자리잡은 클라우드 마이크로서비스(클라우드 기반 MSA)에서 처리율 제한 장치는 API 게이트웨이라는 컴포넌트에 구현된다. API 게이트웨이는 처리율 제한, SSL 종단, 사용자 인증 , IP 허용 관리(Whitelist) 관리 등을 지원하는 완전 관리형 서비스, 즉 클라우드 업체가 유지 보수를 담당하는 서비스를 말한다.
API 게이트웨이를 사용함으로서 얻을 수 있는 장점은, 단일 진입 지점을 통한 서버의 캡슐화와 엔드포인트를 통일함으로써 클라이언트에서 서버 사이드와 통신하기에 더 용이한 편의성을 제공한다.
Pros
Cons
API Gateway를 통한 MSA 구현의 대표적인 사례로는, 넷플릭스가 있다. 클라이언트별 접근을 통해 실행하여 각 기능에 맞는 API를 제공하는 API Gateway를 사용한다. 하나의 API Gateway는 일반적으로 평균 6~7개의 Backend 서비스를 호출하여 각 요청을 처리한다. Netflix API Gateway는 하루에 수십억 건의 요청을 처리한다.
완전관리형?
클라우드 공급자가 서비스의 모든 측면을 관리하고 유지보수하는 서비스 형태를 의미한다. 이는 고객이 인프라스트럭처나 플랫폼을 직접 관리할 필요 없이, 클라우드 공급자가 서버, 네트워크, 운영체제, 데이터베이스, 보안 등을 포함한 모든 관리 작업을 대신 수행하는 서비스다.
대표적인 완전관리형 서비스로는 RDS / Dynamo DB 등이 있다.
부분적인 완전관리형 서비스(대부분 지원하지만, 사용자의 조정과 동작이 필요한)로는 EC2, EKS, Lambda 등이 있다.
처리율 제한 장치를 처음 설계할 때 중요한 것은 다음과 같다.
- 처리율 제한 알고리즘
- 토큰 버킷 알고리즘
- 누출 버킷
- 고정 윈도 카운터
- 이동 윈도 로그
- 이동 윈도 카운터
- 토큰 버킷 알고리즘
- 버킷 크기: 토큰에 담을 수 있는 토큰의 최대 개수
- 토큰 공급률: 초당 몇 개의 토큰이 공급되는지
- 구현이 쉽다.
- 메모리 사용 측면에서 효율적이다.
- 단시간 집중되는 트래픽도 처리 가능하다. 토큰이 남아있기만 하다면 요청은 처리된다.
- 버킷 크기와 토큰 공급률을 튜닝하는 것은 까다로운 일이다.
널리 알려진 처리율 제한 알고리즘은 다음과 같다.
토큰 버킷은 널리 사용되고 있으며, 기업들이 보편적으로 사용하고 있다.
토큰 버킷은 지정된 용량을 갖는 컨테이너다. 사전 설정된 양의 토큰이 주기적으로 채워진다. 토큰이 꽉 찬 버킷에는 토큰이 채워지지 않는다. 토큰 공급기는 정해진 주기에 따라 토큰을 추가한다. 버킷이 가득 차면 추가 공급된 토큰은 버려진다. 요청이 하나 처리될 때마다 토큰을 사용한다.
충분한 토큰이 있는 경우, 토큰 하나를 꺼내 요청을 시스템에 전달한다. 토큰이 없는 경우 해당 요청은 버려진다.
토큰 버킷은 2개 인자를 받는다.
버킷은 몇 개를 사용해야 하는가? 규칙에 따라 달라진다. 예를 들어, 사용자는 하루에 한 번 포스팅 할 수 있고 친구는 150명 까지 추가 가능하며 좋아요 버튼은 다섯 번 까지만 누를 수 있다면 버킷은 3개 필요하다.
IP 주소별로 처리해야 한다면 IP 주소마다 버킷을 하나씩 두어야 한다. 시스템의 전체 처리율이 초당 10,000개로 제한하고 싶다면 공유된 하나의 버킷을 사용해야 한다.
Pros
Cons
아마존에서는 API Gateway의 처리량 제한을 토큰 버킷 알고리즘을 통해 제한하고 있다.
API에 대한 제한 및 할당량을 구성하여 너무 많은 요청으로 인해 과부하되지 않도록 보호할 수 있습니다. 제한과 할당량은 모두 최선의 방식으로 적용되며 보장된 요청 한도가 아닌 대상으로 간주해야 합니다.API Gateway는 요청에 대해 토큰이 계산되는 토큰 버킷 알고리즘을 사용하여 API에 대한 요청을 제한합니다. 특히 API Gateway는 리전별로 계정의 모든 API에 대한 요청 제출 속도와 버스트를 검사합니다. 토큰 버킷 알고리즘에서 버스트는 이러한 제한의 사전 정의된 초과 실행을 허용할 수 있지만, 다른 요인으로도 제한을 초과할 수 있습니다.요청 제출이 정상 상태의 요청 속도 및 버스트 제한을 초과할 경우 API Gateway에서 요청을 제한하기 시작합니다. 이 시점에서 클라이언트는429 Too Many Requests오류 응답을 받을 수 있습니다. 이러한 예외를 포착하면 클라이언트는 속도 제한 방식으로 실패한 요청을 다시 제출할 수 있습니다. AWS, 처리량 향상을 위해 API 요청 조절
위 사례를 통해
현재 서비스에 가장 적합한 알고리즘을 찾아야 한다. 제 3자가 제공하는 게이트웨이를 사용하기로 했다면(서드파티) 알고리즘 선택지는 제한될 수 있다.
라는 적절한 예시를 찾아볼 수 있다.
- 누출 버킷 알고리즘
- 요청이 도착하면 큐가 가득 차 있는지 본다. 빈자리가 있다면 큐에 요청을 추가한다.
- 큐가 가득차면 요청은 버린다.
- 지정된 시간마다 큐에서 요청을 꺼내 처리한다.
- 버킷 크기: 큐 사이즈와 같은 값
- 처리율: 지정된 시간 당 몇 개의 항목을 처리할 지 지정하는 값
- 큐의 크기가 제한되있어, 메모리를 효율적으로 사용할 수 있다.
- 고정 처리율을 갖고 있어 안정적 출력이 필요한 경우 적합하다.
- 단 시간 트래픽이 몰리는 경우 요청들이 쌓이게 되고, 큐가 꽉 차면 요청들이 버려지게 된다.
- 두 인자를 튜닝하기 어렵다.
누출 버킷 알고리즘은, 토큰 버킷과 유사하지만 요청 처리율이 고정되어 있다는 점이 다르다. 보통 FIFO Queue로 구현된다.
누출 버킷 알고리즘은 다음 두 인자를 사용한다.
Pros
Cons
전자 상거래 기업인 쇼피파이가 이 알고리즘을 사용하고 있다.
Shopify API는 다양한 속도 제한 방법을 사용합니다 . 아래에 더 자세히 설명되어 있지만 주요 수치를 간단히 요약하면 다음과 같습니다.
API | 기준한도 | 고급 Shopify 한도 | Shopify Plus 한도 | Shopify 한도별 상거래 구성요소 | |
계산된 쿼리 비용 | 100포인트/초 | 200포인트/초 | 1000포인트/초 | 없음 | |
요청 기반 한도 | 요청 2개/초 | 요청 4개/초 | 요청 20개/초 | 없음 | |
없음 | 없음 | 없음 | 없음 | 없음 | |
계산된 쿼리 비용 | 910포인트/초 | 910포인트/초 | 1820포인트/초 | 없음 | |
계산된 쿼리 비용 | 100포인트/초 | 200포인트/초 | 200포인트/초 | 없음 |
- 고정 윈도 카운터 알고리즘
- 타임라인을 고정된 간격의 윈도로 나누고, 각 윈도마다 카운터를 붙인다.
- 요청이 접수될 때 마다 카운터의 값을 1씩 증가시킨다.
- 카운터의 값이 설정된 임계치에 도달하면 새로운 요청은 새 윈도가 열릴 때 까지 버려진다.
- 메모리 효율이 좋다.
- 이해하기 쉽다.
- 윈도가 닫히는 시점에 카운터를 초기화 하는 방식은 특정 트래픽 패턴을 처리하기 적합하다.
- 윈도 경계 부근에서 일시적으로 트래픽이 몰리는 경우 기대 처리 시스템 한도량 보다 초과하여 사용하게 될 수 있다.
다음과 같이 동작한다.
각 타임라인의 시간 단위는 1초다. 시스템은 초당 3개까지만 허용한다. 매 초마다 열리는 윈도에 3개 이상의 요청이 밀려오면 초과분은 버려진다.
이 알고리즘의 치명적 단점은 특정 구간에 트래픽이 몰릴 경우 할당된 수치보다 더 큰 트래픽이 처리될 수 있는 것이다.
만약 1분 간격으로 5건의 요청만 처리할 수 있다고 임계점을 설정한 후 트래픽이 몰렸을 때,
1:01:00 ~ 1:02:00에 5건, 1:02:00 ~ 1:03:00에 5건을 처리했다면 1:01:30 ~ 1:02:30 사이에는 총 10건의 요청을 처리하게 될 수도 있다. 허용한도의 2배를 처리하게 된 것이다.
Pros
Cons
- 이동 윈도 로깅 알고리즘
- 처리율 제한 매커니즘은 아주 정교하다. 어느 순간의 윈도를 보더라도, 허용되는 요청의 개수는 처리율 한도를 넘지 않는다.
- 다량의 메모리를 사용하는데, 거부된 요청의 타임스탬프도 보관하기 때문이다.
위에서 살펴본 것 처럼, 고정 윈도 알고리즘은 치명적인 단점이 있다. 이동 윈도 로깅 알고리즘은 이런 문제를 해결한다.
이 요청은 타임스탬프를 추적한다. 타임스탬프 데이터는 보통 레디스의 정렬 집합 같은 캐시에 보관한다. 새 요청이 오면 만료된 타임 스탬프는 제거한다. 만료된 타임 스탬프는 그 값이 현재 윈도의 시작 지점보다 오래된 타임스탬프를 말한다.
새 요청의 타임스탬프를 로그에 추가한다. 로그의 크기가 허용치보다 같거나 작으면 요청을 시스템에 전달한다. 그렇지 않은 경우 처리를 거절한다.
위 처리율 제한기는 분당 최대 2건의 요청만을 처리하도록 설계 됐다. 요청이 들어오면 로그가 생성되고, 1분안에 요청이 2건을 초과한다면 처리는 거절된다. 요청이 들어올 때마다 로그가 쌓이고 해당 로그의 타임스탬프를 기준으로 처리하기 때문에 고정 윈도 알고리즘보다 더 정교하게 작동할 수 있다.
Pros
Cons
- 이동 윈도 카운터 알고리즘
- 현재 1분간의 요청수 + 직전 1분간의 요청 수 * 이동 윈도와 직전 1분이 겹치는 비율
- 이 공식에 따르면 현재 윈도에 들어 있는 요청은 3 + 5 * 70% = 6.5개다. 반올림 할 수도 있고, 반내림 할 수도 있다.
- 이전 시간대의 평균 처리율에 따라 현재 윈도 상태를 계산하기 때문에 짧은 시간에 몰리는 트래픽도 잘 대응한다.
- 메모리 효율이 좋다.
- 적정 시간대에 균일하게 분포되어 있다고 가정한 상태에서 추정하기 때문에 다소 느슨하다. 클라우드 플레어의 실험에 따르면 40 억개의 요청 가운데 실 상태와 맞지 않게 허용되거나 버려진 데이터는 0.003%에 불과하다고 했다.
이동 윈도 카운터 알고리즘은 고정 윈도 카운터 알고리즘과 이동 윈도 로깅 알고리즘을 결합한 것이다. 그 중 하나를 설명하면,
처리율 제한 장치의 한도가 분당 7개의 요청으로 설정되어 있고, 이전 1분 동안 5개의 요청이, 그리고 현재 1분 동안 3개의 요청이 왔다고 치면
현재 1분의 30% 시점에 도착한 새 요청의 경우, 현재 윈도에 몇 개의 요청이 온 것으로 보고 처리해야 할까?
Pros
Cons
3단계 상세 설계
다음과 같은 사항은… 여태의 과정으로도 알 수 없다.
- 처리율 제한 규칙은 어떻게 만들어지고 어디에 저장되는가?
- 처리가 제한된 요청들은 어떻게 처리되는가?
- 처리율 제한 규칙
처리율 제한 규칙은 보통 설정 파일 형태로 디스크에 저장된다.
- 처리율 한도 초과 트래픽 처리
- X-Ratelimit-Remaining : 윈도 내에 남은 처리 가능 요청의 수
- X-RateLimit-Limit: 매 윈도마다 클라이언트가 전송할 수 있는 요청의 수
- X-Ratelimit-Retry-After: 한도 제한에 걸리지 않기 위해 몇 초 뒤에 요청을 다시 보내야 하는지 알림
- 클라이언트가 요청을 보내면 요청은 먼저 처리율 제한 미들웨어에 도달한다.
- 처리율 제한 미들웨어는 제한 규칙을 디스크나 캐시에서 가져온다. 알고리즘에 따라, 달라지겠지만 이동 윈도 카운터라면 마지막 요청의 타임스탬프를 레디스 캐시에서 가져온다. 가져온 값에 근거하여 다음과 같은 판단을 내린다.
- 해당 요청이 처리율 제한에 걸리지 않는다면, API 서버로 보낸다.
- 해당 요청이 처리율 제한에 걸린다면, 429 에러와 함께 HTTP 응답 헤더를 보낸다. 해당 요청은 버릴 수도 따로 보관할 수도 있다.
어떤 요청이 한도 제한에 걸리면 API는 HTTP 429 응답(too many request)를 클라이언트에게 보낸다. 한도 제한에 걸린 요청을 나중에 처리하기 위해 큐에 보관할 수도 있다.
처리율 제한 장치가 사용하는 HTTP 헤더
클라이언트의 요청이 처리율 제한에 걸리고 있는지를 어떻게 감지할 수 있을까?
클라이언트의 요청이 처리율 제한에 걸리기까지 얼마나 많은 요청을 보낼 수 있는지 어떻게 알 수 있나?
답은 HTTP response header에 있다. 이번 4장에서 처리하는 제한 장치는 아마도… HTTP 헤더를 클라이언트에게 보낸다.
사용자가 너무 많은 요청을 보내면 429에러와 함게 위 헤더를 반환하도록 한다.
- 분산 환경에서의 처리율 제한 장치의 구현
- 경쟁 조건
- 공유 데이터 수정: 여러 프로세스 또는 스레드가 동시에 공유된 데이터를 수정하려고 할 때, 데이터의 일관성을 유지하기 어려울 수 있다. 예를 들어, 두 개의 스레드가 동시에 동일한 변수를 증가시킨다면, 예상과 다른 결과가 발생할 수 있다.
- 자원 경합: 여러 프로세스 또는 스레드가 동시에 동일한 자원에 접근하려고 할 때, 자원에 대한 경합이 발생할 수 있다. 이로 인해 교착상태(deadlock)나 경합 조건(race condition)이 발생할 수 있다.
- 동기화
단일 서버의 처리율 제한 장치는 그렇게 어렵지 않다. 하지만, 분산환경은 다른 얘기다.
다음 두 난제를 해결해야 한다.
분산환경에서 경쟁조건 이란?
분산환경에서 경쟁조건(Concurrency)은 여러 프로세스 또는 스레드가 동시에 실행되는 상태를 말한다. 경쟁조건은 공유된 자원에 대한 동시 접근으로 인해 발생할 수 있으며, 이로 인해 예기치 않은 결과가 발생할 수 있다.
경쟁조건이 발생하는 대표적인 상황은 다음과 같다:
경쟁조건은 올바른 동기화 메커니즘을 사용하여 해결할 수 있다. 예를 들어, 상호 배제(mutual exclusion)를 위한 락(lock)을 사용하거나, 동기화된 데이터 구조를 사용하여 동시 접근을 제어할 수 있다. 또는 원자적(atomic) 연산을 사용하여 원자성을 보장할 수도 있다.
분산 락(Distributed Lock)이나 트랜잭션(Transaction)과 같은 기술을 사용하여 경쟁조건을 관리할 수 있다.
병행성이 심한 환경에서는, 경쟁 조건 이슈가 발생할 수 있다.
만약 레디스에 저장된 변수 counter의 값이 3이라고 하면, 두 개 요청을 처리하는 스레드가 각각 병렬로 counter 값을 읽었으며 그 둘 가운데 어느 쪽도 아직 변경된 값을 저장하지 않았다면
둘 다 다른 요청의 처리 상태는 보관하지 않고 counter에 +1 더한 값을 레디스에 기록할 것이다. counter의 값은 4지만 올바르게 변경됐다고 믿을 것이다 그리고, 사실 counter의 값은 +1을 두 번 한 샘이니 5가 되야한다.
가장 널리 알려진 방법은 분산 락(Lock)이다. 성능을 떨어트리는 이슈가 있는데.. 대부분 데이터베이스를 사용하니 락을 사용하도록 하자.
애초에 위 경쟁조건은 올바른 동기화를 통해 해결할 수도 있다. 처리율 제한 장치를 여러 대를 두게 된다면, 동기화에 대한 고민이 필요해진다.
예를 들어, 4-15의 왼쪽 그림을 보면 클라이언트 1은 제한 장치 1에 요청을 보내고, 클라이언트2는 제한 장치 2에 보내고 있다.웹 계층은 무상태가 일반적이기 때문에, 클라이언트는 다른 장치로 요청을 보내도 정상적으로 동작해야 한다. 이 때 동기화를 하지 않는다면 제한 장치 1은 클라이언트 2의 작업에 대해서 아무것도 모르고 처리율 제한을 올바르게 작동시킬 수 없을 것이다.
이에 대한 한가지 해결책은 고정 세션이다. 클라이언트로부터 요청은 항상 같은 처리율 제한 장치로 보내는 것이 그 것이고, 더 나은 해결책은 레디스와 같은 중앙 집중형 데이터베이스를 사용하는 것이다. 이 설계에 기반한 것이
위 그림이다.
성능 최적화
성능 최적화는 항상 중요한 문제다. 데이터 센터가 멀리 떨어져 있다면, 처리율 제한 장치를 사용할 때 지연시간(Latency)가 증가할 수 밖에 없다. 따라서, 대부분의 클라우드 사업자는 엣지 서버를 심어놓고 있다. 분산된 엣지 서버를 통해 사용자의 트래픽을 가장 가까운 에지 서버로 전달하여 처리하도록 그리고 그 에지 서버의 처리 장치를 이용하도록 하여 지연시간을 줄인다.
장치 간 데이터를 동기화 할 때 최종 일관성 모델을 사용해야 한다.
모니터링
처리율 제한 장치가 효과적으로 동작하는지 알기 위해 데이터와 메트릭을 수집할 필요가 있다.
4단계 마무리
다음의 질문은 도움이 될 수 있다.
- 경성 또는 연성 처리율 제한
- 경성 처리율 제한 : 요청의 개수는 임계치를 절대 넘어설 수 없다.
- 연성 처리율 제한 : 요청 개수는 잠시 동안은 임계치를 넘어설 수 있다.
- 처리율 제한을 회피하는 방법, 클라이언트를 어떻게 설계해야 하는가?
- 클라이언트 측 캐시를 사용하여 API 횟수를 줄인다.
- 처리율 제한의 임계치를 이해하고 단기간에 너무 많은 요청이나 메세지를 보내지 않도록 한다.
- 예외나 에러를 도입하여 예외상황으로부터 우아하게(gracefully) 복구될 수 있도록 한다.
- 재시도 로직은 충분한 백오프 시간을 둔다.
Share article