[OpenStack] 테넌트 쿼터로 클라우드 비용 효율화하기

목차

• OpenStack 쿼터 관리가 왜 비용 효율성과 연결될까요?
• 프로젝트 테넌트 기준으로 봐야 하는 핵심 자원
• 제가 추천하는 기본 등급 방식
• OpenStack 쿼터 관리 설계 전략: 숫자보다 기준이 먼저입니다
• 실전 구현: OpenStack CLI로 프로젝트 테넌트 쿼터 설정하기
• 1. 현재 프로젝트 목록과 상태 확인
• 2. 현재 쿼터 확인
• 3. Compute 쿼터 설정
• 4. Block Storage 쿼터 설정
• 5. Network 쿼터 설정
• 6. 프로젝트별 기준을 문서화하기
• 자동화까지 가면 더 편합니다: 점검 스크립트 예시
• ⚠️ 실제로 많이 겪는 문제와 트러블슈팅
• 1. 쿼터는 남았는데 인스턴스 생성이 실패하는 경우
• 2. 볼륨은 삭제했는데 용량이 안 돌아오는 경우
• 3. 프로젝트 생성마다 쿼터 요청이 제각각 들어오는 경우
• 검증: 쿼터 정책이 제대로 먹혔는지 확인하는 방법
• 비용 관점에서 꼭 같이 보면 좋은 운영 지표
• 정리: OpenStack 쿼터 관리는 제한이 아니라 운영 최적화입니다
• 자주 묻는 질문
• Q. 모든 프로젝트에 같은 쿼터를 주면 안 되나요?
• Q. 쿼터를 낮게 잡으면 사용자 불만이 커지지 않나요?
• Q. OpenStack 비용 최적화에서 가장 먼저 볼 항목은 뭔가요?

[OpenStack] 테넌트 쿼터로 클라우드 비용 효율화하기

OpenStack 쿼터 관리, 이거 운영 조금만 해보신 분들은 왜 중요한지 바로 체감하실 겁니다. 프로젝트 테넌트(Project Tenant, 프로젝트 단위 자원 사용 영역)를 여러 팀에 열어두면 초반엔 다들 조심해서 쓰는 것 같거든요. 근데 어느 순간부터 vCPU, RAM, Volume(볼륨, 블록 스토리지), Floating IP(플로팅 아이피, 외부 연결용 공인 IP) 같은 자원이 한쪽으로 몰리기 시작합니다. 저도 홈랩이랑 사내 비슷한 테스트 환경을 굴리면서 처음엔 "일단 넉넉하게 주자" 쪽이었는데요. 결과는 뻔했습니다. 누군가는 필요 이상으로 잡아두고, 누군가는 정말 필요한 순간에 못 쓰더라고요. 결국 OpenStack 비용 최적화는 자원을 덜 쓰는 문제가 아니라, 필요한 팀이 필요한 만큼만 쓰게 만드는 운영 규칙에서 시작됩니다.

특히 비용 관점에서 보면 더 명확합니다. 퍼블릭 클라우드처럼 바로 청구서가 날아오지 않더라도, 내부 클라우드도 결국은 서버, 스토리지, 네트워크 장비, 전력, 운영 시간까지 전부 비용이거든요. 그래서 이번 글에서는 제가 실제로 자주 쓰는 방식대로 OpenStack 쿼터 관리의 개념, 프로젝트 테넌트별 설계 기준, 그리고 운영 중 삽질했던 포인트까지 한 번에 정리해보겠습니다.

프로젝트 테넌트마다 컴퓨트, 스토리지, 네트워크 자원이 어떻게 제한되고 분배되는지 보여주는 개요 이미지입니다.

OpenStack 쿼터 관리가 왜 비용 효율성과 연결될까요?

쉽게 말해 쿼터(Quota, 사용 한도)는 "이 프로젝트가 얼마나 많이 가져갈 수 있는가"를 정하는 안전장치입니다. 이걸 안 걸어두면 성실한 팀이 손해를 보고, 빨리 점유한 팀이 이득을 보게 되는 거죠. 운영 입장에서는 제일 피곤한 구조더라고요.

제가 처음 쿼터 정책을 손댔을 때 제일 헷갈렸던 부분이 이거였습니다. "어차피 남는 자원인데 굳이 제한해야 하나?" 근데 실제로 써보니까, 남는 자원과 점유된 자원은 완전히 다른 이야기더라고요. 인스턴스(Instance, 가상머신) 하나가 꺼져 있어도 디스크는 잡고 있고, IP는 할당돼 있고, 볼륨 스냅샷까지 누적되면 체감보다 훨씬 빨리 자원이 막혀버립니다.

• 과도한 선점 방지: 한 프로젝트가 전체 클러스터 자원을 독식하는 상황을 막습니다.
• 예산 예측 가능성 확보: 프로젝트별 사용 상한을 정해두면 증설 시점이 보입니다.
• 운영 정책 표준화: 요청이 들어올 때마다 감으로 승인하지 않아도 됩니다.
• OpenStack 비용 최적화: 남는 자원을 없애는 게 아니라, 불필요하게 묶인 자원을 줄입니다.

프로젝트 테넌트 기준으로 봐야 하는 핵심 자원

OpenStack에서 쿼터를 잡을 때 보통 Compute(컴퓨트), Block Storage(블록 스토리지), Network(네트워크) 세 축으로 나눠서 봅니다. 여기서 중요한 건 팀이 실제로 병목을 느끼는 자원을 먼저 보는 겁니다.

영역	대표 쿼터 항목	운영에서 자주 문제 되는 부분
Compute	instances, cores, ram	테스트 VM 대량 생성, 과도한 vCPU 점유
Block Storage	volumes, snapshots, gigabytes	안 쓰는 볼륨 누적, 스냅샷 방치
Network	floating-ips, ports, routers	공인 IP 고갈, 포트 수 초과

여기서 중요한 포인트! 모든 프로젝트에 동일한 숫자를 주는 건 공평해 보이지만, 실제로는 비효율적인 경우가 많습니다. 예를 들어 개발팀은 인스턴스 수는 많이 필요하지만 볼륨 용량은 적을 수 있고요. 데이터 처리 팀은 반대로 대용량 스토리지가 더 중요할 수 있거든요. 그래서 프로젝트 테넌트 성격별 기본 등급을 나눠두는 방식이 운영이 훨씬 편합니다.

제가 추천하는 기본 등급 방식

1. 샌드박스용 프로젝트: 작은 인스턴스 수와 낮은 RAM 한도
2. 개발/검증용 프로젝트: 중간 수준의 vCPU, RAM, 볼륨 허용
3. 운영/서비스용 프로젝트: 승인 기반으로 높은 한도 부여

이렇게 해두면 신규 프로젝트 생성 때마다 처음부터 숫자 싸움을 안 해도 되거든요. 진짜 편하더라고요.

OpenStack 쿼터 관리 설계 전략: 숫자보다 기준이 먼저입니다

쿼터 값 자체보다 더 중요한 건 "왜 이 숫자인가"입니다. 저도 처음엔 그냥 현재 남는 자원을 보고 나눴었는데요. 그 방식은 시간이 지나면 꼭 꼬입니다. 지금 비어 있다고 앞으로도 비는 게 아니거든요.

그래서 기준을 아래처럼 잡아두면 좋습니다.

• 현재 총 자원이 아니라 안전 여유분을 제외한 가용 자원을 기준으로 잡습니다.
• 프로젝트 중요도와 업무 특성을 반영합니다.
• 일시적 피크와 상시 사용량을 구분합니다.
• 분기별 재평가 일정을 미리 운영 정책에 넣습니다.

예를 들어 vCPU 200개가 있다고 해서 프로젝트들에 합산 200개를 딱 맞춰 배정하면 안 됩니다. 장애 복구, 호스트 점검, 임시 증설 같은 변수 때문에 버퍼가 필요하거든요. 실제로 호스트 하나 유지보수 들어가면 체감 여유분이 확 줄어들더라고요. 저는 이런 부분 때문에 쿼터를 자원 총량 관리가 아니라, 리스크 관리로 보는 편입니다.

실전 구현: OpenStack CLI로 프로젝트 테넌트 쿼터 설정하기

이제 실제로 설정하는 흐름을 보겠습니다. 예시는 OpenStack CLI 기준으로 적겠습니다. 환경마다 서비스 구성 차이는 있지만, 기본 흐름은 비슷합니다.

1. 현재 프로젝트 목록과 상태 확인

openstack project list
openstack project show myproject

먼저 어떤 프로젝트 테넌트에 정책을 적용할지 확인합니다. 이름이 비슷한 프로젝트가 많으면 ID 기준으로 작업하는 게 안전하거든요. 저도 이름만 보고 했다가 다른 프로젝트를 건드린 적이 있었는데, 그때 식은땀 좀 났습니다 ㅎㅎ

2. 현재 쿼터 확인

openstack quota show myproject
openstack volume quota show myproject
openstack network quota show myproject

배포판이나 서비스 버전에 따라 출력 항목이 조금 다를 수 있습니다. 핵심은 Compute, Volume, Network를 분리해서 확인하는 습관을 들이는 거죠.

운영자가 CLI에서 프로젝트별 쿼터를 조회하고 조정하는 실제 작업 흐름을 보여주는 이미지입니다.

3. Compute 쿼터 설정

openstack quota set \
  --instances 20 \
  --cores 40 \
  --ram 81920 \
  myproject

여기서 RAM은 보통 MB 단위로 다루는데, 꼭 환경 문서를 먼저 확인하셔야 합니다. 숫자 단위를 헷갈리면 의도보다 훨씬 크게 열어줄 수 있거든요.

4. Block Storage 쿼터 설정

openstack quota set \
  --volumes 20 \
  --snapshots 20 \
  --gigabytes 2048 \
  myproject

스토리지 쪽은 특히 방치 비용이 큽니다. 인스턴스는 지워도 볼륨과 스냅샷이 남아 있는 경우가 정말 많거든요. OpenStack 비용 최적화 관점에서는 이 영역이 생각보다 효과가 크더라고요.

5. Network 쿼터 설정

openstack quota set \
  --floating-ips 5 \
  --ports 50 \
  --routers 2 \
  myproject

공인 IP가 적은 환경에서는 Floating IP 제한만 잘 잡아도 운영이 훨씬 안정됩니다.

6. 프로젝트별 기준을 문서화하기

명령어만 실행하고 끝내면 나중에 왜 그렇게 했는지 아무도 모릅니다. 저는 최소한 아래 형태로 남겨두는 걸 추천하거든요.

project_quota_policy:
  project_name: myproject
  profile: development
  compute:
    instances: 20
    cores: 40
    ram_mb: 81920
  storage:
    volumes: 20
    snapshots: 20
    gigabytes: 2048
  network:
    floating_ips: 5
    ports: 50
    routers: 2
  reason: "개발 검증 환경 기본 등급"
  review_cycle: "quarterly"

운영은 결국 사람이 이어받는 일이 많으니까요. 문서화된 기준이 있어야 분쟁도 줄고, 승인 속도도 빨라집니다.

자동화까지 가면 더 편합니다: 점검 스크립트 예시

쿼터 설정은 한 번 해두는 걸로 끝나지 않습니다. 실제 사용량과 비교해야 의미가 있거든요. 저는 예전에 프로젝트는 많은데 사람이 일일이 확인하다 보니 누수 자원을 놓치는 경우가 많았습니다. 그래서 간단한 점검 스크립트라도 돌려보는 걸 추천합니다.

import json
import subprocess

PROJECT = "myproject"

result = subprocess.run(
    ["openstack", "quota", "show", PROJECT, "-f", "json"],
    capture_output=True,
    text=True,
    check=True,
)
quota = json.loads(result.stdout)

for key in ["instances", "cores", "ram"]:
    value = quota.get(key)
    print(f"{key}: {value}")

물론 실제 운영에선 사용량 조회와 비교 로직까지 붙여야 합니다. 다만 시작은 단순한 게 좋거든요. 처음부터 거대한 자동화 만들려다가 손 놓는 경우가 더 많더라고요.

각 프로젝트의 사용량 대비 쿼터 한도를 한눈에 비교해 병목과 과다 할당을 찾는 대시보드 이미지입니다.

⚠️ 실제로 많이 겪는 문제와 트러블슈팅

이 섹션은 제가 삽질 좀 했던 부분입니다. 문서만 보면 쉬워 보이는데, 운영에서는 꼭 이런 일이 생깁니다.

1. 쿼터는 남았는데 인스턴스 생성이 실패하는 경우

이건 쿼터 문제가 아니라 실제 물리 자원 부족이거나 스케줄링(Scheduling, 배치 결정) 이슈일 수 있거든요. 예를 들어 특정 AZ(Availability Zone, 가용 영역)나 호스트 집합에 여유가 없으면 쿼터가 남아도 실패합니다.

• 프로젝트 쿼터와 실제 클러스터 가용량을 분리해서 봅니다.
• 특정 호스트 집합에 몰리는 Flavor(플레이버, VM 사양 템플릿) 사용 패턴을 확인합니다.

2. 볼륨은 삭제했는데 용량이 안 돌아오는 경우

스냅샷, 백업, 또는 분리된 리소스가 남아 있을 수 있습니다. 저는 처음에 인스턴스만 없애면 끝인 줄 알았는데, 실제로 써보니까 스토리지가 조용히 계속 점유되고 있더라고요.

• 미연결 볼륨과 오래된 스냅샷을 주기적으로 점검합니다.
• 프로젝트 종료 절차에 스토리지 정리 단계를 넣습니다.

3. 프로젝트 생성마다 쿼터 요청이 제각각 들어오는 경우

이건 기술 문제가 아니라 정책 부재죠. 기준 등급이 없으면 모든 요청이 예외처럼 보입니다. 그래서 아예 기본 프로필을 나눠두고, 초과 요청은 사유 기반 승인으로 바꾸는 게 운영이 훨씬 편합니다.

상황	권장 대응
개발팀 신규 프로젝트	기본 개발 등급 자동 적용
일시적 부하 테스트	기간 제한 임시 증액 후 자동 회수
운영 서비스 확장	근거 확인 후 상향 조정 및 재검토 일정 등록

검증: 쿼터 정책이 제대로 먹혔는지 확인하는 방법

설정한 뒤에는 반드시 검증이 필요합니다. 여기서 대충 넘어가면 나중에 "분명 설정했는데 왜 안 되죠?" 상황이 옵니다.

1. 프로젝트별 쿼터를 다시 조회해 의도한 값이 반영됐는지 확인합니다.
2. 테스트 인스턴스 생성으로 제한 동작을 확인합니다.
3. 볼륨, 스냅샷, Floating IP도 같은 방식으로 검증합니다.
4. 운영 문서와 실제 값이 일치하는지 대조합니다.

openstack quota show myproject
openstack volume quota show myproject
ostack network quota show myproject

가능하면 소규모 프로젝트 하나를 골라서 먼저 적용해보세요. 한 번에 전 프로젝트에 밀어 넣는 방식은 위험합니다. 저도 처음엔 빨리 끝내고 싶어서 한꺼번에 바꾸려다가, 예외 케이스 때문에 되돌아보는 시간이 더 길었거든요.

검증이 끝나면 보통 아래 같은 변화가 보입니다.

• 공유 자원 고갈 빈도가 줄어듭니다.
• 불필요한 증설 요청이 감소합니다.
• 프로젝트별 책임 범위가 명확해집니다.
• 클러스터 전체 자원 사용률이 더 예측 가능해지더라고요. 🎉

쿼터 정책 적용 전과 후의 자원 점유율, 낭비 감소, 운영 효율 향상을 비교하는 요약 이미지입니다.

비용 관점에서 꼭 같이 보면 좋은 운영 지표

OpenStack 쿼터 관리만으로 모든 비용 문제가 해결되지는 않습니다. 하지만 아래 지표를 같이 보면 OpenStack 비용 최적화 효과가 훨씬 명확하게 드러납니다.

• 프로젝트별 평균 인스턴스 가동률
• 미연결 볼륨 수와 총 용량
• 스냅샷 누적량
• Floating IP 미사용 비율
• 임시 증액 요청 빈도

이런 지표를 한 달만 모아도 "어디가 진짜 병목인지"가 보입니다. 감으로 운영할 때랑은 차이가 정말 크거든요. 혹시 지금 프로젝트 테넌트 쿼터를 이미 쓰고 계신데도 자원 부족이 계속 반복되시나요? 그럼 숫자를 더 주는 것보다, 사용 패턴과 회수 정책부터 점검해보시는 게 맞습니다.

정리: OpenStack 쿼터 관리는 제한이 아니라 운영 최적화입니다

오늘 이야기의 핵심은 단순합니다. OpenStack 쿼터 관리는 사용자를 불편하게 하려는 장치가 아니라, 클라우드 자원 관리의 기준선을 만드는 작업이라는 점입니다. 제가 직접 해보니 쿼터를 잘 잡아두면 장애가 줄고, 승인 절차가 빨라지고, 무엇보다 비용 이야기할 때 근거가 생기거든요. 이게 진짜 큽니다.

특히 프로젝트 테넌트가 늘어나는 환경이라면, 초기에 조금 귀찮아도 기본 등급과 재검토 주기를 만들어두세요. 나중에 훨씬 편합니다. 드디어 됐다 싶었던 순간이 바로, 운영팀과 사용자팀이 같은 숫자를 보고 이야기하기 시작했을 때였거든요.

다음 글에서는 프로젝트 테넌트 사용량을 주기적으로 수집해서 보고서 형태로 만드는 방법도 다뤄볼 예정입니다. 이전 글에서 다뤘던 인스턴스 라이프사이클 정리 정책과 같이 보시면 더 흐름이 잘 잡히실 겁니다. ✅

자주 묻는 질문

Q. 모든 프로젝트에 같은 쿼터를 주면 안 되나요?

가능하지만 비효율적인 경우가 많습니다. 업무 특성이 다르기 때문에 같은 숫자가 오히려 낭비를 만들 수 있거든요.

Q. 쿼터를 낮게 잡으면 사용자 불만이 커지지 않나요?

기준 없이 낮추면 그렇습니다. 대신 기본 등급, 임시 증액 절차, 재검토 일정을 같이 운영하면 마찰을 많이 줄 수 있습니다.

Q. OpenStack 비용 최적화에서 가장 먼저 볼 항목은 뭔가요?

제 경험상 미연결 볼륨, 오래된 스냅샷, 과도한 Floating IP 점유부터 보는 게 체감 효과가 빠릅니다.

📚 함께 읽으면 좋은 글

• OpenStack 업그레이드 10가지 체크리스트: 실전 베스트 프랙티스로 성공 확률 높이기
• OpenStack VXLAN 오버레이 네트워크 성능 벤치마크 가이드
• OpenStack Manila 도입 1년 회고