[OpenStack] DevStack 환경에서 OpenStack 서비스 간 연동 문제 해결 가이드

목차

• 1. 왜 DevStack 개발 환경에서 OpenStack 서비스 연동 문제가 자주 생길까
• 2. OpenStack 서비스 연동을 흐름으로 이해하기
• 3. DevStack 트러블슈팅 전에 먼저 확인할 기본 체크리스트
• 4. 실전 구현: DevStack 환경에서 서비스 연동 상태 점검 순서
• 4-1. DevStack 설정 파일부터 다시 봅니다
• 4-2. 서비스 프로세스와 API 포트를 확인합니다
• 4-3. 서비스 카탈로그와 엔드포인트를 검증합니다
• 4-4. 서비스별 실제 호출을 해봅니다
• 5. ⚠️ 실제로 많이 만나는 OpenStack 서비스 연동 문제와 해결법
• 5-1. Keystone 인증은 되는데 Nova 인스턴스 생성이 실패하는 경우
• 5-2. Neutron 네트워크는 보이는데 포트 생성이 안 되는 경우
• 5-3. Glance 이미지 목록은 보이는데 부팅만 실패하는 경우
• 5-4. RabbitMQ 또는 DB 연결 문제로 서비스가 간헐적으로 실패하는 경우
• 6. 검증: 어디까지 확인해야 진짜 해결된 걸까
• 7. 빠른 진단 기준
• 8. 자주 묻는 질문과 실무 팁
• Q1. 서비스가 모두 떠 있는데도 왜 연동이 안 될까요?
• Q2. DevStack을 다시 설치하는 게 더 빠를 때도 있나요?
• Q3. 로그는 어디부터 봐야 하나요?
• 9. 마무리: DevStack 트러블슈팅의 핵심은 흐름을 보는 눈입니다

DevStack 환경에서 OpenStack 서비스 간 연동 문제 해결 가이드

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 서비스 연동을 너무 어렵게 볼 필요는 없습니다. 요청 하나가 아래처럼 지나간다고 생각하시면 됩니다.

1. 사용자 또는 CLI가 Keystone에 인증 요청을 보냅니다.
2. 인증이 끝나면 서비스 카탈로그(service catalog, 서비스 목록)와 토큰을 받습니다.
3. Nova가 Glance, Neutron, Placement 같은 다른 서비스와 통신합니다.
4. 백엔드에서는 메시지 큐와 데이터베이스가 중간 연결을 받쳐줍니다.
5. 문제가 생기면 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에 서비스 활성화가 빠져 있거나, 비밀번호 변수 구성이 엇갈리면 설치는 돼도 연동이 흔들립니다. 아래는 가장 기본적인 예시입니다.

[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
HOST_IP=192.168.56.10

ENABLED_SERVICES=g-api,g-reg,key,n-api,n-cpu,n-cond,n-sch,n-novnc,q-svc,q-agt,q-dhcp,q-l3,q-meta,placement-api,c-api,c-bak,c-sch,horizon

여기서 중요한 건 비밀번호를 단순하게 맞추라는 의미가 아니라, DevStack이 기대하는 변수 간 일관성을 유지하라는 겁니다. 실제 운영 환경에서는 당연히 더 엄격하게 관리해야 하고요.

4-2. 서비스 프로세스와 API 포트를 확인합니다

서비스 연동 오류처럼 보여도 실제로는 프로세스가 죽어 있는 경우가 꽤 많습니다.

sudo systemctl --type=service | grep -E 'apache2|mariadb|mysql|rabbitmq'
ss -lntp | grep -E '5000|8774|9292|9696|8776'
ps -ef | grep -E 'nova|neutron|glance|keystone' | grep -v grep

포트 기준으로 보면 보통 다음을 많이 확인합니다.

• 5000: Keystone API
• 8774: Nova API
• 9292: Glance API
• 9696: Neutron API
• 8776: Cinder API

DevStack 설정 파일과 활성화된 OpenStack 서비스가 어떤 관계로 연결되는지 보여주는 설명 이미지입니다.

4-3. 서비스 카탈로그와 엔드포인트를 검증합니다

OpenStack 서비스 연동에서 진짜 자주 문제를 만드는 게 endpoint입니다. 서비스는 살아 있는데 잘못된 URL을 보고 있으면 호출이 실패합니다.

openstack service list
openstack endpoint list --long
openstack catalog list

여기서 체크할 건 단순합니다.

1. Keystone에 각 서비스가 등록되어 있는지
2. public, internal, admin URL이 비정상 주소를 가리키지 않는지
3. 호스트명과 IP가 현재 DevStack 환경과 일치하는지

특히 예전에 스냅샷이나 VM 복제로 실험 환경을 다시 만들었을 때, 예전 IP가 남아 있어서 삽질 좀 했습니다. 겉으론 다 살아 있는데 실제 호출은 엉뚱한 주소로 나가더라고요.

4-4. 서비스별 실제 호출을 해봅니다

CLI 목록 조회가 된다고 끝이 아닙니다. 진짜 연동이 되는지 보려면 서비스별로 최소 기능을 직접 호출해야 합니다.

openstack image list
openstack network list
openstack flavor list
openstack server list
openstack volume service list

그리고 가능하면 테스트용 네트워크와 인스턴스 생성까지 확인합니다.

openstack network create demo-net
openstack subnet create demo-subnet --network demo-net --subnet-range 10.10.0.0/24
openstack router create demo-router
openstack router add subnet demo-router demo-subnet

이 단계에서 Neutron이 꼬여 있으면 바로 드러납니다. DevStack 트러블슈팅은 결국 조회 성공보다 생성/변경 요청 성공이 더 중요하더라고요.

5. ⚠️ 실제로 많이 만나는 OpenStack 서비스 연동 문제와 해결법

5-1. Keystone 인증은 되는데 Nova 인스턴스 생성이 실패하는 경우

증상은 보통 인스턴스가 ERROR 상태로 떨어집니다. 이럴 때는 Nova 로그와 scheduler 흐름을 먼저 봅니다.

sudo journalctl -u devstack@n-api -n 100 --no-pager
sudo journalctl -u devstack@n-cpu -n 100 --no-pager
sudo journalctl -u devstack@n-sch -n 100 --no-pager

제가 자주 본 원인은 아래 셋입니다.

• Glance 이미지 조회 실패
• Neutron 포트 생성 실패
• Placement 자원 조회 실패

즉 Nova 자체 문제처럼 보여도 실제로는 다른 서비스 연동 이슈인 경우가 많습니다.

5-2. Neutron 네트워크는 보이는데 포트 생성이 안 되는 경우

이건 Linux bridge나 Open vSwitch 같은 네트워크 백엔드 구성과 에이전트 상태를 함께 봐야 합니다. DevStack에서는 설치가 끝났어도 에이전트가 비정상 상태일 때가 있습니다.

openstack network agent list
sudo journalctl -u devstack@q-svc -n 100 --no-pager
sudo journalctl -u devstack@q-agt -n 100 --no-pager

Alive 상태가 XXX 로 보이면, 네트워크 에이전트가 컨트롤 플레인과 정상 통신하지 못하는 경우가 많습니다. 여기서 중요한 포인트는 API만 보지 말고 에이전트 헬스까지 같이 봐야 한다는 점입니다.

5-3. Glance 이미지 목록은 보이는데 부팅만 실패하는 경우

처음엔 이게 뭔가 싶었는데, 이미지 메타데이터나 다운로드 경로 문제일 때가 있었습니다. 이미지가 등록됐다고 해서 실제 boot path가 정상이라는 뜻은 아니거든요.

openstack image show cirros
sudo journalctl -u devstack@g-api -n 100 --no-pager

여기서는 이미지 상태가 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. 검증: 어디까지 확인해야 진짜 해결된 걸까

로그 한 줄 없어졌다고 끝난 건 아닙니다. 저는 아래 순서가 모두 통과하면 그제야 해결로 봅니다.

1. 토큰 발급이 정상 동작한다.
2. 서비스 목록과 엔드포인트가 정상 조회된다.
3. 이미지, 네트워크, 플래버 목록 조회가 된다.
4. 테스트 네트워크와 서브넷 생성이 된다.
5. 테스트 인스턴스가 ACTIVE 또는 기대 상태로 전환된다.
6. 필요 시 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 서비스 연동 문제를 겪고 계시다면, 오늘 소개한 체크리스트만 따라가도 원인 범위를 꽤 빨리 좁히실 수 있을 겁니다. 드디어 됐다! 하는 순간이 분명 오거든요. 그 맛에 또 홈랩 만지게 됩니다 ㅎㅎ

📚 함께 읽으면 좋은 글

• OpenStack Glance 이미지 관리, 효율적인 스토리지 활용 전략
• OpenStack Nova 성능 최적화: CPU 스케줄링 및 리소스 할당 분석
• OpenStack Keystone 인증 시스템, 1년 운영 후기 및 보안 강화 팁