사용률
사용률은 디스크나 네트워크 같은 자원이 얼마나 바빴는지를 알려 주는 값입니다. 정해 둔 시간 가운데 자원이 일한 시간이 얼마만큼인지를 비율로 셉니다. 이 값이 높아질수록 요청이 줄을 서서 기다리는 시간이 급하게 늘어납니다. 메모리나 디스크처럼 공간을 내주는 자원에서는 얼마나 찼는지를 같은 이름으로 부르기도 합니다.
쉽고 빠른 이해
무슨 일을 하는 값인가 — 자원은 CPU(Central Processing Unit, 중앙 처리 장치) · 디스크 · 커넥션 풀처럼 일을 받아 처리하는 것을 말합니다. 사용률은 이 자원이 얼마나 바빴는지를 0 과 1 사이 값으로 보여 줍니다. CPU가 1분 가운데 45초를 일했다면 사용률은 0.75 입니다.
왜 재나 — 자원이 모자란지 남는지를 이 값으로 가늠합니다. 이 값 없이 서버를 늘릴지 줄일지 정하면 짐작에 기댈 수밖에 없습니다.
어떻게 도나
- 정해 둔 시간 동안 자원이 일한 시간을 잽니다
- 그 시간을 전체 시간으로 나눕니다
대가 — 값이 1 에 가까워질수록 요청이 기다리는 시간이 가파르게 늘어납니다. 그래서 사용률을 높게 유지하면 장비를 아끼는 대신 응답이 느려집니다. 낮게 두면 응답은 빠릅니다. 하지만 쉬는 장비에도 돈을 냅니다.
상세
이 절은 사용률을 구하는 두 방법부터 봅니다. 이어서 사용률을 1 까지 채워 쓰지 않는 까닭을 대기 시간 표로 보입니다. 끝에서 사용률이 가리는 것과 병목을 찾는 쓰임, 공간을 재는 사용률을 짚습니다.
일한 시간의 비율
계산원이 한 명 있는 가게를 떠올려 봅니다. 한 시간 동안 손님을 받은 시간이 45분이었습니다. 나머지 15분은 손님이 없어 계산대 앞에 서 있었습니다. 이 계산원은 한 시간의 4분의 3 동안 바빴습니다.
사용률은 이 「바빴던 몫」을 자원에 대해 잰 값입니다. 정해 둔 구간에서 자원이 일한 시간을 구간 길이로 나눕니다. CPU가 1분 가운데 45초를 일했다면 사용률은 0.75 입니다. 대시보드는 대개 이 값에 100 을 곱해 퍼센트로 보여 줍니다.
자원에는 CPU · 디스크 · 네트워크 같은 장치만 있는 것이 아닙니다. 스레드 풀이나 커넥션 풀처럼 개수가 정해진 소프트웨어 자원도 같은 방식으로 잽니다. 풀에 든 것 가운데 몇 개가 일하고 있었는지를 시간에 걸쳐 평균 내면 됩니다.
들어오는 양과 처리하는 양으로 구하기
일한 시간을 재지 않고도 사용률을 구할 수 있습니다. 들어오는 속도와 처리하는 속도를 알면 됩니다. 아직 받아 보지 않은 트래픽에서 사용률을 미리 셈할 때 이 방법을 씁니다. 서버를 몇 대 둘지 미리 정하는 용량 계획이 이 셈에서 출발합니다.
요청이 줄을 서고 처리되는 모습을 수식으로 다루는 분야를 큐잉 이론이라고 합니다. 이 분야는 사용률을 아래 두 값으로 셈합니다.
| 이름 | 무엇을 재나 |
|---|---|
| 도착률 | 단위 시간에 들어오는 요청 수 |
| 서비스율 | 자원 하나가 단위 시간에 끝낼 수 있는 요청 수 |
| 사용률 | 도착률을 서비스율로 나눈 값 |
초당 80건이 들어오고 서버 한 대가 초당 100건을 끝낼 수 있다면 사용률은 0.8 입니다. 서버가 여러 대면 서비스율에 서버 수를 곱한 값으로 나눕니다. 같은 요청을 서버 두 대가 나눠 받으면 사용률은 0.4 로 내려갑니다.
셈한 값이 1 을 넘지 않는 동안에는 일한 시간을 재서 얻은 값과 같습니다. 초당 100건을 끝내는 서버라면 한 건에 0.01초가 걸립니다. 초당 80건을 받으면 1초 가운데 0.8초를 일하는 셈입니다. 1 을 넘을 때 두 값이 어떻게 갈리는지는 아래 「1 을 넘는 사용률」에서 봅니다.
사용률과 대기 시간
사용률이 오르면 요청이 순서를 기다리는 시간, 곧 대기 시간도 늡니다. 그런데 둘은 나란히 늘지 않습니다. 사용률이 1 에 가까워질수록 대기 시간이 가파르게 늘어납니다.
까닭은 요청이 고른 간격으로 오지 않는 데 있습니다. 몇 건이 한꺼번에 몰리면 뒤에 온 요청은 앞의 요청이 끝나기를 기다립니다. 자원이 한가한 시간이 넉넉하면 이렇게 생긴 줄이 금방 빠집니다. 사용률이 높으면 줄을 빼 줄 빈 시간이 모자라 줄이 오래 남습니다.
가장 단순한 모형으로 이 모양을 셈해 볼 수 있습니다. 창구가 하나인 모형입니다. 요청은 서로 상관없이 제멋대로 도착합니다. 한 건을 처리하는 시간도 들쭉날쭉합니다.
큐잉 이론은 사용률을 그리스 글자 ρ(로)로 적습니다. 이 모형에서 평균 대기 시간은 한 건을 처리하는 시간의 ρ/(1−ρ) 배입니다. 분모의 1−ρ 가 0 에 가까워질수록 값이 커집니다. 사용률마다 셈해 보면 아래와 같습니다.
| 사용률 | 평균 대기 시간 (한 건 처리 시간의 몇 배) |
|---|---|
| 0.5 | 1 |
| 0.7 | 약 2.3 |
| 0.8 | 4 |
| 0.9 | 9 |
| 0.95 | 19 |
| 0.99 | 99 |
표에서 볼 것은 아래로 갈수록 벌어지는 간격입니다. 0.5 에서 0.8 로 올리는 동안 대기는 네 배가 됩니다. 0.9 에서 0.99 로 가면 열 배가 넘게 늡니다. 응답 시간은 기다린 시간에 처리 시간을 더한 값이라 같은 모양으로 늡니다.
표의 값은 평균입니다. 요청이 몰린 순간에 들어온 몇 건은 이보다 훨씬 오래 기다립니다. 응답 시간을 길이 순으로 늘어놓았을 때 맨 끝 몇 퍼센트를 꼬리 지연이라고 부릅니다. 사용률이 높으면 이 값이 먼저 튑니다.
그래서 운영에서는 사용률을 1 까지 채우지 않고 여유를 남깁니다. 이 여유를 헤드룸(headroom)이라고 부릅니다. 얼마를 남길지는 서비스가 견딜 수 있는 응답 시간을 보고 정합니다.
이 여유를 자동으로 지키는 장치가 오토스케일링입니다. 오토스케일링은 사용률이 정해 둔 값을 넘으면 서버를 자동으로 늘립니다. 서버가 늘면 한 대가 받는 요청이 줄어 사용률이 다시 내려갑니다.
1 을 넘는 사용률
도착률이 서비스율보다 크면 셈한 사용률은 1 을 넘습니다. 처리하는 것보다 들어오는 것이 많으니 줄이 끝없이 길어집니다. 이때는 평균 대기 시간이 정해지지 않습니다. 기다림이 시간이 갈수록 늘기만 합니다.
재서 얻는 사용률은 1 에서 멈춥니다. 자원은 쉬지 않고 일하는 것보다 더 바쁠 수 없기 때문입니다. 그래서 잰 사용률이 1 에 붙은 뒤로는 얼마나 밀렸는지가 이 값에 안 나옵니다.
밀린 양은 포화가 보여 줍니다. 포화는 자원이 받지 못해 기다리는 일의 양을 재는 값입니다. 사용률이 1 에 닿은 뒤에도 포화는 계속 오르므로 둘을 함께 봅니다.
사용률이 가리는 것
사용률은 한 구간을 평균 낸 값입니다. 평균은 짧게 튄 순간을 가립니다. 그래서 사용률이 낮게 나와도 요청이 기다렸을 수 있습니다.
1분 평균이 0.5 인 CPU도 그 1분 안의 몇 초 동안은 사용률이 1 이었을 수 있습니다. 그 몇 초 사이에 들어온 요청은 줄을 섰습니다. 구간을 짧게 잘라 재면 이런 순간이 드러납니다.
여러 개를 평균 낸 값도 같은 함정을 품습니다. 코어는 CPU 안에서 명령을 따로따로 실행하는 처리 장치입니다.
코어가 넷인 CPU에서 한 코어만 쉬지 않고 일한다고 해 봅니다. 나머지 셋은 놉니다. 그러면 전체 사용률은 0.25 로 나옵니다. 그 코어에 매인 일은 더 빨라질 여유가 없어도 그래프는 한가해 보입니다.
사용률이 높다고 쓸모 있는 일을 하고 있다는 뜻도 아닙니다. 잠금이 풀리기를 기다리며 풀렸는지 확인만 되풀이하는 코드도 CPU 사용률을 끌어올립니다. 그동안 끝나는 일은 없습니다.
그래서 사용률은 처리량과 나란히 봅니다. 처리량은 단위 시간에 끝난 일의 수입니다. 사용률이 올라도 처리량이 그대로면 자원이 헛돌고 있다는 뜻입니다.
병목을 찾는 단서
요청 하나는 자원 여러 개를 차례로 거칩니다. 애플리케이션 서버의 CPU를 지나 데이터베이스의 디스크에 닿는 식입니다. 부하를 늘리면 이 가운데 사용률이 가장 먼저 1 에 닿는 자원이 생깁니다. 그 자원이 전체 처리량의 상한을 쥡니다. 이 자원을 병목이라고 부릅니다.
flowchart TD
R["요청"] --> A["애플리케이션 서버 CPU · 사용률 0.4"]
A --> D["데이터베이스 디스크 · 사용률 0.95"]
D --> E["응답"]
이 그림에서 앞 단계는 여유가 절반 넘게 남았습니다. 뒤 단계는 거의 꽉 찼습니다. 애플리케이션 서버를 늘려도 요청은 디스크 앞에서 다시 줄을 섭니다. 손쓸 곳은 사용률이 가장 높은 디스크 쪽입니다.
자원마다 사용률 · 포화 · 오류 셋을 차례로 확인해 병목을 찾는 점검법이 있습니다. 이 점검법을 USE 방법(Utilization Saturation Errors, 사용률 포화 오류)이라고 부릅니다. 사용률로 바쁜 자원을 먼저 추립니다. 이어서 포화와 오류로 그 자원이 요청을 줄 세우거나 거절하고 있는지 확인합니다.
공간을 재는 사용률
메모리나 디스크 용량처럼 공간을 내주는 자원에도 사용률이라는 말을 씁니다. 이때는 시간이 아니라 전체 용량 가운데 찬 몫을 셉니다. 디스크 100기가바이트 가운데 60기가바이트가 찼다면 사용률은 0.6 입니다.
공간 사용률은 높아져도 줄을 세우지 않습니다. 대신 가득 차는 순간 쓰기가 실패합니다. 디스크가 꽉 차면 새 파일을 못 씁니다. 메모리가 모자라면 운영체제가 프로그램을 강제로 끝내기도 합니다.
메모리 사용률은 높게 나오는 것이 흔합니다. 운영체제가 남는 메모리를 파일 내용을 담아 두는 캐시로 채워 두기 때문입니다. 이 캐시는 필요하면 비워서 내줄 수 있습니다. 사용률 숫자만 보고 메모리가 모자라다고 판단하면 틀리기 쉽습니다.
관련 항목
사용률을 셈하는 입력값
도착률 · 서비스율 · 서비스 시간 · 처리량
사용률을 다루는 이론
큐잉 이론 · 리틀의 법칙 · 켄달 표기법 · 운영 법칙
사용률이 오를 때 함께 나빠지는 지표
대기 시간 · 응답 시간 · 꼬리 지연 · 지연 · 큐 길이
사용률이 못 보여 주는 것을 채우는 지표
포화 · 오류율 · USE 방법 · 골든 시그널 · 백분위수
사용률로 드러나는 장애
병목 · 과부하 · 라이브락 · 재시도 폭풍 · 메모리 부족
사용률을 재는 자원
자원 · CPU · 코어 · 메모리 · 디스크 · 대역폭 · 스레드 풀 · 커넥션 풀 · 페이지 캐시
사용률의 하위 종류
CPU 사용률 · 디스크 사용률 · 메모리 사용량
사용률에 맞춰 자원을 늘리고 줄이는 수단
용량 계획 · 헤드룸 · 오토스케일링 · 수평 확장 · 수직 확장 · 부하 분산 · 스로틀링 · 백프레셔
사용률이 속하는 상위 분류
다른 이름: utilization · 이용률 · 자원 사용률