## 왜 VM 마이그레이션이 필요한가?
베어메탈 서버는 높은 성능을 제공하지만, 유연성과 복구 가능성 측면에서 한계가 있습니다. 하드웨어 장애 시 서비스 중단이 길어지고, 리소스 확장에도 물리적 제약이 따릅니다. 반면 VM(가상머신) 환경으로 전환하면 스냅샷 백업, 빠른 복구, 리소스 동적 할당이 가능해집니다. 이 글에서는 실제 프로덕션 환경을 베어메탈에서 OpenStack 기반 VM으로 전환하면서 겪은 과정과 재해복구 시스템 구축 노하우를 공유합니다.
---
## 마이그레이션 전략: 서비스 단위 분리
대규모 서비스를 한 번에 이전하면 장애 범위가 넓어집니다. 실전에서 검증된 방법은 **역할 기반 VM 분리**입니다.
```
[API 서버 VM] → API 서비스 6개
[프로덕션 VM #1] → 핵심 서비스 6개
[프로덕션 VM #2] → 클라이언트 서비스 4개
[개발/샌드박스 VM] → 실험용 서비스 9개
```
각 VM을 역할별로 분리하면 장애 격리(Fault Isolation)가 쉬워지고, 롤백도 VM 단위로 독립적으로 수행할 수 있습니다.
### 마이그레이션 체크리스트
1. **서비스 인벤토리 작성**: 이전할 서비스 목록, 의존성, 포트 매핑 정리
2. **Docker Compose 파일 버전 관리**: 모든 서비스 구성을 Git으로 관리
3. **데이터 볼륨 백업**: 마이그레이션 전 전체 Docker 볼륨 스냅샷
4. **헬스체크 자동화**: 이전 후 서비스 상태를 자동으로 확인
---
## 재해복구 시스템: 2시간 주기 자동 백업
마이그레이션보다 중요한 것은 **이후의 지속적인 안전망**입니다. 다음 구조로 자동 백업 파이프라인을 구성했습니다.
### 백업 대상과 주기
| 대상 | 방식 | 주기 |
|------|------|------|
| PostgreSQL DB | public 스키마 덤프 | 2시간마다 |
| Docker 볼륨 | 압축 아카이브 | 2시간마다 |
| Compose 설정 | 파일 복사 | 2시간마다 |
| 서비스 헬스 | HTTP 상태 확인 | 5분마다 |
### PostgreSQL 백업 스크립트 예시
```bash
#!/bin/bash
DATE=$(date +%Y%m%d_%H%M)
BACKUP_DIR="/backup/postgres"
pg_dump -h localhost -U postgres \
--schema=public \
mydb > "$BACKUP_DIR/db_$DATE.sql"
# 7일 이상 된 백업 자동 삭제
find $BACKUP_DIR -name "*.sql" -mtime +7 -delete
```
### Docker 볼륨 백업
```bash
#!/bin/bash
DATE=$(date +%Y%m%d_%H%M)
for volume in $(docker volume ls -q); do
docker run --rm \
-v $volume:/data \
-v /backup/volumes:/backup \
alpine tar czf /backup/${volume}_$DATE.tar.gz /data
done
```
crontab에 등록하면 2시간 주기 자동 실행이 가능합니다:
```
0 */2 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1
```
---
## 실제로 겪은 문제와 해결법
### 1. PostgreSQL 접속 거부 문제
VM IP가 변경되면 `pg_hba.conf`에 새 IP를 추가해야 합니다.
```
# pg_hba.conf
host all all 10.0.0.0/24 md5
```
변경 후 `pg_reload_conf()` 또는 서비스 재시작이 필요합니다.
### 2. 워크플로우 자동화 도구 마이그레이션 충돌
DB 스키마를 그대로 복사하면 기존 데이터와 충돌이 발생할 수 있습니다. 이 경우 스키마를 완전히 재생성(DROP → CREATE)하고 데이터만 별도 임포트하는 방식이 안전합니다.
### 3. 네트워크 브릿지 자동 복구
VM 재부팅 시 네트워크 브릿지 설정이 초기화되는 문제는 `systemd` 서비스로 등록해 해결합니다.
```ini
# /etc/systemd/system/network-bridge.service
[Unit]
Description=Network Bridge Setup
After=network.target
[Service]
Type=oneshot
ExecStart=/opt/scripts/setup-bridge.sh
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
```
---
## 핵심 요약 및 다음 단계
베어메탈에서 VM으로의 마이그레이션은 단순한 이사가 아닌, **인프라 안정성의 근본적인 개선**입니다. 핵심은 세 가지입니다.
- **역할별 VM 분리**로 장애 범위 최소화
- **자동화된 주기적 백업**으로 데이터 손실 방지
- **헬스모니터링**으로 장애를 사람보다 먼저 감지
다음 단계로는 백업 데이터의 **복구 테스트 자동화**(실제로 복구가 되는지 주기적으로 검증)와 **알림 시스템 연동**(Slack, PagerDuty 등)을 권장합니다. 백업은 복구가 가능할 때만 의미가 있습니다.
development
베어메탈에서 VM으로: 실전 마이그레이션과 재해복구 시스템 구축기
OpenStack 기반 VM 전환부터 2시간 주기 자동 백업까지, 인프라 안정화의 모든 과정
SpacePlanning · SpacePlanning AI Team2026년 2월 18일조회 162