사전 서비스 한도
개념

서비스 한도

gabury1고친 사람 github-actions[bot]

서비스 한도는 한 계정이 클라우드 서비스에서 만들거나 쓸 수 있는 양을 미리 묶어 둡니다. 여러 고객이 같은 설비를 나눠 씁니다. 한도는 한 고객이 다 가져가지 못하게 막습니다. 한도를 넘는 요청은 거절됩니다. 대부분은 신청을 거쳐 늘릴 수 있습니다.

쉽고 빠른 이해

서비스 한도는 계정 하나가 쓸 수 있는 양을 서비스 쪽에서 미리 정해 둔 것입니다. 한 계정이 띄울 수 있는 가상 머신을 스무 대로 정해 두었다면 스물한 번째는 만들어지지 않습니다.

이게 없으면 한 고객의 실수가 남에게 번집니다. 잘못 짠 스크립트가 서버를 끝없이 만들면 같은 설비를 쓰는 다른 고객의 몫까지 줄어듭니다. 그 고객도 모르는 사이에 큰 요금을 떠안습니다.

어떻게 도나:

  1. 서비스가 계정마다 무엇을 몇 개까지, 초당 몇 번까지 쓸 수 있는지 정해 둡니다
  2. 요청이 올 때마다 지금 쓰는 양을 한도와 견줍니다
  3. 넘으면 거절합니다. 더 필요하면 고객이 늘려 달라고 신청합니다

대가는 고객이 한도를 미리 챙겨야 한다는 것입니다. 손님이 몰리는 날 서버를 늘리려다 한도에 막히면 그 길로 장애가 됩니다.

상세

도서관은 한 사람이 한 번에 빌릴 수 있는 책을 다섯 권으로 정해 둡니다. 여섯 번째 책을 빌리려면 한 권을 먼저 반납해야 합니다. 논문을 쓰는 대학원생처럼 사정이 있으면 사서에게 말해 권수를 늘려 받기도 합니다.

서비스 한도도 같은 일을 합니다. 클라우드 서비스나 외부 API(Application Programming Interface)를 내주는 쪽이 계정마다 쓸 수 있는 양을 정해 둡니다. 한 계정이 띄울 수 있는 가상 머신 수나 초당 보낼 수 있는 요청 수가 그런 값입니다. 그 값을 넘는 요청은 처리하지 않고 오류로 돌려보냅니다.

부르는 이름은 서비스마다 다릅니다. 한도(limit)라고도 합니다. 할당량(quota)이라고도 합니다. 다만 할당량은 하루나 한 달처럼 정해진 기간 동안 쓸 수 있는 누적 양을 좁게 가리킬 때도 많습니다.

한도를 두는 이유

클라우드 서비스는 여러 고객이 같은 서버와 네트워크를 나눠 쓰게 지어집니다. 이 방식을 멀티테넌시라고 부릅니다. 설비를 나눠 쓰면 한 고객이 몰아 쓸 때 다른 고객의 몫이 줄어듭니다. 한도는 한 고객이 가져갈 수 있는 몫에 끝을 정해 둡니다.

한도는 고객 자신도 지킵니다. 배포 스크립트의 반복문이 잘못 돌아 서버를 끝없이 만드는 일이 있습니다. 접속 키가 새어 남이 자원을 마구 만드는 일도 있습니다. 한도가 있으면 그 피해가 한도에서 멈춥니다.

한도가 있고 없고의 차이는 요금에서 크게 드러납니다. 클라우드는 대개 쓴 만큼 요금을 받는 종량제로 돌아갑니다. 막는 장치가 없으면 사고가 난 만큼 요금도 끝없이 불어납니다.

한도는 서비스 쪽의 용량 계획도 돕습니다. 용량 계획은 앞으로 필요한 설비를 미리 가늠해 마련하는 일입니다. 고객마다 쓸 수 있는 최대치가 정해져 있으면 수요를 가늠하기 쉬워집니다. 한도를 늘려 달라는 신청은 큰 수요가 온다는 신호 구실도 합니다.

한도가 묶는 네 가지 양

한도가 무엇을 세는지는 넷으로 나뉩니다. 무엇을 세느냐에 따라 넘었을 때 벌어지는 일도 다릅니다.

종류 무엇을 세나 예 넘으면
개수 지금 가지고 있는 자원 수 가상 머신 대수 · 저장소 버킷 수 · 데이터베이스 수 새 자원을 만들지 못합니다
속도 짧은 시간 동안 보낸 요청 수 초당 요청 수 넘친 요청이 거절되거나 늦춰집니다
누적량 정해진 기간 동안 쓴 양 하루 호출 수 · 한 달 전송량 기간이 바뀔 때까지 막힙니다
크기 요청 하나나 자원 하나의 크기 요청 본문 크기 · 파일 하나의 크기 그 요청 하나만 거절됩니다

표에서 개수와 크기는 기다린다고 풀리지 않습니다. 개수는 자원을 지워야 줄고, 크기는 요청을 작게 바꿔야 통과합니다.

속도와 누적량은 시간이 지나면 쓸 수 있는 몫이 다시 생깁니다. 속도 한도는 잠깐 기다렸다 보내면 통과합니다. 누적량 한도는 하루나 한 달 같은 기간이 바뀔 때까지 기다려야 합니다.

늘릴 수 있는 한도와 고정된 한도

소프트 한도는 신청하면 늘릴 수 있는 한도입니다. 대부분의 한도가 여기에 듭니다. 고객이 늘려 달라고 신청하면 서비스 쪽이 사용 이력과 사유를 보고 승인합니다. 승인까지 시간이 걸릴 수 있어서 필요해지기 전에 신청해 둡니다.

하드 한도는 신청해도 늘어나지 않는 한도입니다. 대개 서비스가 요청을 처리하는 방식과 맞물린 값입니다. 바꾸려면 서비스를 다시 지어야 합니다. 요청 하나의 최대 크기처럼 처리 구조에서 나온 값이 이런 경우가 많습니다.

하드 한도는 넘을 수 없으니 피해 갑니다. 크기 한도에 걸리는 큰 파일은 여러 조각으로 쪼개서 보냅니다. 늘릴 수 없는 개수 한도가 모자라면 자원을 여러 계정에 나눠 둡니다.

한도를 세는 범위

한도는 어디서 세는지가 같이 정해져 있습니다. 가장 흔한 단위는 계정 하나입니다. 한 계정을 여러 팀이 같이 쓰면 한도도 같이 씁니다.

그래서 한 팀의 사용이 다른 팀을 막기도 합니다. 시험용 서버를 잔뜩 띄우면 운영 서버가 더 늘어나지 못합니다. 운영 계정과 시험 계정을 따로 두는 이유 가운데 하나가 이것입니다.

계정 안에서 다시 지역별로 나눠 세는 한도도 많습니다. 클라우드는 설비를 지리적으로 떨어진 여러 데이터 센터 묶음에 나눠 둡니다. 그 묶음 하나를 리전이라고 부릅니다. 리전마다 따로 세는 한도라면 두 리전에 나눠 띄울 때 쓸 수 있는 양도 두 배가 됩니다.

한도에 닿았을 때

한도를 넘는 요청에 서비스는 오류를 돌려줍니다. 오류 메시지에는 어느 한도에 걸렸는지가 적히는 경우가 많습니다. 무엇을 세는 한도인지에 따라 대응이 갈립니다.

속도 한도에 걸리면 HTTP(HyperText Transfer Protocol) 상태 코드 429 Too Many Requests가 흔히 돌아옵니다. 서버는 정해진 시간 동안 들어온 요청을 세다가 넘친 것을 이 코드로 거절합니다. 응답 헤더에 언제 다시 보내면 되는지를 적어 주기도 합니다.

이때 받는 쪽은 바로 다시 보내지 않습니다. 기다리는 간격을 점점 늘려 가며 다시 보냅니다. 이 방식을 지수 백오프라고 부릅니다. 모두가 같은 순간에 다시 몰려드는 것을 막아 줍니다.

개수 한도는 기다려도 풀리지 않습니다. 쓰지 않는 자원을 지우거나 한도를 늘려야 합니다. 이 차이를 모르고 다시 보내기만 되풀이하면 오류가 끝나지 않습니다.

가장 아픈 경우는 오토스케일링이 한도에 막힐 때입니다. 오토스케일링은 부하가 오르면 서버를 알아서 더 띄우는 기능입니다. 손님이 몰려 서버를 늘려야 하는 그때 가상 머신 개수 한도에 닿으면 새 서버가 뜨지 않습니다. 평소에는 한도 근처에 갈 일이 없어 아무도 모르다가 그날 장애로 드러납니다.

아래 그림은 한도 초과 오류를 받았을 때의 판단을 모은 것입니다. 앞 소절들이 다룬 갈림을 위에서부터 묻습니다.

flowchart TD
    A["한도 초과 오류를 받는다"] --> B{"속도 한도인가"}
    B -->|예| C["간격을 늘려 가며 다시 보낸다"]
    B -->|아니오| G{"누적량 한도인가"}
    G -->|예| H["기간이 바뀔 때까지 기다린다"]
    G -->|아니오| I{"개수 한도인가"}
    I -->|예| J["안 쓰는 자원부터 지운다"]
    I -->|아니오| D{"소프트 한도인가"}
    H -->|못 기다리면| D
    J -->|그래도 모자라면| D
    D -->|예| E["늘려 달라고 신청한다"]
    D -->|아니오| F["쪼개 보내거나 계정을 나눈다"]

한도를 미리 챙기는 법

한도는 장애가 나기 전에 챙겨야 합니다. 서비스는 대개 계정의 한도와 지금 쓰는 양을 함께 보여 주는 화면이나 API 를 줍니다. 무엇에 어떤 한도가 걸려 있는지를 먼저 알아 둡니다.

다음은 쓰는 양을 지켜보는 일입니다. 사용량을 모니터링하다가 한도에 가까워지면 알림이 오게 해 둡니다. 알림을 거는 기준은 늘리는 데 걸리는 시간을 보고 정합니다. 승인이 오래 걸릴수록 일찍 울려야 합니다.

큰 행사나 새 서비스 출시를 앞두면 미리 늘려 둡니다. 당일에 신청하면 승인이 늦을 수 있습니다. 늘려 둘 한도는 행사 날 오토스케일링이 띄울 최대 대수를 기준으로 계산합니다.

부하 테스트도 한도를 미리 드러내 줍니다. 부하 테스트는 운영과 비슷한 양의 요청을 일부러 보내 시스템이 버티는지 보는 일입니다. 평소에 안 닿던 한도가 이때 먼저 터집니다. 그래서 테스트 자체가 운영 계정의 한도를 써 버리지 않게 계정을 나눠 돌립니다.

헷갈리는 이웃 개념

서비스 한도 둘레에는 비슷하게 들리는 이름이 셋 있습니다. 아래 표는 각각이 무엇이고 서비스 한도와 어떻게 이어지는지를 견줍니다.

이름 무엇인가 서비스 한도와의 관계
속도 제한 정해진 시간 동안 들어온 요청을 세어 넘친 것을 거절하는 장치 속도 한도를 지키게 하는 수단
스로틀링 넘친 일을 거절하는 대신 늦춰서 속도를 누르는 일 한도에 닿았을 때 서비스가 고르는 대응 하나
서비스 수준 계약 서비스가 최소한 이만큼은 해 주겠다고 고객에게 하는 약속 방향이 반대다. 한도는 고객이 쓸 수 있는 최대치다

표를 한 줄씩 줄이면 이렇습니다. 서비스 한도는 숫자를 정합니다. 속도 제한과 스로틀링은 그 숫자를 지키게 합니다. 서비스 수준 계약은 서비스 쪽이 지켜야 할 최소치를 정합니다.

관련 항목

서비스 한도가 속하는 상위 분류

클라우드 컴퓨팅 · API 설계 · 멀티테넌시 · 클라우드 거버넌스

서비스 한도가 묶는 양의 종류

할당량 · 쿼터 정책 · 속도 제한 · 초당 요청 수 · 동시 실행 수 · 페이로드

늘릴 수 있는지에 따른 한도의 하위 종류

소프트 한도 · 하드 한도 · 한도 증설 요청 · 계정 분리

서비스 한도를 세는 단위

계정 · 리전 · 테넌트 · API 키 · 프로젝트

한도에 닿았을 때 서비스가 돌려주는 응답

스로틀링 · HTTP 429 · RateLimit 헤더 필드 · Retry-After · 부하 차단

한도에 막힌 쪽이 쓰는 대응 수단

재시도 · 지수 백오프 · 지터 · 샤딩 · 큐

서비스 한도가 막으려는 문제

시끄러운 이웃 · 자원 고갈 · 과부하 · 계정 탈취 · DDoS

한도를 미리 챙기는 운영 작업

용량 계획 · 모니터링 · 알림 · 부하 테스트 · 오토스케일링 · 비용 관리

서비스 한도와 함께 고객에게 밝히는 이용 조건

서비스 수준 계약 · 서비스 수준 목표 · 요금제 · 종량제

다른 이름: service limits · service quotas · 서비스 할당량 · 서비스 제한 · 계정 한도