[OpenStack] 오픈스택 쿼터 초과 장애 해결: 테넌트 자원 고갈 진단부터 관리까지

운영하다 보면 제일 당황스러운 순간이 있어요. 분명 하이퍼바이저(Hypervisor, 가상화 호스트) 자원은 남아 있는데 사용자 쪽에서는 인스턴스(Instance, 가상머신)가 더 이상 생성되지 않는 상황이거든요. 저도 홈랩(Home Lab, 개인 실험 환경)과 실무 환경에서 비슷한 일을 몇 번 겪었는데, 처음엔 컴퓨트 노드(Compute Node) 장애인가 싶어서 로그만 한참 뒤졌습니다. 그런데 원인은 의외로 단순했어요. 바로 오픈스택 쿼터 초과였거든요. 특히 여러 프로젝트(Project, 테넌트 단위)와 팀이 함께 쓰는 환경에서는 오픈스택 테넌트별 자원 제한을 제대로 보지 않으면, 겉으로는 인프라 장애처럼 보여도 실제로는 정책 문제인 경우가 대부분이에요.

혹시 이런 경험 있으신가요? CPU나 메모리는 남아 있는데 신규 서버가 안 떠서 급하게 노바(Nova), 신더(Cinder), 뉴트론(Neutron) 로그부터 보는 경우요. 저도 그랬습니다 ㅎㅎ 이번 글에서는 제가 실제로 많이 겪었던 패턴을 바탕으로, 자원 고갈처럼 보이는 쿼터 이슈를 어떤 순서로 확인하고, 어떻게 복구하고, 이후엔 어떤 식으로 쿼터 관리 체계를 잡아야 덜 고생하는지 정리해보겠습니다.

프로젝트별로 컴퓨트, 스토리지, 네트워크 자원이 어떻게 제한되고 소비되는지 한눈에 보여주는 개요 이미지입니다.

1. 왜 오픈스택 쿼터 초과가 장애처럼 보일까

쉽게 말해 쿼터(Quota, 사용 한도)는 멀쩡한 클라우드 자원 앞에 달린 논리적 문지기예요. 물리 자원이 남아 있어도 테넌트에 할당된 한도를 넘으면 API 단계에서 요청이 거절됩니다. 그래서 현상만 보면 진짜 자원 부족과 거의 비슷해 보여요.

• 인스턴스 생성 실패: vCPU, RAM, instances 한도 초과
• 볼륨 생성 실패: 볼륨 수 또는 총 용량 한도 초과
• 포트 생성 실패: 네트워크 포트 수 제한 도달
• 플로팅 IP 부족처럼 보이는 현상: 실제 풀 부족이 아니라 프로젝트 쿼터 제한일 수 있음

현장에서 무서운 건 여기서부터예요. 사용자 입장에서는 그냥 "서버가 안 만들어진다"로 보이고, 운영자도 로그만 대충 보면 스케줄러(Scheduler, 배치 결정기) 문제로 오해하기 쉽거든요. 오픈스택 장애 해결에서 중요한 건, 물리 자원 확인 전에 논리 자원 제한부터 보는 습관이에요. 이 순서 하나로 장애 대응 시간이 꽤 줄어듭니다.

2. 핵심 개념 정리: 테넌트, 쿼터, 사용량

저도 처음엔 프로젝트(Project)와 테넌트(Tenant) 용어가 좀 헷갈렸는데요. 실무에서는 거의 같은 맥락으로 쓰는 경우가 많습니다. 중요한 건 "누가 얼마까지 쓸 수 있나"를 나누는 단위라는 점입니다.

여기서 중요한 포인트! 오픈스택 쿼터 초과는 꼭 사용자가 과하게 쓴 경우만 의미하지 않아요. 삭제했다고 생각한 리소스가 실제로는 남아 있거나, 포트(Port, 네트워크 연결 단위)나 스냅샷(Snapshot, 시점 복사본)처럼 눈에 잘 안 띄는 리소스가 누적돼도 발생합니다. 제가 직접 해보니 특히 테스트 환경에서 이런 잔여 리소스가 잘 쌓이더라고요.

자주 막히는 리소스 종류

• cores(vCPU 코어 수)
• ram(메모리 총량)
• instances(가상머신 개수)
• volumes(볼륨 개수)
• gigabytes(볼륨 총 용량)
• ports(네트워크 포트 수)
• floating-ips(공인 IP 할당 수)

3. 증상 확인: 에러 메시지부터 방향을 잡아야 해요

장애 대응 초반엔 일단 증상을 짧게 정리해야 합니다. 저는 아래 3가지를 먼저 봐요.

1. 사용자가 어떤 작업에서 실패했는지 확인합니다. 인스턴스 생성인지, 볼륨 생성인지, 포트 할당인지가 중요하거든요.
2. CLI(Command Line Interface, 명령행 도구) 또는 대시보드에서 에러 문구를 확인합니다.
3. 관리자 권한으로 해당 프로젝트의 사용량과 쿼터를 바로 조회합니다.

대표적으로 보게 되는 흐름은 이렇습니다.

openstack server create --flavor m1.small --image ubuntu-test --network private-net test-vm

이때 실패하면 사용자 쪽에서는 막연히 "인스턴스 생성 실패"로만 전달하는 경우가 많아요. 근데 실제로는 쿼터 메시지가 붙어 있는 경우가 있습니다. 그래서 저는 같은 프로젝트 컨텍스트(Context, 인증 범위)에서 자원 상태를 먼저 재현해 봅니다.

쿼터 조회와 사용량 확인 명령을 실행하며 원인을 좁혀가는 운영 절차를 보여주는 이미지입니다.

4. 실전 점검 절차: 제가 실제로 쓰는 확인 순서

이 부분이 핵심이에요. 삽질 좀 했던 경험을 바탕으로, 지금은 거의 이 순서대로 갑니다. 괜히 노바 로그부터 깊게 파지 않고, 범위를 빠르게 좁히는 방식입니다.

4-1. 프로젝트 쿼터 조회

openstack quota show <PROJECT_ID 또는 PROJECT_NAME>

이 명령으로 현재 제한값을 봐요. 환경에 따라 cores, instances, ram, volumes, snapshots, ports 같은 항목이 나옵니다. 숫자만 보지 말고, 어떤 항목이 업무 성격상 먼저 닳을지 감으로 연결해야 합니다. 예를 들어 쿠버네티스(Kubernetes, 컨테이너 오케스트레이션) 실험용 프로젝트는 포트가 생각보다 빨리 찹니다.

4-2. 실제 사용량 확인

openstack server list --project <PROJECT_ID>
openstack volume list --project <PROJECT_ID>
openstack port list --project <PROJECT_ID>

여기서 저는 꼭 리소스 개수와 상태(Status, 현재 상태)를 같이 봐요. 삭제 중으로 남아 있거나 에러 상태인 리소스가 quota usage에 영향을 주는 경우가 있거든요. 처음엔 이게 뭔가 싶었는데, 특히 포트와 볼륨에서 잔재가 남는 경우가 꽤 있었습니다.

4-3. 하이퍼바이저 자원과 분리해서 판단

openstack hypervisor stats show

이건 ‘진짜 인프라 자원 부족인지’를 분리하기 위한 확인이에요. 하이퍼바이저에 여유가 있는데 프로젝트 생성만 막히면, 높은 확률로 쿼터 또는 스케줄링 정책 쪽입니다. 반대로 전체 자원도 부족하다면 단순 쿼터 상향만으로는 해결이 안 됩니다.

4-4. 필요 시 쿼터 조정

openstack quota set --cores 40 --ram 81920 --instances 20 <PROJECT_ID>
openstack quota set --volumes 20 --gigabytes 2000 <PROJECT_ID>
openstack quota set --ports 150 <PROJECT_ID>

여기서 중요한 게 하나 있어요. 무조건 늘리는 게 답이 아니라는 점입니다. 저도 예전엔 급하다고 넉넉하게 올려줬었는데, 결국 몇 주 뒤 다른 팀이 영향을 받는 식으로 되돌아오더라고요. 그래서 지금은 증상 완화용 임시 상향과 정책 반영용 영구 조정을 분리해요.

4-5. 남은 리소스 재정리

openstack server delete <SERVER_ID>
openstack volume delete <VOLUME_ID>
openstack port delete <PORT_ID>

실제로 써보니까 쿼터를 늘리는 것보다 먼저 불필요 리소스를 비우는 편이 더 깔끔한 경우가 많았어요. 특히 테스트 프로젝트에서는 종료된 인스턴스보다 남아 있는 포트나 미사용 볼륨이 더 문제였습니다.

5. 주의사항과 트러블슈팅: 여기서 많이 헷갈립니다

오픈스택 장애 해결을 하다 보면 쿼터 문제는 금방 끝날 것 같지만, 실제로는 꼬인 상태가 종종 있어요. 제가 자주 봤던 패턴을 정리해보겠습니다.

⚠️ 1) 인스턴스는 없는데 쿼터가 찬 것처럼 보이는 경우

이럴 땐 네트워크 포트나 볼륨, 스냅샷을 의심해요. 사용자는 VM만 지웠다고 생각하지만, 연결된 리소스가 남아 있는 경우가 많거든요.

• 포트 목록 확인
• 볼륨과 스냅샷 목록 확인
• 에러 상태 리소스 확인

⚠️ 2) 쿼터를 올렸는데도 바로 안 되는 경우

정책 반영 지연이라기보다, 실제 실패 원인이 다른 리소스일 수 있어요. 예를 들어 cores는 늘렸는데 ports가 이미 꽉 차 있으면 증상은 그대로입니다. 저도 한 번 이걸 놓쳐서 "왜 안 풀리지?" 하면서 한참 돌았습니다.

⚠️ 3) 관리자와 사용자 기준 숫자가 다르게 보이는 경우

프로젝트 스코프(Project Scope, 프로젝트 범위)나 도메인(Domain, 계정 그룹) 선택이 다르면 조회 결과가 달라질 수 있어요. CLI 인증 정보부터 다시 보는 게 좋습니다.

⚠️ 4) 임시 증설이 상시 정책이 되는 경우

이게 은근 위험해요. 한 번 올려준 쿼터는 잘 안 내려가거든요. 결국 특정 오픈스택 테넌트가 과도한 자원을 점유하면서 다른 팀 배포에 영향을 줄 수 있습니다. 그래서 저는 변경 후 꼭 사유를 남겨요.

# 예시: 변경 전후 값을 운영 기록에 남기기
openstack quota show <PROJECT_ID>

운영 기록은 위키나 티켓 시스템에 남겨두는 편이 좋습니다. 나중에 "왜 이 프로젝트만 이렇게 높지?"라는 질문이 꼭 나오더라고요.

인스턴스, 볼륨, 포트, 스냅샷 중 어디를 먼저 확인할지 보여주는 트러블슈팅 흐름도입니다.

6. 검증 방법: 수정 후엔 꼭 다시 확인해야 합니다

조치가 끝났다고 바로 닫으면 안 돼요. 저는 최소한 아래 순서로 검증합니다.

1. 실패했던 동일 작업을 다시 실행합니다.
2. 프로젝트 쿼터와 사용량을 다시 조회합니다.
3. 사용자에게 실제 서비스 배포가 진행되는지 확인받습니다.
4. 다른 프로젝트에 영향이 없는지도 봐요.

openstack quota show <PROJECT_ID>
openstack server create --flavor m1.small --image ubuntu-test --network private-net quota-check-vm
openstack server list --project <PROJECT_ID>

검증 포인트는 단순히 "생성이 된다"가 아니에요. 자원 고갈이 구조적으로 반복될 상황인지까지 봐야 합니다. 예를 들어 일시적으로 1대 생성은 되지만, 자동 확장(Auto Scaling, 부하에 따라 자동 증설) 워크로드가 예정돼 있다면 지금 쿼터로는 또 막힐 수 있거든요. 여기서 한 번 더 업무 패턴을 확인해두면 같은 장애를 반복하지 않아요.

조치 후 VM 생성 성공과 리소스 사용량 증가가 정상적으로 반영된 결과 화면을 보여주는 이미지입니다.

7. 운영 기준 제안: 쿼터 관리를 이렇게 바꾸니 덜 아팠습니다

제가 몇 번 데이고 나서 바꾼 방식이 있어요. 그냥 요청 올 때마다 수동으로 늘려주는 방식은 오래 못 갑니다. 결국 장애 대응도 늦고, 정책도 흐려져요.

• 기본 쿼터 표준화: 개발, 테스트, 운영 프로젝트별 기본값을 구분합니다.
• 증설 요청 기준 문서화: 인스턴스 수, 코어, RAM, 볼륨 증설 사유를 받습니다.
• 유휴 자원 정리 주기화: 미사용 볼륨, 포트, 스냅샷 점검 일정을 둬요.
• 임시 상향 만료 기준: 이벤트성 증설은 종료 시점에 원복 여부를 검토합니다.

특히 쿼터 관리는 자원 절약만의 문제가 아니에요. 장애를 예측 가능하게 만드는 운영 체계에 가까워요. 드디어 됐다! 하고 쿼터만 올려두면 그날은 끝나지만, 다음 분기엔 더 큰 문제로 돌아오더라고요.

8. 정리와 FAQ: 오픈스택 쿼터 초과 대응의 핵심

정리하면 이렇습니다. 오픈스택 쿼터 초과는 물리 자원이 남아 있어도 충분히 발생할 수 있고, 겉으로는 인프라 장애처럼 보이기 때문에 더 헷갈려요. 그래서 확인 순서는 아주 단순해야 해요. 프로젝트 쿼터 확인, 실제 사용량 확인, 잔여 리소스 점검, 필요한 경우에만 제한 조정. 이 순서만 몸에 익어도 대응 속도가 확실히 빨라집니다.

저도 처음엔 무조건 시스템 로그부터 깊게 봤었는데, 실제로는 쿼터 하나 때문에 시간을 꽤 썼습니다. 근데 여기서 배운 게 있어요. 장애 대응은 많이 아는 것보다 먼저 의심할 순서를 잘 세우는 게 더 중요하다는 점입니다. 다음 글에서는 프로젝트별 자원 사용량을 주기적으로 점검하는 방법이나, 간단한 자동화 스크립트로 경고를 만드는 방법도 다뤄볼 예정입니다. 이전 글에서 다룬 스토리지 정리 루틴과 함께 보시면 운영 흐름을 잡는 데 더 도움이 될 거예요.

자주 묻는 질문

• Q. 하이퍼바이저 자원이 남는데도 생성이 실패할 수 있나요?
  A. 네, 가능해요. 프로젝트 쿼터가 먼저 막고 있을 수 있습니다.
• Q. 쿼터를 무조건 크게 잡는 게 안전한가요?
  A. 아니에요. 특정 팀의 과점유를 막기 위해 적정선이 필요합니다.
• Q. 가장 자주 놓치는 리소스는 뭔가요?
  A. 경험상 포트, 볼륨, 스냅샷 같은 잔여 리소스가 많았어요.

운영자가 바로 참고할 수 있도록 쿼터 점검 순서와 관리 원칙을 요약한 인포그래픽 이미지입니다.

✅ 핵심만 다시 적어보면, 오픈스택 쿼터 초과는 흔하지만 의외로 진단 순서만 잡으면 빠르게 해결돼요. 🎉 중요한 건 단발성 복구가 아니라, 같은 유형의 자원 고갈 이슈가 반복되지 않게 운영 기준을 만드는 거예요. 저처럼 처음에 로그만 파다가 시간 보내지 마시고, 다음 장애 때는 꼭 쿼터부터 확인해보세요. 이거 진짜 편하더라고요.