LabHub
시작하기
배우기 러닝패스 코스

용량 계획과 변경 관리 — 언제 차는지 계산하고 멈출 시각을 먼저 적는다

언제 차는가를 계산한다 — 유기적 증가와 계단, 그리고 발주 마감일

LabHub 에서 이어서 보기

한 줄 요약

용량 계획의 답은 "지금 몇 % 인가" 가 아니라 "언제까지 무엇을 주문해야 하는가" 다. 그 날짜는 세 숫자로 정해진다 — 평소에 늘어나는 속도(유기적 증가), 넘으면 안 되는 선(임계), 주문부터 설치까지 걸리는 시간(리드 타임). 한 번뿐인 큰 증가(계단)를 추세에 섞으면 예측이 통째로 틀어진다.

왜 이게 필요했나

디스크가 95% 가 된 뒤에 증설을 요청하면 이미 늦다. 서버와 스토리지는 발주·배송·랙 작업·작업 창 확보까지 몇 주가 걸리고, 클라우드도 예약 용량이나 예산 승인에는 시간이 든다. 그래서 용량 담당자는 "지금 괜찮은가" 가 아니라 "주문 버튼을 늦어도 언제 눌러야 하는가" 를 답해야 한다.

Google SRE 책의 머리말은 용량 계획에 필요한 것으로 정확한 유기적 수요 예측과, 새 기능 출시·고객 이관 같은 비유기적 수요를 따로 반영하는 것, 그리고 조달 리드 타임을 넘는 기간을 내다보는 것을 든다. 이 모듈은 그 세 가지를 디스크 사용량 표 하나로 손에 익힌다.

어떻게 동작하나

추세선. 하루 한 번 잰 사용량을 x = 첫날부터의 날수, y = 사용량(GB)으로 놓고 최소제곱 직선을 긋는다. 기울기는 다음 식이다.

기울기 = Σ (x − x̄)(y − ȳ) / Σ (x − x̄)²        단위: GB/일

엑셀의 SLOPE, 파이썬의 몇 줄이면 된다. 직선은 거칠지만, 주말에 덜 쌓이고 평일에 더 쌓이는 흔들림은 몇 달 치를 모으면 기울기에 거의 영향을 주지 않는다.

계단을 떼어 낸다. 표를 그려 보면 어느 하루에 수백 GB 가 한꺼번에 늘어난 자리가 있다. 옛 서버의 데이터를 옮겨 왔거나, 새 고객을 받았거나, 로그 보관 기간을 늘린 날이다. 이것은 다시 일어나지 않는 일이다. 전체 기간에 직선을 그으면 그 계단이 기울기에 섞여 "매일 이만큼 늘어난다" 로 번역되고, 예측은 실제보다 훨씬 비관적이 된다. 그래서 가장 큰 하루 증가를 찾아 그날 이후만으로 기울기를 다시 구한다. 앞으로 예정된 계단(다음 달 이관 계획)이 있으면, 그것은 추세에 섞지 말고 따로 더한다.

남은 날수. 임계가 80% 라면 남은 날수는 올림((용량 × 0.8 − 지금 사용량) ÷ 기울기) 이다. 100% 까지도 같은 식으로 구해 두면 "임계를 넘은 뒤에도 얼마나 버티는가" 를 말할 수 있다. 올림하는 이유는 "며칠 뒤" 를 보수적으로 잡기 위해서다.

발주 마감일. 임계 도달일 − 리드 타임 이 늦어도 주문해야 하는 날이다. 이 날짜가 이미 지났거나 며칠 남지 않았다면 보고서의 첫 줄이 되어야 한다.

임계는 왜 100% 가 아닌가. 파일시스템은 가득 차기 훨씬 전부터 느려지고(조각화, 예약 블록), 데이터베이스는 정리 작업에 여유 공간을 요구하며, 예측은 언제나 틀릴 수 있다. 임계와 100% 사이의 간격은 예측 오차와 갑작스러운 증가를 흡수하는 완충이다. 그래서 계획은 임계에 맞추고, 100% 까지 남은 날수는 "예측이 틀렸을 때 얼마나 버티는가" 를 말하는 데 쓴다.

숫자 어디서 오나 틀리면
유기적 기울기 계단 이후의 추세선 계단을 섞으면 과잉 발주, 성장을 무시하면 결품
임계 운영 기준(여유·성능 저하 지점) 너무 높으면 대응할 시간이 없다
리드 타임 구매·배송·작업 창 짧게 잡으면 발주가 늦는다

현장에서 만나는 모습

가장 흔한 실수는 모니터링 화면의 "예측" 을 그대로 믿는 것이다. 많은 도구가 최근 며칠이나 몇 시간의 기울기로 선을 긋는다. 어제 백업 파일이 한꺼번에 쌓였으면 "3일 뒤 가득 참" 이 뜨고, 다음 날 정리되면 "400일 뒤" 가 뜬다. 어느 기간으로 그었는지 확인하지 않은 예측은 숫자가 아니라 소음이다.

두 번째는 계단을 모르는 것이다. 이관 직후의 보고서가 "증가율이 세 배가 됐다" 고 말하면, 누군가 그 숫자로 1년 치 예산을 잡는다. 반대로 다음 달 예정된 이관을 빼먹으면 추세는 멀쩡한데 어느 날 갑자기 모자란다. 그래서 용량 보고서는 추세(유기적)와 예정된 일(비유기적)을 따로 적는다.

직선이 틀리는 경우도 안다. 사용자가 늘면서 증가 속도 자체가 빨라지는 서비스라면 직선은 늘 늦게 경고한다. 그럴 때는 최근 구간의 기울기와 전체 기울기를 나란히 적어 가속을 드러내고, 리드 타임에 여유를 더 둔다. 반대로 보관 기간 정책이 있는 로그 볼륨처럼 오래된 것이 지워지며 평형에 가까워지는 데이터는 직선이 과하게 비관적이다. 예측 모델을 정교하게 만들기보다, 어떤 가정으로 그은 선인지를 보고서에 한 줄로 밝히는 것이 먼저다.

세 번째는 같은 계산을 매달 손으로 하는 것이다. 표가 바뀌어도 같은 답을 내는 작은 스크립트로 만들어 두면, 다음 달에는 명령 한 줄이고 다른 볼륨에도 그대로 쓴다.

다음 실습에서 할 것

120일 치 디스크 사용량 표와 운영 기준(용량·임계·리드 타임)을 받는다. 지금 상태를 적고, 전체 기간 기울기를 구한 뒤, 계단이 난 날을 찾아 그 이후의 유기적 기울기를 다시 구한다. 임계와 100% 까지 남은 날수, 발주 마감일을 계산하고, 마지막으로 이 계산을 아무 표에나 돌릴 수 있는 스크립트로 만든다. 채점기는 그 스크립트를 채점할 때마다 새로 만든 표에도 돌린다.