스로틀링

스로틀링은 어떤 일이 일어나는 속도를 정해 둔 상한 아래로 일부러 누릅니다. 몰려드는 일을 다 받으려다 시스템이 느려지거나 멈추는 것을 막으려고 겁니다. 서버로 들어오는 요청에도, 프로세서를 쓰는 시간에도 같은 이름을 씁니다.

상세

수도꼭지를 조금만 열어 두면 물탱크가 가득 차 있어도 물줄기는 가늘게만 나옵니다. 물이 얼마나 빨리 나오는지는 탱크가 아니라 꼭지가 정합니다.

스로틀링은 어떤 일이 일어나는 속도를 일부러 늦춰서, 그 일이 정해 둔 속도 이하로만 일어나게 하는 것입니다. 「1초에 몇 번」처럼 상한을 먼저 정합니다. 상한을 넘는 일은 곧바로 처리하지 않습니다. 스크롤할 때마다 불리는 함수를 10밀리초에 한 번까지만 부르게 묶는 것이 그런 예입니다.

무엇을 세느냐는 맥락마다 다릅니다. 웹 서버는 들어오는 요청 수를 셉니다. 운영체제는 프로세스 묶음이 프로세서를 쓴 시간을 셉니다. 브라우저 코드는 함수를 부른 간격을 셉니다.

세는 대상이 달라도 「상한을 넘지 않게 누른다」는 뜻은 하나입니다. 속도가 떨어지는 네트워크를 흉내 내려고 한 번에 보낼 수 있는 데이터 양을 묶는 네트워크 스로틀링도 같은 뜻입니다.

시계를 읽는 함수에도 같은 말을 씁니다. 지금 시각을 돌려주는 Date.now() 를 쉬지 않고 불러도 돌아오는 값이 최대 어느 속도로만 바뀌게 시계의 정밀도를 거칠게 만드는 것이 타이머 스로틀링입니다.

누르는 대상이 들어오는 일만은 아닙니다. 바깥에서 부르는 서비스가 실패하거나 오류를 돌려주면, 그쪽으로 내보내는 호출 수를 스스로 줄이기도 합니다. 상대가 회복되면 원래 흐름으로 되돌립니다.

먼저 차는 지점

서버 쪽에서는 무엇을 셀지 고르는 일이 상한 값보다 앞섭니다. 가장 흔히 세는 것은 초당 요청 수입니다. 하지만 먼저 차는 것은 다른 단위인 경우가 많습니다.

동시에 처리 중인 요청 수, 큐 길이, 프로세서·메모리 사용률, 뒤에서 부르는 다른 서비스의 한도가 그렇습니다. 큐 길이는 처리를 기다리며 줄 선 일의 수입니다.

한 요청이 여러 곳으로 퍼져 나가는 지점에서 동시 처리 수가 먼저 차는 시스템은, 초당 요청 수만 묶어서는 못 지킵니다. 요청이 서비스에 닿기 전에 거치는 앞단 서버인 게이트웨이, 서비스, 뒤에서 부르는 서비스처럼 상한을 거는 경계마다 무엇이 먼저 차는지 찾습니다. 그리고 그 단위에 상한을 겁니다.

한 번 거르고 끝나지 않는 고리

스로틀링은 요청 하나를 들일지 말지 한 번 정하고 끝나는 문이 아닙니다. 포화 정도를 계속 잽니다. 정해 둔 경계에서 상한을 지킵니다. 트래픽 모양이 바뀌면 상한도 고칩니다.

충분히 자란 시스템은 과부하를 사고로 보지 않습니다. 감지해서 회복하는 평상시 상태 가운데 하나로 다룹니다.

flowchart TD
    A["포화 정도를 잰다"] --> B{"상한을 넘었나"}
    B -->|안 넘었다| C["바로 처리한다"]
    B -->|넘었다| D["넘긴 일을 다룬다 · 거절 · 기능 끄기 · 큐 · 미루기"]
    C --> E["트래픽 모양이 바뀌면 상한을 고친다"]
    D --> E
    E -->|다시 잰다| A

넘긴 일을 다루는 방법 넷은 아래 「갈래」가 하나씩 짚습니다.

남은 몫을 세는 방법

지금 얼마나 썼는지를 세는 방법이 몇 가지 있습니다. 짧은 순간 한꺼번에 몰려드는 요청을 버스트라고 부릅니다. 어느 방법을 고르느냐가 버스트를 얼마나 받아 주는지를 정합니다.

스로틀링이 못 하는 일

스로틀링은 자동 확장과 함께 쓸 수 있습니다. 자동 확장은 수요에 맞춰 서버 같은 자원을 늘리고 줄이는 것입니다. 수요가 높게 이어질 것 같으면 확장이 끝날 때까지 스로틀링이 시스템을 버티게 합니다. 새 용량이 붙으면 상한을 풉니다.

다만 수요가 새 용량이 붙는 속도보다 빨리 늘면, 스로틀링을 건 시스템도 무너질 수 있습니다. 상한을 걸어도 들어오는 수요 자체가 줄지는 않습니다. 새 자원이 제때 오지 않으면 지금 있는 자원이 바닥납니다.

최대 부하에 상한을 거는 일은 캐시가 대신하지 못합니다. 캐시는 원본에 걸리는 평균 부하를 낮추지만 최대 부하에는 상한을 못 겁니다. 캐시에 없는 요청은 전부 원본으로 갑니다. 인기 있는 키가 몰림 속에 만료되면 여럿이 한꺼번에 그 값을 다시 채우러 달려갈 수도 있습니다.

배경

서버에 걸리는 부하는 시간에 따라 출렁입니다. 업무 시간에는 로그인하는 사용자가 늘어납니다. 월말마다 계산량이 많은 분석 작업을 돌리는 시스템도 있습니다. 예고 없는 몰림도 옵니다.

처리 요구가 처리할 수 있는 양을 넘으면 시스템은 느려지거나 멈춥니다. 약속한 서비스 수준 목표도 깨집니다.

자원을 늘려서 받는 길이 있습니다. 자동 확장은 지금 수요에 맞춰 준비해 둔 자원을 늘리고 줄입니다. 그런데 새 자원을 준비하는 데는 시간이 걸리고 비용이 붙습니다. 수요가 용량이 늘어나는 속도나 예산을 넘어서면 자원이 모자라는 구간이 생깁니다.

그래서 자원을 쓰는 양에 상한을 두는 방법이 필요했습니다. 쓰는 양이 그 상한을 넘으면 요청을 누릅니다. 그러면 시스템은 계속 돌면서 약속한 수준을 지킵니다.

이 일을 스로틀링이라고 부릅니다. 원래는 흐르는 유체를 무언가로 막아 흐름을 늦추는 것을 가리키던 말입니다.

예시

Amazon API Gateway

Amazon API Gateway 는 계정 하나·리전(지역) 하나에 걸친 모든 API(Application Programming Interface, 응용 프로그램 인터페이스) 요청을 토큰 버킷으로 셉니다. 토큰 하나가 요청 하나입니다.

계정의 기본값은 두 개입니다. 둘은 서로 다른 상한이 아니라 한 통의 두 부품입니다.

flowchart TD
    R["토큰을 초당 10,000개 채운다"] --> T
    subgraph BK["통 · 최대 5,000개"]
      T["쌓인 토큰"]
    end
    T --> Q{"꺼낼 토큰이 있나"}
    Q -->|있다| P["토큰 하나를 꺼내 요청을 처리한다"]
    Q -->|없다| X["429 Too Many Requests 를 돌려준다"]

통에는 토큰이 초당 10,000개 채워집니다. 요청 하나가 토큰 하나를 꺼내 갑니다. 그래서 고르게 이어지는 요청은 초당 10,000건까지 지나갑니다. 짧은 순간 몰리는 요청은 통에 쌓여 있던 토큰만큼 더 지나갑니다.

케이프타운·밀라노·자카르타 같은 일부 리전은 기본값이 2,500 과 1,250 입니다. 버스트 값은 서비스 운영 팀이 정합니다. 고객이 바꿔 달라고 요청할 수 없습니다.

요청이 이 두 값을 넘으면 API Gateway 는 요청을 스로틀링하기 시작합니다. 이때 클라이언트는 HTTP(HyperText Transfer Protocol) 상태 코드 429 Too Many Requests 를 받을 수 있습니다. 클라이언트는 실패한 요청을 속도를 줄여 다시 보낼 수 있습니다.

사용량 계획(usage plan)을 쓰면 API 단위나 배포 단계(stage) 단위로 메서드마다 상한 목표값을 걸 수 있습니다. 거기서 정하는 throttling rate 는 통에 토큰을 채우는 초당 개수입니다. throttling burst 는 통의 크기입니다.

두 값은 최선을 다해 맞추는 목표값이지 보장된 천장이 아닙니다. 다른 요인 때문에 상한을 넘어 통과하는 요청이 생기는 경우도 있습니다.

리눅스 CFS 대역폭 제어

리눅스 커널은 프로세스 여럿을 한 묶음으로 묶어 자원을 함께 다루는 단위를 cgroup(control group)이라고 부릅니다. 그 묶음이 쓸 프로세서 시간에 상한을 걸 수 있습니다.

이 기능의 이름은 CFS(Completely Fair Scheduler, 완전 공정 스케줄러)의 대역폭 제어입니다. 여기서 대역폭은 네트워크 속도가 아니라 한 주기에 쓸 수 있는 프로세서 시간의 최대치를 가리킵니다.

상한은 두 값으로 정합니다. 주기(period)는 셈을 다시 시작하는 시간 간격입니다. 몫(quota)은 한 주기 안에 쓸 수 있는 프로세서 시간입니다.

주기마다 묶음은 몫까지의 프로세서 시간을 받습니다. 묶음 안의 스레드가 몫을 다 가져가면 그 뒤로 시간을 더 달라는 스레드는 스로틀링됩니다. 스로틀링된 스레드는 몫이 다시 채워지는 다음 주기까지 못 돕니다.

# echo 10000 > cpu.cfs_quota_us   # 몫 = 10ms
# echo 50000 > cpu.cfs_period_us  # 주기 = 50ms

파일 이름의 _us 는 마이크로초입니다. 50밀리초마다 10밀리초를 쓰므로 묶음 전체가 프로세서 하나의 20% 로 묶입니다. 주기를 이렇게 짧게 잡으면 응답 지연이 고르게 나오는 대신 한꺼번에 몰아 쓸 여유가 줄어듭니다.

쉬지 않고 돌려는 스레드가 하나뿐이라면 두 주기 동안 이렇게 돌고 멈춥니다.

block-beta
  columns 10
  a["실행 10ms"]:1
  b["멈춤 40ms"]:4
  c["실행 10ms"]:1
  d["멈춤 40ms"]:4
  e["주기 1 · 50ms · 몫을 다 쓰면 주기 끝까지 멈춘다"]:5
  f["주기 2 · 50ms · 몫이 다시 채워져 다시 돈다"]:5

몫은 한꺼번에 다 주어지지 않습니다. 프로세서마다 자기한테 돌 차례를 기다리는 스레드를 담아 두는 줄이 따로 있습니다. 이 줄을 실행 큐(run queue)라고 부릅니다. 커널은 묶음 안의 스레드가 돌 준비가 될 때마다 몫을 조금씩 떼어 그 프로세서의 실행 큐로 보냅니다.

그래서 스레드가 여럿이면 위 그림과 달라집니다. 몫은 흐른 시간이 아니라 프로세서 시간으로 셉니다. 스레드 둘이 서로 다른 프로세서에서 동시에 돌면 같은 몫이 두 배로 빨리 닳습니다. 시계로 재는 실행 구간은 10밀리초보다 짧아지고 멈춤은 그만큼 일찍 옵니다.

기본 주기는 100ms 입니다. 몫의 기본값 -1 은 상한이 없다는 뜻입니다. 위 두 파일은 cgroup v1 의 것입니다. cgroup v2 는 cpu.max 한 파일에 $MAX $PERIOD 꼴로 적습니다.

묶음이 얼마나 눌렸는지는 cpu.stat 에 남습니다. nr_periods 는 지나간 주기 수입니다. nr_throttled 는 스로틀링된 횟수입니다. 눌린 시간의 합은 판마다 이름과 단위가 다릅니다.

cgroup 은 묶음 안에 또 묶음을 둘 수 있습니다. 위를 부모, 아래를 자식이라고 부릅니다. 자식은 자기 몫을 다 쓰지 않아도, 부모가 그 주기의 몫을 다 쓰면 부모 몫이 다시 채워질 때까지 못 돕니다.

브라우저 스크롤 함수

스크롤 이벤트는 화면이 1픽셀 움직일 때마다 일어날 수 있습니다. 거기 묶인 onScrolled 함수가 계산량이 많으면 앞선 호출이 뒤 호출을 제때 못 돌게 막을 수 있습니다. 그러면 화면이 눈에 띄게 끊깁니다. 이 함수를 10밀리초에 한 번까지만 불리게 스로틀링합니다.

첫 호출이 일어난 때를 앞 가장자리(leading edge)라고 부릅니다. 그로부터 10밀리초가 지난 때가 뒤 가장자리(trailing edge)입니다. 두 가장자리는 10밀리초 구간의 앞뒤 끝입니다. 첫 호출에서 10밀리초 안에 온 호출은 그 구간 안에 든 것이라 따로 실행하지 않습니다.

대개 앞 가장자리에서 한 번만 실행합니다. 쓰임에 따라 뒤 가장자리나 양쪽에서 실행하기도 합니다. 스크롤하는 동안 화면 요소는 계속 따라 움직이지만 함수는 필요 이상으로 자주 돌지 않습니다.

자바스크립트 유틸리티 라이브러리 lodash 의 _.throttle 이 이 일을 합니다.

// _.throttle(func, [wait=0], [options={}])
jQuery(window).on('scroll', _.throttle(updatePosition, 100));

스크롤하는 동안 updatePosition 을 100밀리초에 한 번까지만 부릅니다. options.leading 과 options.trailing 은 기본값이 둘 다 true 입니다. 둘 다 켜 두면 대기 시간 안에 두 번 이상 불렸을 때만 뒤 가장자리에서 한 번 더 실행합니다.

디바운스는 이웃한 기법입니다. 호출이 쉬지 않고 이어지면 스로틀링은 정한 최대 속도로 계속 실행합니다. 디바운스는 호출이 멎을 때까지 기다렸다가 한 번 실행합니다.

POWERNV 프로세서의 온도 스로틀링

하드웨어도 자기 속도를 누릅니다. 리눅스에서 프로세서 주파수를 조절하는 cpufreq 드라이버 가운데 POWERNV 드라이버는 칩마다 이 파일에 횟수를 남깁니다.

/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/overtemp

프로세서가 지나치게 뜨거워져 최대 주파수가 더 낮은 주파수로 눌린 횟수입니다. 같은 디렉토리의 powercap 은 전력 상한 때문에 눌린 횟수입니다. unthrottle 은 눌렸다가 풀린 횟수입니다.

같은 cpufreq 디렉토리에는 perf_limited 파일도 있습니다. 값이 0 이 아니면 온도·전력·전류 한도 때문에 눌림이 일어나 요청한 성능보다 낮게 나왔다는 뜻입니다.

커널은 온도를 재는 구역을 따로 나눠 둡니다. 이 구역을 온도 구역(thermal zone)이라고 부릅니다. 구역마다 지금 온도와 경계 온도(trip point temperature)가 딸려 있습니다. 경계 온도는 거기에 닿으면 손을 쓰기로 미리 정해 둔 온도입니다.

커널은 이 값들을 사용자 공간으로 내보냅니다. 사용자 공간은 커널 바깥에서 도는 프로그램들의 영역입니다. 식히는 데 쓰는 장치의 속성도 함께 내보냅니다.

온도를 관리하는 프로그램은 거기서 읽은 지금 온도와 경계 온도를 보고 알맞은 장치의 속도를 누를 수 있습니다.

경계

상한을 넘긴 요청을 곧바로 429 로 돌려보내는 것도 스로틀링인가. 맞습니다.

Amazon API Gateway 는 상한을 넘긴 요청을 두고 스로틀링을 시작한다고 합니다. 그때 클라이언트는 429 를 받을 수 있습니다. 스로틀링과 그 이웃 전략을 함께 묶은 목록에서도 첫 줄이 「설정한 속도를 넘긴 사용자의 요청을 거절한다」입니다. 자동 확장이 끝나기 전에 넘치는 요청을 거절해 자원 사용을 한계 아래로 붙드는 것도 스로틀링이 하는 일입니다.

같은 429 를 HTTP 표준은 「속도 제한(rate limiting)」이라 부릅니다. 그래서 거절하는 쪽에서는 두 이름이 같은 신호를 가리킵니다. 「스로틀링은 기다리게 하고 속도 제한은 거절한다」로 두 낱말을 가르는 정의는 이 쓰임과 맞지 않습니다.

스로틀링에는 거절도, 기다리게 하기도 들어 있습니다.

갈래

상한을 넘긴 일을 어떻게 다루느냐가 축입니다. 같은 상한을 걸어도 넘친 일을 거절하나, 줄 세우나, 기능을 덜어 내나, 미루나에 따라 누가 무엇을 내주는지가 달라집니다.

거절하고 다시 오라고 알리기

정해 둔 시간 창 동안 설정한 속도를 넘긴 사용자의 요청을 거절합니다. 그러려면 요청마다 누가 보냈는지 가려 그 사용자 몫으로 쓴 양을 세야 합니다. 상한을 지역 게이트웨이처럼 넓은 단위에 걸면, 부하를 일으킨 것은 몇 명뿐인데 상관없는 사용자 여럿이 같이 눌릴 수 있습니다.

거절이 일시적이라는 것은 상태 코드로 알립니다. 정해진 시간 동안 너무 많이 보냈으면 429 Too Many Requests 입니다. 지금 요청을 받을 수 없으면 503 Service Unavailable 입니다. 예상 못 한 몰림이 그 원인인 경우가 많습니다.

여기에 Retry-After 헤더를 붙여 언제 다시 보내면 되는지를 날짜나 초 단위로 알려 줄 수 있습니다. 거절한 요청은 서버에 남지 않습니다. 다시 보내는 책임이 보낸 쪽으로 넘어갑니다. 내주는 것은 그 요청의 결과입니다.

sequenceDiagram
    participant C as 클라이언트
    participant G as 게이트웨이
    participant S as 서비스
    C->>G: 요청
    G->>S: 상한 안이라 넘긴다
    S-->>G: 결과
    G-->>C: 응답
    C->>G: 상한을 넘긴 요청
    G-->>C: 429 · Retry-After 로 다시 올 때를 알린다
    C->>G: 알려 준 때가 지난 뒤 다시 보낸다

거절은 그것이 막는 일보다 싸야 합니다. 거절하는 데 계산량이 큰 인증이나 깊은 파싱이 들면, 거절당할 요청이 쏟아지는 것만으로 시스템이 포화될 수 있습니다. 그래서 요청이 지나는 길의 되도록 앞쪽에서 거절합니다.

구성 요소가 포화된 뒤에야 거절하기 시작하면, 호출하는 쪽이 속도를 줄이라는 신호를 받기도 전에 지연이 먼저 치솟습니다.

덜 중요한 기능 끄기

꼭 필요하지 않은 기능을 끄거나 품질을 낮춰, 꼭 필요한 기능이 쓸 자원을 남깁니다. 동영상 스트리밍 서비스가 해상도를 낮추는 것이 이 갈래입니다. 요청을 거절하지는 않습니다. 내주는 것은 응답의 완전함입니다. 그 대신 서비스가 계속 응답합니다.

큐로 고르게 흘리기

넘긴 일을 거절하지 않고 큐에 받아 두었다가 고른 속도로 꺼내 처리합니다. 큐가 완충 역할을 해서, 일을 넣는 쪽이 들쭉날쭉한 속도로 몰려도 서비스는 자기 속도로 처리합니다. 보낸 쪽은 다시 보내지 않습니다. 내주는 것은 기다리는 시간입니다.

한 시스템을 여러 고객 단위가 나눠 쓸 때 그 고객 단위를 테넌트라고 부릅니다. 큐로 고르게 흘리면 여러 테넌트가 함께 쓰는 환경에서는 모든 테넌트의 성능이 같이 떨어집니다. 그래서 테넌트마다 맺은 서비스 수준 계약이 다르면, 계약 수준이 높은 테넌트의 일을 먼저 꺼내 처리합니다. 우선순위가 낮은 일은 밀린 일이 풀릴 때까지 큐에 붙잡아 둡니다.

이 갈래를 스로틀링의 하나로 세지 않는 쓰임도 있습니다. 큐를 앞에 두어 수요가 상한에 닿지 않게 미리 막는 장치로 보는 것입니다.

우선순위 낮은 쪽 미루기

우선순위가 낮은 애플리케이션이나 테넌트의 작업을 미룹니다. 큐에서 꺼내는 차례를 미루는 것과 다릅니다. 그 작업 자체를 멈추거나 줄입니다.

그리고 나중에 다시 시도하라는 예외를 돌려줍니다. 내주는 것은 우선순위가 낮은 쪽의 진행입니다.

관련 항목

스로틀링과 같은 뿌리에서 갈라진 억제 수단

속도 제한 · 백프레셔 · 흐름 제어 · 혼잡 제어 · 부하 제한 · 동시성 제한 · 벌크헤드 · 우아한 저하 · 디바운스

스로틀링이 세는 대상에 따라 갈린 하위 종류

네트워크 스로틀링 · 타이머 스로틀링 · 열 스로틀링 · CFS 대역폭 제어

스로틀링이 남은 몫을 세는 알고리즘과 그 설정값

토큰 버킷 · 누출 버킷 · 고정 윈도 카운터 · 슬라이딩 윈도 · 세마포어 · 버스트 · 쿼터 정책

스로틀링과 짝을 이루는 설계 패턴

자동 확장 · 큐 기반 부하 평준화 · 우선순위 큐 · cache-aside · 서킷 브레이커

상한에 걸린 쪽에 돌아가는 신호와 그 처리

HTTP 429 · HTTP 503 · Retry-After · RateLimit 헤더 필드 · 재시도 · 지수 백오프 · 지터 · 재시도 폭풍

커널이 자원을 눌러 둘 때 같이 쓰는 기능

cgroup · 스케줄링 · 메모리 부족 킬러 · 메모리 회수 · 디스크 입출력 · CPU · 컨테이너

스로틀링을 걸어 주는 앞단 장비

API 게이트웨이 · Amazon API Gateway · 로드 밸런서 · 리버스 프록시 · 서비스 메시 · 웹 애플리케이션 방화벽 · nginx

스로틀링이 지키거나 깎는 성능 지표

처리량 · 응답 시간 · 꼬리 지연 · 초당 요청 수 · 대역폭 · 큐 길이

스로틀링을 잘못 걸었을 때 나는 장애

썬더링 허드 · 기아 · 타임아웃 · 캐스케이딩 장애 · 큐 적체

스로틀링의 상한을 정할 때 보는 문서

용량 계획 · 서비스 수준 목표 · 서비스 수준 계약 · 서비스 한도 · 할당량 · 사용량 계획