[OpenStack] 오픈스택 비용 분석: 프로젝트별 자원 사용량 기반 차지백 모델

오픈스택 비용 분석 이야기는 결국 운영팀과 서비스팀이 같은 숫자를 보느냐의 문제로 이어집니다. OpenStack(오픈스택)을 오래 만지다 보면 CPU는 누가 얼마나 썼는지, Block Storage(블록 스토리지)는 어느 프로젝트가 계속 늘리는지, 떠 있는 인스턴스는 왜 줄지 않는지 같은 질문이 계속 나오거든요. 저도 처음엔 단순히 Quota(쿼터)만 잘 걸면 되겠지 싶었는데, 실제로 운영해보니 그걸로는 안 되더라고요. **프로젝트 테넌트(Project/Tenant)별 자원 사용량을 근거로 한 차지백(Chargeback, 비용 청구) 모델**이 있어야 각 팀이 자기 사용량을 이해하고, 운영팀도 클라우드 비용 관리를 설득력 있게 할 수 있더라고요.

특히 내부 프라이빗 클라우드에서는 퍼블릭 클라우드처럼 자동 청구서가 나오지 않으니, 오픈스택 비용 분석 체계를 직접 설계해야 합니다. 오늘은 제가 실제로 많이 부딪혔던 기준으로, 무엇을 측정할지, 어떻게 집계할지, 프로젝트별로 어떤 방식으로 금액화할지를 정리해보겠습니다. 복잡하게 시작하면 오래 못 갑니다. 그래서 이번 글은 작동하는 최소 모델부터 시작하는 방향으로 설명드릴게요.

Keystone, Nova, Cinder, Glance, Ceilometer, Gnocchi, CloudKitty가 어떻게 연결되어 프로젝트별 비용 집계로 이어지는지 보여주는 개요 이미지입니다.

왜 오픈스택 차지백이 필요한가

쉽게 말해, 차지백은 "누가 얼마나 썼는지 보이고, 그에 맞게 비용을 배분하는 방식"입니다. Showback(쇼백, 사용량 공개만 하는 방식)에서 시작해 Chargeback(실제 비용 배분)으로 가는 경우가 많습니다.

• 운영팀 입장: 증설 요청이 들어왔을 때 근거가 생깁니다.
• 서비스팀 입장: 유휴 자원(idle resources)을 줄일 유인이 생깁니다.
• 경영/관리 입장: 클라우드 비용 관리가 숫자로 보입니다.

제가 처음 차지백 모델을 설계할 때 가장 많이 들었던 말이 "우린 그냥 공용 클라우드인데 굳이 계산해야 하나요?"였는데요, 몇 달만 지나면 분위기가 달라집니다. 누군가는 항상 더 많이 쓰고, 누군가는 자기가 손해 본다고 느끼거든요. 여기서 중요한 포인트! 차지백의 핵심은 완벽한 회계가 아니라, 합의 가능한 기준입니다.

프로젝트 테넌트와 자원 사용량, 어디까지 볼 것인가

OpenStack Identity(아이덴티티) 서비스인 Keystone(키스톤) 기준으로 Project(프로젝트)는 예전 표현으로 Tenant(테넌트)와 거의 같은 의미로 쓰입니다. 실제 운영 현장에서도 아직 프로젝트 테넌트라는 말을 섞어서 많이 쓰죠. 비용 배분의 기준 단위는 보통 이 프로젝트예요.

그다음은 어떤 자원을 과금 대상으로 볼지 정해야 합니다. 저는 처음부터 너무 넓게 잡지 않는 걸 추천하는 편입니다.

보통 처음에는 Compute + Volume만으로도 충분하거든요. 왜냐하면 이 두 항목이 가장 설명하기 쉽고, 프로젝트별 자원 사용량 변화가 잘 보이기 때문입니다. 반대로 Network egress(외부 송신 트래픽) 같은 항목은 측정과 합의가 조금 더 까다로워요.

오픈스택 비용 분석의 기본 구조

OpenStack Telemetry(텔레메트리) 쪽을 보면 Ceilometer(실로미터)가 미터(meter)와 샘플을 수집하고, 환경에 따라 Gnocchi(그노치) 같은 시계열 저장소와 함께 사용합니다. 그리고 CloudKitty(클라우드키티)는 공식 문서 기준으로 Rating-as-a-Service(과금/평가 서비스) 역할을 하는 프로젝트입니다. 즉, 사용량 수집과 요금 규칙 적용을 분리해서 생각하면 구조가 훨씬 명확해져요.

1. Keystone에서 프로젝트 식별
2. Nova, Cinder, Glance 등에서 자원 메타데이터 확인
3. Ceilometer/Gnocchi로 사용량 데이터 수집
4. CloudKitty 또는 별도 스크립트로 단가(rule) 적용
5. 프로젝트별 월간 리포트 생성

여기서 꼭 기억하실 부분이 있습니다. 사용량 데이터가 있다고 바로 비용 청구가 되는 게 아니더라고요. 측정값(Meter)과 과금 항목(Billable item)은 다르거든요. 예를 들어 CPU 사용률 자체보다는, 실제 운영에서는 할당된 vCPU 수와 인스턴스 실행 시간을 곱해서 보는 편이 훨씬 설명하기 쉽더라고요.

Telemetry 수집부터 프로젝트별 요금 계산, 리포트 생성까지 이어지는 파이프라인을 단계별로 표현한 이미지입니다.

실전 구현 1: 최소 차지백 기준부터 정하기

제가 직접 해보니 제일 먼저 해야 하는 건 도구 설치가 아니라 과금 기준표를 문서로 박는 일이었어요. 기준이 없으면 숫자가 나와도 싸움만 납니다 ㅎㅎ

예를 들면 이런 식입니다.

이 모델의 장점은 간단해요.

• 프로젝트 테넌트별 설명이 쉽습니다.
• 월별 추세 비교가 가능합니다.
• Idle VM(유휴 가상머신) 정리에 바로 효과가 납니다.

반대로 단점도 물론 있어요.

• 실사용 CPU와 할당 CPU가 다를 수 있습니다.
• Overcommit(오버커밋) 환경을 100% 반영하지 못합니다.
• 네트워크 사용량까지 정밀하게 포함하긴 어렵습니다.

그래도 첫 버전은 이 정도가 딱 좋더라고요. 처음부터 완벽한 원가 계산으로 들어가면 운영팀만 지쳐요.

실전 구현 2: OpenStack CLI로 프로젝트와 자원 목록 뽑기

이제 실무적으로 데이터를 뽑아보겠습니다. OpenStackClient(오픈스택 클라이언트)가 있다는 전제입니다.

1. 프로젝트 목록 확인

openstack project list -f value -c ID -c Name

이 명령으로 프로젝트 ID와 이름을 간단히 가져와요. 나중에 리포트에서 사람이 읽기 좋은 이름을 붙일 때 필요합니다.

2. 인스턴스 목록 확인

openstack server list --all-projects -f json

기본 목록은 여기까지인데, 실제 비용 계산에서는 Flavor(플레이버) 정보가 꼭 필요하더라고요. vCPU와 RAM이 여기 들어 있으니까요.

3. 볼륨 목록 확인

openstack volume list --all-projects -f json

볼륨은 생각보다 누수 포인트가 많아요. 인스턴스는 지워졌는데 볼륨은 남아 있는 경우, 스냅샷만 계속 쌓이는 경우 정말 흔하거든요.

4. 사용량 통계 확인

openstack usage list --start 2026-08-01 --end 2026-08-31

환경에 따라 제공 정보가 제한적일 수 있지만, 월간 사용량 감을 잡는 데는 꽤 유용하더라고요.

실전 구현 3: 간단한 비용 계산 스크립트 예시

처음부터 CloudKitty를 붙이지 않고, CSV 또는 JSON 기반으로 먼저 검증하는 방식을 추천드립니다. 저도 실제로 써보니까 이 단계가 있어야 과금 로직을 눈으로 검산할 수 있어서 훨씬 편하더라고요.

from decimal import Decimal

RATES = {
    "vcpu_hour": Decimal("15"),
    "ram_gb_hour": Decimal("5"),
    "volume_gb_month": Decimal("1000"),
}

project_usage = {
    "team-a": {
        "vcpu_hours": Decimal("240"),
        "ram_gb_hours": Decimal("960"),
        "volume_gb_month": Decimal("500"),
    },
    "team-b": {
        "vcpu_hours": Decimal("120"),
        "ram_gb_hours": Decimal("480"),
        "volume_gb_month": Decimal("1200"),
    },
}

for project, usage in project_usage.items():
    total = (
        usage["vcpu_hours"] * RATES["vcpu_hour"]
        + usage["ram_gb_hours"] * RATES["ram_gb_hour"]
        + usage["volume_gb_month"] * RATES["volume_gb_month"]
    )
    print(project, total)

숫자 자체는 예시입니다. 여기서 중요한 건 요금 규칙과 사용량 데이터를 분리하는 구조예요. 그러면 나중에 단가 조정, 할인 정책, 특정 프로젝트 예외 처리가 훨씬 쉬워져요.

실제 운영에서는 보통 아래 흐름으로 갑니다.

1. OpenStack API나 리포트로 원천 데이터 추출
2. 프로젝트 ID 기준으로 그룹화
3. vCPU-hour, GB-hour, GB-month 같은 과금 단위로 변환
4. 단가 테이블 적용
5. 월간 리포트 CSV/HTML/PDF 생성

실전 구현 4: CloudKitty를 붙일 때 보는 포인트

CloudKitty는 OpenStack용 차지백/레이팅에 특화된 프로젝트더라고요. 규모가 커지면 검토할 가치가 있어요. 공식 문서 기준으로 hashmap(해시맵) 방식의 rating module(평가 모듈)을 사용해 규칙 기반 요금 계산을 구성할 수 있거든요.

cloudkitty module list

이런 식으로 모듈 상태를 먼저 확인하고, 어떤 rating module을 쓸지 정합니다. 다만 여기서 한 가지. CloudKitty를 도입한다고 해서 비용 모델 설계가 자동으로 해결되는 건 아니더라고요. 오히려 내부 단가 기준과 메타데이터 정합성이 훨씬 더 중요해요.

제가 삽질했던 포인트는 딱 세 가지더라고요.

• 프로젝트명 변경 이력 관리가 안 되어 과거 리포트와 현재 명칭이 안 맞음
• 삭제된 인스턴스의 사용 이력을 어디까지 반영할지 기준이 없음
• Volume과 Snapshot의 집계 시점을 월말 기준으로 볼지 평균 보유량으로 볼지 합의가 안 됨

이런 건 기술 문제가 아니라 운영 기준 문제예요. 그래서 저는 항상 먼저 문서화해요.

프로젝트별 vCPU, 메모리, 볼륨 사용량과 월간 비용이 한눈에 보이는 내부 대시보드 예시 이미지입니다.

⚠️ 주의사항: 실제로 자주 터지는 문제들

여기서부터는 정말 현업 냄새 나는 구간입니다. 저도 처음엔 이게 뭔가 싶었는데, 몇 번 월말 정산을 돌려보면 패턴이 보이더라고요.

1. Meter와 Billing Unit을 혼동하는 문제

Ceilometer에서 수집한 meter(미터)는 정말 많아요. 하지만 다 과금에 쓸 수 있는 건 아니더라고요. 예를 들어 CPU 누적 시간, 메모리 사용률 같은 값은 관제에는 좋은데, 비용 청구 기준으로는 오히려 설명하기가 어려워요.

해결법: 운영팀이 설명 가능한 단위로 단순화하세요. vCPU-hour, GB-hour, GB-month가 시작점으로 좋습니다.

2. 삭제 자원 누락 문제

월중에 생성됐다가 삭제된 인스턴스는 목록 조회만으로는 빠질 수 있거든요. 이 때문에 "분명 썼는데 왜 청구가 안 됐지?" 또는 반대로 "왜 이 숫자가 나오지?"가 생깁니다.

해결법: 상태 스냅샷만 보지 말고, 사용량 기록 또는 이벤트 이력을 기준으로 월간 집계하세요.

3. 프로젝트 메타데이터 불일치

프로젝트명, 비용 센터(cost center), 담당 조직 정보가 제각각이면 리포트가 엉망이 되더라고요.

해결법: Keystone 프로젝트에 연결되는 관리용 메타데이터 체계를 따로 두고, 리포트 생성 전에 매핑 테이블을 정리하세요.

4. 스토리지 과금 시점 논쟁

볼륨 용량은 월말 시점만 볼지, 일평균 보유량을 볼지에 따라 결과가 달라지더라고요. 둘 다 틀린 건 아닌데, 기준이 매달 바뀌면 신뢰를 잃어요.

해결법: 정책을 먼저 고정하고, 월별로 동일하게 적용하세요.

검증: 리포트가 맞는지 어떻게 확인할까

완성된 차지백 모델은 반드시 검증 단계를 거쳐야 하더라고요. 저는 보통 아래 3단계로 확인하는 편이에요.

1. 샘플 프로젝트 1개를 골라 수작업으로 계산해 보기
2. OpenStack CLI 결과와 리포트 결과를 대조하기
3. 운영팀과 서비스팀이 함께 숫자를 리뷰하기

예를 들면 이런 검증표를 만들어두면 좋습니다.

이 과정을 지나면 드디어 “아, 이제 숫자가 말이 된다” 싶은 순간이 와요. 그때부터는 Showback 보고서만 돌려도 팀들이 먼저 반응하더라고요. 어떤 팀은 오래된 테스트 인스턴스를 지우고, 어떤 팀은 Snapshot 정리를 하더라고요. 이거 진짜 편합니다. 비용 청구 이전에 자원 최적화 효과가 먼저 나타나거든요.

유휴 자원 감소, 프로젝트별 비용 가시성 향상, 월간 리포트 정착 전후를 비교하는 요약 인포그래픽입니다.

정리: 오픈스택 비용 분석은 완벽함보다 지속 가능성이 중요합니다

오늘 정리한 내용을 한 문장으로 요약하면 이래요. 오픈스택 비용 분석은 Telemetry(텔레메트리) 수집보다, 프로젝트 테넌트 기준의 합의 가능한 과금 모델을 만드는 일이 훨씬 더 중요하더라고요.

제가 여러 번 해보니 가장 현실적인 순서는 아래와 같더라고요.

1. Compute와 Volume만으로 시작
2. 프로젝트별 자원 사용량 리포트부터 정착
3. Showback으로 1~2개월 운영
4. 이후 Chargeback으로 확대
5. 필요하면 CloudKitty 같은 전용 도구 도입

혹시 지금 오픈스택 차지백을 준비 중이신가요? 그렇다면 처음부터 거대한 과금 엔진을 만들기보다, 설명 가능한 숫자를 먼저 만드는 걸 강력 추천해요. 그게 결국 오래 갑니다. 다음 글에서는 프로젝트별 태깅 전략과 비용 센터 매핑, 그리고 리포트 자동화 파이프라인을 더 깊게 다뤄볼 생각입니다. 이전 글에서 다뤘던 OpenStack 운영 표준화 이야기도 같이 보시면 흐름 잡는 데 도움이 되실 거예요.

FAQ: 현장에서 자주 받는 질문

Q1. 오픈스택 비용 분석은 반드시 CloudKitty가 있어야 하나요?

아니에요. 초기에는 OpenStack API 결과와 간단한 스크립트만으로도 충분히 시작할 수 있어요. 다만 규모가 커지고 규칙이 복잡해지면 전용 도구 검토 가치가 있더라고요.

Q2. 프로젝트 테넌트 기준이 항상 맞나요?

대부분의 내부 차지백에서는 가장 관리하기 쉬운 기준이에요. 다만 조직 구조와 다르면 프로젝트와 비용 센터 매핑 테이블을 별도로 두는 편이 좋아요.

Q3. CPU 사용률 기반 과금이 더 정확한 것 아닌가요?

정확성만 보면 일리가 있지만, 실제 운영에서는 설명 가능성과 재현 가능성이 훨씬 더 중요하더라고요. 그래서 할당량 기반의 vCPU-hour 모델이 출발점으로 많이 쓰여요.