[인프라] OpenStack 멀티노드 클러스터 1년 운영 회고

목차

• 왜 OpenStack 멀티노드 운영은 설치보다 운영이 더 어렵나
• 운영 전에 잡아야 했던 기본 원칙
• 제가 실제로 사용한 운영 구조와 체크 포인트
• 실전 구현에서 효과 있었던 운영 습관
• ⚠️ 실제로 크게 데였던 장애와 해결 과정
• 1. 메시지 큐 지연으로 인한 인스턴스 생성 실패
• 2. Neutron 포트 생성은 되는데 통신이 안 되는 문제
• 3. 스토리지 연결은 되는데 성능이 들쭉날쭉한 상황
• 4. 데이터베이스는 살아 있는데 API가 간헐적으로 느린 문제
• 문제 줄이기 위해 정착시킨 검증 절차
• 1년 운영 후 남은 성과와 아쉬움
• OpenStack 멀티노드 운영 정리: 지금 다시 시작한다면
• 자주 묻는 질문
• Q1. 홈랩에서도 멀티노드가 의미가 있나요?
• Q2. 가장 먼저 모니터링해야 할 것은 뭔가요?
• Q3. 설치 도구보다 중요한 건 뭔가요?
• 마무리

[인프라] OpenStack 멀티노드 클러스터 1년 운영 회고

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(에이치에이프록시, 로드밸런서)를 조합하면 기본 뼈대는 갖춰집니다.

배포 자동화는 도구마다 방식이 다르지만, 원칙은 비슷합니다.

1. 호스트 이름과 DNS를 먼저 고정합니다.
2. NTP 또는 Chrony로 시간 동기화를 맞춥니다.
3. 관리망 IP와 서비스 엔드포인트(endpoint, 서비스 접속 주소)를 문서화합니다.
4. 메시지 큐와 데이터베이스 상태를 먼저 확인합니다.
5. 그다음 OpenStack 서비스 등록과 에이전트(agent, 백그라운드 작업 프로세스) 상태를 검증합니다.

제가 자주 쓰던 점검 명령은 이런 식이었습니다.

openstack service list
openstack endpoint list
openstack compute service list
openstack network agent list
openstack hypervisor list
openstack server list --all-projects

처음엔 서비스 목록만 보고 안심했었는데, 실제로는 에이전트가 살아 있어도 기능이 망가진 경우가 있더라고요. 그래서 저는 아래처럼 시스템 레벨도 꼭 같이 확인했습니다.

systemctl --type=service | grep -E 'nova|neutron|cinder|glance|keystone'
ss -lntp
journalctl -u nova-compute -n 100
journalctl -u neutron-server -n 100
rabbitmqctl list_queues
mysql -e 'show processlist;'

여기서 핵심은 "OpenStack 명령 결과"와 "OS 레벨 상태"를 분리해서 보는 겁니다. 둘 중 하나만 보면 꼭 놓치는 구간이 생깁니다.

Keystone, Nova, Neutron, RabbitMQ, MariaDB가 어떤 흐름으로 연결되는지 설명하는 구성 다이어그램 위치입니다.

실전 구현에서 효과 있었던 운영 습관

프로덕션 OpenStack 회고 관점에서 보면, 기술보다 습관이 더 오래 남습니다. 제가 1년 동안 남긴 것 중 실제로 가장 도움이 됐던 건 아래 네 가지였습니다.

1. 변경 작업 전 체크리스트 작성
   패키지 업데이트, 네트워크 설정 변경, 서비스 재시작 전후 확인 항목을 고정했습니다.
2. 설정 파일 차이(diff, 변경점) 기록
   나중에 왜 바꿨는지 기억이 안 나는 순간이 오거든요.
3. 장애 재현 메모
   증상, 원인 후보, 실제 원인, 해결 순서를 남겨두면 다음 장애 때 시간이 확 줄어듭니다.
4. 작은 자동화라도 바로 적용
   반복 명령은 셸 스크립트(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 멀티노드 운영에서 가장 위험한 장애는 완전 다운보다 반쯤 되는 장애입니다. 운영자가 방심하기 쉽거든요.

로그 추적, 큐 적체 확인, 네트워크 흐름 분석을 한 번에 보여주는 운영 관제 이미지 위치입니다.

문제 줄이기 위해 정착시킨 검증 절차

문제가 생긴 뒤 고치는 것도 중요하지만, 더 중요한 건 변경 후 검증입니다. 저는 아래 순서로 체크했습니다.

1. 인증 확인: 토큰 발급과 서비스 카탈로그(service catalog, 서비스 목록) 확인
2. 컴퓨트 확인: 하이퍼바이저 목록과 서비스 up/down 상태 확인
3. 네트워크 확인: 네트워크 생성, 서브넷 연결, 포트 생성 테스트
4. 부팅 확인: 테스트 인스턴스 생성 후 콘솔 접속 확인
5. 삭제 확인: 인스턴스 삭제, 볼륨 정리, 포트 잔존 여부 확인

간단한 검증 흐름 예시는 이렇습니다.

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 멀티노드 운영을 구성한다면 아래 순서로 갑니다.

1. 네트워크 분리 설계부터 문서화합니다.
2. 배포 자동화를 처음부터 전제로 둡니다.
3. 공통 로그와 모니터링을 설치 초기에 붙입니다.
4. 테스트 VM 생성/삭제 검증을 표준 절차로 만듭니다.
5. 장애 기록 템플릿을 운영 첫날부터 사용합니다.

이 다섯 개만 지켜도 OpenStack 배포 실패 사례의 상당수를 예방할 수 있습니다. 물론 환경마다 디테일은 다를 겁니다. 그래도 뼈대는 비슷하더라고요. 특히 OpenStack 멀티노드 운영은 "한 번 설치 성공"보다 "열 번 재현 가능"이 훨씬 값집니다.

자주 묻는 질문

Q1. 홈랩에서도 멀티노드가 의미가 있나요?

있습니다. 오히려 작은 환경에서 역할 분리와 장애 흐름을 이해하기 좋습니다. 다만 과한 고가용성(HA, 고장 대비 이중화)보다는 기본 동작과 복구 절차부터 익히는 게 낫습니다.

Q2. 가장 먼저 모니터링해야 할 것은 뭔가요?

CPU나 메모리보다 먼저 API 응답 지연, 메시지 큐 적체, 데이터베이스 연결 상태, 네트워크 에이전트 상태를 보시는 걸 권합니다.

Q3. 설치 도구보다 중요한 건 뭔가요?

운영 문서, 변경 이력, 검증 절차입니다. 도구는 바꿀 수 있지만 운영 습관은 쉽게 안 바뀌거든요.

마무리

1년 동안 OpenStack 멀티노드 클러스터를 운영하면서 느낀 건, OpenStack은 화려한 기능보다 기본기가 훨씬 중요하다는 점이었습니다. 서비스 간 관계를 이해하고, 장애를 추적하는 순서를 만들고, 변경을 기록하는 것. 이 세 가지가 결국 운영 품질을 갈랐습니다. 저도 처음엔 "왜 이렇게 복잡하지?" 싶었는데, 하나씩 뜯어보니 결국 시스템은 거짓말을 안 하더라고요.

혹시 지금 OpenStack 멀티노드 운영을 준비 중이시라면, 설치 성공 화면에서 끝났다고 생각하지 마시고 검증 절차부터 붙여보세요. 그게 나중에 가장 큰 차이를 만듭니다. 다음 글에서는 스토리지 연동과 백업 전략 쪽을 더 현실적으로 풀어보겠습니다. ✅

📚 함께 읽으면 좋은 글

• OpenStack Neutron 네트워크 장애 진단 및 해결 5단계
• VMware ESXi에서 OpenStack으로 전환한 실제 사례
• OpenStack 멀티노드 배포, 컨트롤러/컴퓨트/네트워크 노드 역할 분석