개념
관리 플랫폼 QA가 OpenStack을 만나는 방식
Private Cloud 관리 플랫폼은 대개 OpenStack을 직접 만들지 않는다. OpenStack 서비스(Keystone 인증, Nova 컴퓨트, Neutron 네트워크, Cinder 블록 스토리지, Glance 이미지 등)를 배포·운영하고, 그 위에 자기 콘솔·API·과금·조직 관리·GPU 스케줄링 기능을 얹는다. 그래서 QA의 검증 대상은 두 층이다.
| 층 | 누가 만들었나 | QA의 질문 |
|---|---|---|
| OpenStack 서비스 자체 | 상류 커뮤니티 (플랫폼 기업은 설정·패치) | 우리 배포 에서 표준 API가 표준대로 동작하는가 |
| 관리 플랫폼 기능 | 플랫폼 기업 | 우리 기능이 기대대로 동작하고, 아래의 OpenStack 상태와 일치 하는가 |
첫 번째 층은 상류가 만든 표준 도구로 검증하고, 두 번째 층은 모듈 38의 기준·파이프라인으로 검증한다. 두 층의 경계를 정하지 않으면 두 가지 실패가 생긴다. 상류가 이미 충분히 시험한 Nova API 동작을 처음부터 다시 테스트하느라 시간을 쓰거나, 반대로 "OpenStack이니까 되겠지"라며 우리 설정 이 만든 결함을 놓친다.
Tempest — 우리 배포가 표준 API를 지키는가
Tempest는 OpenStack의 통합 테스트 스위트다. 실제로 배포된 클라우드의 API 엔드포인트를 대상으로 테스트를 실행한다. QA가 알아야 할 구조는 이렇다.
| 구분 | 내용 |
|---|---|
| API 테스트 | 서비스 하나의 API 동작 (서버 생성·조회, 볼륨 연결 등) |
| 시나리오 테스트 | 여러 서비스를 엮은 사용자 흐름 (이미지로 서버 생성 → 볼륨 연결 → SSH 접속 → 데이터 쓰기) |
| smoke 태그 | 빠르게 도는 핵심 테스트 묶음. 배포 직후 확인용 |
| 플러그인 | 서비스별 추가 테스트 (Octavia 로드밸런서, Manila 파일 공유 등) |
tempest.conf | 엔드포인트, 테스트용 이미지·플레이버, 활성화된 기능 목록 |
실행과 선택은 대략 이렇게 한다.
tempest init qa-workspace && cd qa-workspace
# tempest.conf 에 인증 정보, 이미지·플레이버 ID, 기능 플래그를 채운다
tempest cleanup --init-saved-state # 테스트 전 리소스 상태 저장
tempest run --smoke # 배포 직후 확인
tempest run --include-list compute-gpu.txt --exclude-list known-unsupported.txt
tempest cleanup --dry-run # 테스트가 남긴 리소스 확인
tempest cleanup # 저장 상태에 없던 리소스 정리여기서 QA가 판단해야 할 두 가지가 있다.
기능 플래그가 곧 검증 범위 선언이다. tempest.conf 의 기능 목록(예: 라이브 마이그레이션 지원 여부, 특정 볼륨 타입)을 꺼 두면 관련 테스트는
건너뛰기 가 된다. 건너뛴 테스트는 실패가 아니므로 결과가 깨끗해 보인다. 모듈 38 레슨 5의 "실행되지 않은 필수 기준은 통과가 아니다"가
여기서 설정 파일 한 줄로 무너질 수 있다. 기능 플래그와 제외 목록을 리뷰 대상 산출물 로 다루고, 건너뛴 테스트 수를 게이트 요약에 올린다.
제외 목록에는 이유와 만료가 있어야 한다.
# known-unsupported.txt — 제외 이유를 줄마다 적는다
# 우리 배포는 GPU 패스스루 플레이버의 라이브 마이그레이션을 지원하지 않음 (제품 문서 §4.2, 의도)
tempest.api.compute.admin.test_live_migration.*gpu.*
# 상류 버그 LP#xxxxxxx, 2026.1 패치 적용 후 제거 예정 — 만료 2026-11-30
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern제외 목록이 이유 없이 자라면 몇 년 뒤에는 무엇이 "원래 안 되는 것"이고 무엇이 "고치지 않은 것"인지 아무도 모른다.
tempest cleanup이 드러내는 결함
레슨 1의 부분 생성 누수 검증을 Tempest가 도구로 제공한다. --init-saved-state 로 테스트 전 상태를 저장하고 테스트 후 --dry-run 으로
남은 리소스를 보면, 테스트가 스스로 정리하지 못한 리소스 목록이 나온다.
이 목록의 각 항목은 둘 중 하나다.
- 테스트가 정리를 요청했는데 플랫폼이 지우지 못했다 → 제품 결함 후보 (삭제 중 멈춘 볼륨, 분리되지 않은 포트)
- 테스트가 실패해서 정리 단계까지 못 갔다 → 테스트 실패의 부산물
두 경우를 가르려면 정리 요청 로그와 대조한다. 정리 요청이 성공 응답을 받았는데 리소스가 남아 있으면 제품 결함이다. 운영에서 고객이 겪는 "삭제했는데 쿼터가 안 줄어요" 문의의 상당수가 이 부류다.
주의할 점도 있다. tempest cleanup 은 저장 상태에 없는 리소스를 지우므로, 공유 환경에서 다른 사람이 만든 리소스까지 지울 수 있다. 과거에
네트워크를 전부 지운 버그 보고도 있었다. 공유 스테이징에서는 반드시 --dry-run 을 먼저 보고, 테스트 전용 프로젝트에서만 실제 정리를 돌린다.
Rally — 제어 평면이 부하를 견디는가
Tempest가 "동작하는가"를 본다면, Rally는 "여러 사용자가 동시에 할 때도 동작하는가, 얼마나 걸리는가"를 본다. Rally 작업은 시나리오·부하 방식·성공 기준(SLA) 으로 구성된다.
# rally 작업 — GPU 플레이버 서버 생성·삭제를 동시 10으로 100회
version: 2
title: gpu-server-boot-delete
subtasks:
- title: boot and delete gpu server
scenario:
NovaServers.boot_and_delete_server:
flavor: { name: "gpu.a100.1" }
image: { name: "ubuntu-24.04-cuda" }
runner:
constant:
times: 100
concurrency: 10
contexts:
users: { tenants: 2, users_per_tenant: 2 }
sla:
max_seconds_per_iteration: 180
failure_rate: { max: 1 }SLA의 두 항목이 판정 기준이다. 반복 하나가 180초를 넘거나, 실패한 반복이 1%를 넘으면 작업이 실패로 판정된다. 모듈 38 레슨 1의 "빠르게"를 수치로 바꾸는 방식이 Rally에서는 설정 파일에 들어간다.
Rally 결과를 읽을 때 QA가 추가로 볼 것들이 있다.
| 관찰 | 의미 |
|---|---|
| 반복 순번에 따라 시간이 늘어난다 | 무언가가 쌓인다 — 정리되지 않은 포트, DB 테이블 증가, 스케줄러 캐시 |
| 동시성 5→10에서 실패가 급증한다 | 락 경합·쿼터 서비스 병목·API 워커 수 |
| 실패 메시지가 한 종류에 몰린다 | 특정 하위 서비스(Neutron 포트 바인딩 등)의 한계 |
| 평균은 SLA 안인데 최댓값이 튄다 | 모듈 31 레슨 4 — 평균만 보면 안 된다. 백분위수로 기준을 다시 쓴다 |
| 부하 후 tempest cleanup dry-run 에 리소스가 남는다 | 동시성 조건에서만 나는 누수 |
마지막 줄이 특히 중요하다. 단일 요청에서는 깨끗하게 지워지던 리소스가 동시 삭제 경합 에서만 남는 결함이 흔하다. 부하 시험 뒤에 누수 확인을 붙이는 것만으로 이 부류를 잡을 수 있다.
Rally는 Tempest를 검증기로 돌리는 기능(rally verify)도 제공해 두 도구의 결과를 한 곳에 모을 수 있다.
관리 플랫폼 기능과 OpenStack 상태의 일치
관리 플랫폼이 OpenStack 위에 얹은 기능은 두 개의 진실 원천 을 만든다. 플랫폼 DB와 OpenStack. 둘이 어긋나는 순간이 결함이다.
| 플랫폼 기능 | 어긋남 결함 예 | 검증 |
|---|---|---|
| 조직·프로젝트 관리 | 플랫폼에서 프로젝트 삭제, Keystone 프로젝트는 남음 | 플랫폼 조작 후 Keystone 조회 대조 |
| 쿼터 화면 | 플랫폼 표시 사용량과 Nova·Cinder 쿼터 사용량 불일치 | 양쪽 조회 대조, 동시 생성 후 대조 |
| GPU 플레이버 카탈로그 | 플랫폼 카탈로그에 있는데 Nova 플레이버의 추가 속성(PCI 별칭)이 틀림 | 플레이버 속성 대조, 실제 부팅 후 nvidia-smi |
| 과금 | Nova에서 서버가 ERROR인데 플랫폼은 과금 | 상태별 과금 이벤트 규칙 |
| 사용자 역할 | 플랫폼 역할과 Keystone 역할 매핑 오류 | 역할별 권한 매트릭스 시험 |
이 대조를 정기 일치 검사(reconciliation) 로 자동화하면 모듈 4 레슨 6의 리콘실리에이션이 운영 품질 도구가 된다. 플랫폼 DB의 리소스 목록과 OpenStack의 리소스 목록을 매일 비교해 차이를 보고하고, 차이의 원인을 결함으로 추적한다.
SLURP 주기와 업그레이드 검증
OpenStack은 6개월마다 새 버전을 낸다. 2022년부터는 SLURP(Skip Level Upgrade Release Process) 를 적용해 매년 첫 릴리스(.1)를 SLURP
릴리스로 지정하고, SLURP 릴리스 사이에는 중간 릴리스를 건너뛰는 업그레이드를 지원한다. 2025.1 Epoxy와 2026.1 Gazpacho(2026년 4월)가 연속한
SLURP 릴리스이므로 Epoxy에서 2025.2 Flamingo를 거치지 않고 Gazpacho로 바로 올릴 수 있다.
설치형 플랫폼에게 이것은 고객마다 업그레이드 경로가 다르다 는 뜻이다. 검증할 경로를 명시한다.
[업그레이드 경로 검증 — 플랫폼 릴리스 2026.38]
경로 A Epoxy(2025.1) → Gazpacho(2026.1) SLURP 건너뛰기 릴리스 전 층
경로 B Flamingo(2025.2) → Gazpacho(2026.1) 연속 릴리스 전 층
경로 C Gazpacho 패치 버전 간 회귀 층 (주 1회)
각 경로 공통 기준
- 업그레이드 전 생성한 서버·볼륨·네트워크·로드밸런서가 업그레이드 중·후 데이터 평면 유지
(실행 중 GPU 서버 내부의 학습 프로세스가 끊기지 않는가 — 계획된 중단이 있다면 문서와 일치)
- 업그레이드 후 기존 리소스 조작(중지·시작·크기 변경·스냅샷·삭제) 가능
- API 마이크로버전 하위 호환: 플랫폼 콘솔이 쓰는 마이크로버전 호출 전부 통과
- DB 마이그레이션 시간: 운영 규모 데이터 복제본에서 측정, 유지보수 창 안
- 롤백 절차 리허설 (지원 범위 명시)"업그레이드 전 생성한 리소스"를 검증하려면 업그레이드 전에 만들어 두는 단계 가 파이프라인에 있어야 한다. 새로 설치한 환경에서 업그레이드 스크립트만 돌리면 이 기준은 영원히 검증되지 않는다(모듈 38 레슨 4 릴리스 전 층).
상호운용성 가이드라인과 한계
OpenStack 커뮤니티는 상호운용성 작업 그룹이 정의한 필수 기능 목록과 Tempest 기반 도구로 "OpenStack Powered" 같은 상표 프로그램을 운영해 왔다. 관련 도구 저장소 일부는 현재 아카이브 상태다. 설치형 플랫폼이 고객·조달 요건에서 "OpenStack 호환"을 요구받는다면, 어느 가이드라인의 어느 기능 목록 을 기준으로 삼는지 계약 단계에서 확인하고 그 목록을 Tempest 포함 목록으로 고정해 증거를 남긴다. 표준 이름만으로 합의하면 레슨 9의 납품 검증에서 해석이 갈린다.
실무에서 왜 필요한가
OpenStack 기반 Private Cloud 기업의 QA 공고에 Tempest·Rally가 이름으로 나오지 않더라도, 이 도구들이 만드는 증거 없이는 "우리 배포가 표준대로 동작한다"를 고객에게 설명할 수 없다. 반대로 Tempest 결과만 보고 품질을 말하면 관리 플랫폼 층의 결함, 특히 플랫폼 DB와 OpenStack의 어긋남 을 놓친다. 운영 고객 문의의 상당수가 이 어긋남에서 나온다.
업그레이드 경로 검증은 설치형 플랫폼 QA의 가장 비싼 업무이자 가장 큰 사고 예방 수단이다. 고객이 SLURP 건너뛰기 경로로 올린 날 기존 GPU 서버가 부팅되지 않으면, 원인이 상류에 있어도 계약과 신뢰는 플랫폼 기업이 잃는다.