베어메탈에서 VM으로 마이그레이션하는 법 | 재해복구 시스템 구축 가이드

## 왜 VM 마이그레이션이 필요한가? 베어메탈(Bare Metal) 서버는 높은 성능을 제공하지만, 유연성과 복구 능력 면에서 한계가 있습니다. 하드웨어 장애 시 서비스 중단이 길어지고, 스케일 아웃도 쉽지 않습니다. 반면 OpenStack과 같은 IaaS 플랫폼 위에서 VM(Virtual Machine)으로 서비스를 운영하면 스냅샷·볼륨 백업·신속한 복구 등 운영 효율이 크게 향상됩니다. 이 글에서는 실제 프로덕션 환경에서 베어메탈 서비스를 VM으로 이전하고, 재해복구(DR) 체계를 구축한 경험을 일반화하여 공유합니다. --- ## 1. 마이그레이션 전 체크리스트 VM 이전 전에 반드시 정리해야 할 항목입니다. - **서비스 인벤토리 작성**: 각 VM에 올라갈 서비스, 포트, 의존성을 표로 정리합니다. - **네트워크 설계**: 외부 브리지(br-ex 등) 설정, 보안 그룹 규칙, 방화벽 정책을 사전에 확정합니다. - **데이터베이스 접근 제어**: PostgreSQL의 경우 `pg_hba.conf`에 VM의 IP 대역을 미리 추가해야 합니다. 이를 빠뜨리면 마이그레이션 후 DB 연결 실패가 발생합니다. ```bash # pg_hba.conf 예시 - VM 서브넷 허용 host all all 10.0.0.0/24 md5 ``` --- ## 2. 마이그레이션 과정에서 흔히 만나는 문제 ### 스키마 충돌 (Schema Conflict) 워크플로우 자동화 도구(예: n8n)처럼 자체 DB 스키마를 관리하는 애플리케이션은 마이그레이션 시 기존 스키마와 충돌할 수 있습니다. 이럴 때는 스키마를 완전히 드롭(drop)하고 재생성하는 방식이 가장 안전합니다. ```sql -- 스키마 재생성 예시 DROP SCHEMA public CASCADE; CREATE SCHEMA public; ``` 단, 이 작업 전에 반드시 데이터 덤프를 확보하세요. ### 네트워크 브리지 자동 복구 OpenStack 환경에서 외부 네트워크 브리지(br-ex)는 서버 재부팅 시 설정이 초기화되는 경우가 있습니다. 이를 systemd 서비스로 등록하면 재부팅 후 자동 복구가 가능합니다. ```ini # /etc/systemd/system/fix-br-ex.service [Unit] Description=Restore br-ex bridge configuration After=network.target [Service] Type=oneshot ExecStart=/usr/local/bin/fix_br_ex.sh RemainAfterExit=yes [Install] WantedBy=multi-user.target ``` ```bash systemctl enable fix-br-ex.service ``` --- ## 3. 자동화된 백업 시스템 설계 마이그레이션 이후 가장 중요한 것은 **정기 백업 자동화**입니다. cron을 활용한 3단계 백업 구조를 권장합니다. | 대상 | 주기 | cron 표현식 | |------|------|-------------| | DB (PostgreSQL) | 2시간마다 | `0 */2 * * *` | | VM 볼륨 + compose 파일 | 2시간마다 (15분 오프셋) | `15 */2 * * *` | | 헬스 체크 | 5분마다 | `*/5 * * * *` | DB 백업은 `pg_dump`로 public 스키마만 추출하고, Docker 환경이라면 볼륨 디렉토리와 `docker-compose.yml`을 함께 묶어 보관하는 것이 복구 속도를 높입니다. ```bash # PostgreSQL 백업 예시 pg_dump -h localhost -U postgres -n public mydb > backup_$(date +%Y%m%d_%H%M).sql # Docker 볼륨 백업 예시 tar czf volumes_$(date +%Y%m%d_%H%M).tar.gz /var/lib/docker/volumes/ ``` --- ## 4. 헬스 모니터링 자동화 5분 간격 헬스 체크 스크립트는 VM 상태, DB 연결, 주요 서비스 포트 응답을 확인하고 이상 시 알림을 발송하는 구조로 설계합니다. ```bash #!/bin/bash # health_check.sh 핵심 로직 check_service() { local host=$1 local port=$2 nc -z -w3 "$host" "$port" && echo "OK" || echo "FAIL" } # DB 연결 확인 pg_isready -h db-host -p 5432 || notify "DB connection failed" # 서비스 포트 확인 for port in 8080 8443 3000; do result=$(check_service app-host $port) [ "$result" = "FAIL" ] && notify "Port $port unreachable" done ``` --- ## 5. 재해복구 문서화의 중요성 기술적인 구현 못지않게 **문서화**가 핵심입니다. 최소한 아래 두 가지는 반드시 갖춰야 합니다. 1. **서비스 레지스트리**: VM별 서비스 목록, 포트, 담당자, 재시작 명령어 2. **재해복구 런북(Runbook)**: 장애 유형별 단계별 복구 절차와 복구 스크립트 장애 상황에서는 판단력이 흐려지기 쉽습니다. 런북이 있으면 누구라도 절차에 따라 복구할 수 있습니다. --- ## 마치며 VM 마이그레이션은 단순한 서버 이전이 아니라, 인프라 운영 방식을 한 단계 성숙시키는 과정입니다. 핵심은 세 가지입니다. - **사전 준비**: 네트워크, DB 접근 제어, 서비스 인벤토리 - **자동화**: 백업·헬스 체크를 cron과 systemd로 자동화 - **문서화**: 런북과 서비스 레지스트리로 팀 전체가 대응 가능한 체계 구축 이 세 가지를 갖추면 장애 발생 시에도 빠르게 복구하고, 서비스 안정성을 높일 수 있습니다.

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

관련 글

AI 개발 도구 생태계: MCP 서버와 에이전트 스킬 소스 관리 가이드

Wiki.js API 권한 설정과 계정 생성 자동화 구축하기

AI 에이전트 시스템을 위한 커널 아키텍처 설계 가이드

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