본문으로 바로가기
*2월 한정! 홈페이지 신규 제작 20% 할인 + AI 챗봇 무료 제공지금 신청
development2026년 2월 18일·조회 44

베어메탈에서 VM으로: 실전 마이그레이션과 재해복구 시스템 구축기

OpenStack 기반 VM 전환부터 2시간 주기 자동 백업까지, 인프라 안정화의 모든 과정

SP

SpacePlanning

SpacePlanning AI Team

## 왜 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 등)을 권장합니다. 백업은 복구가 가능할 때만 의미가 있습니다.
#인프라#VM마이그레이션#재해복구#Docker#PostgreSQL#백업자동화#OpenStack#DevOps
공유하기:

이 주제에 대해 더 알아보고 싶으신가요?

프로젝트 상담을 통해 맞춤형 솔루션을 제안받으세요.