오픈스택이 아직도 프라이빗 클라우드의 기본값인 이유

퍼블릭 클라우드로 다 옮기지 못하는 이유는 대개 규제, 지연시간, 비용 셋 중 하나다. OpenStack(오픈스택)이 프라이빗·하이브리드 IaaS(Infrastructure as a Service) 표준 자리를 오래 지키고 있는 것도 이 세 조건이 사라지지 않기 때문이다. 컴퓨트·네트워크·스토리지 자원을 API 중심으로 통합하고 멀티 벤더 하드웨어와 연동하는 개방형 아키텍처 위에서, 대규모 확장성과 강한 격리, 자동화로 기업형 워크로드를 유연하게 운영할 수 있게 해준다.

하나의 플랫폼이 아니라 서비스 집합이다

OpenStack은 오픈 소스 IaaS 프레임워크이자 서비스 집합이다. Nova(컴퓨트), Neutron(네트워크), Cinder/Swift(스토리지), Keystone(아이덴티티), Glance(이미지), Horizon(대시보드), Heat(오케스트레이션), Ironic(베어메탈)이 각자 독립 모듈로 존재한다. 컨트롤 플레인과 데이터 플레인을 분리한 구조이고, AMQP 메시지 브로커(RabbitMQ 등)와 RDBMS(MariaDB/Galera 등)를 백본으로 쓰는 마이크로서비스 아키텍처다. API 우선 설계 위에 멀티테넌시와 프로젝트·도메인 분리, 롤 기반 접근제어(RBAC), 쿼터·Placement 기반 자원 스케줄링이 얹힌다.

컴퓨트: 스케줄링이 먼저, 실행은 그다음

Nova는 셀 v2 구조와 Placement 서비스로 자원 가용성·적합성을 먼저 평가한다. NUMA·CPU 핀 고정·HugePages·GPU/FPGA 가속기, 라이브 마이그레이션까지 지원하고, KVM/QEMU 기반 가상화를 중심으로 베어메탈(Ironic)과 연동해 혼합 워크로드를 수용한다.

네트워킹: 백엔드 선택이 성능과 운영 복잡도를 가른다

Neutron은 ML2 플러그인과 OVS/OVN, SR-IOV/DPDK 등 백엔드를 선택할 수 있다. L2/L3, DHCP, Security Group, Floating IP, LBaaS(Octavia), FWaaS를 제공하고, 포트 바인딩과 에이전트 기반 파이프라인, 컨트롤러 HA 구성으로 대규모 테넌트 격리를 달성한다.

백엔드	성능	확장성	일관성	안정성	운영 편의
ML2/OVS	중간, CPU 오버헤드 존재	중간	에이전트 기반, 구성 다양성 높음	성숙	문서/커뮤니티 풍부, 트러블슈팅 용이
OVN	중~상, 오프로드 옵션	상, 컨트롤 플레인 효율	중앙집중 상태로 예측 가능	성숙도 지속 상승	정책 기반, 플로우 단순화
SR-IOV(+DPDK)	매우 높음, 네이티브 I/O	중, 하드웨어 의존	호스트 바인딩에 강결합	하드웨어 안정성 영향	운영 복잡, 라이브 마이그레이션 제약

선정 기준은 워크로드 특성(대역폭·지연), 운영 인력 숙련도, 하드웨어 오프로드 가용성, 라이브 마이그레이션 요구 수준이다.

스토리지: 블록·오브젝트·파일을 나눠 붙인다

블록 스토리지는 Cinder가 LVM·NFS·FC·Ceph RBD 등을 백엔드로 붙이고, 오브젝트는 Swift나 Ceph RGW, 파일은 Manila가 NFS·SMB로 맡는다. 스냅샷·백업·복제 정책과 QoS, 멀티 AZ 구성을 지원하고, 이미지 서비스(Glance)는 볼륨 부팅·이미지 캐싱과 통합돼 있다.

아이덴티티와 백본, 관측·자동화

Keystone이 인증·인가를 맡고 페더레이션(OIDC/SAML) 연동을 지원하며, Horizon 대시보드와 OpenStackClient가 관리 인터페이스를 제공한다. 메시지 큐(RabbitMQ Quorum, 최신 정보 확인 필요)와 DB 클러스터(Galera)를 이중화해 컨트롤 플레인의 내고장성을 확보한다.

텔레메트리(Ceilometer/Gnocchi)와 알람(Aodh)이 로깅·메트릭을 통합하고, Heat·Mistral이 IaC와 워크플로 자동화를 맡는다. 배포 프레임워크로는 Kolla-Ansible, OpenStack-Ansible, Kayobe 등이 쓰이며 롤링 업그레이드·블루그린 전략을 지원하지만, 도구 호환성은 릴리스별로 달라 그때그때 확인이 필요하다.

요청 하나가 인스턴스가 되기까지

⤢✕

요청은 이미지·플래버·네트워크·볼륨과 인증 토큰을 입력으로 받아, Nova 스케줄링 → Placement 적합성 평가 → Neutron 포트 바인딩 → Cinder 볼륨 준비 → QEMU 인스턴스 생성 순서로 처리되고, 인스턴스 가동과 IP/FIP 할당, 모니터링 이벤트 발생으로 이어진다.

에러 처리도 계층별로 정해져 있다. 인증 실패는 Keystone 토큰 재발급이나 IdP 교정으로, 스케줄 실패는 쿼터·가용성 확인 후 호스트 애그리게이트·AZ 조정으로, 네트워크 바인딩 실패는 포트 상태와 ML2 에이전트·OVN 컨트롤러 헬스 체크로, 볼륨 연결 실패는 백엔드 도달성·멀티패스·권한 검증과 재시도·포스 디태치로 대응한다.

프로비저닝 절차: 입력, 처리, 출력

입력은 이미지 선택(Glance), 플래버·NUMA/HugePage/CPU 핀 정책, 네트워크·보안그룹·키페어, 부팅 소스(볼륨·이미지)다. 처리는 Keystone 인증 → Nova 요청 수신 → Placement 후보군 필터링 → 스케줄 확정 → Neutron 포트 생성·바인딩(OVN/OVS/SR-IOV) → Security Group 규칙 인스톨 → Cinder 볼륨 생성·맵핑 → Nova libvirt 도메인 정의 → QEMU/KVM 부팅 → 클라우드이닛 메타데이터 주입 순서로 진행된다. 출력은 프라이빗 IP와 선택적 Floating IP 연결, 텔레메트리 이벤트, 로깅, 상태 헬스 리포트다. 셀프서비스 포털을 통해 이 절차를 자동화하면 프로비저닝 리드타임이 시간 단위에서 분 단위로 줄어들고, DevSecOps 파이프라인의 변동 수요 대응성도 함께 올라간다.

Nova/Neutron/Cinder 간 워크플로는 분산돼 있고 최종적 일관성 모델을 따르므로, MQ 재시도와 아이템포턴시 키 사용이 권장되며, 롤백 시 포트·볼륨 잔존 리소스를 가비지 컬렉션하는 주기 운영 정책이 필요하다.

배포 예시와 명령 실행

전제조건은 OpenStack 2024.1(Caracal) 환경, ML2/OVN 네트워킹, Cinder=Ceph RBD, openstackclient 설치·인증 설정 완료(환경 변수 로드)다. 네임스페이스는 예시 목적이며 실제 환경에서는 명명 규칙을 따로 준수해야 한다.

# 네트워크/서브넷/라우터
openstack network create proj-net
openstack subnet create --network proj-net --subnet-range 10.10.0.0/24 proj-subnet
openstack router create proj-rtr
openstack router add subnet proj-rtr proj-subnet
openstack router set --external-gateway public proj-rtr

# 키페어/보안그룹
openstack keypair create --public-key ~/.ssh/id_rsa.pub proj-key
openstack security group rule create --proto tcp --dst-port 22 default
openstack security group rule create --proto icmp default

# 이미지/플레이버
openstack image create --disk-format qcow2 --container-format bare \
  --file ubuntu-22.04.qcow2 ubuntu-22.04
openstack flavor create m1.small --vcpus 2 --ram 4096 --disk 20

# 부팅(볼륨에서)
openstack server create --flavor m1.small --image ubuntu-22.04 \
  --key-name proj-key --network proj-net --boot-from-volume 20 vm01

# Floating IP 할당
openstack floating ip create public
openstack server add floating ip vm01 <ALLOCATED_FIP>

볼륨형 부팅을 권장하는 이유는 호스트 로컬 디스크 의존도를 줄이고 마이그레이션을 쉽게 만들기 때문이다. 메타데이터·클라우드이닛 스크립트로 에이전트리스 초기설정을 구현하는 것도 실무에서 자주 쓰는 방식이다.

실제로 쓰이는 곳

프라이빗 클라우드 현대화에서는 vSphere·테넌트 분리의 한계를 API 기반 셀프서비스로 해소하고, 코스트옵스와 쇼백·차지백을 도입하며 표준 이미지·플레이버 카탈로그를 운영한다. 이 표준 API·오픈 아키텍처로 멀티 벤더 전략을 실현하면 상용 하이퍼바이저 대비 TCO를 20~40% 절감할 수 있다(환경별 상이). 텔코·NFV와 엣지에서는 SR-IOV·NUMA·핀닝으로 초저지연 VNF/CNF를 혼합 운용하고, 리전·셀을 분산해 경량 컨트롤 플레인과 원격 컴퓨트 존을 구성한다. HPC·AI/ML 가속에서는 GPU 패스스루, MIG, 멀티-NIC 바인딩을 쓰고 데이터 로컬리티를 고려해 Ceph나 고속 인터커넥트를 구성한다. 이런 구성으로 OpenStack은 수백 호스트·수천 인스턴스 규모 운영이 실제로 검증된 아키텍처이며, 실패 도메인 분리와 셀 구조로 장애 격리·복구 탄력성까지 함께 강화한다.

트레이드오프는 미리 검증해야 한다

컨트롤 플레인 HA는 MQ Quorum Queue, Galera 3노드 이상, API 엔드포인트 LB 이중화로 확보하는데, 일관성·복구 시간이 좋아지는 대신 운영 복잡도와 리소스가 늘어난다. 네트워크 격리와 성능은 테넌트 네임스페이스·보안그룹을 최소 권한으로 설계하고 east-west 트래픽 경로를 최적화해야 하지만, SR-IOV를 채택하면 라이브 마이그레이션이 제한돼 운영 융통성이 떨어진다. 스토리지는 Ceph(RBD/RGW)로 블록·오브젝트를 통합하고 장애 도메인을 분리하는 게 기본이지만, 고성능 로컬 NVMe를 쓴다면 데이터 내구성·이중화 설계를 별도로 보완해야 한다. 업그레이드는 릴리스 노트 기반으로 마이너에서 메이저로 점증하고 Canary 리전을 두는 게 정석인데, 배포 툴 체계(Kolla-Ansible 등)의 릴리스 호환성은 매번 확인이 필요하다(최신 정보 확인 필요).