아마존 Elastic Compute Cloud(EC2)는 전 세계 사용자에게 즉시 확장 가능한 컴퓨팅 자원을 제공하도록 설계된 웹 서비스입니다. 아마존의 대규모 데이터 센터 안에 구축된 거대한 가상화 그리드로, 필요할 때마다 CPU 연산 능력과 디스크 공간을 누구에게나 실시간으로 공급합니다. 사용자가 할 일은 결제뿐이며, 생각보다 비용도 많이 들지 않습니다.
아마존은 자체 인프라를 구축하고 유지하는 비용과 견줄 만한, 매우 합리적인 가격에 이 서비스를 제공합니다. 일반 가정용 사용자에게는 당장 크게 와닿지 않을 수 있지만, 수요 변동이 잦은 중소기업이라면 하드웨어에 얽매이지 않는 유연성이 분명 매력적으로 다가올 것입니다.
이 개념을 좋아하는 사람도 있고 싫어하는 사람도 있겠습니다. 저는 특히 리눅스 기반으로 운영되고 주로 리눅스를 지원한다는 점에서 훌륭한 프로젝트라고 생각하며, 이는 리눅스 시장 성장에 상당한 기회가 됩니다. 마크 셔틀워스(Mark Shuttleworth)는 아마존 기능을 우분투(Ubuntu) 차기 버전에 통합하려는 계획으로 많은 비판을 받았지만, 데스크톱과 웹의 요구가 융합되는 시대에는 클라우드만이 제공할 수 있는 '유연함'이 필요하기 때문에 현명한 선택이라고 봅니다.
가정에서의 활용
집에서는 클래식한 가상화가 제공하는 수준 이상의 성능이 필요한 경우가 드뭅니다. 하지만 거실에 16GB RAM을 갖춘 데이터베이스 서버를 두는 데 드는 비용을 고민하게 되는 순간, 아마존을 진지하게 고려하게 될 것입니다.
그런 일이 생긴다면 아마존 EC2 사용법을 알아야겠죠. 전체 과정을 다루는 완전한 튜토리얼은 이 글의 범위를 벗어나며, 공식 문서를 참고하시면 됩니다.
대신 이 글에서는 그중에서도 가정용 사용자가 가장 마주치게 될 핵심 부분, 바로 아마존 가상 머신 이미지 생성 방법을 소개하겠습니다. VMware 제품에서 사용하는 가상 하드 디스크를 EC2에서 사용할 수 있는 아마존 호환 이미지로 변환하는 과정을 보여드립니다.
처음부터 아마존용 이미지를 만들거나 기존 템플릿을 쓰면 안 되나요?
좋은 질문입니다! 아마존은 처음부터 이미지를 직접 만들거나, SUSE·Ubuntu·RedHat 같은 기존 템플릿을 출발점으로 삼는 것을 허용합니다. 다만 이미지 생성 과정은 다소 복잡하고, 기존 템플릿이 원하는 형태가 아닐 수도 있습니다. 예컨대 특수하게 커스터마이징된 배포판을 돌리고 싶거나, 본인만 접근할 수 있는 디지털 서명된 프라이빗 이미지를 사용하고 싶을 수 있습니다. 완전한 통제권을 원한다면 남에게 이미지 생성을 맡길 수 없겠죠.
목표: 집에서 이미지를 만들고, 아마존에 업로드하기
이 튜토리얼은 매우 구체적인 주제로 좁혀서 다룹니다. 자체 인증서를 갖춘 프라이빗 이미지를 원하고, 대역폭 비용이나 긴 설정 작업에 돈을 낭비하지 않으면서 집에서 여유 있게 만들고 싶은 것이죠. 준비가 끝나면 이를 변환해 아마존 Simple Storage Service(S3)에 업로드하게 됩니다.
참고: 이 튜토리얼의 내용을 실제로 활용하려면 유효한 아마존 EC2 계정이 반드시 필요합니다. 또한 성공적으로 따라 하려면 리눅스 환경을 사용해야 합니다. 여기서 사용하는 일부 도구는 리눅스 전용입니다. 아마존 자체가 리눅스 위에서 돌아간다는 점을 감안하면 놀랄 일은 아니죠.
첫 번째 질문: 무엇을 변환하는가?
역시 좋은 질문입니다. 데스크톱 가상화 포맷은 매우 다양하지만, 집에서 가상화를 한다면 VMware 제품군을 사용하고 있을 가능성이 높습니다. VMware는 가상 하드 디스크에 .vmdk 포맷을 사용합니다. 이것이 우리의 소스 포맷이며, 이것을 아마존 머신 이미지(AMI)로 변환하는 것이 목표입니다.
그러나 VMDK 가상 디스크를 AMI로 직접 변환할 수는 없습니다. 어떤 절차가 필요한지 이 글에서 단계별로 설명하겠습니다.
1단계: 필요한 모든 요소 확인하기
본격적으로 시작하기 전에, 섣불리 변환 작업에 뛰어들기 전에 반드시 고려해야 할 중요한 사항들이 꽤 많습니다.
또한 읽기 시작하기 전에 알아두셔야 할 점이 있습니다. 아마존 EC2는 아직 초기 단계의 프로젝트였으므로, 여기서 제시하는 권장 사항은 미래의 환경에는 부분적으로만 적용되거나 전혀 맞지 않을 수 있습니다. 평소에는 결론을 조심스럽게 말하지 않지만, 이 경우에는 변수가 너무 많아 성공을 보장하기 어렵습니다. 하지만 이 정직한 고백 때문에 기운 내지 마세요! 함께 따라와 주세요.
아마존 일반 요구 사항 (VMware와 무관)
Xen 요구 사항
변환 후 아마존에서 사용하려면 배포판을 Xen에 맞게 준비(xenify)해야 합니다. 아마존의 가상 인프라는 오픈소스 하이퍼바이저인 Xen 기반으로, VMware·KVM 등 다른 가상화 제품과 유사합니다. 아마존 가상 머신이 이 플랫폼에서 실행되려면 특정 커널과 커널 모듈이 필요합니다. 적절한 Xen 커널을 내려받고 압축을 풀어 Xen 모듈을 설치한 뒤 GRUB 메뉴를 갱신해야 합니다.
구체적으로는 사용 중인 배포판의 웹사이트나 소프트웨어 저장소에서 해당 버전에 맞는 커널을 내려받습니다. 압축을 해제하고 파일들을 /boot와 /lib에 넣습니다. 다음으로 관련 모듈 파일을 생성합니다:
depmod -F /boot/System.map-<kernel>-xenU -a <kernel>-xenU
여기서 kernel은 uname -r 명령으로 확인한 자신의 버전과 일치해야 합니다.
완료되면 /lib/modules/<kernel>-xenU 디렉터리 아래에 모듈이 존재하는지 확인합니다. 마지막으로 GRUB의 menu.lst 설정 파일에 Xen 커널 항목(stanza)을 추가하고, 이 항목이 기본 부팅 항목이 되도록 합니다.
파티셔닝 요구 사항
또 하나 까다로운 부분입니다. 아마존 가상 머신은 매우 구체적인 파티션 레이아웃을 요구합니다. /etc/fstab 구조는 다음과 같아야 합니다:
/dev/sda1 / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
자체 스왑(swap)이나 /mnt 마운트 지점을 사용 중이라면 /etc/fstab에서 제거하세요. 아마존이 인스턴스 실행 시 자체 설정을 적용하기 때문입니다.
일반적으로 가상 머신이 어떤 모습이어야 하는지에 대한 세부 사항은 아마존의 'Creating an AMI' 공식 문서를 참고하세요. 방대한 정보에 압도되지 않아도 됩니다. 대부분은 이 테스트 사례와 무관하며, 실질적으로 신경 써야 할 것은 커널 모듈, 파티션 레이아웃, 네트워크 설정 세 가지입니다.
기본 런레벨 및 서비스
아마존 머신에 실제로 접속하려면 방화벽 서비스를 비활성화하거나 SSH 인바운드 연결을 허용하도록 설정하고, 기본 런레벨에서 SSH 서비스가 활성화되어 있어야 합니다. 기본적으로 SSH는 TCP 22번 포트를 사용합니다.
런레벨 이야기를 하자면, Xen 머신은 보통 사용되지 않는 런레벨 4로 부팅됩니다. 따라서 /etc/inittab 파일을 편집해 런레벨 4의 주석을 해제하고 기본 런레벨로 지정해야 합니다. 또한 관련 서비스를 활성화해야 하는데, 추천할 만한 마법 같은 서비스 목록은 없습니다.
참고로 아마존에서는 X(그래픽 세션)를 실행할 수 없으므로 런레벨 5는 논외입니다. 런레벨별 서비스 구성에 도움이 필요하다면 관련 리눅스 서비스 튜토리얼을 참고하세요.
네트워크 인터페이스
네트워크 장치가 DHCP를 통해 IP 주소를 할당받도록 구성하고 IPv6 프로토콜은 비활성화해야 합니다. 대부분의 경우 기본값이므로 큰 작업은 아닙니다.
추가로 알아두어야 할 중요 사항
VMware 제품은 데이터가 채워짐에 따라 커지는 동적 확장형 이미지를 지원합니다. 따라서 40GB 가상 디스크라도 실제 데이터가 700MB뿐이면 용량도 700MB에 불과합니다. 물론 크기를 미리 할당(pre-allocate)할 수도 있는데, 이 경우 디스크는 처음부터 40GB 전체 크기를 차지합니다. 디스크 공간을 아끼기 위해 많은 사용자가 동적 디스크를 선호합니다.
하지만 VMDK를 RAW로 변환하는 순간 동적 확장의 이점은 사라집니다. 디스크 이미지는 실제 크기만큼 확장됩니다. 따라서 가상 머신 생성 시 디스크 크기에 주의하세요.
둘째, 아마존은 현재 최대 10GB까지만 이미지를 지원합니다. 즉, VMDK가 10GB를 초과하면 안 됩니다. 그렇지 않으면 AMI를 만들 수 없으며 다음과 같은 오류가 발생합니다:
ERROR: the specified image file <something>.raw is too large
셋째, 리눅스 머신에 Java와 Ruby가 설치되어 있어야 합니다. 그리고 이 튜토리얼 3단계를 수행하려면 리눅스 머신이 반드시 필요합니다. 작업을 시작하기 전에 이 모든 요건을 충족했는지 확인하세요.
2단계: QEMU로 VMDK를 RAW로 변환하기
필요한 것이 무엇인지 알았으니 이제 QEMU를 사용해 변환합니다. QEMU는 Windows와 Linux 모두에서 사용할 수 있는 강력한 만능 에뮬레이터이자 이미지 유틸리티로, VMDK 파일을 RAW 포맷으로 변환할 수 있습니다.
QEMU는 오래전 VMware Player 관련 글에서 가상 하드 디스크 생성 도구로 소개한 바 있습니다. 변환 같은 디스크 관련 작업에도 활용할 수 있습니다.
VMware 디스크를 RAW 포맷으로 변환해야 합니다. 본질적으로 이 과정은 디스크 이미지에서 VMware의 스마트한 알고리즘을 걷어내고, 섹터 단위의 순수 디스크 이미지로 확장하는 작업입니다.
QEMU는 이 작업을 잘 처리합니다. 사실 QEMU는 다양한 변환에 사용할 수 있지만, 지금 우리가 원하는 것은 vmdk → raw 변환입니다. 해당 .vmdk 파일을 찾아 다음 qemu-img 명령을 실행하세요:
qemu-img convert -O raw source.vmdk target.raw
작업이 완료될 때까지 기다립니다. 머신 사양과 이미지 크기에 따라 시간이 꽤 걸릴 수 있습니다.
3단계: AMI 도구로 이미지 번들링하기
아마존은 EC2 서비스 작업을 위해 두 가지 도구 세트를 제공합니다. 하나는 EC2 서비스용 클라이언트 인터페이스인 API 도구이고, 다른 하나는 AMI를 생성·번들링·업로드하는 명령줄 유틸리티 모음인 AMI 도구입니다.
우리에게 필요한 것은 AMI 도구입니다. 내려받아 압축을 풀되, 가급적 홈 디렉터리 안에 두세요. 그다음 다음과 같은 형태의 긴 변환 명령을 실행합니다:
./ec2-bundle-image -i <image> -r <arch> -c <cert>
-k <key> --user <user id>
옵션을 하나씩 살펴보겠습니다.
- -i <image>: RAW 파일 경로입니다.
- -r <arch>: 가상 머신의 아키텍처(i386, x86_64 등)입니다.
- -c <cert>: 아마존에서 발급받은 인증서입니다. 홈 디렉터리나 명령을 실행하는 디렉터리에 보관해야 합니다. ec2-bundle-image 명령은 인증서 경로 끝의 슬래시(/)를 허용하지 않기 때문입니다. 이유는 불분명하지만 어쨌든 그렇습니다. 슬래시를 붙이면 다음과 같은 오류가 발생합니다:
--prefix has invalid value 'cert.pem':'/' character not allowed.
- -k <key>: 개인 키(private key)입니다. 인증서와 동일한 규칙이 적용됩니다.
- --user <user id>: 아마존 사용자 ID입니다.
환경 변수 설정
명령을 그대로 입력했다고 해서 끝이 아닙니다. ec2-bundle-image는 다음과 같이 불평할 것입니다:
ec2-bundle-image: line 3: EC2_HOME: Neither of EC2_AMITOOL or EC2_HOME environment variables are set
즉, 유틸리티를 사용하기 전에 몇 가지 환경 변수를 export해야 합니다.
BASH
bash에서는 export 명령을 사용합니다:
export EC_HOME=<path>
export EC_AMITOOL_HOME=<path>
TCSH
tcsh는 export를 지원하지 않으므로 대신 setenv를 사용합니다:
setenv EC_HOME <path>
setenv EC_AMITOOL_HOME <path>
경로는 다음에 해당해야 합니다:
- EC_HOME: 홈 디렉터리 또는 그 안의 ec2 하위 디렉터리일 가능성이 높습니다. /tmp 파일시스템은 사용하지 마세요. EC_HOME이 '안전하지 않은, 전체 읽기 가능한 디렉터리'라고 불평할 수 있습니다.
- EC_AMITOOL_HOME: AMI 도구의 압축을 푼 디렉터리입니다.
매번 변수를 수동으로 입력하는 게 지겹다면, 모든 변수와 값을 담은 파일을 만들어 두고 필요할 때 source로 불러오는 방법도 효율적입니다:
source file-containing-all-exports
이제 준비가 끝났습니다. 긴 변환 명령에서 Enter 키를 누르고 기다리세요. 잠시 후 프로세스가 성공적으로 완료될 것입니다. '성공적으로'라는 말을 강조하는 이유는, 이것이 작동하려면 앞서 언급한 섬세한 준비 작업들을 모두 완료해야 하기 때문입니다.
VMDK → RAW → AMI 변환에 성공했다면 이제 파일을 업로드할 준비가 된 것입니다. 변환이 성공했음을 알려주는 신호는 /tmp 디렉터리에 생성된 파일 목록과 XML 매니페스트 파일입니다. /tmp가 기본 출력 디렉터리입니다.
이것으로 실제 변환 과정은 끝입니다. 다음 단계는 업로드이지만, 이는 이 글의 범위를 벗어납니다. 다음 기회에 다루겠습니다. 아마존은 앞으로도 계속 성장할 것이므로, 관련 글이 앞으로도 더 올라올 것입니다.
결론
보시다시피 이 작업은 간단하지는 않지만 충분히 수행 가능하며, 상당한 시간과 대역폭, 나아가 비용을 절약해 줍니다. 이미지를 변환할 수 있다는 것은 아마존 EC2의 특정 요건을 넘어선 자유를 의미합니다. 앞서 VMware Converter를 활용하는 방법을 살펴봤는데, 이번에는 QEMU라는 또 하나의 강력한 도구로 가상화 요구를 충족할 수 있었습니다.
다만 꽤 많은 규칙을 지켜야 하며, 특히 AMI 도구 관련 사항이 중요합니다. 이미지가 너무 크지 않은지, 인증서와 개인 키 경로 끝에 슬래시를 붙이지 않았는지, 환경 변수가 제대로 export되었는지, 아마존 도구를 '안전하지 않은' 디렉터리에 두지 않았는지 등을 확인하세요. 이제 클라우드 위를 걸으며 즐거운 시간 보내시기 바랍니다.
후속 글에서는 강력한 SUSE Build Service의 훌륭한 구성 요소인 Kiwi를 다루고, 이를 활용해 커스텀 배포판이나 심지어 자신의 물리적 설치 환경에서 Xen 또는 AMI 이미지를 생성하는 방법을 소개하겠습니다. VMware Converter에 필적하거나 그 이상의 기능을 제공하는 Image Creator와 Product Creator도 함께 살펴볼 예정입니다. SUSE Studio와 그 밖의 흥미로운 혁신적인 개념, 아이디어, 프로젝트들도 이야기하겠습니다.
Markus, AMI 튜토리얼을 요청하셨죠? 여기 있습니다. 즐겁게 읽어주세요.
Cheers.