용량 계획
고친 사람 github-actions[bot]
용량 계획은 앞으로 부하가 얼마나 늘어날지 미리 헤아려 그만큼 자원을 미리 마련해 둡니다. 자원이 한계에 닿기 전에 미리 늘려 두어, 그 사이 손님이 느려진 응답이나 실패를 겪지 않게 합니다. 늘리는 대상은 서버 대수만이 아니라 저장 공간이나 네트워크 대역처럼 여러 가지입니다.
쉽고 빠른 이해
용량 계획은 지금 얼마나 쓰고 있는지와 앞으로 얼마나 늘지를 보고 언제 자원을 얼마나 늘릴지 미리 정하는 일입니다. 미리 정해 두지 않으면 부하가 늘 때 자원을 뒤늦게 늘리게 되고, 서버를 들이는 데도 시간이 걸려 그 사이 손님이 느려진 응답을 겪습니다.
어떻게 하나:
- 지금 씀씀이와 늘어나는 속도를 잰다
- 그 속도로 얼마 뒤 한계에 닿을지 헤아린다
- 한계보다 여유 있게 자원을 미리 늘린다
여유를 넉넉히 잡을수록 안전하지만, 그만큼 안 쓰는 자원에도 비용을 치르는 것이 대가입니다.
상세
식당 주인은 명절에 손님이 몰릴 것을 미리 알면 그날이 오기 전에 재료를 더 시키고 일손을 더 부릅니다. 손님이 밀어닥친 뒤에 재료를 시키면 이미 늦어서 손님을 돌려보내야 합니다.
용량 계획은 시스템이 감당해야 할 부하가 앞으로 얼마나 늘어날지 미리 헤아려, 늘어난 만큼을 감당할 자원을 미리 마련해 두는 일입니다. 여기서 자원은 서버 대수·메모리·저장 공간· 네트워크 대역처럼 늘리거나 줄일 수 있는 것을 통틀어 가리킵니다. 부하가 자원의 한계에 닿은 뒤에 늘리면 그 사이 요청이 느려지거나 실패하므로, 한계에 닿기 전에 미리 늘려 둡니다.
무엇을 보고 앞날을 헤아리나
용량 계획은 두 가지를 근거로 삼습니다. 하나는 지금까지 사용량이 늘어난 속도입니다. 초당 얼마나 많은 요청을 처리하는지를 보는 처리량이나 초당 요청 수를 보면 한 달에 얼마나 느는지 대략 잡을 수 있습니다. 다른 하나는 미리 알려진 사건입니다. 세일이나 명절처럼 특정 날짜에 손님이 몰릴 것을 미리 아는 경우입니다.
이 늘어나는 속도를 지금 자원으로 버틸 수 있는 한계와 견줍니다. 이 한계는 지금 있는 자원에 가상의 요청을 걸어 어디까지 버티는지 실험해 보는 부하 테스트로 미리 알아냅니다. 늘어나는 속도와 지금의 한계를 나란히 놓으면 언제 한계에 닿을지 날짜로 잡을 수 있습니다.
여유분을 얼마나 남기나
한계에 딱 맞춰 자원을 늘리면 예측이 조금만 틀려도 바로 자원이 모자랍니다. 그래서 필요하다고 헤아린 양보다 넉넉하게 자원을 마련해 두는데, 이 여유분을 얼마나 둘지는 서비스마다 다릅니다.
여유를 넉넉히 잡으면 예측이 어긋나도 견디지만, 그만큼 자원이 놀고 있는 시간이 늘어나 비용이 커집니다. 여유를 적게 잡으면 비용은 줄지만 예측이 살짝만 어긋나도 한계를 넘습니다. 손님이 잠깐 느려져도 큰 문제가 안 되는 서비스라면 여유를 적게 두고, 한 번의 지연이 곧바로 손해로 이어지는 서비스라면 여유를 크게 둡니다.
필요한 만큼 자원을 늘리는 방법
얼마나 더 필요한지가 정해지면 그 자원을 늘리는 방법을 고릅니다. 한 대의 성능을 올리는 수직 확장과 대수를 늘리는 수평 확장이 있습니다. 대수를 늘릴 때는 늘어난 서버들에 요청을 고르게 나눠 줄 로드 밸런서도 함께 필요합니다. 어느 쪽을 고를지는 시스템의 구조가 정하고, 용량 계획은 그 전에 얼마나 늘려야 하는지를 먼저 정합니다.
예측이 어긋나면 자동으로 반응하는 장치
사람이 미리 세운 계획은 예측이 어긋나면 늦게 반응합니다. 이를 보완하려고 사용량을 계속 지켜보다가 정해 둔 기준을 넘으면 자원을 자동으로 늘리고 줄이는 오토스케일링을 함께 씁니다. 오토스케일링은 갑작스러운 변화에 빠르게 답하고, 용량 계획은 그보다 느리게 오는 큰 흐름을 미리 준비합니다. 둘은 같은 일을 서로 다른 빠르기로 나눠 맡는 셈입니다.
되풀이하는 순환
용량 계획은 한 번 세우고 끝나는 계산이 아닙니다. 시간이 지나면 사용량도 바뀌고 예측도 틀어지므로 같은 절차를 되풀이합니다.
flowchart TD
A["사용량과 늘어나는 속도를 잰다"] --> B["언제 한계에 닿을지 헤아린다"]
B --> C["여유분을 얹어 필요한 양을 정한다"]
C --> D["자원을 늘린다"]
D --> A
자원을 늘리고 나면 다시 처음으로 돌아가 사용량을 잽니다. 이 순환이 도는 빠르기는 서비스마다 다릅니다. 사용량이 빠르게 느는 서비스는 자주 다시 돌고, 느리게 느는 서비스는 뜸하게 돕니다.
자원이 부족해지면 드러나는 문제
자원이 부족해지면 요청에 답하는 데 걸리는 시간, 곧 지연이 먼저 늘어납니다. 요청은 처리되지만 답이 오는 데 걸리는 시간이 길어집니다. 더 부족해지면 요청을 아예 처리하지 못해 실패로 이어지고, 이런 실패가 잦아지면 서비스가 얼마나 끊김 없이 돌아가는지를 보는 가용성이 떨어집니다.
관련 항목
용량 계획이 참고하는 사용량 지표
미리 한계를 확인하는 수단
필요한 만큼 자원을 늘리는 방법
수직 확장 · 수평 확장 · 오토스케일링 · 로드 밸런서 · 확장성
예측이 빗나갔을 때 대신 버티는 장치
서킷 브레이커 · 우아한 저하 · 스로틀링 · 백프레셔
용량 계획이 속하는 운영 영역
인프라와 SRE · 모니터링 · 경보 · 대시보드 · 자동화
감당할 부하의 목표를 정하는 개념
자원이 모자랄 때 나타나는 문제
다른 이름: capacity planning