[성능] 스로틀링(Throttling)이란?

스로틀링(Throttling)이란?

PC, 노트북, 모바일 기기의 CPU, GPU 등이 지나치게 과열될때 기기의 손상을 막고자 클럭과 전압을 강제적으로 낮추거나 강제로 전원을 꺼서 발열을 줄이는 기능이다. 성능을 강제로 낮춘다는 점에서 거부감이 들 수 있으나, 발열을 제대로 제어할 수 없게 되면 기기의 수명과 배터리에 악영향을 주게 되므로 꼭 필요한 기능이라 할 수 있다.

 

특히 발열에 취약한 스마트폰/태블릿/노트북 등은 필수적으로 스로틀링 기능을 갖추고 있다. 같은 사양의 노트북이 데스크톱에 비해 성능이 떨어지는 이유도 방열성능이 떨어져 그만큼 스로틀링이 빨리오거나, 부품 보호를 위해 스로틀링의 임계값이 낮게 세팅되어 있기 때문이다.

 

PC, 노트북과 같이 쿨링팬과 히트싱크 구조를 가지고 있는 기기의 경우에는 내부의 먼지가 끼어 통풍이 불량해지거나, 쿨러에 도포 되어 있는 서멀 그리스가 굳어 열전도 성능이 떨어지게 되면 방열 기능이 떨어져 스로틀링이 발생하게 된다. 따라서, PC가 고성능을 요구하는 작업을 일정 시간 실행한 이후에 갑자기 급격하게 성능이 저하되거나, 별다른 작업을 하지도 않았는데도 쿨링팬이 굉음을 내며 돌아간다면 이를 의심해보고 쿨링팬, 방열판 등의 먼지 제거와 함께 서멀 그리스 재도포 등의 조치를 취하는 것이 좋다.

(먼지 청소와 서멀 그리스의 재도포가 필요한 시점은 일반적으로 컴퓨터를 사용한 이후로 2~3년 정도 시점이며, 먼지의 경우에는 오래 묵힐 경우 먼지가 굳어져 청소하기 힘들어지므로 자주 해주는 것이 좋다)

 

데스크탑의 경우, 원래부터 쿨링 성능이 워낙 좋고 구조적으로 여러 옵션까지 추가하는 것이 가능하기 때문에 아무리 오버클럭을 해도 섭씨 70도를 유지할 수 있다. 제품 문제 기기를 제외하고는 100도까지 올라간다면 쿨러에 문제가 있는 경우이다. 특별한 경우가 아닌데, 오버클럭할때 70~80도 이상 올라간다면 컴퓨터를 의심해보는 것이 좋다.

 

한편, 설계 단계에서부터 쿨링 구조 및 시스템이 안좋으면 평범하게 사용해도 스로틀링이 걸리기도 한다. 대포적으로 애플의 일체형 PC 제품들. iMac의 경우 팬하나로 CPU/GPU를 냉각하는 구조고 디자인의 한계로 인해 작업 및 게임을 할때 팬이 엄청난 속도로 돌아감에도 불구하고 발열이 감당되지 않아 스로틀링이 일어나기도 한다. iMac Pro의 경우, 팬이 두개로 늘어났지만 CPU가 무려 95도까지 치솟아서 워크스테이션답지 않다는 점으로 지적받았다.

 

서버에 부담이 되는 과한 이벤트 등이 일어날때 제어 파라미터를 통한 성능 제한을 둔다. 너무 많은 요청으로 인해 API가 가득차는 것을 방지하기 위해 API Gateway 레이어에서 API 요청에 대한 조절을 할 수도 있다. API Gateway에서는 계정의 모든 API에 대한 요청 제출 버스트 및 안정적인 상태의 속도에 관한 한도를 설정 기능을 추가한다. (토큰 버킷 알고리즘)

 

Request가 안정적인 상태의 요청 속도 및 버스트 한도를 초과할 경우, API Gateway에서 한도 초과 요청을 실패시키고 "429 Too Many Requests" 오류 응답을 클라이언트에 반환하게 된다. 그런 예외가 발생할 경우, 클라이언트는 API Gateway 조절 한도를 준수하면서 속도를 제한하여 실패한 요청을 다시 제출할수 있도록 한다.

 

API 개발자는 전체 성능향상을 위해 개발 API 단계 또는 메서드에 대한 한도를 설정할 수 있다. 또는 사용량 계획을 활성화하여 클라이언트 요청 제출을 지정된 요청 속도 및 할당량 이내로 제한할 수도 있다. 수준 조절 한도에서 크게 벗어나지 않도록 전체 요청을 제한할 수 있게 된다.

 

---

API Throttling

[가설] 기본적으로 API Gateway에서는 안정적인 상태 요청 속도를 10,000rps(초당 요청수)로 제한하고, API에 대해 버스트(즉, 최대 버킷 크기)를 5,000 요청으로 제한한다. API Gateway에서 버스트 한도는 API Gateway에서 429 Too Many Requests 오류 응답을 반환하지 않고, 정상적으로 이행할 수 있는 최대 동시 요청 제출 수이다.

---

[CASE 1] 호출자가 1초 동안 균등하게 10,000개의 요청을 제출하면(예를 들어 1밀리초마다 10개 요청), API Gateway는 어떤것도 삭제하지 않고 모든 요청을 처리.

 

[CASE 2] 호출자가 첫 밀리초내에 10,000개 요청을 제출하면 API Gateway는 1초 내에 이 요청 중 5,000개를 처리하고 나머지 요청을 조절.

 

[CASE 3] 호출자가 첫 밀리초내에 5,000개 요청을 제출한 후, 남은 999밀리초 동안 5,000개 요청을 균등하게 분산해 제출하면(예를 들어 1밀리초마다 약 5개 요청), API Gateway는 429 Too Many Requests 오류 응답을 반환하지 않고 1초 동안 전체 10,000개 요청을 처리한다.

 

[CASE 4] 호출자가 첫 밀리초 내에 5,000개 요청을 제출하고 101번째 밀리초에 나머지 5,000개 요청을 제출하면, API Gateway는 이 1초 내에 6,000개 요청을 처리하고 나머지 요청을 조절합니다. 왜냐하면 API Gateway는 10,000rps의 속도로 첫 100밀리초가 지난 후 1,000개 요청을 처리하여 동일한 용량만큼 버킷을 비웠기 때문이다. 다음의 5,000개 요청 스파이크 중에서 1,000개 요청이 버킷을 채우고, 처리 대기 상태에 놓입니다. 나머지 4,000개 요청은 버킷 용량을 초과하므로 무시됩니다.

 

[CASE 5] 호출자가 첫 밀리초 내에 5,000개 요청을 제출하고 101번째 밀리초에 1,000개 요청을 제출한 후 남은 8999밀리초 동안 4,000개 요청을 균등하게 분산해 제출하면 API Gateway는 조절없이 1초 동안 전체 10,000개 요청을 처리한다.

 

토큰버킷 알고리즘 - API 처리 계통도

 

일반적으로, 지정된 순간에 버킷에 b가 포함되어있고 최대 버킷 용량이 B일 경우 버킷에 추가될 수 있는 최대 추가 토큰 수는 Δ=B-b이다. 이 최대 추가 토큰수는 클라이언트가 429 오류 응답을 수신하지 않고 제출할 수 있는 최대 추가 동시 요청 수에 해당한다. 일반적으로 Δ는 시간에 따라 다른다. 값의 범위는 0(버킷이 가득찬 상태, b=B)부터 B(버킷이 비어있는 상태, b=0)까지 이다. 범위는 요청 처리 속도(버킷에서 토큰이 제거되는 속도)와 속도 한도 속도(버킷에 토큰이 추가되는 속도)에 따라 달라진다.

---

실제 서비스에서 스로틀링 설정을 위한 사용량 계획은 어떻게 세우면 좋을까?

 

톰캣 MaxThreadCount의 개수가 500개인데, 500개 이상의 동시 요청이 들어오면, 클라이언트에서는 Connection을 맺지 못하여, Timeout이 될때까지 기다리다 한참 뒤에 실패응답을 받게 된다. 이런 경우, 스로틀링 설정을 500개로 지정하여, 현재 활성화된 요청 큐의 수를 제한하는 스로틀링 설정이 도움될 수 있다.

 

요청수 서버 처리 한도를 넘어섰을때, 클라이언트로 바로 429 에러응답을 주면, 초과 요청을 제출한 클라이언트도 빠른 실패 응답을 받을 수 있어, 실패에 대한 대응을 빠르게 처리할 수 있다. 더불어, 요청 쓰레드가 밀려서 전체 사용자 응답이 느려지는것을 방지할 수 있다.