[OpenStack] OpenStack Glance 이미지 관리, 효율적인 스토리지 활용 전략

목차

• 1. 왜 Glance 스토리지 전략이 먼저 잡혀야 할까
• 2. OpenStack Glance 이미지 관리 핵심 개념 정리
• 2-1. 자주 보는 용어
• 2-2. 어떤 백엔드가 비용 효율적일까
• 3. 비용을 줄이는 첫 번째 방법: 업로드 전 이미지 최적화
• 3-1. 업로드 전 점검 순서
• 4. 실전 구현: Glance 스토리지 구성 전략
• 4-1. 단순한 filesystem 기반 예시
• 4-2. Ceph RBD 기반 예시
• 4-3. 이미지 분류 정책까지 같이 가야 합니다
• 5. ⚠️ 운영 중 자주 겪는 문제와 트러블슈팅
• 5-1. 업로드는 되는데 부팅이 안 되는 경우
• 5-2. 오래된 이미지가 안 지워지는 경우
• 5-3. 이미지가 너무 많아서 관리가 안 되는 경우
• 6. 검증: 결과는 어떻게 확인할까
• 6-1. 제가 보는 체크리스트
• 7. 비용 관점에서 추천하는 운영 습관
• 8. 정리와 다음 단계
• 자주 묻는 질문

[OpenStack] OpenStack Glance 이미지 관리, 효율적인 스토리지 활용 전략

OpenStack Glance 이미지 관리가 생각보다 금방 스토리지를 잡아먹는다는 점, 운영해보신 분들은 아마 바로 공감하실 겁니다. 처음엔 이미지 몇 개 올리는 정도라서 괜찮아 보이는데, 팀이 늘고 프로젝트가 늘고 베이스 이미지가 조금씩 갈라지기 시작하면 디스크 사용량이 갑자기 튀더라고요. 저도 홈랩이랑 테스트 클러스터를 같이 굴리면서 이 부분에서 삽질 좀 했습니다 ㅎㅎ 특히 같은 계열의 Ubuntu(우분투)나 Rocky Linux(로키 리눅스) 이미지를 여러 버전으로 쌓아두다 보니, 관리보다 저장 공간이 더 큰 고민이 되더군요.

이번 글에서는 OpenStack Glance 이미지 관리를 비용 관점에서 다시 정리해보겠습니다. 단순히 이미지를 올리고 지우는 수준이 아니라, 어떤 백엔드 스토리지(back-end storage, 이미지가 실제 저장되는 저장소)를 고를지, 업로드 전 이미지를 어떻게 다듬을지, 그리고 운영 중 어떤 기준으로 정리해야 클라우드 스토리지 비용과 관리 복잡도를 같이 낮출 수 있는지 경험 위주로 풀어보겠습니다.

Glance, Nova, Ceph 또는 파일 스토리지 간의 관계를 한눈에 보여주는 전체 구성도입니다.

1. 왜 Glance 스토리지 전략이 먼저 잡혀야 할까

쉽게 말해 Glance(글랜스)는 가상머신 이미지 창고입니다. 그런데 창고라고 해서 무조건 크게만 만들면 되는 건 아니거든요. 이미지가 한 번 올라오면 여러 프로젝트에서 반복 사용되고, 템플릿처럼 복제되고, 오래된 이미지가 방치되기 쉽습니다. 결국 Glance 스토리지는 성능만의 문제가 아니라 운영비와 정리 습관의 문제이기도 합니다.

제가 직접 해보니 흔히 생기는 패턴이 이렇습니다. 처음엔 테스트용 이미지 3~4개로 시작합니다. 그러다 패키지를 미리 넣은 커스텀 이미지가 생기고, 보안 패치 반영본이 생기고, 긴급 롤백용 이전 이미지까지 남기게 됩니다. 여기서 중요한 포인트! 이미지가 늘어나는 속도는 생각보다 빠른데, 줄어드는 속도는 거의 0에 가깝습니다. 그래서 초반에 정책 없이 시작하면 나중에 정리 비용이 더 커집니다.

• 공용 베이스 이미지와 프로젝트 전용 이미지를 구분해야 합니다.
• 업로드 전 최적화를 하지 않으면 같은 용도의 이미지도 용량 차이가 크게 납니다.
• 백엔드 선택에 따라 확장성, 운영 난이도, 장애 대응 방식이 달라집니다.
• 수명주기 정책이 없으면 오래된 이미지가 계속 남습니다.

2. OpenStack Glance 이미지 관리 핵심 개념 정리

저도 처음엔 헷갈렸는데, Glance는 이미지를 보관하고 메타데이터(metadata, 이미지 설명 정보)를 관리하는 역할에 가깝습니다. 실제 이미지 파일은 별도 저장소에 들어갑니다. 이 저장소가 filesystem(파일시스템), Ceph RBD(분산 블록 스토리지), Swift(오브젝트 스토리지) 같은 형태로 붙는 거죠.

2-1. 자주 보는 용어

• Image format(이미지 포맷): qcow2, raw 같은 디스크 이미지 형식입니다.
• Store(스토어): Glance가 실제 데이터를 저장하는 대상입니다.
• Visibility(가시성): public, private, community처럼 누가 볼 수 있는지 정하는 속성입니다.
• Checksum / Hash(무결성 검증값): 업로드 중 손상 여부를 확인할 때 중요합니다.

2-2. 어떤 백엔드가 비용 효율적일까

정답은 환경마다 다릅니다. 다만 원칙은 있습니다. 작은 단일 노드 환경이나 랩 환경에서는 filesystem이 단순하고 빠릅니다. 반대로 운영 클라우드처럼 확장성과 장애 대응이 중요하면 Ceph 같은 분산 스토리지가 훨씬 편해집니다. Swift도 오브젝트 스토리지 특성상 장점이 있지만, 실제 운영에서는 팀의 익숙함과 기존 스택 영향을 많이 받습니다.

백엔드	장점	주의할 점	추천 상황
Filesystem	구성이 단순하고 빠르게 시작 가능	확장성과 이중화 설계가 직접 필요	소규모 랩, 단일 리전 테스트
Ceph RBD	확장성과 고가용성, 운영 일관성 확보에 유리	초기 학습비용과 클러스터 운영 난이도 존재	중대형 프라이빗 클라우드
Swift	오브젝트 스토리지 기반 운영에 적합	조직 내 운영 경험이 없으면 진입장벽이 있음	기존 Swift 활용 조직

3. 비용을 줄이는 첫 번째 방법: 업로드 전 이미지 최적화

이미지 최적화는 생각보다 효과가 큽니다. 사실 많은 팀이 스토리지 백엔드부터 바꾸려고 하는데, 저는 그 전에 업로드 대상 이미지부터 정리하는 쪽을 먼저 권합니다. 이유는 간단합니다. 불필요하게 큰 이미지를 아무리 좋은 스토리지에 넣어도 낭비는 그대로거든요.

실제로 써보니까 가장 기본은 세 가지였습니다. 첫째, 정말 필요한 패키지만 넣기. 둘째, 임시 파일과 캐시 비우기. 셋째, raw가 꼭 필요한 환경이 아니라면 qcow2를 우선 검토하기. 물론 성능이나 호환성 요구사항 때문에 raw가 필요한 경우도 있습니다. 그래서 무조건 하나만 고집하면 안 되고, 목적별로 나누는 게 좋습니다.

3-1. 업로드 전 점검 순서

1. 이미지 내부의 로그, 패키지 캐시, 임시 파일을 정리합니다.
2. Cloud-init(클라우드 초기화 도구) 설정이 남아 있는지 확인합니다.
3. 필요한 디스크 포맷을 결정합니다.
4. 이미지 속성과 용도를 메모해 둡니다.

# 이미지 정보 확인
qemu-img info ubuntu-base.qcow2

# 필요 시 다른 포맷으로 변환
qemu-img convert -f qcow2 -O qcow2 ubuntu-base.qcow2 ubuntu-base-optimized.qcow2

# OpenStack에 업로드
openstack image create "ubuntu-base-optimized" \
  --file ubuntu-base-optimized.qcow2 \
  --disk-format qcow2 \
  --container-format bare \
  --public

여기서 중요한 포인트! 이미지 변환은 마법이 아닙니다. 원본 안에 불필요한 데이터가 많으면 포맷만 바꿔도 큰 차이가 없더라고요. 저도 처음엔 convert만 하면 다 해결될 줄 알았는데 아니었습니다. 결국 이미지 내부 정리가 먼저였습니다.

4. 실전 구현: Glance 스토리지 구성 전략

이제 실제로 어떤 식으로 구성할지 보겠습니다. 저는 보통 두 가지 시나리오로 접근합니다. 작은 환경은 filesystem 기반으로 빨리 시작하고, 운영 환경은 Ceph RBD 같은 공용 스토리지로 정리합니다. 멀티 스토어(multi-store, 여러 저장소를 함께 사용하는 방식)를 쓰는 환경이라면 용도에 따라 분리하는 것도 좋습니다.

4-1. 단순한 filesystem 기반 예시

[glance_store]
stores = file
default_store = file
filesystem_store_datadir = /var/lib/glance/images/

이 방식은 이해하기 쉽고 장애 포인트도 적습니다. 대신 스토리지가 커질수록 확장과 백업 구조를 직접 챙겨야 합니다. 홈랩에서는 이거 진짜 편하더라고요. 근데 운영 규모가 커지면 결국 한계가 옵니다.

4-2. Ceph RBD 기반 예시

[glance_store]
stores = rbd
default_store = rbd
rbd_store_pool = images
rbd_store_user = glance
rbd_store_ceph_conf = /etc/ceph/ceph.conf

Ceph를 이미 다른 워크로드에 쓰고 있다면, Glance 이미지를 같은 운영 체계 안에서 관리하기가 훨씬 수월합니다. 장애 대응, 용량 확장, 모니터링 흐름을 통일하기 좋거든요. 물론 Ceph 자체 운영 경험이 없다면 진입장벽은 분명 있습니다.

filesystem과 Ceph RBD 백엔드 선택 시 데이터 흐름이 어떻게 달라지는지 보여주는 구성 예시입니다.

4-3. 이미지 분류 정책까지 같이 가야 합니다

스토리지만 바꿔서는 절반짜리입니다. 실제 운영에서는 이미지 네이밍 규칙과 속성 관리가 같이 들어가야 합니다.

# 이미지 목록 확인
openstack image list

# 특정 이미지 상세 확인
openstack image show ubuntu-base-optimized

# 태그 또는 속성을 활용한 구분 예시
openstack image set \
  --property os_distro=ubuntu \
  --property image_role=base \
  ubuntu-base-optimized

• base: 공용 베이스 이미지
• app: 애플리케이션 포함 이미지
• deprecated: 신규 배포 금지, 삭제 대기 이미지
• golden: 표준 운영 이미지

이렇게 분류해두면 나중에 정리 작업이 훨씬 쉬워집니다. OpenStack Glance 이미지 관리는 저장소 용량보다도, 사실 이름 짓기와 분류 정책에서 승부가 많이 나더라고요.

5. ⚠️ 운영 중 자주 겪는 문제와 트러블슈팅

여기서는 제가 실제로 자주 부딪힌 문제를 적어보겠습니다. 화려한 기능보다 이런 부분이 운영에 더 중요하거든요.

5-1. 업로드는 되는데 부팅이 안 되는 경우

대부분은 이미지 포맷, 버스 타입, cloud-init 설정, 또는 운영체제 내부 드라이버 문제인 경우가 많습니다. Glance 문제가 아니라 게스트 이미지 준비 상태 문제인 경우도 많더라고요.

• disk-format이 실제 파일 형식과 맞는지 확인합니다.
• virtio 드라이버 지원 여부를 확인합니다.
• 부팅 직후 네트워크가 안 붙으면 cloud-init 로그를 봅니다.

5-2. 오래된 이미지가 안 지워지는 경우

이건 삭제 정책이 없어서 생기는 일이 많습니다. 이미지가 실제로 인스턴스 생성에 아직 참조되는지, 운영팀이 롤백 용도로 잡아둔 것인지 확인 없이 지우면 사고 납니다. 저는 최소한 아래 기준으로 봅니다.

1. 최근 배포 이력 확인
2. 현재 표준 이미지 여부 확인
3. 롤백 필요 기간 경과 여부 확인
4. 삭제 전 백업 또는 export 수행

# 이미지 다운로드 백업
openstack image save --file ubuntu-base-backup.qcow2 ubuntu-base-optimized

# 더 이상 쓰지 않는 이미지 삭제
openstack image delete old-ubuntu-image

5-3. 이미지가 너무 많아서 관리가 안 되는 경우

이건 기술 문제이기도 하지만 프로세스 문제입니다. 생성은 누구나 쉽게 하는데 폐기는 아무도 안 하거든요. 그래서 저는 월 1회 정도는 공용 이미지 점검 시간을 따로 잡습니다. 별거 아닌데 효과가 큽니다.

• 이미지 오너(owner) 또는 관리 책임자 지정
• 생성일과 용도 속성 관리
• deprecated 상태를 거친 뒤 최종 삭제
• 업로드 승인 기준 최소화

6. 검증: 결과는 어떻게 확인할까

구성하고 나면 꼭 확인해야 합니다. 드디어 됐다! 하고 넘어가면 나중에 누적 비용에서 뒤통수 맞습니다. 검증은 어렵지 않습니다. 이미지 목록, 이미지 크기, 실제 백엔드 사용량, 부팅 성공 여부까지 같이 보면 됩니다.

# 이미지 목록과 상태 확인
openstack image list --long

# 특정 이미지 상세 확인
openstack image show ubuntu-base-optimized

# 파일시스템 사용량 확인 예시
du -sh /var/lib/glance/images

# Ceph 사용량 확인 예시
rbd du -p images

제가 직접 해보니, 검증 단계에서 가장 많이 놓치는 건 논리적 크기와 실제 사용량의 차이였습니다. 이미지 메타데이터에 보이는 크기와 백엔드에서 실제 차지하는 용량은 다를 수 있습니다. 그래서 CLI 출력만 보지 말고 저장소 쪽 사용량도 같이 봐야 합니다.

이미지 목록, 실제 저장소 사용량, 정리 전후 변화를 확인하는 검증 화면을 표현한 시각 자료입니다.

6-1. 제가 보는 체크리스트

확인 항목	왜 중요한가	확인 방법
이미지 상태	업로드 실패 또는 비정상 상태 조기 발견	openstack image list
실제 저장소 사용량	비용 분석의 핵심 지표	du, rbd du 등
부팅 성공 여부	최적화 후 기능 이상 여부 확인	테스트 인스턴스 생성
중복 이미지 비율	정리 대상 선별	이름, 태그, 생성일 비교

🎉 결과적으로 잘 정리된 환경은 운영이 훨씬 편해집니다. 저장소가 줄어드는 것도 좋지만, 더 큰 장점은 표준 이미지가 명확해져서 배포 속도가 빨라진다는 점입니다.

7. 비용 관점에서 추천하는 운영 습관

검색 의도가 cost analysis라면, 결국 중요한 건 기술 선택보다 운영 습관입니다. 클라우드 스토리지 비용은 한 번에 크게 터지기보다, 조금씩 새는 식으로 커집니다. 그래서 아래 습관이 꽤 중요합니다.

1. 공용 베이스 이미지는 최소 개수로 유지합니다.
2. 커스텀 이미지는 목적과 만료 기준을 같이 적어둡니다.
3. 정기 정리일을 운영 캘린더에 넣습니다.
4. 업로드 전 이미지 최적화를 표준 절차로 만듭니다.
5. 백엔드 사용량 보고를 월 단위로 확인합니다.

혹시 이런 경험 있으신가요? 이미지는 지우기 무섭고, 안 지우자니 저장소가 계속 늘어나는 상황 말입니다. 저도 처음엔 그냥 큰 디스크를 더 붙이면 되겠지 했었는데, 결국 관리 체계 없이 용량만 늘리면 같은 문제가 반복되더라고요.

이미지 정리 정책, 업로드 전 최적화, 백엔드 선택에 따른 운영 포인트를 비교 요약한 인포그래픽입니다.

8. 정리와 다음 단계

정리해보면, OpenStack Glance 이미지 관리에서 가장 중요한 건 세 가지입니다. 첫째, 이미지 업로드 전에 최대한 정리할 것. 둘째, 환경에 맞는 Glance 스토리지 백엔드를 고를 것. 셋째, 이미지 수명주기 정책을 운영 프로세스로 만들 것. 이 세 가지가 잡히면 이미지 최적화와 클라우드 스토리지 비용 관리가 같이 따라옵니다.

다음 글에서는 Nova(노바)와 Cinder(신더) 관점에서 이미지 기반 배포와 볼륨 기반 배포를 어떻게 나눠야 하는지도 다뤄볼 예정입니다. 이전 글에서 Ceph 운영 기초를 정리해두셨다면 같이 보시면 흐름이 더 잘 잡히실 겁니다. 결국 운영은 기능보다 연결이더라고요.

자주 묻는 질문

• Q. 무조건 Ceph가 더 좋은가요?
  A. 아닙니다. 규모와 운영 역량에 따라 filesystem이 더 합리적인 경우도 많습니다.
• Q. qcow2가 항상 정답인가요?
  A. 아닙니다. 호환성과 성능 요구사항에 따라 raw가 더 맞는 경우도 있습니다.
• Q. 이미지 최적화만으로 충분한가요?
  A. 아니요. 최적화와 함께 삭제 정책, 태그 정책, 검증 절차가 같이 있어야 효과가 납니다.

✅ 오늘 바로 해볼 수 있는 건 어렵지 않습니다. 현재 Glance 이미지 목록을 뽑고, 공용 베이스 이미지와 오래된 커스텀 이미지를 먼저 분류해보세요. 거기서부터 스토리지 전략이 보이기 시작합니다.

📚 함께 읽으면 좋은 글

• OpenStack Nova 성능 최적화: CPU 스케줄링 및 리소스 할당 분석
• OpenStack Keystone 인증 시스템, 1년 운영 후기 및 보안 강화 팁
• OpenStack Ironic으로 베어메탈 서버 자동 프로비저닝 실전 사례
• Flux 이미지 모델 실무 적용 사례 분석: 성공과 실패를 넘어
• Stable Diffusion 고급 활용: 이미지 일관성 유지 및 워크플로우 최적화 팁