OpenStack 플레이버 설계가 중요한 이유

OpenStack 플레이버 설계는 단순히 vCPU 몇 개, RAM 몇 GB를 고르는 일이 아닙니다. 실제 운영 환경에서는 이 선택 하나 때문에 웹 서버는 멀쩡한데 DB만 느려지거나, 작은 배치 작업 하나가 Compute Node(컴퓨트 노드, 가상 머신을 실제로 실행하는 호스트)의 리소스를 오래 붙잡는 상황이 생기거든요.

저도 처음 홈랩에서 OpenStack을 만졌을 때는 “그냥 small, medium, large 만들면 되겠지”라고 생각했습니다. 그런데 실제로 써보니 꽤 다르더라고요. 같은 4 vCPU VM(Virtual Machine, 가상 머신)이라도 웹 워크로드와 데이터베이스 워크로드가 원하는 리소스 성격은 완전히 달랐습니다. CPU가 순간적으로 치솟는 서비스도 있고, 메모리를 꾸준히 쓰는 서비스도 있고, 디스크 I/O(Input/Output, 입출력) 때문에 전체가 버벅이는 경우도 있었습니다.

VM 사양은 넉넉해 보이는데 애플리케이션은 느리고, 반대로 어떤 VM은 리소스를 거의 안 쓰는데 너무 큰 플레이버를 물고 있는 상황을 본 적 있으신가요? 이 글에서는 Nova 플레이버를 워크로드 기준으로 어떻게 나누고, 어떤 명령어로 만들고, 운영 중 어떤 지표를 보고 조정할지 실무 관점으로 정리해보겠습니다.

OpenStack에서 플레이버가 VM 크기뿐 아니라 워크로드 배치 전략의 출발점이 된다는 흐름을 보여주는 개요 이미지입니다.

Nova 플레이버 개념: VM의 표준 사이즈표

OpenStack에서 Flavor(플레이버)는 VM을 만들 때 선택하는 리소스 묶음입니다. vCPU, Memory(메모리), Disk(디스크) 같은 기본값을 정의하고, 필요하면 Extra Specs(추가 속성)를 붙여 스케줄링, CPU 정책, 메모리 페이지 정책까지 조정합니다.

쉽게 말해 옷 사이즈표와 비슷합니다. small, medium, large라는 이름만 있다고 좋은 게 아니라, 우리 서비스에 맞는 치수표를 만들어야 합니다. 운영자가 미리 합리적인 사이즈를 만들어두면 사용자는 매번 VM 사양을 고민하지 않아도 되고, 인프라 입장에서는 리소스 낭비를 줄일 수 있습니다.

• vCPU: 가상 CPU 개수입니다. CPU 연산이 많은 워크로드에서 중요합니다.
• RAM: VM에 할당되는 메모리입니다. 캐시, DB, JVM 기반 서비스에서 특히 민감합니다.
• Root Disk: 기본 부팅 디스크 크기입니다. 이미지 기반 배포에서는 너무 크게 잡지 않는 편이 관리가 쉽습니다.
• Ephemeral Disk: VM 삭제 시 함께 사라지는 임시 디스크입니다.
• Extra Specs: CPU 고정, Huge Pages(휴즈 페이지, 큰 메모리 페이지), NUMA(Non-Uniform Memory Access, 비균일 메모리 접근) 같은 고급 옵션을 지정할 때 씁니다.

중요한 포인트는 하나입니다. 플레이버는 “많이 주면 좋다”가 아닙니다. 워크로드 분석을 먼저 하고, 그 다음에 VM 모양을 맞춰야 합니다. 이 순서가 바뀌면 나중에 튜닝이 꽤 피곤해집니다.

워크로드 분석 기준: CPU, 메모리, 디스크, 네트워크

실제 운영에서는 워크로드를 크게 네 부류로 나눠 보는 게 편했습니다. 웹/API 서버, 데이터베이스, 배치/분석 작업, 네트워크 장비형 VM입니다. 이름은 단순하지만 확인해야 할 지표는 서로 다릅니다.

실무에서는 평균값보다 피크 패턴을 더 자주 봅니다. CPU 평균이 낮아도 특정 시간대에 요청이 몰리면 체감 성능은 나빠집니다. 반대로 하루에 한 번만 도는 배치 작업에 항상 큰 플레이버를 붙여두면 리소스가 아깝습니다. VM 수가 늘어나면 이 차이가 진짜 크게 느껴지더라고요.

OpenStack 플레이버 설계 실전: CLI로 생성하기

이제 실제 명령어로 가보겠습니다. 아래 예시는 OpenStackClient 기준입니다. 환경마다 인증 방식은 다르지만, 보통은 OpenRC 파일을 source 한 뒤 실행합니다.

source ~/admin-openrc.sh

openstack flavor create m1.web.small \
  --vcpus 2 \
  --ram 4096 \
  --disk 20

openstack flavor create m1.api.medium \
  --vcpus 4 \
  --ram 8192 \
  --disk 30

openstack flavor create m1.db.memory \
  --vcpus 4 \
  --ram 16384 \
  --disk 40

openstack flavor list

여기서 RAM 단위는 MB입니다. 4096은 4GB, 8192는 8GB로 보면 됩니다. 처음엔 저도 이 단위를 대충 보고 넘겼다가 “왜 생각보다 작게 잡혔지?” 하고 한참 봤던 기억이 있습니다. 은근히 자주 하는 실수입니다.

DB나 지연 시간에 민감한 워크로드는 Extra Specs(추가 속성)를 고민할 수 있습니다. 예를 들어 CPU를 공유 정책으로 둘지, dedicated(전용 할당) 정책을 쓸지 판단해야 합니다. 다만 hw:cpu_policy=dedicated 같은 설정은 Compute Node의 전용 CPU 집합, Placement 리소스, Nova 설정이 맞아야 의미가 있습니다. 명령어만 넣는다고 마법처럼 빨라지지는 않더라고요.

OpenStack CLI로 기본 플레이버를 만들고 Extra Specs를 붙여 워크로드별로 구분하는 과정을 나타낸 구성 이미지입니다.

openstack flavor create m1.db.dedicated \
  --vcpus 4 \
  --ram 16384 \
  --disk 40

openstack flavor set m1.db.dedicated \
  --property hw:cpu_policy=dedicated \
  --property hw:mem_page_size=large

openstack flavor show m1.db.dedicated

hw:cpu_policy=dedicated는 전용 pCPU(Physical CPU, 물리 CPU)에 vCPU를 고정하는 정책이고, hw:mem_page_size=large는 큰 메모리 페이지 사용을 요청합니다. 단, Huge Pages는 호스트 커널과 libvirt/KVM 쪽 준비가 필요합니다. 지원되지 않는 환경에서 무작정 넣으면 VM 생성이 실패할 수 있습니다.

가상 머신 최적화: 작은 VM 여러 대 vs 큰 VM 한 대

가상 머신 최적화에서 자주 나오는 고민이 있습니다. “2 vCPU VM 여러 대가 나을까, 8 vCPU VM 한 대가 나을까?” 정답은 워크로드에 따라 다릅니다. 웹/API 서버처럼 stateless(상태를 서버에 많이 저장하지 않는 구조)에 가까우면 작은 VM을 여러 대 두고 로드밸런서로 나누는 편이 운영상 편했습니다. 장애 격리도 좋고, 배포 롤백도 덜 무섭습니다.

반대로 DB처럼 상태가 크고 디스크 I/O가 중요한 서비스는 무작정 쪼개기 어렵습니다. 이 경우에는 메모리와 디스크 경로를 먼저 보고, 필요하면 전용 CPU 정책이나 빠른 Cinder Volume(신더 볼륨, OpenStack 블록 스토리지)을 붙이는 식으로 접근합니다.

1. 먼저 애플리케이션의 병목 후보를 정합니다. CPU인지, 메모리인지, 디스크인지 구분합니다.
2. 작은 기본 플레이버로 시작하되, 모니터링 지표를 붙입니다.
3. 피크 시간대에 CPU iowait, 메모리 swap, 디스크 await 같은 값을 확인합니다.
4. 증설이 필요하면 같은 계열의 다음 플레이버로 올립니다.
5. 계속 같은 병목이 반복되면 플레이버 문제가 아니라 애플리케이션 구조나 스토리지 설계를 다시 봅니다.

추천하는 방식은 “처음부터 대형 플레이버”가 아니라 계열을 나눠 점진적으로 올리는 방식입니다. 예를 들어 web.small → web.medium → web.large처럼 같은 성격 안에서만 키우면 운영자가 판단하기 쉽습니다. 이거 진짜 편하더라고요.

점검 명령어: VM 내부와 OpenStack 외부를 같이 보기

플레이버가 적절한지 보려면 VM 내부 지표와 OpenStack 외부 상태를 같이 봐야 합니다. VM 안에서는 리눅스 성능 도구를 씁니다. 아래 명령어는 대부분의 리눅스 서버에서 sysstat 패키지를 설치하면 사용할 수 있습니다.

# CPU 사용률과 iowait 확인
sar -u 1 5

# 디스크 서비스 시간, 대기열, 사용률 확인
iostat -x 1 5

# 프로세스별 CPU/메모리/디스크 사용 확인
pidstat -urd 1 5

# 메모리와 swap 확인
free -h

해석은 이렇게 합니다. sar에서 %iowait가 계속 눈에 띄게 높다면 CPU가 부족하다기보다 디스크 응답을 기다리는 쪽을 의심합니다. iostat -x에서는 await, %util, r/s, w/s를 함께 봅니다. %util이 계속 높은데 await도 같이 늘면 스토리지 병목 가능성이 커집니다. free -h에서 swap 사용량이 증가하고 줄지 않는다면 메모리 플레이버를 올리거나 애플리케이션 메모리 설정을 줄여야 합니다.

OpenStack 쪽에서는 현재 하이퍼바이저 자원 상태와 VM 배치를 확인합니다. 일부 명령은 관리자 권한이 필요할 수 있습니다.

openstack hypervisor list
openstack hypervisor stats show
openstack server list --all-projects --long
openstack server show <SERVER_ID>

여기서 보는 핵심은 “한 Compute Node에 특정 유형 VM이 몰렸는가”입니다. CPU 집약형 VM이 한 노드에 너무 몰리면 개별 VM 스펙은 정상이어도 전체 성능이 흔들릴 수 있습니다. 이때는 Availability Zone(가용 영역), Host Aggregate(호스트 집합), Flavor Extra Specs를 조합해서 배치 정책을 나누는 쪽을 검토합니다.

주의사항과 트러블슈팅: 자주 헷갈리는 부분

OpenStack 플레이버 설계에서 가장 많이 하는 실수는 “플레이버 이름만 그럴듯하게 만든 것”입니다. m1.large라는 이름은 익숙하지만, 정작 어떤 워크로드용인지 아무도 모르면 시간이 지나면서 엉망이 됩니다. 그래서 이름에 목적을 넣는 편이 좋습니다. 예를 들면 m1.web.small, m1.db.memory, m1.batch.cpu처럼요.

• VM 생성 실패: Extra Specs가 호스트 기능과 맞지 않을 때 발생합니다. flavor show와 nova-compute 로그를 같이 봅니다.
• 디스크가 느림: vCPU 증설로 해결되지 않습니다. Cinder 백엔드, 볼륨 타입, 게스트 파일시스템, iostat 지표를 확인합니다.
• 메모리가 부족함: swap이 늘면 체감 성능이 급격히 나빠집니다. RAM 증설 또는 애플리케이션 heap 설정을 조정합니다.
• CPU를 많이 줬는데도 느림: CPU steal, iowait, 스레드 병렬성, 애플리케이션 락을 같이 봐야 합니다.

재현 가능한 시나리오 하나를 들어보겠습니다. 웹 서버 VM에 2 vCPU, 4GB RAM을 주고 운영했는데 피크 시간에 응답이 느려졌습니다. 처음에는 CPU가 부족한 줄 알고 4 vCPU로 올렸습니다. 그런데 개선이 애매했습니다. 다시 보니 sar에서 iowait가 계속 보였고, iostat에서는 디스크 대기가 늘어났습니다. 원인은 로그가 같은 루트 디스크에 과하게 쌓이는 구조였고, 별도 볼륨으로 로그 경로를 분리하니 훨씬 안정됐습니다.

검증과 결과: 플레이버 변경 후 확인할 것

플레이버를 바꿨다면 “VM이 켜졌다”에서 끝내면 안 됩니다. 저는 최소한 아래 순서로 확인합니다. 특히 resize 이후에는 환경에 따라 confirm 단계가 필요할 수 있으니 운영 정책도 같이 확인하세요.

1. VM 생성 또는 resize(크기 변경)가 정상 완료됐는지 확인합니다.
2. 게스트 OS에서 CPU, 메모리, 디스크가 기대한 값으로 보이는지 확인합니다.
3. 애플리케이션 로그에 오류나 타임아웃이 늘지 않았는지 봅니다.
4. 피크 시간대 지표를 이전과 비교합니다.
5. 동일 계열 VM 여러 대의 편차가 크지 않은지 확인합니다.

openstack server resize --flavor m1.api.medium <SERVER_ID>
openstack server resize --confirm <SERVER_ID>

# VM 내부에서 확인
nproc
free -h
lsblk

결과 해석 기준은 간단하게 잡아두면 좋습니다. CPU 사용률이 피크 시간에만 높고 요청 지연이 없다면 굳이 올리지 않아도 됩니다. 메모리는 swap이 생기는지, 디스크는 iowait와 await가 함께 나빠지는지 봅니다. 네트워크는 대역폭뿐 아니라 인터페이스 오류, retransmission(재전송)도 같이 봐야 합니다.

CPU, 메모리, 디스크 I/O 지표를 기준으로 플레이버 변경 전후를 비교하는 검증용 대시보드 예시입니다.

자주 묻는 질문: OpenStack 플레이버 설계 FAQ

Q1. 플레이버는 몇 종류로 시작하는 게 좋나요?

처음부터 너무 많이 만들지 않는 걸 추천합니다. 웹/API용 2~3개, 메모리 중심 1~2개, CPU 중심 1~2개 정도로 시작하고 실제 사용 패턴을 보면서 늘리는 편이 관리하기 쉽습니다.

Q2. dedicated CPU는 무조건 좋은 선택인가요?

아닙니다. 지연 시간에 민감하거나 성능 격리가 중요한 VM에는 도움이 될 수 있지만, 전체 클러스터 효율은 떨어질 수 있습니다. 호스트의 전용 CPU 구성과 운영 정책이 준비된 경우에만 쓰는 게 좋습니다.

Q3. 디스크 크기를 크게 잡으면 성능도 좋아지나요?

대부분의 경우 단순 디스크 용량과 성능은 별개로 봐야 합니다. 성능은 스토리지 백엔드, 볼륨 타입, 캐시 정책, I/O 패턴 영향을 더 많이 받습니다.

마무리: 워크로드별 추천 기준

OpenStack에서 VM 구성을 잘 잡고 싶다면 플레이버를 “사이즈”가 아니라 “운영 정책”으로 봐야 합니다. 이 관점이 잡히면 OpenStack 플레이버 설계가 훨씬 쉬워집니다.

• 웹/API 서버라면 작은 VM 여러 대와 수평 확장을 우선 추천합니다.
• DB 서버라면 메모리, 디스크 I/O, 볼륨 타입을 먼저 보고 필요할 때 전용 CPU를 검토하세요.
• 배치 작업이라면 실행 시간대와 동시성 기준으로 CPU형 플레이버를 따로 두는 게 좋습니다.
• 네트워크 장비형 VM이라면 CPU 정책, 인터럽트, 드라이버, 패킷 처리량을 함께 봐야 합니다.

제 기준에서는 기본 플레이버를 작고 명확하게 시작한 뒤, 관측 지표를 보고 계열을 늘리는 방식이 가장 덜 아팠습니다. 한 번에 완벽한 표준안을 만들려고 하면 오히려 오래 걸리더라고요. 다음 글에서는 Host Aggregate와 Availability Zone을 이용해서 특정 플레이버를 특정 Compute Node 그룹에 배치하는 방법을 다룰 예정입니다. 이전 글에서 다룬 OpenStack 네트워크 기본 구조도 함께 참고하면 흐름이 더 잘 이어질 겁니다.

웹, DB, 배치, 네트워크형 VM을 어떤 기준으로 나눌지 한눈에 정리한 요약 이미지입니다.