어디까지 견뎌야 하는가: 미터링 용량을 세 가지 제약으로 역산한 의사결정

TL;DR
GPU 클라우드 미터링 시스템의 용량 설계 의사결정입니다.
처음엔 GPU 장비 수를 상한 기준으로 봤지만, 실제 병목은 장비 수가 아니라 데이터가 쌓이는 단일 DB 스토리지(관리형 MySQL, 최대 2TB)였습니다.
스키마를 GPU 인스턴스 수에 독립적으로(복합 키 + 월별 파티션) 설계해, 인스턴스가 늘어도 구조 변경 없이 스토리지 한계까지 흡수하도록 했습니다.
실측 운영 규모는 일 30~50만 건(한 주기 약 10초)이고, 여유를 얹어 일 200만 건 규모까지 이 스토리지 스펙 안에서 대응하도록 설계했습니다. 보존 기간은 사업 계약 주기에 맞춰 1년입니다.

GPU 클라우드 미터링 시스템을 만들면서 가장 먼저 답해야 했던 질문은 단순했습니다. “어디까지 견뎌야 하나?”

처음에는 인프라 상한, 즉 GPU 장비 수를 기준으로 잡으면 충분하다고 생각했습니다. 하지만 그 가정으로 잡은 수치가 실제 운영에서 의미를 가지려면, 장비 수보다 먼저 병목이 되는 다른 제약이 없어야 합니다. 확인해 보니 그게 성립하지 않았습니다. 실제 병목은 장비 수가 아니라 데이터가 적재되는 스토리지에 있었습니다.

문제: 장비 수만 보면 실제 병목을 놓친다

미터링 시스템의 용량 설계는 보통 다음 중 하나로 시작합니다.

1. 인프라 상한에서 출발 (GPU/노드/CPU 코어 수)
2. 트래픽 예측에서 출발 (TPS, 요청 수, 활성 사용자 수)
3. 데이터 보존 요구에서 출발 (보존 기간, 조회 패턴)

운영하는 환경에서는 1번에서 출발하기 쉬웠습니다. GPU 장비 수가 곧 인스턴스 상한이고, 인스턴스 수가 곧 미터링 데이터의 발생량과 직결되기 때문입니다.

하지만 1번만 보면 두 가지를 놓칩니다.

놓치는 것 1: 데이터가 적재되는 RDB의 스토리지 상한이 GPU 인프라 상한보다 먼저 도달할 수 있습니다. 당장은 여유가 있어 보여도, 인스턴스가 늘면 누적 레코드가 RDB 스토리지 한계에 부딪힙니다.

놓치는 것 2: 보존 기간이 정해져야 누적량이 정해지는데, 보존 기간을 무엇에 맞출지가 인프라 관점에서는 보이지 않습니다. “몇 년 치 데이터를 가지고 있어야 하나?”라는 질문에 인프라 상한은 답을 주지 않습니다.

이 두 가지를 함께 풀려면, 인프라·스토리지·사업 라이프사이클을 같은 축에 놓고 검토해야 했습니다.

분석: 세 제약을 함께 놓고 보면 병목은 스토리지다

핵심 명제는 하나입니다. 용량 경계는 인스턴스 수가 아니라 단일 DB 스토리지에서 결정됩니다.

GPU 인프라 (규모 배경)
   │  인스턴스가 늘어도
   ▼
스토리지 (병목 · 용량 앵커) ── 관리형 MySQL 최대 2TB
   │  1년 보존을 이 안에서 감당하는 규모가 경계
   ▼
사업 라이프사이클 (보존 1년)

스키마를 인스턴스 수에 독립적으로(복합 키 + 월별 파티션) 설계했기 때문에, “GPU 몇 대까지 버티나”가 아니라 “적재 데이터가 2TB 안에 1년 보존으로 들어가나”가 실질 상한입니다.

제약 1. GPU 인프라: 규모 배경이지 병목은 아니다

GPU 인프라 규모 자체는 큽니다. 하지만 그게 용량 병목은 아닙니다. 인스턴스(GPU 워크로드) 수를 상한으로 내세우기 쉽지만, 두 가지 이유로 그렇게 하지 않았습니다.

• 스키마가 인스턴스 수에 독립적입니다. 인스턴스가 늘어도 복합 키와 월별 파티션 구조가 그대로라, 병목이 인스턴스 축에서 오지 않습니다.
• 보유 규모와 실배포·운영 규모는 다릅니다. GPU는 단가가 높아, 보유 물량 전체를 동시에 배포·운영하는 극단은 현실적이지 않습니다. 장비를 확보했다고 그 전부를 오케스트레이션하지 않습니다. 실배포 상한은 물리 머신 수에 종속됩니다.

그래서 인스턴스 절대 상한을 용량 수치로 내세우지 않았습니다. 인스턴스 축은 병목에서 뺐습니다.

제약 2. 스토리지 상한(용량 앵커): 관리형 MySQL 2TB

미터링 데이터는 사용 중인 관리형 MySQL RDS에 적재됩니다. 이 RDS의 데이터 스토리지는 20GB ~ 2TB 범위이며, 자동 스토리지 확장 기능으로 사용률 임계치 도달 시 설정한 최대 크기까지 자동 확장됩니다. 이 2TB가 설계의 앵커입니다.

2TB는 처음부터 점유하는 크기가 아니라 사용량만큼 동적으로 확장되는 상한 스펙입니다. 실운영 규모의 1년 보존을 이 스펙 안에서 인프라 문제없이 수용함을 확인한 것이지, 2TB를 미리 점유하는 것이 아닙니다.

용량 확인 방식:

1. 테이블별 로우당 최대 크기를 DB 스키마와 코드 기준으로 계산
2. (로우당 최대 크기) × (예상 레코드 수)가 2TB 안에 들어오는지 대조
3. 스키마가 인스턴스 수에 독립이므로, 인스턴스 증가는 레코드 수 증가로만 반영되고 구조 변경 없이 스토리지 여유 안에서 흡수

제약 3. 사업 라이프사이클: 보존 1년

세 번째 제약은 인프라가 아닌 사업 측면입니다.

운영하는 GPU 서비스는 사업 계약 1년 단위가 기본이었습니다. 계약 만료 시 자원이 회수되고, 재계약으로 재할당됩니다.

설계 함의:

• 서비스가 수년 이상 누적되는 영속 라이프사이클이 아님
• 사업 단위 라이프사이클 = 1년 보존이 자연스러운 경계
• 영속 서비스라면 “데이터를 계속 쌓아야 하나?”라는 질문이 생기지만, 사업 단위면 1년 후 회수와 함께 과거 데이터의 조회 요구가 사실상 소멸
• 소프트웨어 생명주기(SDLC)와 사업 라이프사이클을 동기화하는 설계

이것이 미터링 보존 기간을 1년으로 확정한 근거였습니다. 스펙 정의에도 “보존 기간이 지난 데이터는 자동으로 삭제”라고 명시했습니다.

행동: 스토리지 앵커로 용량 경계를 고정

용량 경계를 인스턴스 수가 아니라 스토리지에서 고정했습니다.

• 실측 운영 규모는 수십~수백 인스턴스로 일 30~50만 건, 한 주기 약 10초에 처리됩니다.
• 여기에 여유를 얹어 일 200만 건 규모까지 2TB 스펙 안에서 대응하도록 설계했습니다.
• 스키마가 인스턴스 수에 독립이라, 인스턴스가 늘어도 이 경계까지 구조 변경 없이 흡수됩니다.

일 200만 건은 실측이 아니라 설계 목표입니다. 검증한 것은 현재 운영 규모(일 30~50만 건, 한 주기 약 10초)까지이고, 200만은 스토리지 스펙과 인스턴스 독립 스키마를 근거로 잡은 목표입니다. 이 규모의 부하 테스트는 수행하지 않았으므로 “검증”이라 하지 않고 “설계”까지만 말합니다.

인스턴스 상한을 성과로 내세우지 않은 이유

인프라 보유 규모로 큰 인스턴스 수를 상한으로 잡을 수도 있었습니다. 하지만 그 수치는 실무 관점에서 방어되지 않습니다.

• GPU는 단가가 높아 보유 물량 전체를 배포·운영하는 시나리오는 비현실적이고, 실배포 상한은 물리 머신 수에 종속됩니다. 확보한 장비를 전부 오케스트레이션하지 않습니다.
• 게다가 스키마를 인스턴스 수에 독립적으로 설계했기 때문에, 인스턴스 축은 애초에 병목이 아닙니다. 병목은 스토리지입니다.

그래서 “몇 인스턴스까지 견딘다”가 아니라 “스토리지 스펙 안에서 얼마의 적재를 1년 보존으로 감당하나”를 용량 경계로 잡았습니다. 이 경계가 저장 전략 판단으로 이어집니다. UPSERT에서 DELETE + INSERT로 전환한 결정도 “이 규모에서는 성능이 결정 변수가 아니다”라는 판단에서 출발했고, 그 판단의 근거가 바로 용량 경계를 스토리지에서 고정한 이 결정이었습니다.

결과: 운영 실측과 설계 목표의 분리

운영 실측:

• 파이프라인이 주기 안에서 실시간으로 동작합니다. 수집(5분)·집계(10분)가 주기 내에 끝나고, 한 주기 처리는 약 10초입니다.
• 현재 운영 규모는 수십~수백 인스턴스로 일 30~50만 건이며, 관측 구간에서 배치 실패는 없었습니다.
• 1년 보존 자동 삭제 정책이 동작합니다.

설계 목표 (미래 대비):

• 일 200만 건 규모까지 2TB 스펙 안에서 대응하도록 설계
• 부하 테스트는 미수행. 설계까지이며, 대규모 실측으로 과장하지 않습니다

판단 유효 기간:

시점	상황	저장 전략
현재	일 200만 건 규모까지 2TB 안에서 수용	DELETE+INSERT 유효
MIG 부분 도입	인스턴스 증가, RDS 2TB 병목 근접	재검토 트리거
MIG 전면 도입 / 장기 증설	2TB 초과 예상	저장 전략 + 스토리지 아키텍처 전면 재평가 (파티셔닝 고도화, 샤딩, 외부 저장소)

이 경계는 의사결정에서 짚어 둔 한계입니다. 현 설계는 “스토리지 앵커가 유효한 기간 동안” 성립하고, 제약 중 하나라도 변경(MIG 확산으로 인스턴스 급증, RDS 상품 스펙 변경, 사업 라이프사이클 확장)되면 재평가가 필요합니다.

MIG(Multi-Instance GPU)는 단일 GPU를 최대 7개 독립 인스턴스로 분할하는 기술입니다. 최신 GPU 모델을 지원하고, GPU 수익성 개선 목적으로 도입이 검토되고 있습니다. 다만 MIG는 설계 시점의 근거가 아니라 사후 고려 사항이었습니다. 현 설계는 MIG 없는 가정에서 스토리지 앵커로 귀결되었고, MIG 확산은 위 표의 재평가 트리거입니다.

MIG POC를 직접 수행한 경험이 있어 적용 가능성과 한계를 파악하고 있고, 이것이 “MIG 도입 시점이 저장 전략 재평가 트리거”라는 판단을 막연한 낙관이 아닌 구체적 경계로 만드는 근거가 됩니다.

의의: 한 축이 아닌 병목 지점을 정확히 본 설계

이 설계 과정에서 얻은 가장 큰 학습은 다음과 같습니다.

1. 단일 제약(GPU 장비 수)만 본 설계는 병목 지점을 놓칠 수 있다
   • 인프라 상한이 아니라 스토리지가 먼저 병목이 됨
   • 어떤 제약이 먼저 한계에 닿는지를 함께 봐야 의사결정이 정확해짐
2. 사업 라이프사이클을 설계 변수에 넣는다
   • “왜 1년 보존인가?”라는 질문에 원칙 있는 답을 줌
   • SDLC와 사업 라이프사이클의 동기화는 영속 서비스가 아닌 환경에서 자연스러운 경계
3. 재검토 시점을 미리 명시한다
   • 현 설계의 유효 기간을 분명히 한정
   • MIG·RDS 변경·라이프사이클 확장 등 변경 트리거를 사전에 정의

용량을 인스턴스 수로 잡는 것과 병목인 스토리지로 잡는 것은, 결과처럼 보여도 의사결정의 정확도가 다릅니다. “이 용량은 어떻게 산정했나요?”라는 질문을 받았을 때, 인프라 한 축만 본 설계는 한 가지 근거만 제시하지만, 병목을 정확히 짚은 설계는 왜 스토리지가 경계인지, 왜 인스턴스 축이 병목이 아닌지를 함께 답할 수 있습니다.

좋은 의사결정은 결과 수치보다 그 수치에 도달한 분석에서 갈린다고 봅니다. 어떤 제약이 먼저 병목이 되는지를 정확히 짚었는가가 설계의 정확도를 결정합니다.

참고 출처

• 사용 중인 관리형 MySQL RDS 공식 가이드 (데이터 스토리지 20GB ~ 2TB 범위, 자동 확장 기능)
• 미터링 파이프라인 운영 실측 (일 30~50만 건, 한 주기 약 10초, 정상 동작)

이 글은 Claude와 함께 작업했습니다.