클라우드 환경에서 실행 중인 인스턴스의 스펙을 업그레이드하거나 다운그레이드하는 인스턴스 타입 변경(Instance Type Change)은 인스턴스를 완전히 새로 생성하지 않고도 CPU 코어 수, 메모리 용량, 네트워크 대역폭, 스토리지 I/O 성능 등 컴퓨팅 자원을 실시간에 가깝게 유연하게 조정할 수 있는 매우 강력하고 편리한 기능입니다. 하지만 이 과정은 반드시 인스턴스를 완전히 중지(Stop)한 상태에서만 수행할 수 있으며, 중지 중 EBS 볼륨의 스냅샷 자동 생성 여부, 루트 볼륨 암호화 설정, 네트워크 인터페이스 유지 옵션 등을 사전에 정확히 확인하지 않으면 부팅 실패, 데이터 접근 불가, 예상치 못한 과금 증가 등의 심각한 문제가 발생할 수 있습니다.
클라우드 환경에서 실행 중인 인스턴스의 스펙을 업그레이드하거나 다운그레이드하는 인스턴스 타입 변경(Instance Type Change)은 인스턴스를 완전히 새로 생성하지 않고도 CPU 코어 수, 메모리 용량, 네트워크 대역폭, 스토리지 I/O 성능 등 컴퓨팅 자원을 실시간에 가깝게 유연하게 조정할 수 있는 매우 강력하고 편리한 기능입니다. 하지만 이 과정은 반드시 인스턴스를 완전히 중지(Stop)한 상태에서만 수행할 수 있으며, 중지 중 EBS 볼륨의 스냅샷 자동 생성 여부, 루트 볼륨 암호화 설정, 네트워크 인터페이스 유지 옵션 등을 사전에 정확히 확인하지 않으면 부팅 실패, 데이터 접근 불가, 예상치 못한 과금 증가 등의 심각한 문제가 발생할 수 있습니다.
1. 타입 변경의 기본 요구 사항과 영향
인스턴스 타입 변경은 서비스 중단이 필수이므로, 사전에 변경 가능 여부와 서비스 영향을 확인해야 합니다.
- 필수 중단 (Downtime): 인스턴스 타입 변경을 위해서는 해당 인스턴스를 중지(Stop)해야 합니다. 중지-시작 주기가 발생하므로, 서비스는 필연적으로 다운타임(Downtime)을 겪습니다. 인스턴스를 중지하면 휘발성 스토리지(Instance Store)에 저장된 데이터는 모두 소실되므로, 이 점을 반드시 확인해야 합니다.
- 스토리지 제약 (AWS EC2): AWS의 경우, 기존 세대 인스턴스(M1, C1 등)에서 최신 세대 인스턴스(M5, C5 등)로 변경하려면 EBS 볼륨의 루트 디바이스 타입이 현재 타입과 호환되는지 확인해야 합니다. 특히, 루트 볼륨이 마그네틱(Magnetic)이나 이전 세대 SSD인 경우 변경이 제한될 수 있습니다.
2. 네트워크 및 드라이버 호환성 문제
타입 변경은 CPU와 메모리뿐만 아니라 네트워크 인터페이스의 구성도 함께 변경하기 때문에 호환성 문제가 발생할 수 있습니다.
- 네트워크 드라이버 호환성: 최신 인스턴스 타입(예: AWS C5, M5, GCP N2)은 향상된 네트워킹(Enhanced Networking) 기능이나 NVMe 스토리지 드라이버를 요구합니다. 만약 구형 인스턴스에서 생성된 이미지(AMI)나 OS가 이러한 드라이버를 포함하고 있지 않다면, 타입 변경 후 네트워크에 접속하지 못하거나 디스크를 인식하지 못하여 부팅 실패(Reachability Check Failed) 오류가 발생할 수 있습니다.
- 조치: 타입 변경 전에 OS에 Ena(AWS) 또는 VirtIO(GCP/KVM) 드라이버가 설치되어 있고 활성화되었는지 확인해야 합니다.
- IP 주소 및 MAC 주소 변경: 인스턴스를 중지하고 다시 시작하면 사설 IP 주소(Private IP)가 변경될 수 있으며, 경우에 따라 MAC 주소도 변경됩니다.
- 조치: 정적 IP를 사용해야 한다면 인스턴스 중지 전에 Elastic IP(EIP)나 보조 사설 IP(Secondary Private IP)를 연결하여 IP 유실을 방지해야 합니다. 또한, OS 내부에서 정적 IP 설정을 사용했다면, 새 MAC 주소와 충돌하지 않도록 설정 파일(ifcfg-eth0 등)을 DHCP로 변경해야 합니다.
3. 라이선스 및 비용 문제
타입 변경이 단순히 기술적인 문제만 일으키는 것은 아니며, 비용 및 법적인 측면도 고려해야 합니다.
- 운영체제 라이선스: 온디맨드 라이선스(예: Windows Server)의 경우, 라이선스가 인스턴스 타입에 묶여 있기 때문에 일반적으로 문제가 없습니다. 그러나 BYOL(Bring Your Own License)을 사용하거나 코어(Core) 수 기반으로 라이선스를 구매한 경우, CPU 코어 수가 증가하면 라이선스가 부족해지거나 규정을 위반할 수 있습니다. 타입 변경 전에 라이선스 허용 범위를 반드시 확인해야 합니다.
- 비용 예측: 인스턴스 타입이 변경되면 시간당 비용이 크게 달라집니다. 특히 GPU가 추가되거나 메모리 집약적인 인스턴스 타입으로 변경할 경우, 월별 청구 비용을 사전에 정확히 예측해야 합니다.
4. 모범 사례: 사전 확인 및 백업
안전한 타입 변경을 위해 다음의 순서를 따르는 것이 좋습니다.
- 백업: 타입 변경 전, 현재 인스턴스의 AMI를 생성하거나 루트 볼륨의 스냅샷을 생성하여 언제든지 원본 상태로 복구할 수 있도록 대비합니다.
- 드라이버 확인: OS 내부에서 필요한 최신 네트워크 및 스토리지 드라이버가 설치되어 있고 부팅 시 로드되는지 확인합니다.
- 중지 및 변경: 인스턴스를 중지하고 원하는 신규 타입으로 변경을 진행합니다.
- 부팅 확인: 인스턴스 시작 후, AWS의 시스템 로그(System Log) 또는 GCP의 시리얼 콘솔(Serial Console)을 통해 부팅 과정을 확인하여 오류 없이 OS 프롬프트까지 도달했는지 검증합니다.
Disclaimer: 본 블로그의 정보는 개인의 단순 참고 및 기록용으로 작성된 것이며, 개인적인 조사와 생각을 담은 내용이기에 오류가 있거나 편향된 내용이 있을 수 있습니다.