#2 VM(가상컴퓨터)에 대하여

안녕하십니까. 빅두 입니다.

이번엔 가상컴퓨터에 대해서 알아보도록 하겠습니다.

서두는 씹어먹어 버리고, 바로 시작해 보겠습니다.

 

먼저 남아메리카의 큰 강부터 소개해 보죠

다들(아마….) 아시다시피 AWS는 Open Stack을 이용하여 클라우드 라는 인프라를 구성하였습니다. 지금 생각해 보면 참 대단한 기업이구나~ 싶기도 합니다.

AWS의 시작은 PV(ParaVirtual)에서 시작합니다. PV란 기존 서버의 리눅스 커널에 체인을 걸어 독립적인 구성을 지원하는 반 가상화 시스템입니다. 때문에 기본적으로 접속에 대한 보안이 대두가 되었으며, 원본이 되는 Linux의 커널을 사용했기 때문에 버전 이슈 및 드라이버 이슈가 많았었습니다.

Linux는 보편적으로 Shell을 접속할 때 SSH를 이용하였기 때문에 AWS는 보안 최고등급인 공개/개인키를 제작하여 해당 키를 기반으로 접속을 하도록 보안을 강화하였습니다. 그러다 보니 AWS 사용자들은 공개키를 만들어야 하는 불편함이 생겨서 AWS에서는 "까짓꺼 우리가 만들어 줄께"라는 개념으로 Key-Pair라는 서비스가 있습니다. 이 개념으로 AWS 리소스 관리자는 Key-Pair Name으로 EC2를 제작하고, 실제 Server 관리자(Admin)은 생성된 Key-Pair의 .pem 파일로 EC2 운영체제에 접근하는 업무 이원화가 가능합니다.

 

현재 AWS에서는 PV를 사용하지 않는 것을 권장하고 있습니다만, 어찌되었든, 현재도 사용하고 있는 Type이기 때문에 간단하게 그림으로 설명을 드리도록 하겠습니다.

 

 

PV Type의 VM인 EC2(Elastic Cloud Compute)는 Hypervisor로 동작중인 Host의 Kernel에 링크를 걸어 사용됩니다. 그렇기 때문에 Boot volume은 Host의 용량을 사용할 수 밖에 없는 그림이 되어 버립니다. PV의 좋은 점이라고도 할 수 있겠습니다만, OS Kernel을 공유함으로써 Host Internal Disk의 일부 영역을 할당 받습니다. SAN or iSCSI 연결이 아닌 Local 접근이 되는 Disk영역이기 때문에 접근성(읽기/쓰기)가 빠르다는 장점이 있습니다. 별도의 EBS Volume을 쓰지 않고 VM을 동작 시킬 수 있다는 장점도 가지고 있습니다. 이 Disk의 단점은 휘발성 이라는 점 입니다.

 

PV의 치명적인 단점이 있습니다. 바로 드라이버(Driver) 이슈 입니다. 위에서 보시는 그림으로는 Host Linux의 Kernel에 링크를 걸어 동작시키는 그림이기 때문에 전적으로 Host의 Driver에 의존하는 그림입니다. 따라서, Hypervisor의 Version과 더불어 Driver의 이슈가 발생하게 되면 모든 VM은 해당 업데이트 패치를 진행해 주어야 합니다.

 

HVM은 우리가 잘 알고 있는 전 가상화 방식입니다. 각각 VM은 CPU, Memory, Disk를 별도로 할당 받으며, 할당 받은 리소스 내에서만 동작이 가능하도록 설계 되어 있습니다. 글을 읽으시는 분들도 잘 알고 계시겠지만, 그래도 그림으로 도식화 하여 설명해 보겠습니다.

 

 

다들 너무 잘 알고 있는 그림이라 굳이 설명은 안 드리겠습니다만, 어찌됐든 HVM은 마이크로커널 방식의 전가상화 시스템이라는 것입니다.

다들 궁금하지 않으시겠지만, 개인적으로 AWS Support를 통해 물어보니 EBS는 SCSI로 연결되어 있다고 합니다. IDE를 사용하지 않으니 이 얼마나 놀랍습니까?

 

리소스 얘기를 좀 해보겠습니다.

EC2는 EBS라는 Volume과 ENI라는 Network Interface가 있어야 제작이 가능합니다. 물론 AWS 마법사(?)를 통해 EC2 제작 시에 같이 만들 수 있습니다.

기본적으로 EC2와 EBS, ENI는 AZ에 종속됩니다. 특히 ENI의 경우 Subnet에 종속 되고, Subnet은 VPC에 종속되는 리소스 입니다. 이 관계는 잘 알고 계셔야 합니다.(나중에 삽질하지 않으시려면…)

Security Group이라는 녀석은 ENI와 N:1 Mapping이 가능하며, Security Group은 VPC에 종속을 받습니다.

공인 IP인 EIP는 ENI와 1:1 Mapping이 가능하며 VPC에만 종속을 받습니다.

네트워크도 같이 이야기 해야 이해가 되시는 부분이 있지만, 이번 블로깅은 컴퓨팅만 주제로 하니 나중에 네트워크 쪽 할 때 연결해 드리겠습니다.

말로 쓰니까 많이 복잡하시죠? 그럼 그림으로 그려보죠~

 

 

나중에 AWS 문서든 다른 것들을 보실 때 아이콘과 표시에 익숙해 지시라고 아이콘은 AWS아이콘으로 첨부 드렸습니다. VPC는 아이콘이 두 개고, ENI는 아이콘이 없더라고요. 제보 해 주시면 수정하겠습니다.

 

옵션까지 자세하게 설명드리긴 너무 길어지니 아래 URL을 참고해 주세요.

EC2 : https://aws.amazon.com/ko/ec2/instance-types/

EBS : http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

 

EC2는 기본적으로 AWS Marketplace에 게시된 AMI로 생성이 가능하며, Custom AMI 또는 VM Import 기능으로 EC2를 생성하실 수 있습니다.

VM 가져오기 : http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/UsingImportImage.html

 

기본적으로 AWS 계정을 처음 생성 하시면 생성 가능한 EC2의 개수는 20개로 제한되어 있습니다. AWS를 사용하실 땐 언제나 한계 값을 고려하여 사용하셔야 별 탈이 없습니다.

 

 

그럼 다음으로 작은 프로그램에 대해 알아 봅시다.

이것도 이미 아시다시피 Azure는 자사 솔루션인 Hyper-V를 이용하여 구축되어 있습니다. 들리는 말로는 WS2016에서 나오는 Nano Server가 Azure용 OS라고 하던데 그건 접어두고요.

 

기본적으로 Hyper-V는 마이크로커널 방식의 전가상화 입니다.

편의를 위해 Azure Classic은 언급하지 않고 AzureRM기준으로 알아보겠습니다.

Azure를 보고 저를 가장 놀라게 했던 것은 UI가 아닌 Resource Group 이었습니다. 이건 물건입니다. 찬송가를 만들까? 생각도 했었습니다.

결론부터 말씀 드리자면, Azure의 모든 Resource는 Resource Group에 종속됩니다. 그리고 Resource Group간 Resource접근도 가능합니다(무슨 이런 먼치킨이!?) 뭐 자세한 내용은 다른 블로깅에서 다루기로 하겠습니다. 왜냐하면 이번 블로깅은 컴퓨팅에 관련된 내용만 올릴꺼니 까요.

리소스 이야기가 나와서 정리를 하고 넘어가자면, 앞서 기술한 대로 Azure의 모든 Resource는 Resource Group에 종속됩니다.

가상 컴퓨터(VM)은 네트워크 인터페이스와 저장소 계정에 종속되며, 네트워크 인터페이스는 서브넷에 종속되며, 서브넷은 가상 네트워크에 종속됩니다.

또한 네트워크 인터페이스와 네트워크 보안 그룹은 1:1 Mapping이 되며, 네트워크 인터페이스와 공용 IP 주소는 1:1 Mapping이 됩니다.

역시나 말로 설명하면 어려우니 그림으로 그려 보겠습니다.

리소스 그룹은 하나만 그렸습니다만, 여러 개가 되어도 상관 없으며, 앞서 언급 드린 대로 Resource Group간 Resource끼리 접근이 가능합니다. 물론 대 전제는 Region입니다. 일단 종속관계만 따지기 위해 위와 같이 그려봤습니다.

한가지 아쉬운 점은 Azure Portal의 Icon과 Microsoft에서 제공하는 Icon이 다르다는 점 입니다. 위 이미지는 다음 URL에서 다운받은 Icon 입니다.

https://www.microsoft.com/en-us/download/details.aspx?id=41937

 

일단, 컴퓨팅 생성만 가지고 보면, Azure는 역시 Windows의 아들(?) 같이 ID/PW를 제작자에게 물어봅니다. Azure를 만든 사람의 기준은 "컴퓨팅을 사용하는 사람이 컴퓨팅 리소스를 직접 관리해야 한다"라는 개념으로 접근한 것 같습니다. 따라서, VM 리소스 제작자 = VM 접근 가능자 이기 때문에 이 Role을 이원화 하지 못하고 VM 리소스 제작자가 VM 접근 가능자에게 PW를 전달하는 방식으로 제작이 가능합니다.

 

VM과 저장소의 성능에 대해서는 아래 URL을 참고해 주시기 바랍니다.

Azure VM : https://azure.microsoft.com/ko-kr/documentation/articles/virtual-machines-windows-sizes/

Azure Storage : https://azure.microsoft.com/ko-kr/documentation/articles/storage-scalability-targets/

 

각 서비스당 제한에 대해서도 다음 URL을 참고해 주시기 바랍니다.

https://azure.microsoft.com/ko-kr/documentation/articles/azure-subscription-service-limits/

Azure도 AWS와 마찬가지로 MarketPlace에 게시된 이미지로 제작이 가능하며, 직접 제작한 VHD 파일을 올려 VM생성도 가능합니다. Microsoft에서는 VM Migration Tool도 지원합니다만, 한가지 아쉬운 점은, 아직까진 VHDX를 지원하지 않는다는 점 입니다.

 

 

두 클라우드의 공통점은 라이브 마이그레이션이 되지 않습니다. 왜 안되느냐!? 개인적인 생각은 관리적 문제와 내부 리소스 모니터링에 소모되는 리소스가 관련 있을 것 같습니다만, 정확한 내용을 알고 싶으시면 운영자로 취직하시면 아실 수 있을 겁니다 :)

 

이번 블로깅에서는 가상 컴퓨터를 기준으로 구조와 명칭에 대한 이야기, 그리고 관계에 대해서 차이점을 비교해 봤습니다.

실제로 컴퓨팅 성능에 대한 비교자료를 궁금해 하실 것 같은데요. 그 내용은 공유하지 않겠습니다. 사실 Cloud에서는 VM의 성능보다는 "어떻게 서비스를 유기적으로 운영이 가능한가?"와 "가격 인하"가 주된 목표라고 생각하기 때문 입니다.

 

부족한 블로깅 이었지만, 많은 지적과 정정을 통해 더욱 발전하는 블로그가 될 수 있다고 생각합니다. 많은 분들의 피드백을 기다립니다!

감사합니다.

============================================

수정 1. Azure VM 생성하는 MarketPlace에 대한 내용 언급과 VM 올리기에 대한 내용 추가하였습니다.