인프라 자원 신청서, 실측값으로 산정근거 쓰기

사내 Kubernetes 자원과 DB를 신청하면서 산정근거표를 쓴 방법을 정리했다. Grafana 실측값으로 CPU·메모리를, 첨부파일 증가 추세로 스토리지를 계산하는 방식과 함께 내야 하는 서류 3종을 다룬다.

산정근거표가 되돌아오는 이유

사내 인프라 자원을 신청하면 거의 항상 산정근거를 요구한다. 처음에는 '사용자 몇 명, 넉넉하게 몇 코어' 식으로 썼다가 다시 써야 했다. 심사하는 쪽이 묻는 건 하나다. 그 숫자가 어디서 나왔는가.

예상치는 반박하기 쉽고 실측치는 반박하기 어렵다. 이미 돌고 있는 서비스가 있다면 그 서비스의 모니터링 수치가 가장 강한 근거다. 이 글은 실측값으로 CPU, 메모리, 스토리지 근거를 쓰는 방법이다.

내야 하는 서류 3종

구성도에서 자주 하는 실수가 외부 시스템을 클러스터 안에 그리는 것이다. 신청하는 자원은 클러스터 안에 들어갈 것만이다. DB, SSO, 데이터 레이크, LLM API처럼 다른 조직이 운영하는 시스템은 반드시 바깥 박스로 그린다. 그래야 심사하는 쪽이 신청 범위를 오해하지 않는다.

CPU·메모리: 모니터링 실측값으로

이미 운영 중인 환경이 있다면 Grafana 같은 모니터링에서 최근 몇 주의 최대 사용량을 본다. 평균이 아니라 최대값이다. 계산식은 단순하게 둔다.

여기에 Kubernetes 특유의 사정 두 가지를 더해야 한다. 둘 다 실제로 겪은 일이다.

ML 모델을 메모리에 올리는 앱

scikit-learn이나 LightGBM 모델을 앱 시작 때 메모리에 올리는 Flask 서비스는 웹 워커 수만큼 모델이 복제된다. 워커 4개면 모델도 4벌이다. 실제로 메모리 한도 1Gi에서 Pod가 OOM으로 계속 재시작됐고, 워커를 1개로 줄이고 스레드로 동시 요청을 처리하도록 바꿔 해결했다. 산정할 때도 워커 구성을 먼저 정하고 그 기준으로 실측해야 한다.

롤링 업데이트는 잠깐 두 배를 쓴다

배포할 때 새 Pod를 먼저 띄우고 옛 Pod를 내리는 게 기본 동작이다. 그 사이에는 Pod가 하나 더 떠 있다. Namespace 메모리 할당량이 4Gi이고 이미 3Gi를 쓰는 상태에서 메모리를 2Gi 요청하는 Pod를 배포하면, 새 Pod를 띄울 자리가 없어 배포가 실패한다. 할당량은 배포 순간까지 계산해서 잡는다.

스토리지: 첨부파일 증가 추세로

스토리지는 현재 사용량보다 증가 속도가 중요하다. 첨부파일을 저장하는 시스템이라면 현재 누적 용량, 건수, 월별 증가량을 뽑는다. 실제로 뽑은 값은 이랬다.

여기에 보존 기간과 여유율을 곱하면 된다. 아래에서 조건을 바꿔 보면 숫자가 어떻게 달라지는지 볼 수 있다.

DB 디스크도 같은 방식이다. 테이블별 행 수와 평균 행 크기에 인덱스 몫을 더하고, 월별 증가율과 보존 기간을 곱한다. 숫자 하나하나보다 '입력값을 어디서 뽑았는지'를 표에 같이 적는 게 핵심이다.

정리

• 근거는 예상치보다 실측치가 강하다. 평균이 아니라 최대값을 쓴다.
• 구성도에서 외부 시스템은 클러스터 밖에 그린다.
• ML 모델을 올리는 앱은 워커 수를 먼저 정하고 메모리를 잰다.
• 할당량은 롤링 업데이트 중 추가로 뜨는 Pod까지 포함해 잡는다.
• 스토리지는 현재 용량 + 월 증가량 × 보존 기간 × 여유율로 계산하고 입력값 출처를 함께 적는다.