[OpenStack] 오픈스택 플레이버 최적화로 유휴 자원 줄이기

목차

• 왜 OpenStack 플레이버 최적화가 중요한가
• OpenStack 플레이버 개념, 쉽게 말해 이런 겁니다
• 현재 상태부터 점검해보세요: 유휴 자원은 숫자로 봐야 합니다
• 표준 플레이버를 줄이고, 비율을 맞추는 게 비용 절감의 시작입니다
• 실전 구현: OpenStack 플레이버 재설계와 적용 순서
• 권장 운영 기준
• ⚠️ 제가 실제로 겪은 문제들: 트러블슈팅과 주의사항
• 1. 플레이버만 줄였는데도 자원이 안 돌아오는 경우
• 2. 메모리 단편화가 심해 배치가 꼬이는 경우
• 3. extra_specs를 너무 공격적으로 쓰는 경우
• 4. 이름만 바꾸고 정책은 안 바뀌는 경우
• 검증은 이렇게 보시면 됩니다: 자원 최적화가 됐는지 확인하는 법
• 자주 묻는 질문
• Q1. OpenStack 플레이버를 많이 만들수록 사용자 만족도가 높아지지 않나요?
• Q2. 비용 절감 효과를 어떻게 설명하면 좋을까요?
• Q3. 기존 인스턴스는 언제 옮기는 게 좋을까요?
• 정리: 비용 절감은 작은 플레이버가 아니라 좋은 기준에서 시작됩니다

[OpenStack] 오픈스택 플레이버 최적화로 유휴 자원 줄이기

프라이빗 클라우드 운영을 하다 보면 CPU는 남는데 메모리가 먼저 바닥나거나, 반대로 스토리지는 넉넉한데 작은 워크로드가 큰 VM 사양을 계속 잡아먹는 상황을 자주 보게 됩니다. 저도 홈랩과 업무 환경에서 이런 패턴을 여러 번 겪었고, 결국 문제의 중심에는 OpenStack 플레이버 설계가 있더라고요. 처음엔 인스턴스만 잘 뜨면 된다고 생각했는데, 실제로 써보니까 플레이버가 조금만 느슨해도 유휴 자원(idle resource)이 금방 쌓이고, 그게 곧 비용 압박으로 이어졌거든요.

특히 프라이빗 클라우드 운영에서는 퍼블릭 클라우드처럼 청구서가 바로 날아오지 않아서 체감이 늦습니다. 근데 여기서 방심하면 안 됩니다. 서버 증설, 전력, 랙 공간, 백업, 운영 시간까지 다 합치면 결국 내부 비용이 꽤 커지거든요. 그래서 오늘은 OpenStack 플레이버를 어떻게 다듬어야 자원 최적화와 비용 절감을 동시에 가져갈 수 있는지, 제가 삽질했던 포인트까지 포함해서 정리해보겠습니다.

플레이버 정의가 컴퓨트 노드 자원 사용률에 어떤 영향을 주는지 한눈에 보여주는 개요 이미지입니다.

왜 OpenStack 플레이버 최적화가 중요한가

쉽게 말해 플레이버는 VM의 기본 체급표입니다. vCPU, RAM, root disk 같은 자원 크기를 미리 정해두고, 사용자는 그중 하나를 골라 인스턴스를 만들게 되죠. 문제는 이 체급표가 현실과 안 맞을 때 생기더라고요.

• 너무 큰 플레이버만 있으면 작은 서비스도 과하게 큰 자원을 점유합니다.
• 너무 많은 플레이버가 있으면 운영 기준이 흐려지고, 사용자도 뭘 골라야 할지 헷갈립니다.
• 이름 규칙이 제각각이면 자동화 스크립트와 정책 관리가 꼬이기 쉽습니다.
• 워크로드 특성에 맞지 않는 비율로 설계하면 CPU overcommit(오버커밋)이나 메모리 낭비가 반복됩니다.

저도 처음엔 부서 요청이 들어올 때마다 플레이버를 하나씩 추가했었습니다. 그때는 빨리 만들어주는 게 친절이라고 생각했는데요. 시간이 지나니까 m1-medium-v2-final 같은 이름이 생기고, 용도는 겹치고, 어떤 VM은 메모리만 남고 어떤 VM은 CPU만 묶여버리는 이상한 상태가 되더라고요. 그때부터 기준을 다시 세웠고, 드디어 좀 정리가 됐습니다.

OpenStack 플레이버 개념, 쉽게 말해 이런 겁니다

Flavor(플레이버, 가상머신 자원 템플릿)는 Nova(노바, OpenStack의 컴퓨트 서비스)에서 인스턴스 크기를 정의하는 단위입니다. 일반적으로 아래 항목을 포함합니다.

• vCPU: 가상 CPU 개수
• RAM: 메모리 크기(MB 단위)
• Disk: 루트 디스크 크기(GB 단위)
• Ephemeral Disk: 임시 디스크가 필요한 경우 사용하는 추가 디스크
• Swap: 스왑 영역
• extra_specs: 스케줄링, CPU 정책, NUMA 같은 추가 속성

여기서 중요한 포인트! 플레이버는 단순히 숫자 몇 개를 묶어놓은 게 아닙니다. 실제로는 스케줄러(scheduler, 어느 컴퓨트 노드에 올릴지 결정하는 구성요소)와 운영 정책의 기준점 역할도 해요. 예를 들어 특정 플레이버에 dedicated CPU policy(전용 CPU 정책)나 huge pages(대용량 메모리 페이지) 같은 조건을 넣으면, 같은 4 vCPU / 8GB라도 완전히 다른 자원 소비 패턴이 됩니다.

그래서 자원 최적화를 하려면 단순히 작은 플레이버를 늘리는 게 아니라, 어떤 워크로드를 어떤 비율로 태울지를 먼저 봐야 합니다. 사실 이걸 건너뛰면 플레이버만 바꾸고 결과는 그대로인 경우가 많더라고요.

현재 상태부터 점검해보세요: 유휴 자원은 숫자로 봐야 합니다

제가 직접 해보니 제일 먼저 해야 할 일은 플레이버를 새로 만드는 게 아니라, 지금 어떤 플레이버가 실제로 얼마나 쓰이는지 확인하는 일이었습니다. 감으로 보면 꼭 틀립니다. 특히 오래된 환경일수록 더 그렇거든요.

1. 현재 등록된 플레이버 목록을 확인합니다.
2. 인스턴스별로 어떤 플레이버가 얼마나 사용 중인지 집계합니다.
3. 컴퓨트 노드별 vCPU, 메모리 사용률과 배치 불균형을 함께 봅니다.
4. 실사용 대비 과대 할당된 표준 플레이버를 후보로 뽑습니다.

openstack flavor list --long

openstack server list --all-projects -f value -c ID -c Name -c Flavor

openstack hypervisor list
openstack hypervisor stats show

CLI(Command Line Interface, 명령줄 인터페이스)로 보면 좀 투박하긴 한데, 오히려 현실이 잘 보여요. 예를 들어 플레이버는 12개인데 실제로 자주 쓰는 건 4개뿐인 경우가 꽤 많습니다. 반대로 이름은 비슷한데 메모리만 조금씩 다른 플레이버가 잔뜩 있는 환경도 있었고요.

제가 운영하던 환경에서는 2 vCPU / 8GB 계열 플레이버가 유독 많았는데, 실제 앱은 메모리 3~4GB 수준만 쓰는 경우가 대부분이었습니다. 결국 메모리 단편화(fragmentation, 자원이 애매하게 쪼개져 남는 현상)가 심해졌고, 새 인스턴스를 띄울 때 특정 노드만 계속 부족하다는 알람이 뜨더라고요. CPU는 남는데 메모리 때문에 못 올리는 상황, 이거 꽤 자주 본답니다.

실제 운영에서 자주 보게 되는 플레이버 사용 편중과 노드별 자원 불균형 예시를 보여주는 이미지입니다.

표준 플레이버를 줄이고, 비율을 맞추는 게 비용 절감의 시작입니다

여기서 중요한 건 플레이버 개수를 무조건 늘리는 게 아니라 표준화(standardization, 기준을 통일하는 작업)입니다. 저는 보통 워크로드를 세 가지로 나눠서 봅니다.

• 범용형: 웹, API, 배치처럼 평균적인 CPU/메모리 비율
• 메모리 집중형: 캐시, JVM, 분석 도구처럼 메모리 사용량이 큰 유형
• 컴퓨트 집중형: 빌드, 인코딩, 일부 계산 작업처럼 CPU 사용량이 높은 유형

이걸 바탕으로 플레이버를 단순하게 재구성하면 선택이 쉬워지고, 배치도 예측 가능해집니다. 아래는 많이 쓰는 정리 방식 예시입니다.

구분	예시 이름	용도	설계 포인트
범용형	gp.small / gp.medium	일반 웹, API, 업무 시스템	CPU와 메모리 비율을 균형 있게 유지
메모리형	mem.small / mem.medium	캐시, 메모리 민감 서비스	같은 vCPU 대비 RAM 비율 확대
컴퓨트형	cpu.small / cpu.medium	배치, 변환, CI 작업	메모리보다 CPU 효율 우선
전용형	perf.large	성능 민감 워크로드	extra_specs로 정책 분리

이름 규칙도 꽤 중요합니다. 저는 나중에 자동화할 걸 생각해서 접두사(prefix)를 꼭 넣어요. 예를 들면 gp, mem, cpu 같이요. 이렇게 해야 Terraform(테라폼, 인프라 코드 도구)이나 Ansible(앤서블, 자동화 도구)에서 분기하기 편하더라고요.

참고로 플레이버를 설계할 때는 너무 세밀하게 자르는 것보다 20~30% 정도의 여유 구간을 가진 계단형 구성이 관리가 편합니다. 2GB, 3GB, 4GB, 5GB, 6GB 식으로 촘촘히 만들면 한동안은 좋아 보이는데, 운영자가 나중에 감당하기 힘들어진답니다.

실전 구현: OpenStack 플레이버 재설계와 적용 순서

이제 실제로 손을 대볼 차례입니다. 제가 보통 쓰는 절차는 아래 순서입니다. 한 번에 다 바꾸려고 하면 사고 나요. 저도 예전에 급하게 정리하다가 사용자한테 왜 목록이 바뀌었냐는 문의를 한꺼번에 받았거든요.

1. 기존 플레이버 사용 현황을 수집합니다.
2. 표준 플레이버 목록을 먼저 문서화합니다.
3. 새 플레이버를 추가하되 기존 것은 바로 삭제하지 않습니다.
4. 신규 배포부터 새 플레이버를 사용하게 유도합니다.
5. 사용량이 떨어진 기존 플레이버를 단계적으로 비공개 또는 정리합니다.

# 범용형 플레이버 생성 예시
openstack flavor create gp.small \
  --vcpus 2 \
  --ram 4096 \
  --disk 20

openstack flavor create gp.medium \
  --vcpus 4 \
  --ram 8192 \
  --disk 40

# 메모리형 플레이버 생성 예시
openstack flavor create mem.small \
  --vcpus 2 \
  --ram 8192 \
  --disk 20

# extra_specs 설정 예시
openstack flavor set perf.large \
  --property hw:cpu_policy=dedicated \
  --property hw:mem_page_size=large

위 예시는 어디까지나 구조 예시입니다. 수치는 각 환경의 하이퍼바이저(hypervisor, 가상화 호스트) 구성과 워크로드 특성에 맞춰 잡으셔야 해요. 무작정 따라 넣는 건 추천하지 않습니다. 특히 전용 CPU 정책은 호스트 여유가 부족하면 오히려 배치 가능성이 떨어질 수 있거든요.

실제로 써보니까 신규 플레이버를 만들고 바로 공지하는 것보다, Horizon(호라이즌, OpenStack 웹 대시보드) 또는 내부 포털에서 기본 선택지를 먼저 바꾸는 게 효과가 좋았습니다. 사용자는 기본값을 잘 따라가거든요. 이거 진짜 편하더라고요.

표준 플레이버 생성과 정책 분리를 적용하는 과정을 시각적으로 보여주는 구성 이미지입니다.

권장 운영 기준

• 기존 플레이버는 즉시 삭제하지 말고 일정 기간 공존시키세요.
• 프로젝트별 예외 요구는 별도 전용 플레이버로 격리하세요.
• 자동 배포 템플릿에서 플레이버 이름을 하드코딩했다면 사전 점검이 필요합니다.
• 비용 절감 효과는 VM 개수보다 호스트 증설 지연 효과에서 더 크게 나타날 수 있습니다.

⚠️ 제가 실제로 겪은 문제들: 트러블슈팅과 주의사항

여기서부터가 진짜 운영 이야기예요. 문서에는 잘 안 나오는데, 실제론 이런 부분에서 많이 막힙니다.

1. 플레이버만 줄였는데도 자원이 안 돌아오는 경우

기존 인스턴스는 자동으로 새 플레이버를 쓰지 않아요. resize(리사이즈, 인스턴스 사양 변경)나 재배포가 필요합니다. 저도 처음엔 표준 플레이버 정리만 하면 바로 효과가 날 줄 알았는데, 기존 대형 인스턴스가 그대로 남아 있어서 체감 변화가 거의 없었습니다.

# 인스턴스 리사이즈 예시
openstack server resize --flavor gp.small <SERVER_ID>
openstack server resize confirm <SERVER_ID>

2. 메모리 단편화가 심해 배치가 꼬이는 경우

플레이버 종류가 많으면 같은 총 메모리 용량이라도 애매하게 쪼개져 남아요. 이럴 때는 큰 플레이버를 무작정 유지하는 것보다, 중간 단계를 줄이고 범용형으로 수렴시키는 편이 낫더라고요.

3. extra_specs를 너무 공격적으로 쓰는 경우

특정 성능 요구 때문에 dedicated CPU나 huge pages를 광범위하게 쓰기 시작하면 스케줄링 제약이 커져요. 성능은 좋아질 수 있어도 전체 효율성은 오히려 떨어질 수 있습니다. 성능 민감 워크로드만 별도 클래스로 분리하는 게 안전했습니다.

4. 이름만 바꾸고 정책은 안 바뀌는 경우

이건 꽤 흔합니다. 이름을 optimized로 바꿔도 사용자가 여전히 가장 큰 플레이버를 고르면 의미가 없어요. 그래서 quota(쿼터, 프로젝트별 자원 한도), 기본 템플릿, 셀프서비스 포털 가이드까지 같이 손봐야 합니다.

검증은 이렇게 보시면 됩니다: 자원 최적화가 됐는지 확인하는 법

변경 후에는 감이 아니라 지표로 보셔야 해요. 저는 보통 아래 네 가지를 같이 봅니다.

1. 플레이버별 인스턴스 분포가 표준 세트로 모였는지
2. 컴퓨트 노드별 메모리/CPU 편차가 줄었는지
3. 새 인스턴스 배치 실패가 감소했는지
4. 호스트 증설 시점을 뒤로 미룰 수 있는지

openstack hypervisor stats show
openstack usage show --project <PROJECT_ID>
openstack server list --all-projects --long

제가 직접 해보니 가장 먼저 보이는 변화는 "애매하게 남는 자원"이 줄어드는 점이었어요. 예전에는 노드마다 2GB, 4GB, 6GB씩 찌꺼기처럼 남았는데 실제 배치엔 못 쓰는 경우가 많았거든요. 플레이버를 표준화하고 나니 배치 성공률이 안정되고, 신규 호스트 추가 논의를 한 템포 늦출 수 있었습니다. 프라이빗 클라우드 운영에서는 이 지점이 곧 비용 절감 효과로 이어집니다.

🎉 특히 showback(쇼백, 내부 비용 가시화)이나 chargeback(차지백, 부서별 비용 배분) 체계가 있는 조직이라면 플레이버 표준화가 훨씬 중요합니다. 기준이 명확해야 부서별 사용 패턴도 설명하기 쉽고, 과도한 요청에 근거 있게 대응할 수 있거든요.

최적화 전후의 자원 활용도와 인스턴스 배치 효율 차이를 보여주는 결과 시각화 이미지입니다.

자주 묻는 질문

Q1. OpenStack 플레이버를 많이 만들수록 사용자 만족도가 높아지지 않나요?

짧게 답하면, 꼭 그렇진 않습니다. 선택지가 너무 많으면 오히려 잘못 고를 확률이 높아져요. 표준 플레이버는 적게, 예외는 분리해서 운영하는 쪽이 장기적으로 효율적이었습니다.

Q2. 비용 절감 효과를 어떻게 설명하면 좋을까요?

직접적인 청구 금액보다 호스트 증설 지연, 배치 실패 감소, 유휴 자원 감소 관점으로 설명하는 게 현실적이에요. 프라이빗 클라우드 운영에서는 이게 훨씬 설득력이 있습니다.

Q3. 기존 인스턴스는 언제 옮기는 게 좋을까요?

서비스 영향이 적은 점검 창을 잡아서 순차적으로 resize하거나, 재배포 주기에 맞춰 천천히 전환하는 게 안전해요. 한 번에 몰아붙이면 운영팀만 고생합니다. 저도 그렇게 삽질 좀 했습니다.

정리: 비용 절감은 작은 플레이버가 아니라 좋은 기준에서 시작됩니다

OpenStack 플레이버 최적화의 핵심은 단순히 VM 사양을 낮추는 게 아니에요. 워크로드를 분류하고, 표준 타입을 정하고, 운영 정책과 연결하는 것이죠. 이 흐름이 잡히면 자원 최적화, 효율성 개선, 비용 절감이 같이 따라옵니다. 반대로 기준 없이 요청마다 플레이버를 추가하면 언젠가 운영 복잡도가 비용으로 돌아와요.

혹시 지금 환경에서 플레이버 이름이 제각각이거나, 어떤 걸 없애도 되는지 감이 안 오신다면 먼저 사용 현황부터 뽑아보세요. 거기서 답이 보여요. 다음 글에서는 quota 설계와 프로젝트별 자원 정책을 어떻게 묶어야 실제 프라이빗 클라우드 운영이 편해지는지 다뤄볼 예정입니다. 이전 글에서 다룬 하이퍼바이저 자원 모니터링 글과 함께 보셔도 흐름이 더 잘 잡히실 거예요.

표준화, 운영 정책, 비용 절감 포인트를 한 장으로 정리한 요약 이미지입니다.

✅ 오늘 내용만 실무에 적용해도, 플레이버 목록 정리와 기본값 개선만으로 꽤 큰 차이를 느끼실 가능성이 높습니다. 저도 처음엔 이게 뭔가 싶었는데, 막상 정리하고 나니 운영이 훨씬 덜 피곤해졌거든요.

📚 함께 읽으면 좋은 글

• OpenStack Cinder 볼륨 생성 실패? 흔한 원인과 해결책
• OpenStack Trove vs RDS 마이그레이션, 왜 AWS RDS로 옮겼나
• OpenStack TCO 분석: VMware 대안, 실제 비용은 얼마나 줄어드나?