OpenStack을 처음 보면 Nova, Neutron, Cinder, Keystone, Glance… 낯선 이름에 압도됩니다. 하지만 각각이 “클라우드의 한 부품”이라고 생각하면 의외로 명료합니다. 제가 홈랩 랩에서 공부하며 정리한, 핵심 컴포넌트 지도를 공유합니다.
1. 컴포넌트 한눈에
컴포넌트
역할
익숙한 비유
Keystone
인증·권한(Identity)
로그인·출입증
Glance
OS 이미지 저장소
설치 ISO 창고
Nova
컴퓨트(인스턴스 생성)
VM을 찍어내는 공장
Neutron
네트워킹(가상 네트워크)
가상 스위치·라우터
Cinder
블록 스토리지(볼륨)
붙였다 뗐다 하는 디스크
Horizon
웹 대시보드
관리 콘솔
여기에 오브젝트 스토리지 Swift, 오케스트레이션 Heat 등이 더 있지만, 위 6개가 “인스턴스 하나 띄우기”의 핵심입니다.
2. 인스턴스 하나 띄울 때 무슨 일이 벌어지나
컴포넌트가 어떻게 맞물리는지는 “VM 하나 생성” 흐름을 따라가면 단번에 이해됩니다.
1) 사용자 → Keystone 에 로그인 → 토큰 발급 (이후 모든 요청에 사용)
2) Nova 에 "인스턴스 생성" 요청
3) Nova → Glance 에서 OS 이미지 가져옴
4) Nova → Neutron 에 네트워크/포트 요청 (IP 할당)
5) (선택) Nova → Cinder 에서 볼륨 붙임
6) Nova 스케줄러가 적당한 compute 노드 선택 → VM 부팅
7) Horizon 대시보드에서 상태 확인
즉 Keystone(인증)으로 문을 열고 → Nova(컴퓨트)가 지휘하면서 → Glance(이미지)·Neutron(네트워크)·Cinder(볼륨)를 불러다 조립하는 구조입니다. 이 흐름 하나만 머리에 넣으면 나머지가 술술 풀립니다.
컴퓨트 노드: Nova-compute·Neutron 에이전트 — 실제 인스턴스가 여기서 돎
스토리지: Cinder 백엔드(LVM/Ceph 등)
그래서 컨트롤러는 CPU·메모리를, 컴퓨트는 인스턴스용 자원을 더 챙겨줘야 합니다. 제 랩에서 컴퓨트 노드에 RAM을 더 준 이유가 이것입니다.
4. 공부 순서 추천
Keystone부터: 인증이 안 되면 아무것도 안 됩니다. 토큰·프로젝트·롤 개념 먼저.
Glance → Nova: 이미지 올리고 인스턴스 하나 띄워보기(성취감 큼).
Neutron: 가장 어렵습니다. 네트워크가 되면 절반은 끝난 것.
Cinder: 볼륨 붙이기까지 하면 기본은 완성.
5. 정리
OpenStack은 이름이 많아 겁나 보이지만, “인증(Keystone) → 컴퓨트(Nova)가 이미지·네트워크·볼륨을 조립”이라는 큰 그림 하나면 충분히 잡힙니다. 각 컴포넌트를 따로 외우지 말고, 인스턴스 생성 흐름 속에서 이해하세요. 홈랩 랩에서 직접 인스턴스를 한 번 띄워보면 이 모든 게 손에 익습니다.
OpenStack Ceph 성능 장애는 보통 아주 평범한 증상으로 시작합니다. 인스턴스 부팅이 길어지고, 볼륨 attach가 가끔 멈칫하고, Glance 이미지 업로드가 어느 날부터 오래 걸리죠. 사용자 입장에서는 전부 VM 디스크가 느리다고 느끼지만, 운영자 입장에서는 Ceph OSD가 느린지, OpenStack 서비스가 RBD를 제대로 쓰는지, compute node 네트워크가 막히는지, recovery/backfill이 정상적으로 자원을 쓰는지까지 같이 봐야 합니다.
저는 OpenStack과 Ceph를 같이 볼 때 튜닝값을 먼저 만지지 않는다는 원칙을 꽤 강하게 지킵니다. 특히 운영 환경에서는 osd_max_backfills, osd_recovery_max_active, rbd_cache 같은 값을 감으로 바꾸면 일시적으로 숫자는 좋아져도 장애 반경이 넓어질 수 있거든요. 먼저 병목 위치를 좁히고, 그다음에 설정을 조정해야 합니다.
이 글은 공식 문서식 옵션 나열이 아니라, 실제 장애 대응 순서에 가깝게 구성했습니다. 느리다는 말을 들었을 때 어떤 명령어를 먼저 치고, 어떤 로그를 같이 열고, 어떤 경우에는 Ceph가 아니라 Nova/Cinder/Glance를 의심해야 하는지에 초점을 맞춥니다.
OpenStack Nova, Cinder, Glance가 Ceph RBD 풀과 연결되는 구조를 한눈에 보는 개요 이미지입니다.
OpenStack에서 Ceph 병목이 헷갈리는 이유
OpenStack은 Ceph를 단순한 외장 스토리지처럼 쓰지 않습니다. Nova는 VM ephemeral disk를 RBD에 둘 수 있고, Cinder는 volume을 RBD image로 만들고, Glance는 base image를 Ceph pool에 저장할 수 있습니다. 이 셋이 같은 Ceph 클러스터를 쓰더라도 병목 지점은 서로 다릅니다.
Nova 병목: VM 생성, 부팅, live migration, libvirt secret, compute node의 RBD 접속 경로에서 드러납니다.
Ceph 병목: OSD latency, PG 상태, recovery/backfill, full/nearfull, 네트워크 손실, CRUSH 배치 문제로 드러납니다.
현장에서 자주 본 실패 패턴은 HEALTH_OK니까 Ceph는 아니라고 너무 빨리 결론 내리는 경우였습니다. HEALTH_OK는 클러스터의 일관성과 위험 상태를 보는 신호에 가깝지, 모든 OSD가 빠르고 모든 클라이언트 경로가 정상이라는 보장은 아닙니다. 반대로 HEALTH_WARN이 있어도 실제 사용자 지연의 직접 원인은 libvirt secret 불일치일 수 있습니다. 그래서 Ceph와 OpenStack을 항상 나란히 봐야 합니다.
Ceph 병목을 잡는 첫 10분: 범위를 먼저 자르세요
처음부터 fio를 돌리거나 설정값을 바꾸지 마세요. 저는 먼저 영향을 받는 범위를 세 가지 질문으로 자릅니다.
모든 VM이 느린가, 특정 compute node의 VM만 느린가?
볼륨 작업만 느린가, 이미지 부팅과 업로드도 같이 느린가?
Ceph에서 recovery/backfill/scrub 같은 내부 작업이 돌고 있는가?
이 질문에 답하면 조사 방향이 빨라집니다. 전체 VM이 느리면 Ceph cluster, OSD, 네트워크를 봅니다. 특정 compute node만 느리면 해당 노드의 ceph.conf, keyring, libvirt secret, NIC 오류를 먼저 봅니다. 볼륨 생성만 느리면 Cinder backend와 volumes pool을 봐야지 Nova 설정부터 만지는 건 순서가 아닙니다.
# 컨트롤러 또는 Ceph admin 노드에서 1차 확인
ceph -s
ceph health detail
ceph osd tree
ceph osd df tree
ceph pg stat
ceph osd perf
ceph osd pool stats
# OpenStack 관점에서 영향 범위 확인
openstack server list --all-projects --long
openstack volume list --all-projects --long
openstack image list --long
openstack hypervisor list
openstack compute service list
openstack volume service list
ceph -s에서 recovery, backfill, degraded, undersized, peering 같은 단어가 보이면 성능 저하가 자연스럽게 따라올 수 있습니다. 이때 중요한 건 왜 그런 상태가 됐는지입니다. OSD 하나가 내려갔는지, 디스크 교체 후 재분산 중인지, full ratio에 가까운 OSD가 있는지, 네트워크가 흔들렸는지까지 연결해서 봐야 합니다.
Ceph OSD 지연은 단독 숫자가 아니라 편차로 봅니다
ceph osd perf는 OSD별 commit/apply latency를 보여줍니다. 여기서 가장 위험한 해석은 몇 ms 이상이면 무조건 장애처럼 외부 숫자를 그대로 가져오는 겁니다. HDD, SSD, NVMe, replication size, network, BlueStore DB/WAL 구성에 따라 정상 범위가 달라집니다. 대신 같은 장비군에서 특정 OSD만 지속적으로 튀는지, latency 상승과 iostat의 대기열 증가가 같이 움직이는지를 봐야 합니다.
# Ceph 쪽 편차 확인
ceph osd perf
ceph osd df tree
ceph osd pool stats
# 특정 OSD 호스트에서만 확인합니다. admin socket이 있는 노드에서 실행해야 합니다.
ceph daemon osd.0 perf dump | less
# 운영 중 bench 명령은 부하를 만들 수 있으니 점검 창에서만 사용하세요.
ceph tell osd.0 bench
# OSD 호스트에서 디스크와 CPU 확인
iostat -x 1
sar -n DEV 1
sar -u 1
vmstat 1
journalctl -k --since '1 hour ago'
iostat -x에서는 await, aqu-sz, %util, r_await, w_await를 같이 봅니다. %util이 높고 aqu-sz가 커지면서 await도 같이 오르면 디스크 대기열이 밀리는 그림입니다. 반대로 디스크는 한가한데 Ceph latency만 높다면 네트워크, CPU, OSD 프로세스, RocksDB/WAL 장치, 또는 클라이언트 경로를 더 봐야 합니다.
특정 OSD만 튄다면 바로 out 처리하기보다 먼저 원인을 확인하세요. 커널 로그에 I/O error가 있으면 디스크/컨트롤러 쪽 가능성이 커지고, NIC drop이 같이 보이면 네트워크 쪽입니다. OSD가 있는 호스트의 CPU steal이나 softirq가 높으면 스토리지 문제가 아니라 호스트 자원 경합일 수 있습니다.
OSD latency, iostat, 네트워크 지표를 나란히 비교하며 병목 지점을 좁히는 장면입니다.
Nova, Cinder, Glance 설정은 같은 Ceph를 보는가부터 확인합니다
OpenStack Ceph 연동에서 의외로 많은 문제는 Ceph 성능이 아니라 설정 일관성에서 생깁니다. Glance는 Ceph RBD에 이미지를 저장하는데 Nova는 로컬 파일 기반으로 부팅한다든지, Cinder와 Nova가 서로 다른 user/keyring을 본다든지, compute node마다 /etc/ceph/ceph.conf 내용이 다른 식입니다. 이거 진짜 자주 나옵니다.
rbd_flatten_volume_from_snapshot = false는 clone 기반 흐름을 살려 생성 속도를 빠르게 가져갈 수 있지만, clone depth가 깊어지면 나중에 읽기 경로가 복잡해질 수 있습니다. rbd_max_clone_depth는 그 균형점입니다. 볼륨 생성 속도가 중요하고 snapshot 계층이 잘 관리된다면 clone을 적극적으로 쓰는 편이 유리합니다. 반대로 오래된 snapshot에서 파생된 볼륨이 많이 쌓이고 삭제 정책이 느슨한 환경이라면 flatten 전략을 더 보수적으로 잡아야 합니다.
rbd_secret_uuid는 libvirt secret과 정확히 맞아야 합니다. 예시 UUID를 그대로 쓰면 안 됩니다. 실제 compute node에서 virsh secret-list와 virsh secret-dumpxml로 확인해야 합니다. rbd_volume_local_attach는 RBD Cinder volume을 QEMU의 native RBD 경로가 아니라 compute host의 block device로 붙이는 Nova workaround 옵션입니다. 기본값처럼 false로 두는 구성이 일반적이지만, 배포판과 암호화 볼륨 요구사항에 따라 판단해야 합니다.
Glance를 RBD에 두면 Nova가 base image를 clone하는 흐름을 만들기 쉬워집니다. 다만 이미지 변환이 필요한 포맷을 무분별하게 올리면 업로드나 부팅 경로에서 예기치 않은 지연이 생길 수 있습니다. 운영 기준으로는 Glance 이미지 포맷, Nova images_type, Cinder backend가 한 방향으로 맞아야 합니다. 이미지 저장소는 file, VM은 rbd, volume은 rbd처럼 섞인 구성이 꼭 틀린 건 아니지만, 장애 때 확인해야 할 경로가 늘어납니다.
서비스 계정으로 직접 Ceph에 붙어보면 빠르게 걸러집니다
운영자가 admin keyring으로 ceph -s를 쳐서 성공하는 것과 Nova/Cinder/Glance가 자기 계정으로 RBD pool에 접근하는 것은 완전히 다른 이야기입니다. 장애 대응 때는 반드시 서비스 계정으로 직접 확인해보는 편이 좋습니다.
# compute node에서 Nova 계정 확인
ceph -n client.nova --keyring /etc/ceph/ceph.client.nova.keyring -s
rbd -n client.nova --keyring /etc/ceph/ceph.client.nova.keyring -p vms ls
# cinder-volume 노드에서 Cinder 계정 확인
ceph -n client.cinder --keyring /etc/ceph/ceph.client.cinder.keyring -s
rbd -n client.cinder --keyring /etc/ceph/ceph.client.cinder.keyring -p volumes ls
# glance-api 노드에서 Glance 계정 확인
ceph -n client.glance --keyring /etc/ceph/ceph.client.glance.keyring -s
rbd -n client.glance --keyring /etc/ceph/ceph.client.glance.keyring -p images ls
# libvirt secret 확인
virsh secret-list
virsh secret-dumpxml 00000000-0000-0000-0000-000000000000
여기서 실패하면 Ceph 튜닝은 잠시 내려놓고 인증과 권한을 봐야 합니다. 흔한 원인은 keyring 파일 경로 불일치, 파일 권한, CephX caps 부족, secret UUID 오타, 배포 자동화가 일부 노드에만 반영된 경우입니다. 특히 compute node가 여러 대일 때는 문제 없는 노드와 느린 노드의 /etc/ceph 디렉터리, Nova 설정, libvirt secret을 비교하면 빠릅니다.
스토리지 트러블슈팅을 위한 병목 유형별 판단 기준
아래 표는 실제 점검할 때 쓰는 분류에 가깝습니다. 한 줄짜리 정답표는 아니지만, 어디부터 볼지 정하는 데는 꽤 도움이 됩니다.
증상
같이 볼 지표
가능성이 큰 원인
먼저 할 조치
피해야 할 대응
전체 VM 디스크 I/O가 느림
ceph -s, ceph osd perf, iostat -x
OSD 지연, recovery/backfill, 네트워크 혼잡
느린 OSD와 내부 작업 여부를 먼저 분리
Nova 설정부터 무작정 변경
특정 compute node의 VM만 느림
sar -n DEV, journalctl -u nova-compute, virsh secret-list
compute node 네트워크, keyring, libvirt secret
정상 노드와 ceph.conf/keyring/secret 비교
Ceph 클러스터 전체 재시작
볼륨 생성·삭제가 오래 걸림
Cinder 로그, ceph osd pool stats, RBD clone depth
Cinder backend 부하, snapshot/clone 누적, pool 병목
Cinder service 상태와 volumes pool I/O 확인
사용자 VM fio 테스트로만 판단
이미지 업로드나 첫 부팅이 느림
Glance 로그, image format, Nova images_type
Glance 저장소 경로, 이미지 변환, RBD clone 미사용
Glance default store와 Nova RBD 설정 일관성 확인
OSD 교체부터 검토
평소에는 괜찮다가 특정 시간대만 느림
scrub/deep-scrub, backup, snapshot 작업 로그
예약 작업과 클라이언트 I/O 경합
작업 시간대와 Ceph 내부 작업 스케줄 조정
일시 현상으로 방치
Ceph 최적화 튜닝값은 목적별로 다르게 접근해야 합니다
Ceph 성능 글에서 자주 보이는 실수는 이 값을 올리면 빨라진다는 식의 단정입니다. 실제 운영에서는 값 하나가 성능, 복구 속도, 사용자 I/O 안정성을 동시에 흔듭니다. 특히 OpenStack은 사용자 VM이 계속 I/O를 내고 있으므로, 복구를 빠르게 끝내는 것과 사용자 지연을 줄이는 것 사이에서 선택해야 합니다.
결정 지점
A를 선택할 때
B를 선택할 때
운영 판단
recovery/backfill 속도
장애 복구를 빨리 끝내야 할 때
업무 시간 사용자 I/O를 보호해야 할 때
업무 시간에는 보수적으로, 점검 창에서는 적극적으로 조정
Glance RBD 사용
Nova/Cinder도 Ceph를 쓰고 이미지 clone 경로를 단순화하고 싶을 때
이미지 저장소를 별도로 운영하고 Ceph 부하를 분리하고 싶을 때
Ceph 기반 OpenStack은 Glance도 RBD로 맞추면 운영이 단순해지는 경우가 많습니다
pool 분리
images, vms, volumes의 성격과 장애 분석을 나누고 싶을 때
작은 테스트 환경이라 관리 단순성이 더 중요할 때
운영 환경에서는 최소한 images/vms/volumes는 분리하는 쪽을 권합니다
SSD/NVMe 혼합
워크로드별 CRUSH rule과 pool을 나눌 수 있을 때
장비 수가 적고 장애 도메인이 충분하지 않을 때
빠른 디스크를 섞기만 하면 평균이 좋아지는 게 아니라 예측성이 나빠질 수 있습니다
제가 겪은 대표 삽질: Ceph는 멀쩡한데 VM만 느린 경우
한 번은 ceph -s가 멀쩡하고 OSD latency도 크게 튀지 않는데, 특정 compute node의 VM만 디스크가 굼뜨게 느껴진 적이 있습니다. 처음에는 Ceph 최적화 문제라고 생각했습니다. 그런데 정상 노드와 문제 노드를 비교해보니 /etc/ceph/ceph.conf 배포 시점이 달랐고, libvirt secret도 서로 맞지 않았습니다.
이런 경우에는 Ceph dashboard만 보면 놓칩니다. Ceph는 정상인데, OpenStack 서비스 계층에서 RBD를 제대로 잡지 못하는 상태이기 때문입니다. 저는 이런 케이스 이후로 compute node 단위 문제가 나오면 아래 명령을 거의 습관처럼 칩니다.
정상 노드와 문제 노드의 sha256sum이 다르면 배포 일관성부터 의심합니다. 물론 Ceph 설정 파일이 일부러 다를 수도 있지만, OpenStack compute node에서 의도치 않게 다른 MON 주소나 keyring을 보고 있다면 성능 문제가 아니라 구성 문제입니다. 이때는 튜닝보다 재배포와 서비스 재시작 순서를 차분히 잡는 게 낫습니다.
네트워크 병목은 대역폭보다 손실과 재전송을 먼저 봅니다
Ceph는 네트워크에 민감합니다. 그런데 운영자가 10GbE니까 괜찮겠지라고 생각하는 순간이 위험합니다. 대역폭이 충분해도 packet drop, MTU 불일치, bonding 설정 문제, 스위치 buffer 이슈가 있으면 RBD 클라이언트 입장에서는 지연으로 보입니다.
# OSD/compute node에서 NIC 오류와 처리량 확인
ip -s link
netstat -s | grep -Ei 'retrans|timeout|listen|segments retransmitted'
sar -n DEV 1
sar -n TCP,ETCP 1
# 경로와 MTU 확인
ip route
ip addr show
ping -M do -s 8972 CEPH_OSD_IP
MTU 9000을 쓰는 환경이라면 end-to-end로 맞아야 합니다. compute node, storage node, 스위치, bond, VLAN 어디 하나라도 다르면 큰 패킷이 깨지거나 경로에 따라 묘한 지연이 생깁니다. Jumbo frame은 제대로 맞추면 도움이 될 수 있지만, 반쯤 적용된 jumbo frame은 차라리 기본 MTU보다 나쁩니다. 저는 운영 안정성이 먼저인 환경에서는 모든 구간을 검증할 수 있을 때만 jumbo frame을 쓰는 쪽을 선호합니다.
검증은 고쳤다가 아니라 재현 조건에서 나아졌다로 해야 합니다
수정 후에는 단순히 HEALTH_OK만 보고 끝내지 않습니다. 같은 증상이 났던 경로를 다시 밟아야 합니다. 이미지 업로드가 문제였으면 Glance 경로를, 볼륨 attach가 문제였으면 Cinder와 Nova attach 경로를, 특정 compute node가 문제였으면 그 노드에서 새 VM을 띄워 봐야 합니다.
# Ceph 상태 재확인
ceph -s
ceph health detail
ceph osd perf
ceph osd pool stats
# RBD pool 확인
rbd -p images ls
rbd -p volumes ls
rbd -p vms ls
# OpenStack 리소스 흐름 확인
openstack image list --long
openstack volume list --all-projects --long
openstack server list --all-projects --long
# 최근 로그에서 timeout/auth/error 확인
journalctl -u nova-compute --since '30 minutes ago' | grep -Ei 'rbd|ceph|timeout|error|auth|secret'
journalctl -u cinder-volume --since '30 minutes ago' | grep -Ei 'rbd|ceph|timeout|error|auth'
journalctl -u glance-api --since '30 minutes ago' | grep -Ei 'rbd|ceph|timeout|error|auth'
운영 환경에서 무리한 쓰기 부하 테스트를 바로 돌리는 건 권하지 않습니다. 먼저 작은 테스트 VM과 테스트 볼륨으로 재현 경로를 확인하고, 업무 영향이 낮은 시간대에 점진적으로 부하를 올리는 편이 안전합니다. 스토리지는 한 번 흔들리면 넓게 흔들리는 영역이라서, 확인도 단계적으로 해야 합니다.
Nova, Cinder, Glance 서비스가 각각 vms, volumes, images 풀을 사용하는 구성을 보여주는 이미지입니다.
운영 체크리스트: 성능보다 먼저 무너지는 것들
pool 분리: 운영 환경에서는 images, vms, volumes pool을 분리해 원인 분석과 정책 적용을 쉽게 만듭니다.
CRUSH rule 확인: HDD, SSD, NVMe가 섞인 환경에서는 장치 class와 rule이 의도대로 적용되는지 확인합니다.
시간 동기화: 모든 컨트롤러, compute, storage node에서 chrony 또는 NTP 상태를 확인합니다.
복구 작업 정책: 업무 시간과 점검 시간의 recovery/backfill 정책을 다르게 가져갈지 결정합니다.
로그 보존: nova-compute, cinder-volume, glance-api, libvirt 또는 virtqemud, kernel 로그가 충분히 남도록 설정합니다.
배포 일관성: ceph.conf, keyring, libvirt secret이 모든 관련 노드에 동일하게 배포되는지 검증합니다.
여기서 제일 많이 과소평가되는 항목은 배포 일관성입니다. Ceph 자체가 아무리 튼튼해도 compute node 한 대가 오래된 ceph.conf를 보고 있으면 사용자에게는 OpenStack Ceph 성능 문제로 접수됩니다. 자동화 도구를 쓰더라도 실제 파일 checksum을 비교하는 습관이 도움이 됩니다.
Ceph health, OSD latency, OpenStack 리소스 상태가 안정화된 모습을 보여주는 검증 이미지입니다.
증상별 추천 경로: 이럴 땐 이렇게 보세요
모든 VM이 동시에 느려졌다면 Ceph cluster 상태, OSD latency, recovery/backfill, 네트워크 손실을 먼저 봅니다. 이 경우에는 개별 VM 안에서 fio를 오래 돌리는 것보다 클러스터 전체 지표를 보는 편이 빠릅니다.
특정 compute node의 VM만 느리다면 Ceph 전체 튜닝보다 해당 노드의 네트워크, /etc/ceph 파일, Nova 설정, libvirt secret을 먼저 비교하세요. 정상 노드와 문제 노드의 차이를 찾는 방식이 가장 빠릅니다.
볼륨 생성·삭제·attach만 느리다면 Cinder volume 서비스와 volumes pool을 봅니다. snapshot/clone이 많이 쌓인 환경이라면 clone depth와 flatten 정책도 같이 봐야 합니다.
이미지 업로드나 첫 부팅만 느리다면 Glance 저장소, 이미지 포맷, Nova의 RBD 사용 여부를 확인합니다. Glance와 Nova가 같은 Ceph 기반 흐름을 쓰지 않으면 불필요한 복사나 변환 경로가 끼어들 수 있습니다.
특정 시간대만 느리다면 백업, snapshot, scrub/deep-scrub, recovery 작업 시간표를 확인하세요. 이 경우에는 하드웨어 증설보다 작업 스케줄과 우선순위 조정이 먼저일 수 있습니다.
자주 묻는 질문
Q. OpenStack Ceph 성능 문제는 Ceph 튜닝으로 해결되나요?
항상 그렇지는 않습니다. 실제 현장에서는 Nova/Cinder/Glance 설정 불일치, compute node 네트워크, libvirt secret, keyring 권한 문제가 꽤 많습니다. Ceph 튜닝은 병목이 Ceph 내부에 있다는 근거를 잡은 뒤에 하는 게 안전합니다.
Q. OSD latency가 높으면 바로 디스크 교체인가요?
바로 교체로 가기보다는 특정 OSD만 반복적으로 튀는지, 해당 호스트의 iostat, 커널 로그, NIC 오류, recovery 상태가 같이 움직이는지 봐야 합니다. 디스크 고장일 수도 있지만 네트워크 손실이나 복구 작업 영향일 수도 있습니다.
Q. Glance도 꼭 Ceph RBD를 써야 하나요?
필수는 아닙니다. 다만 Nova와 Cinder가 Ceph를 쓰는 구조라면 Glance도 RBD에 두는 구성이 운영과 장애 분석 측면에서 단순해지는 경우가 많습니다. 특히 이미지 clone 경로를 활용하고 싶다면 세 서비스의 저장 경로를 함께 설계하는 편이 좋습니다.
Q. pool을 꼭 images, vms, volumes로 나눠야 하나요?
작은 테스트 환경에서는 하나로도 돌아갑니다. 운영 환경에서는 분리하는 쪽을 권합니다. 워크로드 성격이 다르고, 장애 분석과 용량 정책, 권한 설정, 향후 CRUSH rule 적용이 쉬워지기 때문입니다.
관련 글로는 OpenStack Nova 트러블슈팅, Cinder 백엔드 설계, Ceph CRUSH rule 운영 가이드를 함께 연결해두면 독자가 다음 점검 단계로 이동하기 좋습니다.
증상별로 Ceph, OpenStack 서비스, 네트워크, 디스크 중 어디를 먼저 확인할지 정리한 요약 이미지입니다.
마지막 판단: 먼저 좁히고, 그다음에 바꾸세요
OpenStack Ceph 성능 문제를 다룰 때 제 추천은 분명합니다. 전체가 느리면 Ceph cluster와 OSD부터, 특정 compute node만 느리면 해당 노드의 RBD 접속 경로부터, 볼륨만 느리면 Cinder와 volumes pool부터, 이미지 부팅만 느리면 Glance와 Nova RBD 연결부터 보세요.
설정값 변경은 마지막 카드에 가깝습니다. ceph -s, ceph osd perf, iostat -x, 서비스 계정 RBD 접근 테스트, Nova/Cinder/Glance 로그를 통해 병목 위치를 먼저 좁히면 불필요한 튜닝을 줄일 수 있습니다. 운영에서 좋은 트러블슈팅은 멋진 한 방이 아니라, 잘못된 가능성을 빠르게 제거하는 과정에 더 가깝습니다.
오픈스택 운영 회고라는 주제로 글을 쓰게 된 이유는 단순합니다. 3년 정도 직접 굴려보니, 처음 기대했던 것과 실제 운영에서 마주치는 현실이 꽤 다르더라고요. 처음엔 “우리도 프라이빗 클라우드(Private Cloud, 사설 클라우드) 하나 제대로 만들어보자” 하고 시작했는데, 막상 돌려보면 기술보다 운영 체력이 더 중요했습니다. 특히 오픈스택 안정성, 클라우드 비용, 그리고 팀의 인프라 관리 방식이 서로 얽혀 있어서, 한 군데만 잘한다고 끝나지 않거든요.
제가 직접 해보니 오픈스택은 분명히 강력합니다. 하지만 강력하다는 말이 곧 편하다는 뜻은 아니었습니다. 기능은 많고 유연성도 높지만, 그만큼 설계와 운영 기준이 없으면 금방 복잡도가 올라갑니다. 혹시 지금 오픈스택 도입을 고민 중이시거나, 이미 운영 중인데 “왜 이렇게 손이 많이 가지?” 싶은 분이라면 오늘 글이 꽤 현실적인 체크리스트가 될 겁니다.
컨트롤 플레인과 컴퓨트, 스토리지, 네트워크가 어떻게 나뉘는지 한눈에 보여주는 아키텍처 이미지입니다.
오픈스택 운영 회고를 시작하기 전에: 쉽게 말해 오픈스택이란?
쉽게 말해 오픈스택(OpenStack)은 가상 서버, 네트워크, 스토리지 같은 인프라 자원을 API로 다루게 해주는 클라우드 운영 프레임워크입니다. 퍼블릭 클라우드(Public Cloud, 공개형 클라우드)에서 버튼 몇 번으로 VM을 만드는 경험을, 우리 데이터센터나 사내 서버 환경에서 구현한다고 생각하시면 이해가 빠릅니다.
근데 여기서 오해하면 안 되는 게 하나 있어요. 오픈스택은 제품 하나를 설치하면 끝나는 패키지가 아니라, 여러 컴포넌트가 맞물려 돌아가는 생태계에 가깝습니다. 예를 들면 Nova(노바, 컴퓨트 관리), Neutron(뉴트론, 네트워크 관리), Cinder(신더, 블록 스토리지), Glance(글랜스, 이미지 관리), Keystone(키스톤, 인증) 같은 서비스가 서로 의존합니다. 처음엔 이게 뭔가 싶었는데, 실제로 써보니까 문제 하나가 다른 레이어로 전파되는 경우가 많아서 구조를 이해하는 게 정말 중요했습니다.
영역
대표 컴포넌트
역할
운영 포인트
인증
Keystone
사용자와 서비스 인증
토큰, 권한, 서비스 엔드포인트 정리
컴퓨트
Nova
가상머신 생성과 스케줄링
하이퍼바이저 상태, 배치 정책 확인
네트워크
Neutron
가상 네트워크와 라우팅
장애 시 추적 난도가 높음
스토리지
Cinder, Swift
블록/오브젝트 스토리지 제공
백엔드 성능과 장애 복구 설계 중요
이미지
Glance
VM 이미지 관리
이미지 표준화가 운영 품질 좌우
3년 운영하면서 느낀 핵심: 안정성은 소프트웨어보다 운영 기준에서 나옵니다
여기서 중요한 포인트! 많은 분들이 오픈스택 안정성을 이야기할 때 소프트웨어 자체의 완성도만 떠올리시는데, 제 경험상 운영 결과를 가르는 건 오히려 다음 세 가지였습니다.
변경 관리(Change Management, 변경 관리)가 있는가
관측성(Observability, 모니터링/로그/메트릭 가시성)이 충분한가
장애 복구 시나리오를 문서가 아니라 실제로 검증했는가
처음 1년은 솔직히 삽질 좀 했습니다 ㅎㅎ 서비스는 떠 있는데 사용자 입장에서는 VM이 안 만들어지고, 네트워크는 붙은 것처럼 보이는데 외부 통신이 안 되고, 스토리지는 정상인데 attach가 지연되는 식의 애매한 문제가 많았거든요. 그때 깨달은 게 있습니다. 오픈스택은 장애가 안 나는 시스템이 아니라, 장애를 빨리 좁혀갈 수 있게 만들어야 하는 시스템이라는 점입니다.
그래서 운영 기준을 바꿨습니다. 컴포넌트별 헬스체크를 따로 보고, API 응답 시간과 큐 적체 여부를 함께 보고, 배포 전에 롤백 경로를 먼저 정리했습니다. 그 뒤로 체감 안정성이 많이 올라갔습니다. 실제로 써보니까 “문제가 줄었다”기보다 “문제가 생겨도 덜 무섭다” 쪽이 더 정확하더라고요.
비용 관점에서 본 오픈스택: 라이선스보다 사람이 비쌉니다
클라우드 비용 이야기도 빼놓을 수 없죠. 오픈스택을 검토할 때 흔히 “오픈소스니까 싸지 않나요?”라는 질문을 받습니다. 반은 맞고 반은 틀립니다. 라이선스 비용만 보면 유리할 수 있습니다. 하지만 실제 총비용(TCO, Total Cost of Ownership)을 보면 얘기가 달라집니다.
제가 정리한 기준은 이렇습니다.
하드웨어 조달 비용이 들어갑니다.
네트워크 설계와 스토리지 백엔드 운영 비용이 들어갑니다.
장애 대응 가능한 운영 인력 비용이 꽤 큽니다.
자동화와 표준화가 부족하면 사람 시간이 계속 녹습니다.
특히 클라우드 비용에서 가장 자주 놓치는 부분이 “기회비용”입니다. 퍼블릭 클라우드라면 몇 분 안에 끝났을 일을, 온프레미스 OpenStack 환경에서는 승인, 자원 계획, 이미지 검증, 네트워크 정책 반영까지 여러 단계를 거쳐야 할 수 있거든요. 물론 규모가 커지고 워크로드가 고정적이면 오픈스택이 유리한 구간도 분명 있습니다. 다만 그 전제는 운영 자동화가 어느 정도 완성되어 있어야 한다
항목
퍼블릭 클라우드
오픈스택 기반 프라이빗 클라우드
초기 구축
낮음
높음
확장 속도
빠름
설계 수준에 따라 다름
운영 자유도
제한적
매우 높음
인력 의존도
상대적으로 낮음
높음
비용 예측
사용량 기반
고정비와 운영비 혼합
실전 구현: 제가 운영 중 반복해서 확인한 기본 점검 절차
이제 조금 실무적으로 가보겠습니다. 아래 절차는 제가 정기 점검이나 장애 초기 대응 때 자주 확인하던 흐름입니다. 배포 방식이 다르더라도 기본 개념은 비슷합니다.
1. 서비스 상태 확인
openstack service list
openstack compute service list
openstack network agent list
openstack hypervisor list
이 단계에서는 서비스가 “떠 있느냐”보다 비정상적으로 down 처리된 항목이 없는지를 먼저 봅니다. 특히 컴퓨트 노드가 보이는데 스케줄링이 안 되는 경우가 있어서, 단순 프로세스 상태만 믿으면 안 되더라고요.
2. 리소스 생성 동작 확인
openstack image list
openstack flavor list
openstack network list
openstack server create --flavor m1.small --image test-image --network private-net test-vm
openstack server list
테스트 VM 하나를 실제로 올려보는 게 중요합니다. 모니터링이 모두 초록색이어도, 실제 프로비저닝(Provisioning, 자원 생성 절차) 단계에서 실패하는 경우가 꽤 있습니다. 저도 처음엔 대시보드만 보고 안심했었는데, 실사용 검증이 빠지면 꼭 뒤에서 터지더라고요.
서비스 목록 확인, 하이퍼바이저 점검, 테스트 VM 생성 검증까지 이어지는 운영 점검 흐름을 설명하는 이미지입니다.
3. 네트워크 연결성 확인
openstack port list --server test-vm
openstack floating ip list
ping -c 4 <floating-ip>
ssh -i ~/.ssh/id_rsa cloud-user@<floating-ip>
네트워크는 늘 마지막까지 확인해야 합니다. Neutron(뉴트론, 네트워크 관리)은 구성 자유도가 큰 만큼 문제 원인도 다양합니다. 보안 그룹(Security Group, 가상 방화벽 규칙), 라우터, 플로팅 IP(Floating IP, 외부 연결용 IP), L2/L3 에이전트 상태를 같이 봐야 하거든요.
이건 실제 제품 설정이라기보다 운영 체크 항목을 어떻게 표준화할지 보여주는 예시입니다. 핵심은 정적 상태 점검과 동적 사용자 시나리오 점검을 분리해서 관리하는 겁니다.
⚠️ 트러블슈팅: 3년 동안 자주 만난 문제들
여기서는 정말 많이 겪었던 문제만 추려보겠습니다. 혹시 이런 경험 있으신가요? 장애 알람은 없는데 사용자만 불편하다고 하는 상황이요. 오픈스택에서는 꽤 흔합니다.
1. 서비스는 정상인데 VM 생성이 지연되는 문제
처음엔 스케줄러(Scheduler, 자원 배치기) 문제인가 싶었는데, 실제로는 백엔드 스토리지 응답 지연이나 이미지 다운로드 지연이 원인인 경우가 있었습니다. 겉보기엔 Nova 문제처럼 보이는데, 파고들면 Glance나 스토리지 레이어였던 거죠. 이럴 땐 API 로그만 보지 말고 생성 요청이 어느 단계에서 오래 머무는지를 추적해야 합니다.
2. 네트워크 연결이 간헐적으로 실패하는 문제
이건 진짜 골치 아팠습니다. 제가 직접 해보니 네트워크 문제는 재현이 안 될 때가 가장 힘들더라고요. 보안 그룹 규칙, MTU, 라우팅 경로, 에이전트 상태가 모두 맞물리기 때문에 증상만 보고 섣불리 판단하면 시간만 씁니다. 그래서 저는 네트워크 이슈가 나면 아래 순서로 봤습니다.
이건 기술 문제라기보다 조직 문제에 가깝습니다. 누가 퇴근하면 아무도 못 건드리는 작업이 생기기 시작하면, 그 순간부터 안정성은 떨어진다고 봐야 합니다. 저도 한동안 특정 점검 절차를 머릿속으로만 기억하고 있었는데, 나중에 돌아보니 그게 제일 위험했어요. 문서화와 자동화가 귀찮아 보여도 결국 가장 싸게 먹힙니다.
openstack server show test-vm
openstack console log show test-vm
openstack port show <port-id>
openstack hypervisor stats show
문제가 생기면 위 같은 기본 명령어부터 차근차근 보는 습관이 중요합니다. 급하다고 바로 재시작부터 하면 원인 단서가 금방 사라지거든요.
검증과 결과: 운영이 편해졌다고 느낀 순간
운영은 결국 체감이 중요합니다. 제가 오픈스택 경험을 통해 “이제 좀 자리 잡았구나” 느낀 기준은 화려한 기능 추가가 아니었습니다.
새 VM 생성 성공 여부를 운영자가 감으로 판단하지 않게 됐을 때
장애 발생 시 어느 레이어부터 볼지 팀 내 공통 언어가 생겼을 때
정기 점검 결과가 사람마다 다르지 않게 됐을 때
비용 논의에서 라이선스가 아니라 운영 방식이 중심이 됐을 때
이런 변화가 생기면 인프라 관리의 수준이 한 단계 올라갑니다. 이전에는 문제를 “해결”하는 데 집중했다면, 이후에는 문제를 “예측 가능하게 만드는 것”으로 관점이 바뀌더라고요. 이 차이가 꽤 큽니다.
서비스 상태, 자원 사용량, 장애 추적 포인트를 한 화면에서 보는 운영 대시보드 느낌의 이미지입니다.
오픈스택을 추천할 때와 말릴 때
모든 환경에 오픈스택이 정답은 아닙니다. 이건 꼭 말씀드리고 싶었습니다. 제가 멘토처럼 조언드린다면 기준은 꽤 명확합니다.
추천하는 경우
워크로드가 비교적 예측 가능하고 장기 운영 비중이 큰 경우
네트워크, 스토리지, 가상화에 대한 내부 이해도가 있는 경우
자동화와 운영 표준화에 시간을 투자할 수 있는 경우
데이터 주권이나 내부 통제가 중요한 경우
말리고 싶은 경우
소수 인원이 모든 걸 동시에 맡아야 하는 경우
빠른 기능 출시가 최우선이고 인프라가 차별점이 아닌 경우
장애 대응 경험이 부족한 상태에서 복잡한 네트워크 구성을 바로 가져가려는 경우
운영 인력 확보 없이 비용 절감만 기대하는 경우
근데 여기서 중요한 건, 말린다고 해서 기술이 나쁘다는 뜻은 아니라는 점입니다. 도구의 성격과 조직의 운영 성숙도가 맞아야 한다
정리와 FAQ: 놓치지 말아야 할 것들
오픈스택 운영 회고를 한 줄로 정리하면 이렇습니다. 안정성은 아키텍처보다 운영 기준에서 나오고, 비용은 라이선스보다 사람과 절차에서 갈립니다. 저도 처음엔 기능 중심으로 봤는데, 결국 오래 가는 환경은 단순하고 반복 가능하게 만든 환경이었습니다.
다음 글에서는 홈랩(Home Lab, 개인 실험실) 기준으로 소규모 OpenStack 검증 환경을 어떻게 꾸렸는지, 그리고 어떤 식으로 실험 순서를 잡았는지 다뤄볼 예정입니다. 이전 글에서 다뤘던 가상화 레이어 점검 방법과 함께 보시면 더 이해가 쉬우실 겁니다.
자주 묻는 질문
Q. 오픈스택은 무조건 비용 절감에 유리한가요?
A. 아닙니다. 하드웨어와 운영 인력, 자동화 수준까지 같이 봐야 합니다. 특히 초반에는 생각보다 손이 많이 갑니다.
Q. 오픈스택 안정성을 높이려면 가장 먼저 뭘 해야 하나요?
A. 서비스 상태 확인보다 먼저 운영 기준을 표준화하는 게 좋습니다. 누가 봐도 같은 절차로 점검할 수 있어야 합니다.
Q. 오픈스택 경험이 적은 팀도 시작할 수 있을까요?
A. 가능합니다. 다만 작은 범위에서 시작하고, 네트워크와 스토리지 복잡도를 초반에 과하게 올리지 않는 게 좋습니다.
안정성, 비용, 운영 기준 세 가지 핵심 교훈을 요약해서 보여주는 마무리 인포그래픽 이미지입니다.
OpenStack 프라이빗 클라우드 보안 이야기는 평소엔 좀 뒤로 밀리기 쉽습니다. 서비스가 잘 돌고 있으면 당장 체감이 안 되거든요. 그런데 클라우드 보안 감사 한 번 들어오면 분위기가 바로 달라집니다. 계정 정책, API TLS, 로그 보관, 이미지 무결성 같은 항목이 한꺼번에 쏟아지니까요. 저도 홈랩과 실무 환경에서 비슷한 점검을 여러 번 겪어봤는데, 처음엔 “이건 설정 파일 몇 개만 손보면 되겠지” 싶었거든요. 근데 막상 들어가 보니 Keystone(키스톤, 인증/인가), Nova(노바, 컴퓨트), Neutron(뉴트론, 네트워크), RabbitMQ(래빗MQ, 메시지 브로커)까지 서로 얽혀 있어서 삽질 좀 했습니다 ㅎㅎ
이번 글은 특정 벤더 보고서 하나를 요약하는 방식보다는, 최근 감사에서 반복적으로 지적되는 OpenStack 보안 항목을 공식 Security Guide와 체크리스트 기준으로 묶어서 정리한 내용입니다. 즉, 보고서가 달라도 결국 자주 걸리는 포인트는 비슷하더라고요. 그래서 오늘은 OpenStack 프라이빗 클라우드 보안을 실제 운영 관점에서 어떻게 강화할지, 제가 실무에서 우선순위를 잡는 방식으로 풀어보겠습니다.
쉽게 말해 감사는 “설정이 있느냐”보다 보안 경계(Security Boundary, 보안 경계)가 실제로 분리되어 있느냐를 봅니다. OpenStack은 컴포넌트가 많아서, 한 군데만 HTTPS를 켰다고 끝나지 않거든요. 예를 들어 Horizon(호라이즌, 대시보드)은 TLS를 쓰는데 서비스 간 내부 통신은 평문으로 남아 있거나, RabbitMQ 인증서는 넣었는데 호스트네임 검증은 꺼져 있는 식입니다. 겉으로는 안전해 보여도 감사에서는 바로 티가 납니다.
제가 최근 점검할 때도 지적이 많이 나온 항목은 아래 네 가지였습니다.
관리망과 외부망 분리 부족: 내부 API가 외부 엔드포인트를 타는 경우
과도한 권한: 관리자 계정 공유, 서비스 계정 권한 과다
로그는 있는데 감사 추적이 어려움: 중앙 수집과 상관분석 부재
이미지/메시지 경로 무결성 미흡: 이미지 서명 검증, 메시지 브로커 TLS 검증 미설정
2. OpenStack 보안 베스트 프랙티스, 핵심만 먼저 잡아보겠습니다
OpenStack 보안 베스트 프랙티스를 한 줄로 줄이면 이겁니다. “외부 공개 구간만 막지 말고, 내부 제어면(Control Plane, 제어 평면)까지 신뢰하지 말자.” 저도 처음엔 내부망이면 괜찮지 않나 싶었는데, 실제로는 운영자 실수나 계정 탈취가 더 무섭더라고요.
감사 항목
자주 보이는 문제
즉시 대응
장기 대응
인증/인가
관리자 계정 공유, MFA 미적용
관리자 계정 분리, 외부 IdP 연동 검토
RBAC 재설계, 페더레이션 적용
통신 보안
내부 API 평문, 인증서 검증 비활성화
HTTPS 강제, internal endpoint 지정
전 구간 TLS, 인증서 수명주기 자동화
감사 로그
노드별 로그 분산, 이벤트 표준화 부족
중앙 로그 수집
CADF 기반 감사 추적 체계화
무결성
이미지 검증 없음, 설정 파일 변경 감시 없음
서명 검증, 권한 점검
FIM, 골든 이미지 파이프라인
여기서 중요한 포인트! 감사 대응은 문서부터 쓰는 게 아니라 데이터 흐름부터 그려야 합니다. 누가 로그인하고, 어떤 API를 타고, 어떤 메시지 브로커를 지나, 최종적으로 어떤 로그가 남는지 보셔야 합니다. 이 흐름이 안 보이면 체크리스트만 돌려도 자꾸 빠지는 항목이 생깁니다.
3. 실전 구현 1: 계정, 엔드포인트, TLS부터 정리합니다
제가 직접 해보니 제일 효과가 큰 첫 단계는 “접속면 줄이기”였습니다. 즉, 공개 엔드포인트와 내부 엔드포인트를 분리하고, 서비스 간 통신이 public URL이 아니라 internal URL을 쓰도록 강제하는 겁니다.
서비스 카탈로그(Service Catalog, 서비스 목록)에서 internal endpoint를 분리합니다.
각 서비스 설정에서 Keystone 인증 URL과 연동 URL이 HTTPS인지 확인합니다.
이 작업은 단순해 보여도 효과가 큽니다. 내부 관리 트래픽이 외부 공개 주소를 타지 않게 되니까요. 특히 프록시나 로드밸런서가 여러 겹일 때 감사 추적도 훨씬 쉬워집니다.
public endpoint와 internal endpoint를 분리하고 서비스 간 통신을 HTTPS로 고정한 예시 구성입니다.
4. 실전 구현 2: RabbitMQ, 로그, 이미지 무결성을 같이 보셔야 합니다
OpenStack은 API만 안전해도 끝이 아닙니다. 실제로 서비스끼리 대화하는 길목은 RabbitMQ 같은 메시지 브로커인 경우가 많거든요. 여기 TLS를 켜도 인증서 체인만 보고 호스트네임 검증을 안 하면 허점이 남습니다. 최근 oslo.messaging 릴리스 노트에서도 이 부분이 분명히 언급됐습니다. 그래서 제가 운영할 때는 브로커 TLS와 로그 표준화를 같이 묶어서 봅니다.
# /etc/nova/nova.conf 또는 공통 oslo.messaging 설정
[oslo_messaging_rabbit]
ssl = true
ssl_ca_file = /etc/ssl/certs/openstack-ca.pem
ssl_cert_file = /etc/ssl/certs/client.pem
ssl_key_file = /etc/ssl/private/client-key.pem
ssl_enforce_hostname_verification = true
단, 이 옵션은 배포판 패키지 버전에 따라 지원 여부가 다를 수 있습니다. 그래서 바로 적용하기 전에 패키지 changelog나 릴리스 노트를 꼭 보셔야 합니다. 저도 이거 모르고 넣었다가 서비스 재시작만 반복한 적이 있었네요.
감사 로그 쪽은 Keystone의 CADF(Cloud Auditing Data Federation, 클라우드 감사 이벤트 표준) 포맷을 적극 검토할 만합니다. 사람이 보기엔 조금 딱딱하지만, SIEM(보안 정보 이벤트 관리)으로 넘길 때 훨씬 정리가 잘 됩니다.
처음엔 이게 너무 과한가 싶었는데, 골든 이미지(Golden Image, 표준 이미지)를 운영하는 환경에서는 진짜 편하더라고요. 누가 어떤 이미지를 올렸는지, 검증됐는지 흐름이 분명해집니다.
메시지 브로커 TLS 보호와 Keystone CADF 감사 로그가 중앙 수집 시스템으로 모이는 흐름입니다.
5. 실전 구현 3: 파일 권한과 노드 하드닝은 기본인데 가장 많이 놓칩니다
이건 너무 기본 같아서 오히려 빼먹습니다. 그런데 공식 Security Checklist를 보면 Keystone, Nova, Neutron 설정 파일의 소유권과 권한을 아주 명확하게 확인하라고 하거든요. 감사에서도 이건 빠지지 않습니다.
stat -L -c "%U %G %a" /etc/keystone/keystone.conf
stat -L -c "%U %G %a" /etc/nova/nova.conf
stat -L -c "%U %G %a" /etc/neutron/neutron.conf
find /etc/keystone /etc/nova /etc/neutron -type f -perm /027 -ls
제가 주로 보는 기준은 이렇습니다.
서비스 계정과 그룹이 올바른지 확인
설정 파일 권한이 과도하게 열려 있지 않은지 확인
SELinux(셀리눅스, 강제 접근 통제)나 AppArmor 정책과 충돌 없는지 확인
FIM(File Integrity Management, 파일 무결성 감시) 대상에 핵심 설정 파일 포함
여기서 많이 겪는 문제는 자동화 도구가 재배포하면서 권한을 널널하게 바꿔버리는 경우입니다. 특히 템플릿 한 군데 잘못 두면 전체 노드가 같은 실수를 반복합니다. 그래서 저는 배포 후 검증 명령을 CI 파이프라인이나 운영 점검 스크립트에 꼭 넣습니다.
6. ⚠️ 감사 때 자주 터지는 트러블슈팅
이 섹션은 실전에서 진짜 많이 부딪히는 부분입니다.
6-1. HTTPS는 켰는데 인증 실패가 납니다
대부분 CA 체인이나 호스트네임 불일치입니다. 인증서를 넣었다고 끝이 아니고, 서비스가 접속하는 URL과 인증서 SAN(Subject Alternative Name, 주체 대체 이름)이 맞아야 합니다.
6-2. 내부 통신을 HTTPS로 바꾸니 서비스 등록은 됐는데 호출이 꼬입니다
이 경우 public endpoint는 바꿨는데, 개별 서비스 설정은 여전히 외부 주소를 보고 있는 경우가 많습니다. 카탈로그와 각 서비스 설정 파일을 둘 다 봐야 합니다.
6-3. 로그는 모이는데 감사 보고서에서 추적성이 부족하다고 나옵니다
이건 단순 보관이 아니라 상관관계(Correlation, 상관 분석) 문제입니다. 사용자 로그인, 토큰 발급, 인스턴스 생성, 볼륨 연결, 보안그룹 변경 이벤트를 하나의 흐름으로 이어서 볼 수 있어야 하거든요. 그래서 Keystone 이벤트, API 로그, 하이퍼바이저 로그를 따로 보지 말고 묶어야 합니다.
6-4. 보안 강화 후 성능이 걱정됩니다
맞습니다. TLS와 추가 로깅은 비용이 있습니다. 그래서 저는 처음부터 전부 켜기보다 인터넷 노출 구간, 관리자 구간, 메시지 브로커, 이미지 검증 순서로 우선순위를 잡습니다. 한 번에 다 바꾸면 장애 원인 분석이 어려워집니다.
7. 검증은 이렇게 하시면 됩니다
보안 설정은 “넣었다”가 아니라 “검증됐다”로 끝내야 합니다. 제가 보통 마지막에 확인하는 체크는 아래와 같습니다.
모든 핵심 서비스 엔드포인트가 HTTPS인지 확인
서비스 설정의 insecure = true 흔적 제거 확인
메시지 브로커 TLS 연결 및 인증서 검증 확인
CADF 또는 중앙 로그에서 관리자 행위 추적 가능 여부 확인
서명되지 않은 이미지가 정책상 차단되는지 확인
openstack endpoint list --long | egrep "https|Region"
grep -R "insecure *= *true" /etc/keystone /etc/nova /etc/neutron /etc/glance
openssl s_client -connect rabbitmq.internal.example:5671 -servername rabbitmq.internal.example
openstack image list
openstack server list
완료 후 대시보드와 CLI 둘 다 테스트해보세요. Horizon만 되고 CLI가 안 되거나, 반대로 API는 되는데 메타데이터 프록시가 깨지는 경우가 있습니다. 저도 이 단계에서 “드디어 됐다!” 했다가 보안그룹 갱신이 안 되는 걸 뒤늦게 발견한 적이 있었거든요.
보안 점검 항목이 통과되고 중앙 로그에서 관리자 행위를 추적할 수 있는 결과 화면 예시입니다.
8. 정리: OpenStack 프라이빗 클라우드 보안은 순서가 중요합니다
OpenStack 프라이빗 클라우드 보안은 기능을 많이 넣는 게임이 아닙니다. 순서를 잘 잡는 작업에 가깝습니다. 제가 실제로 운영하면서 느낀 우선순위는 이렇습니다. 계정 통제 → 내부 API TLS → 메시지 브로커 보호 → 감사 로그 표준화 → 이미지 무결성 → 파일 무결성 감시. 이 순서로 가면 감사 대응도 수월하고, 장애가 나도 어디서 꼬였는지 찾기 편합니다.
혹시 지금 프라이빗 클라우드 감사 대응을 준비 중이시라면, 문서부터 만들기보다 먼저 엔드포인트와 계정, 로그 흐름을 그림으로 그려보세요. 그 다음에 체크리스트를 맞추면 훨씬 빨라집니다. 다음 글에서는 Barbican(바비칸, 비밀 관리 서비스)과 이미지 서명 체계를 조금 더 깊게 다뤄보겠습니다. 이전에 정리한 리눅스 하드닝 글이 있으시면 그 흐름과 같이 보셔도 연결이 잘 됩니다.
계정 통제, TLS, 로그, 이미지 무결성, 파일 무결성 감시 순서로 정리한 대응 우선순위 요약입니다.
9. 자주 묻는 질문
Q1. 작은 홈랩에도 이렇게까지 해야 할까요?
전부 한 번에 할 필요는 없습니다. 다만 관리자 계정 분리, HTTPS, 설정 파일 권한 점검은 작은 환경에서도 바로 체감됩니다.
Q2. 클라우드 보안 감사에서 가장 빨리 점수 올리는 항목은 뭔가요?
보통은 내부 API TLS, 관리자 접근 통제, 중앙 로그 수집입니다. 이 세 개가 눈에 잘 보이고 재현도 쉽습니다.
Q3. OpenStack 보안 베스트 프랙티스를 어디서 시작하면 좋을까요?
공식 Security Checklist를 서비스별로 돌려보는 게 제일 현실적입니다. Keystone, Nova, Neutron부터 보시면 됩니다.
OpenStack 업그레이드 10가지 체크리스트: 실전 베스트 프랙티스로 성공 확률 높이기
OpenStack 업그레이드는 생각보다 자주, 그리고 생각보다 크게 운영팀을 흔듭니다. 평소엔 잘 돌던 Nova(노바, 컴퓨트 서비스), Neutron(뉴트론, 네트워크 서비스), Cinder(신더, 블록 스토리지 서비스)가 업그레이드 직후 서로 미묘하게 어긋나기 시작하면 진짜 진땀 나거든요. 저도 처음엔 “패키지 버전만 맞추면 되겠지” 했다가 메시지 큐(Message Queue, 서비스 간 비동기 통신), DB schema(데이터베이스 스키마), API microversion(API 세부 버전 정책) 때문에 삽질 좀 했습니다 ㅎㅎ 이번 글은 그런 시행착오를 줄이기 위한 OpenStack 업그레이드 체크리스트를 정리한 내용입니다.
특히 운영 중인 프라이빗 클라우드(private cloud)를 관리하시는 분들이라면, 단순히 패키지를 올리는 작업이 아니라 클라우드 업그레이드 전체 흐름으로 봐야 합니다. 오늘은 제가 홈랩과 실서비스 환경에서 반복해서 확인했던 항목들을 기준으로, 실패 확률을 줄이는 순서와 OpenStack 베스트 프랙티스를 풀어보겠습니다.
컨트롤 플레인과 컴퓨트 노드, 스토리지, 네트워크 컴포넌트가 단계적으로 업그레이드되는 전체 흐름을 보여주는 이미지입니다.
왜 OpenStack 업그레이드가 까다로운가
쉽게 말해 OpenStack은 하나의 프로그램이 아니라 여러 서비스 묶음입니다. Keystone(키스톤, 인증 서비스), Glance(글랜스, 이미지 서비스), Nova, Neutron, Cinder 같은 핵심 서비스가 각각 DB, API, 에이전트, 백엔드 드라이버를 갖고 있고요. 그래서 한 군데만 올리면 끝나는 구조가 아닙니다.
여기서 중요한 포인트! 업그레이드의 핵심은 버전 상승 자체가 아니라 호환성 유지입니다. 실제로 써보니까 장애는 대개 패키지 설치보다 서비스 간 정합성이 깨질 때 발생하더라고요. 예를 들어 API는 올라갔는데 agent(에이전트, 각 노드에서 동작하는 구성요소)가 예전 상태면 네트워크 포트 생성이 꼬이거나, DB migration(데이터베이스 마이그레이션)이 덜 끝난 상태에서 서비스가 붙으면서 애매한 오류를 만들기도 합니다.
OpenStack 업그레이드 전 꼭 봐야 할 10가지 체크리스트
공식 릴리스 노트와 업그레이드 경로 확인 지원되는 업그레이드 경로인지 먼저 확인해야 합니다. 중간 릴리스를 건너뛰면 안 되는 경우가 있거든요.
현재 인벤토리와 의존성 파악 컨트롤러, 컴퓨트, 네트워크 노드, 스토리지 백엔드, 하이퍼바이저, OS 패키지 상태를 정리합니다.
백업과 복구 시나리오 검증 DB dump만 뜨고 끝내면 부족합니다. 실제 복원 테스트까지 해봐야 합니다.
테스트 환경 또는 스테이징 검증 프로덕션과 최대한 비슷한 구조에서 한 번 굴려봐야 예상치 못한 이슈를 줄일 수 있습니다.
API, DB, Message Queue 호환성 점검 RabbitMQ 같은 메시지 큐와 MariaDB/MySQL, PostgreSQL 설정 차이도 같이 봐야 합니다.
드레인(Drain)과 유지보수 창 확보 라이브 마이그레이션 가능 여부, 예약 작업, 사용자 공지까지 포함해서 계획을 세워야 합니다.
롤링 업그레이드 가능 범위 확인 서비스별로 순차 적용 가능한지, 전체 중단이 필요한지 구분해야 합니다.
설정 파일 diff 비교 기존 설정과 새 기본값이 어떻게 달라졌는지 비교해야 합니다.
모니터링과 로그 수집 체계 준비 업그레이드 직후엔 로그가 거의 유일한 힌트일 때가 많습니다.
검증 시나리오 문서화 인스턴스 생성, 삭제, 볼륨 연결, 플로팅 IP, 보안 그룹, 이미지 업로드 같은 기본 기능을 체크리스트로 만들어야 합니다.
업그레이드 방식 비교: 인플레이스 vs 블루그린 관점
현실적으로는 대부분 인플레이스(in-place, 기존 환경에서 직접 업그레이드)를 선택합니다. 비용과 장비 여유 때문이죠. 저도 홈랩에서는 거의 인플레이스로 갔었는데, 대신 검증 시나리오를 더 빡세게 잡았습니다. 반대로 규모가 크고 서비스 중단 허용 범위가 작다면 블루그린(blue-green, 신규 환경을 따로 구성 후 전환) 접근이 더 안전할 수 있습니다.
방식
장점
주의점
인플레이스 업그레이드
추가 자원 부담이 적고 기존 운영 체계를 유지하기 쉽습니다
롤백이 까다롭고 서비스 간 버전 혼합 구간 관리가 중요합니다
블루그린 전환
검증 후 전환이 가능해 리스크를 줄이기 좋습니다
추가 인프라와 데이터 동기화 전략이 필요합니다
하이브리드 단계 전환
핵심 서비스만 분리해 현실적으로 적용하기 좋습니다
운영 절차가 복잡해지고 문서화가 필수입니다
실전 구현: OpenStack 업그레이드 작업 순서
여기서는 배포 도구에 종속되지 않는 공통 흐름으로 설명하겠습니다. Ansible(앤서블, 자동화 도구), Kolla-Ansible, OpenStack-Ansible, 수동 패키지 기반 환경 모두 참고 가능한 순서입니다.
1. 현재 상태 수집
처음엔 이게 뭔가 싶었는데, 이 단계가 제일 중요합니다. 업그레이드 전 상태를 남겨놓지 않으면 장애가 나도 비교 기준이 없거든요.
openstack compute service list
openstack network agent list
openstack volume service list
openstack hypervisor list
openstack server list --all-projects
openstack volume list --all-projects
이 명령으로 서비스 상태를 저장해두면 업그레이드 후 비교가 훨씬 쉬워집니다. 가능하면 결과를 파일로 보관하세요.
2. 데이터베이스와 설정 백업
mysqldump --single-transaction --routines --databases keystone glance nova nova_api neutron cinder > openstack-backup.sql
cp -a /etc/keystone /root/backup/etc-keystone
cp -a /etc/nova /root/backup/etc-nova
cp -a /etc/neutron /root/backup/etc-neutron
cp -a /etc/cinder /root/backup/etc-cinder
제가 직접 해보니 DB dump만 믿고 갔다가 설정 파일 옵션 차이 때문에 더 오래 헤맨 적이 있습니다. 그래서 DB + 설정 파일 + 서비스 목록을 같이 백업하는 습관이 중요합니다.
3. 유지보수 창 공지와 워크로드 정리
운영 환경이라면 프로젝트 사용자에게 공지하고, 가능하면 대규모 배포 작업이나 자동 스케일링 작업은 멈춰두는 게 좋습니다. 라이브 마이그레이션이 가능한 구조라면 컴퓨트 노드 분산도 미리 해두세요.
사전 점검, 백업, 서비스 중지, DB 마이그레이션, 단계별 기동 검증까지 이어지는 작업 순서를 시각화한 이미지입니다.
4. 컨트롤 플레인부터 순차 업그레이드
일반적으로는 인증, 이미지, API, 스케줄러, 컨덕터 같은 컨트롤 플레인(control plane, 중앙 제어 계층)을 먼저 올리고 이후 컴퓨트와 에이전트를 따라갑니다. 근데 여기서 중요한 건 무조건 한 번에 다 올리는 게 아니라 서비스별 검증 후 다음 단계로 이동하는 겁니다.
systemctl stop openstack-nova-api
systemctl stop openstack-nova-scheduler
systemctl stop openstack-nova-conductor
# 패키지 업데이트 또는 배포 도구 실행
# 예: dnf update, apt upgrade, ansible-playbook 실행 등
nova-manage api_db sync
nova-manage db sync
systemctl start openstack-nova-api
systemctl start openstack-nova-scheduler
systemctl start openstack-nova-conductor
서비스 이름은 배포판마다 조금 다를 수 있습니다. 그래서 실환경에 맞는 서비스 유닛 이름을 먼저 확인해야 합니다.
5. Neutron과 Cinder는 연결 관계를 같이 본다
네트워크와 스토리지는 겉보기보다 외부 의존성이 많습니다. Neutron은 L2/L3 agent, ML2 plugin, DHCP, Metadata 구성이 엮여 있고요. Cinder는 백엔드 스토리지 드라이버와의 호환성이 중요합니다. 저도 예전에 API는 멀쩡한데 agent 상태가 down으로 찍혀서 한참 로그를 봤던 적이 있네요.
openstack network agent list
openstack volume service list
journalctl -u neutron-server -n 100
journalctl -u openstack-cinder-volume -n 100
6. 컴퓨트 노드는 소수부터 검증
모든 컴퓨트 노드를 한 번에 건드리지 말고, 먼저 일부 노드만 올려서 인스턴스 생성과 마이그레이션을 확인하는 게 좋습니다. 이건 정말 실전에서 체감이 큽니다. 작은 범위에서 틀어지면 복구가 빠르거든요.
설정 파일에서 자주 놓치는 포인트
deprecated option: 더 이상 권장되지 않는 옵션이 남아 있으면 경고만 보이다가 실제 동작에 영향을 줄 수 있습니다.
endpoint URL: 내부 엔드포인트와 퍼블릭 엔드포인트 주소 체계가 섞이면 인증이나 이미지 호출이 실패할 수 있습니다.
policy: 정책 파일 구조가 바뀌는 경우가 있어 권한 문제가 생기기도 합니다.
backend driver 설정: Cinder, Neutron 플러그인 쪽은 예전 옵션명이 유지되지 않는 경우가 있습니다.
설정 비교는 단순히 파일 존재 여부가 아니라 기본값 변화를 보는 작업입니다. 여기서 중요한 포인트! 새 버전 기본 설정 샘플과 현재 운영 설정을 diff로 비교해보세요.
이건 생각보다 흔합니다. 서비스 계정 권한, 커넥션 문자열, 캐시, 메시지 큐 인증 정보가 미묘하게 어긋난 경우가 많더라고요. 로그에서 connection refused, access denied, transport error 같은 키워드를 먼저 찾으세요.
네트워크 에이전트가 살아 있는데 포트 생성이 실패하는 경우
Neutron server와 agent 버전 조합, ML2 설정, OVS(Open vSwitch, 가상 스위치) 또는 Linux bridge 구성이 어긋난 경우가 많습니다. 이럴 땐 API 응답만 보지 말고 agent heartbeat(에이전트 하트비트)와 브리지 상태를 같이 봐야 합니다.
openstack network agent list
ovs-vsctl show
ip link show
인스턴스는 생성되는데 콘솔 접속이 안 되는 경우
novncproxy, metadata, 보안 그룹, 프록시 설정이 엮여 있는 경우가 많습니다. 처음엔 컴퓨트 문제라고 생각하기 쉬운데, 실제로는 프론트 API나 프록시 계층 이슈인 경우도 있었습니다.
롤백이 필요한데 되돌릴 순서가 없는 경우
사실 제일 무서운 상황입니다. 그래서 업그레이드 시작 전에 “어디까지 실패하면 중단할지” 기준을 잡아야 합니다. 저는 보통 컨트롤 플레인 검증 실패, 인스턴스 신규 생성 실패, 기존 VM 네트워크 연결 실패 이 세 가지를 즉시 중단 기준으로 둡니다.
검증: 업그레이드 후 무엇을 확인해야 하나
업그레이드가 끝났다고 바로 종료하면 안 됩니다. OpenStack 유지보수 관점에서는 사후 검증이 절반입니다. 아래 항목은 꼭 순서대로 확인해보세요.
인증 토큰 발급과 대시보드 로그인 확인
이미지 목록 조회와 신규 이미지 업로드 확인
네트워크 생성, 서브넷 생성, 라우터 연결 확인
테스트 인스턴스 생성과 삭제 확인
플로팅 IP 연결 및 외부 통신 확인
볼륨 생성, 연결, 분리 확인
보안 그룹 규칙 반영 확인
라이브 또는 콜드 마이그레이션 시나리오 확인
모니터링 알림과 로그 수집 확인
에러 로그 증가 여부 추적
서비스 상태가 모두 정상이며 컴퓨트, 네트워크, 스토리지 검증 항목이 체크 완료된 운영 대시보드 이미지입니다.
openstack token issue
openstack image list
openstack network list
openstack server create --flavor m1.small --image test-image --network private test-vm
openstack server list
openstack volume create --size 1 test-volume
openstack volume list
이 검증 절차를 문서화해두면 다음 업그레이드 때 시간이 정말 많이 줄어듭니다. 실제로 써보니까 사람 기억보다 체크리스트가 훨씬 믿을 만하더라고요.
제가 정리해보는 OpenStack 베스트 프랙티스
작게 시작해서 넓힌다: 일부 노드, 일부 서비스부터 검증합니다.
업그레이드 전 상태를 숫자와 결과로 남긴다: 서비스 목록, 워크로드 수, 에이전트 상태를 저장합니다.
백업은 복원 테스트까지 포함한다: 백업 파일 존재만으로 안심하면 안 됩니다.
문서화한다: 명령어, 순서, 실패 지점, 복구 시간을 기록합니다.
배포 도구의 자동화를 맹신하지 않는다: 자동화는 빠르지만, 원인 분석은 사람이 해야 하거든요.
혹시 이런 경험 있으신가요? 업그레이드는 끝났는데 사용자 쪽에서 “왜 VM 생성이 예전보다 느려졌죠?”라는 질문이 나오는 경우요. 이런 건 단순 성공/실패가 아니라 성능과 안정성까지 같이 봐야 한다는 뜻입니다. 그래서 클라우드 업그레이드는 배포 이벤트가 아니라 운영 이벤트로 봐야 합니다.
정리: 체크리스트 기반으로 움직이면 성공 확률이 올라갑니다
OpenStack 업그레이드는 한 번의 명령으로 끝나는 작업이 아닙니다. 서비스 의존성, DB migration, 에이전트 상태, 검증 시나리오가 다 맞물려 있습니다. 저도 처음엔 버전만 맞추면 되겠지 싶었는데, 실제로는 사전 점검과 사후 검증이 훨씬 중요했습니다. 드디어 됐다! 싶은 순간은 마지막 패키지 설치가 아니라, 테스트 VM이 정상적으로 뜨고 네트워크와 볼륨이 다 붙는 걸 확인했을 때 오더라고요.
이번 글에서는 운영 기준으로 바로 써먹을 수 있는 체크리스트 중심으로 정리해봤습니다. 다음 글에서는 Kolla-Ansible 기반 환경에서 업그레이드 점검 포인트를 더 구체적으로 다뤄볼 예정입니다. 이전 글에서 백업 전략을 정리해두셨다면 이번 체크리스트와 같이 묶어서 보시면 흐름이 훨씬 잘 잡히실 겁니다.
업그레이드 전 점검 항목과 업그레이드 후 검증 항목을 한눈에 비교할 수 있는 요약 인포그래픽입니다.
자주 묻는 질문
Q. OpenStack 업그레이드는 무중단으로 가능한가요?
일부 구성에서는 롤링 업그레이드가 가능하지만, 실제 운영에서는 서비스 영향도를 0으로 만들기 쉽지 않습니다. 특히 네트워크와 스토리지 쪽은 사전 검증이 더 중요합니다.
Q. 테스트 환경이 작아도 도움이 되나요?
네, 도움이 됩니다. 완벽히 같지 않아도 서비스 기동 순서, DB migration, 기본 API 검증만 해봐도 큰 차이가 납니다.
Q. 가장 먼저 자동화해야 할 부분은 뭔가요?
상태 수집, 백업, 검증 명령 실행 결과 저장입니다. 이 세 가지가 자동화되면 반복 작업이 훨씬 안정적이 됩니다.
OpenStack Ceph 연동은 프라이빗 클라우드를 운영할 때 한 번쯤 꼭 마주치는 주제입니다. 저도 홈랩과 실무 환경에서 OpenStack 스토리지 구성을 여러 번 만졌는데요, 처음엔 단순히 연결만 되면 끝일 줄 알았습니다. 그런데 실제로 써보니까 연동 성공과 제대로 빠르게 동작하는 상태는 완전히 다른 이야기더라고요. 특히 볼륨 생성은 되는데 체감이 느리거나, 가상머신 부팅이 들쭉날쭉하거나, 특정 시간대에 I/O가 몰리면 급격히 지연이 커지는 문제를 겪으면 그때부터 삽질이 시작됩니다. 혹시 지금 OpenStack Ceph 연동 이후 성능이 이상하게 답답하다고 느끼고 계신가요?
여기서 중요한 포인트는, 원인이 Ceph 자체인지 OpenStack 설정인지, 아니면 둘 사이의 연결 방식인지 분리해서 봐야 한다는 점입니다. 이 글에서는 제가 직접 겪었던 OpenStack Ceph 연동 실패 패턴과 해결 방법을 정리했으니, 비슷한 상황이라면 참고하시길 바랍니다.
OpenStack 컴퓨트, 이미지, 블록 스토리지 서비스와 Ceph 클러스터 간 연결 구조를 한눈에 보여주는 아키텍처 이미지입니다.
왜 OpenStack Ceph 연동에서 성능 문제가 자주 생길까
쉽게 말해 OpenStack는 서비스를 제공하는 제어 평면(control plane)이고, Ceph는 실제 데이터를 저장하는 분산 스토리지(distributed storage) 역할을 합니다. 많이들 Cinder(신더, 블록 스토리지), Glance(글랜스, 이미지 서비스), Nova(노바, 컴퓨트)가 Ceph의 RBD(RADOS Block Device, 블록 디바이스 인터페이스)를 함께 쓰도록 구성하죠. 구조만 보면 깔끔합니다. 근데 여기서 병목이 생기는 지점이 꽤 많습니다.
인증 설정은 맞는데 풀(pool) 권한이 어긋난 경우
네트워크 분리가 부족해서 클라이언트 트래픽과 복제 트래픽이 섞이는 경우
풀 설계가 서비스 특성과 맞지 않는 경우
하이퍼바이저(hypervisor) 캐시 정책이 애매해서 지연이 커지는 경우
작은 I/O가 많이 발생하는 워크로드를 고려하지 않은 경우
저도 처음엔 Ceph 최적화라고 하면 OSD(Object Storage Daemon, 오브젝트 스토리지 데몬) 쪽만 보면 된다고 생각했었는데요, 막상 들여다보니 OpenStack 스토리지 설정에서 생기는 비효율이 꽤 컸습니다. 특히 이미지 업로드는 괜찮은데 볼륨 기반 부팅이 유독 느린 경우, 그 원인이 하나가 아니라 여러 레이어에 걸쳐 있는 경우가 많았습니다.
구성 개념 먼저 정리해보겠습니다
OpenStack Ceph 연동을 이해할 때는 각 서비스가 어느 풀을 쓰는지부터 정리하면 훨씬 덜 헷갈립니다.
구성 요소
역할
Ceph 연동 포인트
체크 포인트
Glance
이미지 저장
RBD 이미지 풀
이미지 업로드/변환 지연
Cinder
볼륨 제공
RBD 볼륨 풀
볼륨 생성 속도, attach 지연
Nova
가상머신 부팅
Ceph 백엔드 부트
부팅 시간, I/O 패턴
Ceph MON/OSD
클러스터 관리/데이터 저장
스토리지 코어
복제 상태, 지연, 균형
핵심은 이겁니다. OpenStack 스토리지 성능은 단순히 디스크가 빠르냐 느리냐로 끝나지 않습니다. 인증, 네트워크, 풀 설계, 복제 정책(replication policy), 클라이언트 설정이 다 같이 맞물립니다. 그래서 문제를 볼 때도 한 군데만 보면 안 되죠.
제가 실제로 점검했던 사전 체크리스트
본격적으로 손대기 전에 저는 항상 아래 순서대로 확인합니다. 이 순서를 안 지키면 괜히 OSD 튜닝만 하다가 시간을 많이 쓰게 되더라고요.
Ceph 클러스터 상태가 HEALTH_OK 또는 경미한 경고 수준인지 확인합니다.
Glance, Cinder, Nova가 각각 어떤 Ceph 사용자와 풀을 쓰는지 정리합니다.
스토리지 네트워크와 서비스 네트워크가 분리되어 있는지 확인합니다.
볼륨 생성, 이미지 업로드, 부팅 중 어디가 가장 느린지 구분합니다.
가상머신 내부 체감 속도와 백엔드 I/O 지표를 따로 봅니다.
여기서 중요한 포인트! 사용자는 보통 “Ceph가 느리다”라고 말하지만, 실제로는 이미지 복사 경로가 비효율적이거나 캐시 정책이 안 맞아서 그렇게 느끼는 경우도 많습니다. 저도 예전에 이걸 구분 못 해서 하루를 날린 적이 있습니다. OpenStack Ceph 연동에서는 정말 이런 실수가 흔하거든요.
실전 구현: OpenStack Ceph 연동 기본 점검과 설정
아래 예시는 개념을 설명하기 위한 일반적인 형태입니다. 배포판이나 자동화 도구에 따라 파일 위치와 세부 항목은 조금 다를 수 있습니다. 그래도 큰 흐름은 비슷합니다.
1. Ceph 클러스터 상태 확인
ceph -s
ceph health detail
ceph osd tree
ceph osd df
rbd pool ls
이 단계에서 저는 먼저 복제 지연이나 OSD 불균형부터 봅니다. 연동 전에 백엔드가 불안정하면 OpenStack 쪽에서 아무리 손봐도 체감이 안 좋아집니다.
2. Ceph 사용자 권한 확인
ceph auth list
ceph auth get client.glance
ceph auth get client.cinder
ceph auth get client.nova
권한이 과하게 넓은 것도 문제지만, 더 자주 보는 건 풀 권한이 어설프게 빠져 있는 경우입니다. 그러면 기능은 되는 것처럼 보여도 특정 작업에서만 실패하거나 지연이 생깁니다.
Glance(글랜스, 이미지 서비스)가 Ceph를 바로 쓰도록 해두면 이미지 관리가 단순해집니다. 다만 이미지 업로드와 변환 작업이 많은 환경이라면 여기서도 풀 설계와 I/O 패턴을 꼭 같이 봐야 합니다.
OpenStack 서비스별로 어떤 Ceph 사용자와 풀을 사용하는지 보여주는 구성 다이어그램입니다.
실패 사례: OpenStack Ceph 연동은 됐는데 성능이 안 나온 이유
이제 제가 실제로 겪었던 전형적인 실패 패턴을 말씀드려볼게요. 처음엔 볼륨 생성도 되고 인스턴스도 뜨니까 성공한 줄 알았습니다. 그런데 실제로 써보니까 VM 부팅 시간이 일정하지 않았고, 동시에 여러 작업이 걸리면 체감 지연이 확 올라가더라고요. 여기서부터가 진짜 OpenStack Ceph 연동의 시작이었습니다.
문제 1. 네트워크를 논리적으로만 나눠놓고 물리적으로는 섞어 썼던 경우
Ceph는 복제와 복구 트래픽이 발생합니다. 그런데 클라이언트 액세스와 같은 대역을 공유하면 피크 시간에 지연이 커질 수 있습니다. 저도 홈랩에서 처음엔 VLAN만 나누면 충분하겠지 했었는데, 실제로는 업링크 혼잡이 생기면서 체감 성능이 꽤 흔들렸습니다.
증상: 특정 시간대에 볼륨 attach와 부팅 지연 증가
원인: 스토리지 트래픽과 일반 서비스 트래픽 경합
대응: 스토리지 네트워크 경로를 분리하고 혼잡 구간을 줄임
문제 2. 풀을 나누지 않고 한 곳에 몰아넣은 경우
이미지, 볼륨, 테스트용 작업이 한 풀에 몰려 있으면 관찰도 어렵고 튜닝 포인트도 흐려집니다. Ceph 최적화는 결국 워크로드 분리가 기본이더라고요.
증상: 어떤 작업이 느린지 구분이 잘 안 됨
원인: 서비스별 I/O 특성 혼재
대응: images, volumes 등 역할 단위로 풀을 분리해 관찰성 확보
문제 3. 클론과 스냅샷 체인을 너무 방치한 경우
처음엔 공간 절약 측면에서 좋아 보이는데, 운영 기간이 길어지면 관리 포인트가 늘어납니다. 특히 오래된 이미지 기반으로 파생된 체인이 많아지면, 성능과 운영 복잡도가 같이 올라갈 수 있습니다. OpenStack Ceph 연동 운영에서는 정말 흔한 문제입니다.
문제 4. 성능 문제를 전부 Ceph 탓으로만 본 경우
이거 정말 많이 봅니다. 근데 실제로는 하이퍼바이저 캐시 설정, 인스턴스 유형별 디스크 패턴, 백그라운드 작업 영향도 같이 봐야 하거든요. 저도 처음엔 Ceph OSD만 의심했었는데, 나중에 보니 OpenStack 스토리지 경로에서 이미지 변환과 attach 흐름이 더 큰 영향을 준 케이스가 있었습니다.
⚠️ 트러블슈팅: 제가 효과를 봤던 점검 순서
문제가 생기면 아래 순서로 좁혀가면 좋습니다. 무작정 튜닝부터 하지 마세요. 저도 예전엔 그랬다가 더 꼬였습니다.
Ceph 상태 확인 클러스터 경고, 리밸런싱(rebalancing), 복구 상태를 먼저 확인합니다.
풀 단위 관찰 어느 풀이 바쁜지, 이미지와 볼륨 중 어디서 병목이 생기는지 봅니다.
OpenStack 작업별 분리 이미지 업로드, 볼륨 생성, 인스턴스 부팅을 따로 테스트합니다.
동시 작업 테스트 단건 테스트는 괜찮은데 동시성에서 무너지는 경우가 많습니다.
체인 정리 여부 검토 오래된 스냅샷/클론 구조가 쌓였는지 확인합니다.
openstack volume create --size 10 test-volume
openstack server create --flavor m1.small --image test-image --network private test-vm
rbd ls -p volumes
rbd info volumes/test-volume
ceph osd perf
여기서 ceph osd perf 같은 기본 지표와 OpenStack 작업 시간을 같이 비교해보면 감이 옵니다. 절대적인 숫자보다 언제 느려지는지, 어떤 작업에서 흔들리는지를 보는 게 더 중요합니다.
볼륨 생성과 가상머신 부팅 과정에서 지연이 발생하는 구간을 시각적으로 보여주는 대시보드 이미지입니다.
Ceph 최적화 관점에서 배운 점
이번 경험에서 가장 크게 느낀 건, Ceph 최적화는 단일 옵션 몇 개로 끝나는 작업이 아니라는 점이었습니다. 결국 아래 네 가지가 같이 맞아야 하더라고요.
네트워크 분리: 복제와 클라이언트 경로를 명확히 구분
풀 설계: 워크로드 성격에 맞춰 역할 분리
운영 습관: 오래된 스냅샷/클론 체인 방치 금지
관찰성: OpenStack 로그와 Ceph 상태를 함께 확인
스토리지 성능은 숫자 하나로 판단하기 어렵습니다. 어떤 환경에서는 작은 랜덤 I/O가 문제고, 또 어떤 환경에서는 이미지 배포 흐름이 더 큰 병목이 됩니다. 그래서 저는 요즘은 성능 문제가 나오면 먼저 “이게 Ceph 문제인가, OpenStack 스토리지 경로 문제인가, 아니면 둘 다인가?”부터 구분합니다.
검증 방법: 무엇을 확인해야 실제로 좋아졌다고 볼 수 있을까
개선 후에는 꼭 검증이 필요합니다. 그냥 느낌상 빨라진 것 같다고 넘어가면 다음 장애 때 다시 원점으로 돌아갑니다.
동일한 이미지로 인스턴스 부팅 시간을 여러 번 비교합니다.
동시에 여러 볼륨을 생성해 지연 패턴이 안정적인지 봅니다.
이미지 업로드와 볼륨 생성이 겹칠 때도 성능 저하가 과도하지 않은지 확인합니다.
Ceph 클러스터 상태가 테스트 중에도 안정적인지 체크합니다.
제가 직접 해보니, 단건 테스트보다 동시성 테스트가 훨씬 유의미했습니다. 평소엔 괜찮다가도 작업이 몰리면 바로 티가 나거든요. 드디어 됐다! 싶은 순간도 보통 이 구간을 통과했을 때였습니다.
openstack server list
openstack volume list
ceph -s
ceph df
rbd du -p volumes
검증할 때는 결과만 보지 말고, 테스트 중간에 경고가 발생하지 않는지도 꼭 보세요. 여기서 안정적이면 그제야 실제 운영에 올릴 만한 상태라고 판단합니다.
최적화 이전과 이후의 지연 안정성 차이를 비교하고, 운영자가 점검해야 할 항목을 요약한 이미지입니다.
실무적으로 정리하는 OpenStack 스토리지 운영 팁
항목
권장 접근
피해야 할 패턴
네트워크
스토리지 경로 분리
복제/서비스 트래픽 혼재
풀 설계
서비스별 역할 분리
모든 워크로드를 단일 풀에 집중
운영 관리
스냅샷/클론 주기적 점검
장기간 체인 방치
검증 방식
동시성 포함 반복 테스트
단건 테스트만으로 판단
이 표는 제가 나중에 운영 문서로도 정리해둔 기준입니다. 사실 OpenStack Ceph 연동은 한 번 붙이고 끝나는 프로젝트가 아니라, 붙인 뒤부터 운영 품질이 갈리는 영역입니다. 이전 글에서 다뤘던 기본 네트워크 설계와도 연결되는 부분이고, 다음 글에서는 Ceph 모니터링 포인트를 조금 더 깊게 다뤄볼 예정입니다.
마무리: 연동 성공보다 중요한 건 안정적인 성능입니다
오늘 정리한 실패 사례의 핵심은 단순합니다. OpenStack Ceph 연동이 되었더라도, 그 상태가 곧 최적 상태는 아니라는 점입니다. 저도 처음엔 연결만 되면 다 끝난 줄 알았는데, 실제 운영에서는 네트워크, 풀 설계, 스냅샷 체인, 작업 동시성까지 다 영향을 주더라고요. 삽질 좀 했습니다. 그래도 이런 과정을 겪고 나니 이제는 문제를 훨씬 빨리 좁힐 수 있게 됐습니다.
혹시 지금 OpenStack 스토리지 성능 때문에 답답하셨다면, 오늘 내용처럼 어디서 느려지는지 분리해서 보는 것부터 시작해보세요. 그게 가장 현실적인 첫걸음입니다. 그리고 Ceph 최적화는 무조건 큰 튜닝보다, 구조를 바르게 잡는 쪽이 효과가 더 컸습니다. 이 부분은 정말 경험상 그렇습니다.
연동 성공, 병목 원인 분리, 검증 절차, 운영 팁을 한 장으로 요약한 마무리 인포그래픽입니다.
정리 FAQ
Q. OpenStack Ceph 연동 후 가장 먼저 볼 것은 무엇인가요?
A. Ceph 클러스터 상태와 OpenStack 서비스별 풀/사용자 매핑입니다. 이 두 가지가 기본입니다.
Q. 스토리지 성능이 느리면 무조건 Ceph 튜닝부터 해야 하나요?
A. 아닙니다. 네트워크 경합, 풀 분리 부족, 스냅샷 체인 누적, OpenStack 작업 흐름까지 같이 봐야 합니다.
Q. OpenStack 스토리지 운영에서 가장 실수하기 쉬운 부분은 뭔가요?
A. 연동 성공을 성능 검증 완료로 착각하는 부분입니다. 꼭 동시성 테스트까지 해보셔야 합니다.
DevStack OpenStack 연동 문제는 생각보다 자주 만납니다. 설치는 얼추 끝난 것 같은데 인스턴스가 안 뜨고, 네트워크가 안 붙고, 이미지 조회는 되는데 부팅은 실패하고, 로그를 보면 Keystone(키스톤, 인증 서비스) 쪽 인증 에러가 한 줄씩 튀어나오거든요. 저도 홈랩에서 개발 환경을 구성하면서 이런 삽질을 꽤 했더라고요. 처음엔 서비스가 각각 살아 있으면 되는 줄 알았는데, 실제로는 서비스 간 엔드포인트(endpoint, 접속 지점), 메시지 큐(message queue), 데이터베이스(database), 서비스 사용자(service user) 권한이 한 군데만 어긋나도 전체 흐름이 무너집니다.
이번 글은 제품 홍보나 이론 소개가 아니라, 제가 직접 DevStack 개발 환경에서 반복적으로 겪었던 OpenStack 서비스 연동 문제를 어떤 순서로 확인하고 풀었는지 정리한 실전형 트러블슈팅 가이드입니다. 혹시 DevStack 트러블슈팅 하다가 로그만 한참 보고 계셨다면, 이 순서대로 점검해 보시면 시간 꽤 아끼실 수 있을 겁니다.
Keystone, Nova, Neutron, Glance, Cinder가 DevStack 환경에서 어떻게 연결되는지 한눈에 보여주는 개요 이미지입니다.
1. 왜 DevStack 개발 환경에서 OpenStack 서비스 연동 문제가 자주 생길까
쉽게 말해 DevStack은 빠르게 OpenStack을 올려서 개발과 검증을 하기 위한 환경입니다. 그래서 편한 점도 많지만, 반대로 서비스가 많고 연결 지점도 많습니다. 예를 들어 Nova(노바, 컴퓨트 서비스)가 인스턴스를 띄우려면 Keystone에서 토큰 인증을 받고, Glance(글랜스, 이미지 서비스)에서 이미지를 읽고, Neutron(뉴트론, 네트워크 서비스)에서 포트를 만들고, 필요하면 Cinder(신더, 블록 스토리지)까지 붙어야 하거든요.
즉, 화면에서 보이는 실패 증상은 하나인데 원인은 여러 군데일 수 있습니다. 여기서 중요한 포인트! 증상 기준으로 보지 말고 요청 흐름 기준으로 봐야 빨리 잡힙니다. 저도 처음엔 Horizon(호라이즌, 대시보드)에서 에러만 보고 있었는데, 실제 원인은 RabbitMQ(래빗MQ, 메시지 브로커) 연결 문제였던 적도 있더라고요.
2. OpenStack 서비스 연동을 흐름으로 이해하기
OpenStack 서비스 연동을 너무 어렵게 볼 필요는 없습니다. 요청 하나가 아래처럼 지나간다고 생각하시면 됩니다.
사용자 또는 CLI가 Keystone에 인증 요청을 보냅니다.
인증이 끝나면 서비스 카탈로그(service catalog, 서비스 목록)와 토큰을 받습니다.
Nova가 Glance, Neutron, Placement 같은 다른 서비스와 통신합니다.
백엔드에서는 메시지 큐와 데이터베이스가 중간 연결을 받쳐줍니다.
문제가 생기면 API 응답, 서비스 로그, 백엔드 연결 상태 중 하나가 어긋납니다.
구성 요소
역할
연동 실패 시 흔한 증상
Keystone
인증/권한/엔드포인트 관리
401 Unauthorized, endpoint not found
Nova
가상머신 생성 및 제어
인스턴스 build 실패, scheduling 오류
Neutron
네트워크/포트/IP 관리
포트 생성 실패, floating IP 연결 불가
Glance
이미지 저장 및 조회
이미지 다운로드 실패, boot from image 오류
Cinder
볼륨 제공
볼륨 attach 실패, device not found
이 표만 머리에 넣어도 DevStack OpenStack 연동 문제를 볼 때 훨씬 덜 막막합니다. 사실 로그를 읽는 요령도 결국은 어느 서비스가 다음 서비스를 못 찾고 있는지를 보는 거거든요.
3. DevStack 트러블슈팅 전에 먼저 확인할 기본 체크리스트
본격적으로 로그 보기 전에, 저는 아래 항목부터 먼저 봅니다. 사소해 보여도 여기서 많이 걸립니다.
호스트명과 IP: 서비스가 등록된 주소와 실제 바인딩 주소가 같은지
/etc/hosts: 로컬 이름 해석이 꼬이지 않았는지
시스템 시간: 토큰 인증 문제를 만들 정도로 시간 차이가 없는지
포트 리스닝 상태: 각 API 서비스가 실제로 떠 있는지
환경 변수: admin-openrc 같은 OpenRC 파일을 제대로 불러왔는지
제가 직접 해보니, OpenRC를 안 읽은 상태에서 CLI 테스트를 해서 Keystone 문제로 착각한 경우가 제일 허무했습니다. 드디어 원인 찾았다 싶었는데 그냥 환경 변수 누락이더라고요.
cd ~/devstack
source openrc admin admin
openstack token issue
openstack service list
openstack endpoint list
위 명령이 정상 동작하면 최소한 Keystone 인증과 서비스 카탈로그 조회는 된다는 뜻입니다. 여기서부터 하나씩 좁혀가면 됩니다.
4. 실전 구현: DevStack 환경에서 서비스 연동 상태 점검 순서
4-1. DevStack 설정 파일부터 다시 봅니다
local.conf에 서비스 활성화가 빠져 있거나, 비밀번호 변수 구성이 엇갈리면 설치는 돼도 연동이 흔들립니다. 아래는 가장 기본적인 예시입니다.
여기서는 이미지 상태가 active 인지, 접근 권한 문제는 없는지, Nova가 해당 이미지를 실제 읽을 수 있는지 확인합니다.
5-4. RabbitMQ 또는 DB 연결 문제로 서비스가 간헐적으로 실패하는 경우
이건 더 골치 아픕니다. 같은 명령이 한 번은 되고 한 번은 안 되거든요. 저도 실제로 써보니까 간헐 장애는 오히려 더 찾기 어렵더라고요.
sudo systemctl status rabbitmq-server
sudo systemctl status mariadb
sudo journalctl -u rabbitmq-server -n 100 --no-pager
메시지 큐나 DB 연결이 흔들리면 각 서비스 로그에 timeout, reconnect, access denied 같은 메시지가 섞여 나옵니다. 이럴 때는 개별 서비스보다 공통 백엔드부터 의심하는 게 빠릅니다.
여러 OpenStack 서비스 로그를 비교해서 장애 지점을 추적하는 실제 운영 감각의 트러블슈팅 이미지입니다.
6. 검증: 어디까지 확인해야 진짜 해결된 걸까
로그 한 줄 없어졌다고 끝난 건 아닙니다. 저는 아래 순서가 모두 통과하면 그제야 해결로 봅니다.
토큰 발급이 정상 동작한다.
서비스 목록과 엔드포인트가 정상 조회된다.
이미지, 네트워크, 플래버 목록 조회가 된다.
테스트 네트워크와 서브넷 생성이 된다.
테스트 인스턴스가 ACTIVE 또는 기대 상태로 전환된다.
필요 시 floating IP 연결 또는 콘솔 접속이 된다.
openstack token issue
openstack endpoint list
openstack network list
openstack subnet list
openstack image list
openstack server create --flavor m1.tiny --image cirros --network demo-net test-vm
openstack server list
openstack console url show test-vm
이 단계까지 가면 DevStack OpenStack 연동 문제는 대부분 정리됩니다. 물론 테스트 이미지나 플래버는 환경에 따라 다를 수 있으니, 현재 설치 상태에 맞게 조정하시면 됩니다.
서비스 연동이 정상화된 뒤 CLI와 대시보드에서 인스턴스, 네트워크, 이미지가 모두 보이는 결과 이미지입니다.
7. 빠른 진단 기준
증상
먼저 볼 곳
우선 점검 포인트
401 인증 오류
Keystone
OpenRC, 토큰, 서비스 사용자 비밀번호
인스턴스 생성 실패
Nova
Glance/Neutron/Placement 연동
포트 생성 실패
Neutron
agent 상태, 브리지 구성, endpoint
이미지 부팅 실패
Glance
이미지 상태, 접근 권한, API 응답
간헐적 timeout
RabbitMQ/DB
공통 백엔드 연결 안정성
이 표는 제가 실제로 자주 참고하는 기준입니다. 독자분들도 로그를 보기 전에 먼저 증상별 1차 의심 지점을 잡아두면 훨씬 덜 헤매실 겁니다.
8. 자주 묻는 질문과 실무 팁
Q1. 서비스가 모두 떠 있는데도 왜 연동이 안 될까요?
A. 프로세스가 떠 있는 것과 API 호출이 성공하는 것은 다릅니다. endpoint 등록, 권한, 환경 변수, 에이전트 상태를 같이 보셔야 합니다.
Q2. DevStack을 다시 설치하는 게 더 빠를 때도 있나요?
A. 있습니다. 특히 실험을 여러 번 반복하면서 설정이 꼬였을 때는 부분 수정보다 재구성이 빠를 때가 있더라고요. 다만 그 전에 왜 꼬였는지를 한 번 정리해 두면 다음부터 훨씬 빨라집니다.
Q3. 로그는 어디부터 봐야 하나요?
A. 사용자 요청이 처음 닿는 지점부터 보는 게 좋습니다. 예를 들어 인스턴스 생성 실패면 Nova API부터 보고, 그 다음 Neutron/Glance 쪽 연동 로그를 따라가는 방식이 효율적입니다.
💡 팁: CLI 테스트는 Horizon보다 원인 분리가 쉽습니다.
💡 팁: 한 번에 여러 문제를 고치지 말고, 한 항목씩 검증하세요.
💡 팁: 변경 전 endpoint 목록과 서비스 상태를 저장해 두면 비교가 편합니다.
인증, 네트워크, 이미지, 인스턴스 생성 문제를 어떤 순서로 점검할지 한 장으로 정리한 요약 인포그래픽입니다.
9. 마무리: DevStack 트러블슈팅의 핵심은 흐름을 보는 눈입니다
이번 글에서는 DevStack OpenStack 연동 문제를 단순히 에러 메시지별로 보는 대신, 서비스 요청 흐름 기준으로 점검하는 방법을 정리해 봤습니다. 저도 처음엔 서비스 이름이 너무 많아서 겁부터 났었는데, 실제로는 Keystone, Nova, Neutron, Glance, Cinder가 어떻게 이어지는지만 잡아도 절반은 해결되더라고요.
정리하면 이렇습니다. 인증이 되는지 확인하고, 엔드포인트가 맞는지 보고, 서비스별 실제 생성 요청을 날려보고, 공통 백엔드까지 확인한다. 이 순서가 DevStack 트러블슈팅에서 꽤 강력합니다. 다음 글에서는 DevStack 환경에서 Neutron 네트워크를 조금 더 깊게 파서, 브리지 구성과 외부 네트워크 연결 쪽도 따로 다뤄볼 예정입니다. 이전 글에서 다뤘던 OpenStack 기본 구성 이해 편이 있으시다면 같이 보시면 흐름 잡는 데 더 도움이 될 겁니다.
혹시 지금 비슷한 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라도 완전히 다른 자원 소비 패턴이 됩니다.
그래서 자원 최적화를 하려면 단순히 작은 플레이버를 늘리는 게 아니라, 어떤 워크로드를 어떤 비율로 태울지를 먼저 봐야 합니다. 사실 이걸 건너뛰면 플레이버만 바꾸고 결과는 그대로인 경우가 많더라고요.
현재 상태부터 점검해보세요: 유휴 자원은 숫자로 봐야 합니다
제가 직접 해보니 제일 먼저 해야 할 일은 플레이버를 새로 만드는 게 아니라, 지금 어떤 플레이버가 실제로 얼마나 쓰이는지 확인하는 일이었습니다. 감으로 보면 꼭 틀립니다. 특히 오래된 환경일수록 더 그렇거든요.
현재 등록된 플레이버 목록을 확인합니다.
인스턴스별로 어떤 플레이버가 얼마나 사용 중인지 집계합니다.
컴퓨트 노드별 vCPU, 메모리 사용률과 배치 불균형을 함께 봅니다.
실사용 대비 과대 할당된 표준 플레이버를 후보로 뽑습니다.
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 플레이버 재설계와 적용 순서
이제 실제로 손을 대볼 차례입니다. 제가 보통 쓰는 절차는 아래 순서입니다. 한 번에 다 바꾸려고 하면 사고 나요. 저도 예전에 급하게 정리하다가 사용자한테 왜 목록이 바뀌었냐는 문의를 한꺼번에 받았거든요.
위 예시는 어디까지나 구조 예시입니다. 수치는 각 환경의 하이퍼바이저(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(쿼터, 프로젝트별 자원 한도), 기본 템플릿, 셀프서비스 포털 가이드까지 같이 손봐야 합니다.
검증은 이렇게 보시면 됩니다: 자원 최적화가 됐는지 확인하는 법
변경 후에는 감이 아니라 지표로 보셔야 해요. 저는 보통 아래 네 가지를 같이 봅니다.
플레이버별 인스턴스 분포가 표준 세트로 모였는지
컴퓨트 노드별 메모리/CPU 편차가 줄었는지
새 인스턴스 배치 실패가 감소했는지
호스트 증설 시점을 뒤로 미룰 수 있는지
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 설계와 프로젝트별 자원 정책을 어떻게 묶어야 실제 프라이빗 클라우드 운영이 편해지는지 다뤄볼 예정입니다. 이전 글에서 다룬 하이퍼바이저 자원 모니터링 글과 함께 보셔도 흐름이 더 잘 잡히실 거예요.
표준화, 운영 정책, 비용 절감 포인트를 한 장으로 정리한 요약 이미지입니다.
✅ 오늘 내용만 실무에 적용해도, 플레이버 목록 정리와 기본값 개선만으로 꽤 큰 차이를 느끼실 가능성이 높습니다. 저도 처음엔 이게 뭔가 싶었는데, 막상 정리하고 나니 운영이 훨씬 덜 피곤해졌거든요.
Kolla-Ansible OpenStack 배포를 처음 고민하시는 분들은 거의 비슷한 지점에서 막히시더라고요. 저도 처음엔 ‘그냥 패키지 설치해서 올리면 되는 거 아닌가?’ 싶었는데, 실제로 해보니 배포 방식에 따라 운영 난이도와 장애 대응 속도가 꽤 많이 달랐습니다. 특히 홈랩과 사내 테스트베드에서 OpenStack 설치 비교를 여러 번 해보니까, 처음 설계할 때의 선택이 나중에 진짜 크게 돌아오더라고요. 이번 글에서는 Kolla-Ansible과 Native Install(네이티브 설치, 직접 패키지와 서비스 단위로 구성) 방식을 경험 기준으로 차분히 비교해보겠습니다.
혹시 지금 이런 상황이신가요? 빠르게 PoC(개념 검증, Proof of Concept)를 띄워야 하는데 운영 표준도 챙겨야 하고, 나중에 업데이트나 재배포도 염두에 두고 계신 분들 말입니다. 여기서 중요한 포인트는 단순히 ‘설치가 되느냐’가 아니라, 어떤 방식이 내 팀의 운영 역량과 더 잘 맞느냐입니다.
컨테이너 기반 Kolla-Ansible과 패키지 기반 Native Install의 구조 차이를 한눈에 보여주는 비교 다이어그램입니다.
Kolla-Ansible OpenStack 배포가 왜 주목받는지
쉽게 말해 Kolla-Ansible은 OpenStack 서비스를 컨테이너(Container, 애플리케이션 실행 단위)로 배포하고, Ansible(앤서블, 에이전트 없이 원격 설정을 자동화하는 도구)로 전체 구성을 밀어 넣는 방식입니다. 반면 Native Install은 각 노드에 필요한 패키지를 직접 설치하고, 서비스 설정 파일을 손으로 맞추거나 배포 자동화 스크립트를 따로 관리하는 흐름에 가깝습니다.
제가 직접 해보니 두 방식은 철학 자체가 다르더라고요. Kolla-Ansible은 표준화와 재현성에 강합니다. 반대로 Native Install은 세밀한 제어와 내부 이해에 강하죠. 처음엔 이게 뭔가 싶었는데, 몇 번 재설치를 반복하다 보니 왜 운영팀마다 선호 방식이 갈리는지 바로 이해됐습니다.
Kolla-Ansible: 컨테이너 기반, 역할 분리 명확, 재배포와 확장이 상대적으로 편함
Native Install: 서비스별 설정을 세밀하게 만질 수 있음, 학습에는 좋지만 운영 표준화가 어렵기 쉬움
공통점: 결국 Neutron(뉴트론, 네트워크 서비스), Nova(노바, 컴퓨트 서비스), Keystone(키스톤, 인증 서비스) 같은 핵심 컴포넌트를 이해해야 안정적으로 굴러감
OpenStack 설치 비교: 어떤 환경에 무엇이 맞을까
이제 본론으로 들어가 보겠습니다. OpenStack 설치 비교를 할 때는 설치 편의성만 보면 안 됩니다. 운영 중 변경 작업, 장애 복구, 로그 추적, 업그레이드 전략까지 같이 봐야 하거든요. 저도 예전엔 설치만 되면 끝이라고 생각했었는데, 그 뒤에 남는 유지보수 비용이 더 크더라고요. 삽질 좀 했습니다 ㅎㅎ
비교 항목
Kolla-Ansible
Native Install
배포 방식
컨테이너 이미지와 Ansible 플레이북 기반
패키지 설치와 서비스별 수동 설정 중심
초기 진입 장벽
변수 구조와 네트워크 이해가 필요
설치 흐름은 단순해 보이지만 전체 의존성 파악이 어려움
재현성
높음
운영자 숙련도에 따라 차이 큼
문제 분석
컨테이너 로그와 Ansible 결과를 함께 봐야 함
서비스 단위 로그 확인은 직관적이나 변경 이력 관리가 어려움
업데이트/재배포
자동화에 유리
절차 문서화가 부족하면 리스크 큼
추천 환경
반복 배포, 표준화, 다노드 테스트베드
학습용, 디버깅 중심, 서비스 구조 파악 목적
제 경험상 팀 단위 운영이라면 Kolla-Ansible 쪽이 훨씬 덜 힘들었습니다. 반면 OpenStack 내부 구조를 깊게 공부하려면 Native Install도 한 번은 꼭 해볼 만합니다. 왜냐하면 서비스가 어떤 순서로 붙고, 어디서 설정 충돌이 나는지 몸으로 익히게 되거든요.
Ansible OpenStack 구성 관점에서 보는 핵심 차이
1. 구성 관리 방식
Kolla-Ansible은 보통 전역 설정과 서비스별 오버라이드(override, 기본 설정 덮어쓰기)를 분리해서 관리합니다. 이게 처음엔 조금 낯설어요. 하지만 실제로 써보니까 역할(Role)과 변수(Variable)가 정리돼 있어서, 나중에 다시 볼 때 덜 헷갈리더라고요.
2. 네트워크 설계 난이도
OpenStack은 네트워크에서 많이 넘어집니다. 관리망, 터널망, 외부망을 어떻게 나눌지에 따라 Neutron 구성이 완전히 달라지니까요. Native Install은 서비스 설정 파일을 직접 만지는 만큼 자유도는 높지만, 실수 한 번 하면 어디서부터 틀어졌는지 찾는 데 시간이 오래 걸렸습니다.
3. 운영 표준화
운영 문서가 중요한 조직이라면 OpenStack 배포 자동화 측면에서 Kolla-Ansible이 확실히 유리합니다. 인벤토리(inventory, 관리 대상 호스트 목록)와 변수 파일만 정리되면 재현성이 좋거든요. 이건 새 장비 들어왔을 때 정말 체감됩니다.
컨트롤 노드, 컴퓨트 노드, 네트워크 노드 사이에서 Ansible과 컨테이너 서비스가 어떻게 연결되는지 보여주는 구성도입니다.
실전 구현: Kolla-Ansible로 OpenStack 배포 기본 흐름
이제 실전 쪽 이야기를 해보겠습니다. 여기서는 Kolla-Ansible OpenStack 배포의 전형적인 흐름을 예시로 보겠습니다. 배포판이나 릴리스에 따라 세부 패키지 이름은 조금 달라질 수 있으니, 실제 적용 전에는 운영 중인 환경 기준으로 문서를 꼭 맞춰보셔야 합니다. 저는 이런 식으로 접근하면 시행착오가 많이 줄더라고요.
이 순서대로 가면 됩니다. 특히 prechecks는 꼭 보셔야 해요. DNS, 시간 동기화, 인터페이스 정의 같은 기본 조건이 여기서 많이 걸립니다.
5. OpenStack 클라이언트 환경 적용
source /etc/kolla/admin-openrc.sh
openstack service list
openstack network agent list
openstack hypervisor list
여기까지 오면 1차 확인은 끝입니다. 서비스 카탈로그(Service Catalog, API 엔드포인트 목록)와 하이퍼바이저(Hypervisor, 가상화 호스트) 인식 상태를 먼저 보는 습관을 들이면 좋습니다.
Kolla-Ansible 배포 과정에서 사전 점검과 실제 배포가 진행되는 흐름을 홈랩 분위기로 표현한 이미지입니다.
반대로 Native Install은 언제 유리할까
그렇다고 Native Install이 무조건 불리한 건 아닙니다. 저도 실제로 써보니까 서비스 구조를 이해하는 데는 정말 도움이 컸습니다. 예를 들어 Keystone 설정이 어디서 인증 토큰 흐름에 영향을 주는지, Neutron ML2 플러그인(ML2 Plugin, 네트워크 드라이버 프레임워크)과 브리지 설정이 어떻게 맞물리는지 직접 보게 되거든요.
특히 이런 경우엔 Native Install도 충분히 가치 있습니다.
단일 노드 학습 환경을 빠르게 만들고 싶을 때
컨테이너 추상화보다 서비스 파일과 로그를 직접 보고 싶을 때
특정 컴포넌트의 동작을 깊게 디버깅해야 할 때
자동화보다 구조 이해가 우선일 때
다만 운영 관점에서는 사람이 바뀌거나 시간이 지나면 설정이 점점 꼬이기 시작합니다. 정말 많이 봤거든요. 문서가 조금만 부실해도 ‘이 설정 누가 왜 넣었지?’가 반복되더라고요.
⚠️ 주의사항과 트러블슈팅: 제가 실제로 막혔던 포인트
1. 시간 동기화(NTP, Network Time Protocol) 문제
OpenStack은 인증 토큰과 서비스 통신에서 시간 차이에 민감합니다. Kolla-Ansible이든 Native Install이든 노드 간 시간이 어긋나면 묘한 인증 실패가 납니다. 겉으로는 네트워크 문제처럼 보이는데, 알고 보면 시계 문제인 경우가 있더라고요.
2. 네트워크 인터페이스 이름 불일치
이건 홈랩에서 특히 자주 나옵니다. 예전 문서 보고 eth0, eth1으로 적어놨는데 실제 장비는 ens18, ens19인 경우요. 별거 아닌 오타 같은데 외부 네트워크 바인딩이 안 되고 Floating IP(플로팅 IP, 외부 접근용 가상 IP)도 꼬입니다.
3. 컨테이너는 떠 있는데 서비스가 비정상
Kolla-Ansible에서 흔히 겪는 착시입니다. docker ps나 podman ps 기준으로는 떠 있어도, 내부 서비스가 정상 등록되지 않았을 수 있습니다. 그래서 저는 항상 컨테이너 상태만 보지 않고 OpenStack API 응답까지 같이 확인합니다.
4. Native Install의 설정 드리프트(Configuration Drift, 설정 불일치)
처음엔 한 대에서 잘 되는데, 두 번째 노드부터 미묘하게 설정이 다르기 시작합니다. 결국 장애가 나면 원인 추적이 어려워져요. 여기서 중요한 포인트는 자동화되지 않은 반복 작업은 결국 누락을 만든다는 점입니다.
⚠️ 사전 점검 체크리스트를 문서화하세요
⚠️ 네트워크 맵과 인터페이스명을 먼저 확정하세요
⚠️ 배포 직후 서비스 목록, 에이전트 목록, 하이퍼바이저 목록을 반드시 확인하세요
💡 장애 분석 시에는 인프라 로그와 OpenStack API 결과를 같이 보세요
검증과 결과 확인: 배포 후 무엇을 보면 되나
Kolla-Ansible OpenStack 배포가 끝났다고 바로 안심하면 안 됩니다. 실제 검증은 이제부터거든요. 저는 보통 아래 순서로 확인합니다.
Keystone 인증 정상 여부 확인
Nova 컴퓨트 서비스 등록 확인
Neutron 에이전트 상태 확인
Horizon 대시보드 접속 확인
테스트 네트워크와 인스턴스 생성 확인
source /etc/kolla/admin-openrc.sh
openstack token issue
openstack compute service list
openstack network agent list
openstack image list
openstack server list
실제로 써보니까 이 단계에서 가장 중요한 건 ‘서비스가 보이느냐’보다 ‘실제 워크로드가 도는가’였습니다. 테스트 인스턴스 하나 띄워보고, 네트워크 붙이고, 콘솔 접속까지 해보면 훨씬 확실합니다. 🎉
Horizon 대시보드와 CLI 결과를 통해 배포 성공 여부를 교차 검증하는 장면입니다.
정리: 어떤 선택이 더 현실적인가
결론부터 말씀드리면, 반복 가능한 운영 환경이 목표라면 Kolla-Ansible 쪽이 더 현실적입니다. 특히 팀 단위로 관리하거나 테스트베드를 여러 번 재현해야 한다면 OpenStack 배포 자동화의 장점이 확실히 드러납니다. 반면 Native Install은 구조 학습과 세밀한 디버깅에 강합니다. 저도 처음엔 Native Install로 내부를 익히고, 나중엔 Kolla-Ansible 쪽으로 운영 방식을 옮겨가는 흐름이 가장 자연스러웠습니다.
혹시 지금 둘 중 하나를 선택해야 하는 상황이라면 이렇게 보시면 됩니다.
빠른 표준화와 재배포가 필요하다면 Kolla-Ansible
OpenStack 내부 구조 학습이 우선이라면 Native Install
장기 운영까지 본다면 자동화와 문서화가 쉬운 쪽을 선택
다음 글에서는 Kolla-Ansible 환경에서 네트워크 분리와 외부망 연결, 특히 Neutron 브리지 구성을 조금 더 깊게 다뤄볼 예정입니다. 이전 글에서 다뤘던 리눅스 브리지와 VLAN 설계 내용을 같이 보시면 훨씬 이해가 빠르실 거예요.
두 배포 방식의 선택 기준과 운영 포인트를 빠르게 복습할 수 있도록 정리한 요약 인포그래픽입니다.
자주 묻는 질문
Q1. 처음 배우는 입장에서는 어떤 방식이 더 나을까요?
OpenStack 구조를 제대로 익히고 싶다면 Native Install을 한 번 경험해보는 게 도움이 됩니다. 다만 실제 운영까지 바로 생각하신다면 Kolla-Ansible이 더 덜 고생스럽습니다.
Q2. 홈랩에서는 어떤 쪽이 더 적합한가요?
반복 실험이 많고 초기화 후 다시 띄우는 일이 잦다면 Kolla-Ansible이 편합니다. 반대로 서비스별 설정을 직접 뜯어보고 싶은 학습형 홈랩이라면 Native Install도 괜찮습니다.
Q3. Ansible OpenStack 구성은 운영팀에도 유리한가요?
네, 인벤토리와 변수 파일 기준으로 변경 이력을 관리하기 쉬워서 협업에 유리합니다. 특히 사람 손을 덜 타게 만드는 점이 큽니다.
Q4. OpenStack 설치 비교에서 가장 먼저 봐야 할 기준은 뭔가요?
설치 성공 여부보다 재현성, 운영 문서화, 장애 대응 흐름을 먼저 보시는 게 좋습니다. 결국 오래 남는 건 운영 부담이거든요.
OpenStack 멀티노드 운영을 1년 정도 굴려보면, 설치가 끝이라고 생각했던 시점부터 진짜 일이 시작되더라고요. 저도 처음엔 “컨트롤 플레인(control plane, 제어 영역)만 안정적이면 되겠지”라고 가볍게 봤었는데, 실제로 써보니까 네트워크, 스토리지, 메시지 큐(message queue, 비동기 작업 전달), 그리고 운영 절차가 전부 엮여 있어서 한 군데만 흔들려도 전체가 불안해졌습니다. 혹시 랩 환경(home lab, 개인 실험실)에서 잘 되던 구성이 운영 구간에서 갑자기 말을 안 들어서 당황하신 적 있으신가요? 오늘은 제가 직접 겪은 OpenStack 클러스터 후기, 그리고 OpenStack 배포 실패 사례까지 솔직하게 묶어서 정리해보겠습니다.
이 글은 특정 배포판 홍보가 아니라, OpenStack 멀티노드 운영에서 실제로 부딪히는 포인트를 중심으로 썼습니다. 다음 글에서는 Ceph(세프, 분산 스토리지) 연동 쪽도 따로 다룰 예정이고, 이전 글에서 다뤘던 가상화 호스트 설계 내용이 있다면 함께 보시면 흐름이 더 잘 잡히실 겁니다.
컨트롤 노드, 컴퓨트 노드, 네트워크 경로가 한눈에 보이는 OpenStack 멀티노드 운영 아키텍처 예시입니다.
왜 OpenStack 멀티노드 운영은 설치보다 운영이 더 어렵나
쉽게 말해 OpenStack은 하나의 프로그램이 아니라 여러 서비스의 연합체더라고요. Keystone(키스톤, 인증), Nova(노바, 컴퓨트), Neutron(뉴트론, 네트워크), Glance(글랜스, 이미지), Cinder(신더, 블록 스토리지) 같은 서비스가 각자 잘 떠 있어야 하고, 서로 API 호출도 정상이어야 합니다. 설치 문서는 대부분 “어떻게 올릴까”에 집중하는데, 운영은 “문제가 났을 때 어디부터 볼까”가 핵심이거든요.
제가 1년 운영하면서 느낀 건 딱 세 가지였습니다.
장애는 단일 원인처럼 보이지만 실제론 연쇄 장애인 경우가 많습니다.
성능 문제보다 상태 일관성(state consistency, 서비스 간 상태 맞춤) 문제가 더 까다롭습니다.
사람이 반복하는 운영 작업은 결국 사고로 이어집니다.
예를 들어 인스턴스(instance, 가상 머신) 생성 실패가 떴다고 해서 꼭 Nova 문제는 아니었습니다. 메시지 브로커(broker, 중간 전달자) 지연, Neutron 포트 생성 실패, 데이터베이스 연결 수 부족 같은 식으로 옆 서비스 이슈가 튀어나오는 경우가 꽤 많았거든요. 처음엔 이게 뭔가 싶었는데, 로그를 몇 번 따라가다 보면 OpenStack은 결국 관계도 싸움이라는 걸 알게 됩니다.
운영 전에 잡아야 했던 기본 원칙
여기서 중요한 포인트! OpenStack 멀티노드 운영은 기술 스택보다 운영 원칙을 먼저 정하는 게 훨씬 중요합니다. 저는 초반에 이걸 대충 잡았다가 삽질 좀 했습니다 ㅎㅎ
영역
초기 생각
1년 뒤 결론
네트워크
가능하면 단순하게
관리망, 스토리지망, 테넌트망 분리가 운영 피로를 줄임
스토리지
일단 붙으면 된다
장애 복구 절차와 성능 특성까지 같이 봐야 함
로그
문제 생기면 그때 확인
중앙 수집 없으면 원인 추적 시간이 급격히 늘어남
배포
처음 한 번만 성공하면 됨
재현 가능한 자동화가 없으면 다음 장애 때 무너짐
모니터링
CPU, 메모리만 보면 됨
API 지연, 큐 적체, DB 연결 상태까지 봐야 함
특히 네트워크는 정말 중요했습니다. Neutron이 들어가는 순간 브리지(bridge, 가상 스위치), VLAN(가상 랜), 오버레이 네트워크(overlay network, 가상 터널 네트워크) 이해도가 부족하면 “핑은 되는데 VM 통신은 안 됨” 같은 상황이 자주 생깁니다. 이거 진짜 사람 멘탈 흔듭니다.
제가 실제로 사용한 운영 구조와 체크 포인트
구성 자체는 전형적인 멀티노드 방식이었습니다. 컨트롤 노드에 API와 스케줄러 계열을 두고, 컴퓨트 노드에서 하이퍼바이저(hypervisor, 가상화 실행 계층)를 돌리고, 네트워크는 별도 역할을 분리하거나 최소한 경로를 명확히 나눴습니다. 여기에 MariaDB(마리아디비, 관계형 데이터베이스), RabbitMQ(래빗엠큐, 메시지 큐), HAProxy(에이치에이프록시, 로드밸런서)를 조합하면 기본 뼈대는 갖춰집니다.
배포 자동화는 도구마다 방식이 다르지만, 원칙은 비슷합니다.
호스트 이름과 DNS를 먼저 고정합니다.
NTP 또는 Chrony로 시간 동기화를 맞춥니다.
관리망 IP와 서비스 엔드포인트(endpoint, 서비스 접속 주소)를 문서화합니다.
메시지 큐와 데이터베이스 상태를 먼저 확인합니다.
그다음 OpenStack 서비스 등록과 에이전트(agent, 백그라운드 작업 프로세스) 상태를 검증합니다.
제가 자주 쓰던 점검 명령은 이런 식이었습니다.
openstack service list
openstack endpoint list
openstack compute service list
openstack network agent list
openstack hypervisor list
openstack server list --all-projects
처음엔 서비스 목록만 보고 안심했었는데, 실제로는 에이전트가 살아 있어도 기능이 망가진 경우가 있더라고요. 그래서 저는 아래처럼 시스템 레벨도 꼭 같이 확인했습니다.
여기서 핵심은 “OpenStack 명령 결과”와 “OS 레벨 상태”를 분리해서 보는 겁니다. 둘 중 하나만 보면 꼭 놓치는 구간이 생깁니다.
Keystone, Nova, Neutron, RabbitMQ, MariaDB가 어떤 흐름으로 연결되는지 설명하는 구성 다이어그램 위치입니다.
실전 구현에서 효과 있었던 운영 습관
프로덕션 OpenStack 회고 관점에서 보면, 기술보다 습관이 더 오래 남습니다. 제가 1년 동안 남긴 것 중 실제로 가장 도움이 됐던 건 아래 네 가지였습니다.
변경 작업 전 체크리스트 작성 패키지 업데이트, 네트워크 설정 변경, 서비스 재시작 전후 확인 항목을 고정했습니다.
설정 파일 차이(diff, 변경점) 기록 나중에 왜 바꿨는지 기억이 안 나는 순간이 오거든요.
장애 재현 메모 증상, 원인 후보, 실제 원인, 해결 순서를 남겨두면 다음 장애 때 시간이 확 줄어듭니다.
작은 자동화라도 바로 적용 반복 명령은 셸 스크립트(shell script, 명령 자동화)로 묶었습니다.
예를 들면 컴퓨트 노드 상태 점검은 간단한 스크립트로 묶어두면 꽤 편합니다.
#!/usr/bin/env bash
set -eu
echo '[1] hypervisor list'
openstack hypervisor list
echo '[2] compute services'
openstack compute service list
echo '[3] failed services'
systemctl --failed
echo '[4] recent nova-compute logs'
journalctl -u nova-compute -n 50 --no-pager
이런 건 거창하지 않아도 됩니다. 중요한 건 사람 손을 덜 타게 만드는 것입니다. 제가 직접 해보니 OpenStack 배포 실패 사례 중 꽤 많은 비율이 설치 자체보다, 설치 후 운영 절차 부재에서 시작됐습니다.
⚠️ 실제로 크게 데였던 장애와 해결 과정
1. 메시지 큐 지연으로 인한 인스턴스 생성 실패
증상은 단순했습니다. VM 생성 요청은 들어가는데 완료가 안 되는 겁니다. 처음엔 Nova 스케줄러를 의심했는데, 로그를 따라가 보니 RabbitMQ 큐 적체가 원인이었습니다. 관리망 지연이 누적되면서 RPC(Remote Procedure Call, 원격 호출) 응답이 늦어졌고, 결국 타임아웃이 연쇄적으로 터졌습니다.
배운 점: API 장애처럼 보여도 메시지 경로를 꼭 봐야 합니다.
해결 방법: 큐 상태 확인, 관리망 상태 점검, 재시작 순서 표준화
2. Neutron 포트 생성은 되는데 통신이 안 되는 문제
이건 정말 오래 잡았습니다. 보안 그룹(security group, 가상 방화벽) 문제처럼 보였는데, 실제로는 브리지 매핑(bridge mapping, 네트워크 연결 규칙)과 물리 NIC 연결 정의가 어긋나 있었습니다. 로그상 큰 에러가 안 보여서 더 헷갈렸고요. 저도 처음엔 헷갈렸는데, 결국 에이전트 설정과 호스트 네트워크 구성이 서로 맞아야 한다는 너무 당연한 사실을 다시 배웠습니다.
배운 점: Neutron 문제는 논리 설정과 물리 연결을 같이 봐야 합니다.
해결 방법: 브리지 이름, 인터페이스 매핑, 에이전트 상태를 한 번에 점검
3. 스토리지 연결은 되는데 성능이 들쭉날쭉한 상황
이건 더 무서운 유형입니다. 완전히 죽는 게 아니라 “어제는 괜찮았는데 오늘은 왜 느리지?”가 반복되거든요. 결국 원인은 백엔드 스토리지 경로 경쟁, 작업 몰림, 그리고 이미지 캐시 처리 타이밍이 겹친 문제였습니다. 숫자를 괜히 지어내고 싶진 않아서 구체 수치는 빼겠지만, 체감 성능 차이는 꽤 컸습니다.
배운 점: 스토리지는 붙어 있는지만 보지 말고 패턴을 봐야 합니다.
해결 방법: 작업 시간대 분산, 캐시 정책 점검, 백엔드 모니터링 강화
4. 데이터베이스는 살아 있는데 API가 간헐적으로 느린 문제
이건 딱 “다 살아 있는데 왜 느리지?” 케이스였네요. DB 연결 수, 느린 쿼리(slow query, 지연 질의), 서비스 재시도 패턴이 겹치면서 간헐 지연이 생겼습니다. 이런 문제는 재시작으로 잠깐 가려질 수 있어서 더 위험합니다. 드디어 됐다! 싶었는데 다음날 다시 터지더라고요.
정리하면, OpenStack 멀티노드 운영에서 가장 위험한 장애는 완전 다운보다 반쯤 되는 장애입니다. 운영자가 방심하기 쉽거든요.
로그 추적, 큐 적체 확인, 네트워크 흐름 분석을 한 번에 보여주는 운영 관제 이미지 위치입니다.
문제 줄이기 위해 정착시킨 검증 절차
문제가 생긴 뒤 고치는 것도 중요하지만, 더 중요한 건 변경 후 검증입니다. 저는 아래 순서로 체크했습니다.
인증 확인: 토큰 발급과 서비스 카탈로그(service catalog, 서비스 목록) 확인
컴퓨트 확인: 하이퍼바이저 목록과 서비스 up/down 상태 확인
네트워크 확인: 네트워크 생성, 서브넷 연결, 포트 생성 테스트
부팅 확인: 테스트 인스턴스 생성 후 콘솔 접속 확인
삭제 확인: 인스턴스 삭제, 볼륨 정리, 포트 잔존 여부 확인
간단한 검증 흐름 예시는 이렇습니다.
openstack token issue
openstack network create lab-net
openstack subnet create --network lab-net --subnet-range 192.168.50.0/24 lab-subnet
openstack server create --flavor m1.small --image test-image --network lab-net test-vm
openstack server list
openstack console url show test-vm
여기서 중요한 건 생성만 보는 게 아니라 삭제와 정리까지 확인하는 겁니다. 리소스 찌꺼기(resource orphan, 고아 리소스)가 쌓이기 시작하면 나중에 장애 분석이 훨씬 더 어려워집니다.
1년 운영 후 남은 성과와 아쉬움
🎉 성과부터 말하면, 운영 초반보다 장애 대응 시간이 눈에 띄게 줄었습니다. 원인은 대단한 튜닝이 아니라, 로그 보는 순서와 점검 절차가 정리됐기 때문이었습니다. OpenStack 클러스터 후기를 한 줄로 줄이면 이겁니다. 복잡성은 줄이지 못해도, 복잡성을 다루는 방법은 개선할 수 있다.
반대로 아쉬움도 분명했습니다.
초기 아키텍처 문서를 너무 늦게 정리했습니다.
네트워크 변경 이력을 더 일찍 표준화했어야 했습니다.
테스트 환경과 운영 환경 차이를 가볍게 보면 안 됐습니다.
“지금 되니까 괜찮다”는 판단이 가장 위험했습니다.
특히 프로덕션 OpenStack 회고를 하면서 느낀 건, 운영자는 문제를 해결하는 사람인 동시에 문제가 다시 생기지 않게 만드는 사람이어야 한다는 점이었습니다. 근데 이게 말처럼 쉽진 않죠. 문서화는 귀찮고, 자동화는 미루기 쉽고, 장애는 꼭 바쁠 때 옵니다.
운영 절차 정리 전후의 안정화 흐름과 핵심 교훈을 비교하는 요약 시각화 이미지 위치입니다.
OpenStack 멀티노드 운영 정리: 지금 다시 시작한다면
💡 제가 지금 다시 처음부터 OpenStack 멀티노드 운영을 구성한다면 아래 순서로 갑니다.
네트워크 분리 설계부터 문서화합니다.
배포 자동화를 처음부터 전제로 둡니다.
공통 로그와 모니터링을 설치 초기에 붙입니다.
테스트 VM 생성/삭제 검증을 표준 절차로 만듭니다.
장애 기록 템플릿을 운영 첫날부터 사용합니다.
이 다섯 개만 지켜도 OpenStack 배포 실패 사례의 상당수를 예방할 수 있습니다. 물론 환경마다 디테일은 다를 겁니다. 그래도 뼈대는 비슷하더라고요. 특히 OpenStack 멀티노드 운영은 “한 번 설치 성공”보다 “열 번 재현 가능”이 훨씬 값집니다.
자주 묻는 질문
Q1. 홈랩에서도 멀티노드가 의미가 있나요?
있습니다. 오히려 작은 환경에서 역할 분리와 장애 흐름을 이해하기 좋습니다. 다만 과한 고가용성(HA, 고장 대비 이중화)보다는 기본 동작과 복구 절차부터 익히는 게 낫습니다.
Q2. 가장 먼저 모니터링해야 할 것은 뭔가요?
CPU나 메모리보다 먼저 API 응답 지연, 메시지 큐 적체, 데이터베이스 연결 상태, 네트워크 에이전트 상태를 보시는 걸 권합니다.
Q3. 설치 도구보다 중요한 건 뭔가요?
운영 문서, 변경 이력, 검증 절차입니다. 도구는 바꿀 수 있지만 운영 습관은 쉽게 안 바뀌거든요.
마무리
1년 동안 OpenStack 멀티노드 클러스터를 운영하면서 느낀 건, OpenStack은 화려한 기능보다 기본기가 훨씬 중요하다는 점이었습니다. 서비스 간 관계를 이해하고, 장애를 추적하는 순서를 만들고, 변경을 기록하는 것. 이 세 가지가 결국 운영 품질을 갈랐습니다. 저도 처음엔 “왜 이렇게 복잡하지?” 싶었는데, 하나씩 뜯어보니 결국 시스템은 거짓말을 안 하더라고요.
혹시 지금 OpenStack 멀티노드 운영을 준비 중이시라면, 설치 성공 화면에서 끝났다고 생각하지 마시고 검증 절차부터 붙여보세요. 그게 나중에 가장 큰 차이를 만듭니다. 다음 글에서는 스토리지 연동과 백업 전략 쪽을 더 현실적으로 풀어보겠습니다. ✅
![[OpenStack] OpenStack Ceph 성능 병목과 실전 해결 방안](https://blog.pswq.net/wp-content/uploads/2026/09/openstack-ceph-performance-troubleshooting-thumbnail.jpg)
![[OpenStack] 오픈스택 운영 회고: 안정성, 비용, 그리고 인프라 관리의 핵심](https://blog.pswq.net/wp-content/uploads/2026/08/openstack-3year-operation-retrospective-lessons-thumbnail.jpg)
![[OpenStack] OpenStack 프라이빗 클라우드 보안 강화: 최신 감사 보고서 분석 및 대응 전략](https://blog.pswq.net/wp-content/uploads/2026/08/openstack-private-cloud-security-audit-analysis-thumbnail.jpg)
![[OpenStack] OpenStack 업그레이드 10가지 체크리스트: 실전 베스트 프랙티스로 성공 확률 높이기](https://blog.pswq.net/wp-content/uploads/2026/08/openstack-upgrade-checklist-best-practices-thumbnail.jpg)
![[인프라] OpenStack Ceph 연동 실패 사례와 스토리지 성능 최적화 교훈](https://blog.pswq.net/wp-content/uploads/2026/07/openstack-ceph-integration-failure-case-study-thumbnail.jpg)
![[OpenStack] DevStack 환경에서 OpenStack 서비스 간 연동 문제 해결 가이드](https://blog.pswq.net/wp-content/uploads/2026/07/devstack-openstack-inter-service-troubleshooting-thumbnail.jpg)
![[OpenStack] 오픈스택 플레이버 최적화로 유휴 자원 줄이기](https://blog.pswq.net/wp-content/uploads/2026/07/openstack-flavor-optimization-cost-saving-thumbnail.jpg)
![[OpenStack] Kolla-Ansible vs Native Install: 배포 방식 비교 분석](https://blog.pswq.net/wp-content/uploads/2026/07/kolla-ansible-vs-native-install-openstack-deployment-comparison-thumbnail.jpg)
![[인프라] OpenStack 멀티노드 클러스터 1년 운영 회고](https://blog.pswq.net/wp-content/uploads/2026/07/openstack-multi-node-cluster-1year-retrospective-thumbnail.jpg)
