#4 Network Part_1 Overview

도입

안녕하세요. 빅두 입니다.

6월엔 블로깅이 한 건도 없다는 것에 충격을 받아 7월엔 좀 더 많은 내용을 공유해 보고자 다짐을 해 봤습니다.

오늘 비교해볼 항목은 Network에 대한 부분입니다.

다들 생각보다 만만치 많은 Network를 보고 많이들 당황하셨을 것 같은데요. 그래도 Network 엔지니어가 없이 구성할 수 있는 환경이라는 것에 감사할 따름입니다. (아키텍쳐 설계시엔 네트워크 엔지니어가 필요합니다.)

 

사실 네트워크의 내용이 매우 장황하기 때문에 언급하기를 꺼려했었습니다만, 제 나름대로 열심히 풀어보도록 하겠습니다.

이번 Network에 대해서는 총 4개의 주제로 나누어서 이야기 해 보겠습니다.

 

#4 Network Part_1 Overview

#5 Network Part_2 Traffic Flow&Security

#6 Network Part_3 VPN&Peering

#7 Network Part_4 Tag&Cost&Trubleshooting

 

 

Azure

오늘은 Azure부터 이야기 해 보도록 하겠습니다.

Azure에서의 Network를 이야기 하려면 가장 먼저 확인하는 것이 바로 Virtual Network입니다.

그대로 직역하면 가상 네트워크 인데요. 당연한 것 아니냐? 라고 말씀하시는 분들이 계실 것입니다만, Azure의 서비스 이름 자체가 Virtual Network(VNet)으로 되어 있습니다.

 

다음 그림은 Azure 설명서에서 제공하는 Azure Network의 기본적인 그림 입니다.

 

 

그림을 보시면 아시겠지만, Azure Infra 안에 Virtual Network라는 하나의 Network를 생성한 후 그 안에서 정책과 연결을 구현하는 모습을 보실 수 있습니다.

Azure를 공부하면서 가장 놀라운 사실은 바로 Resource의 Object화로 종속성을 최대한 배제한 아키텍처라는 것입니다.

종속관계가 없이 무언가를 제작할 수는 없습니다만, 최대한 종속성을 피해 제작한 것이 가장 큰 메리트라고 생각합니다.

 

가장 처음으로 VNet의 속성들을 살펴 보도록 하겠습니다.

 

 

여러가지 내용이 있습니다만, 저에게 가장 처음 눈에 띈 것은 바로 Address space 입니다. 기본적으로 Network를 만들었다면 가장 먼저 확인할 내용은 CIDR값이라고 생각합니다. 위 화면에서 보시는 바와 같이 Subnet이 별도로 존재하는 것으로 보아 Compute Resource와 연관된 Resource들은 Subnet과 Mapping이 될 것이라는 것은 추측할 수 있습니다.

그렇다면 Address space는 무엇인가? 여기저기 찾아봤습니다만, 개인적으로 정의를 내리자면 하나의 VNet에서 할당 가능한 IP의 범위 라고 생각합니다.

 

여기서 주목해야 할 부분은 바로 Address space가 수정이 가능하다는 점 입니다. 이 말은 최초 VNet 제작시에 지정한 CIDR값에 변경이 필요하다면, 언제든 변경이 가능하다는 것을 의미합니다. 물론 이 CIDR값을 변경하는 것에는 매우 큰 문제가 발생할 수 있습니다.(VPN을 연결한 경우 Secure Channel이 끊길 수 있습니다.)

기본적으로 최초 네트워크 디자인을 했을 때 보다 더 큰 네트워크(CIDR)가 필요하게 됐을 때, AWS의 경우 새로운 VPC(VNet과 같은 개념)를 만들어 Blue-Green 방식으로 Service Migration을 하는 방법을 고려합니다. 왜냐하면 한번 정의한 Address space(CIDR)값을 수정할 수 없기 때문입니다.

Azure같은 경우 VNet에서는 서비스 마이그레이션을 전혀 고려할 것 없이 Address space(CIDR)를 수정하면 됩니다. (다른 Cloud는 잘 모르겠네요.)

VNet에 IP Address Range를 추가할 수도 있습니다만, 개인적으로는 하나의 VNet에는 하나의 Range(CIDR)만 설정하는 것이 좋다고 생각합니다. 어짜피 논리적으로 구성된 VNet이라면 굳이 여러 개의 Range를 하나의 VNet에 할당할 필요는 없으며, VPN 등 Source CIDR값이 필요한 무언가를 사용할 때를 대비하는 것이 좋다고 생각합니다.

 

  

참고로 CIDR은 /15를 초과한 값(/0~/14)을 입력하면 에러가 나더라고요. /15가 무슨 말인지 모르시는 분들은 후니의 Cisco 네트워킹 책을 읽으시길 바랍니다 :) (netmask를 나타내는 표기법 입니다.)

 

이쯤에서 Powershell 명령을 사용하여 VNet 을 확인해 보겠습니다.

 

PS> Get-AzureRmVirtualNetwork

 

 

출력된 AddressSpace 항목을 보시면 JSON형태의 배열이 출력되는 것을 보실 수 있습니다. 이 내용만 봐도 AddressSpace에는 여러 개의 Range를 할당할 수 있는 것을 알 수 있네요.

 

다음으로 확인할 것은 Subnet입니다.

 

<저도 가로로 긴 모니터가 필요한 것 같아요… 듀얼 스크린이라 가능했던 스크린 샷>

 

Subnet은 Private Network IP가 필요한 모든 Resource들에게 IP를 할당할 수 있는 IP_Prefix를 구현합니다. 간단하게 Virtual Machine(VM)의 Network Interface에 Private IP를 할당 받으려면 Subnet이 필요하다고 말할 수 있겠습니다.

이 Subnet은 VNet에 종속되며, VNet과 달리 Address range는 수정할 수 없습니다.

VNet의 Address range 내에서 Subnet을 계속해서 생성할 수 있으며, VNet의 Address range의 범위에 벗어난 Subnet을 제작하려고 시도하면 생성이 되지 않고 경고가 발생합니다.

위의 cmdlet 결과를 보시면 Subnets의 내용에 배열로 출력되는 것을 보면, 마찬가지로 여러 개의 Subnet을 제작할 수 있다는 것으로 확인하실 수 있습니다.

Cmdlet에서 아래 명령어를 확인해 보니 VNet과 Subnet간 종속성을 확인할 수 있었습니다.

 

PS> Get-Help Get-AzureRmVirtualNetworkSubnetConfig

 

 

보시는 바와 같이 명령어의 필수 매개변수로 VNet을 입력하도록 되어있습니다.

 

Subnets 메뉴에 보면 Gateway subnet 이라는 항목이 있습니다만, 이 내용은 #6 Network Part_3 VPN&Peering

에서 이야기 하도록 하겠습니다.

 

다음으로 눈에 띄는 것은 DNS servers 라는 메뉴입니다.

기본 설정은 아래 화면을 보시는 바와 같이 Azure DNS를 사용하도록 되어있습니다.

 

 

이 녀석은 뭘까? 하고 생각하다가 해당 VNet으로 배포된 컴퓨터들은 DHCP를 사용한다는 것이 떠올랐습니다. 기본적으로 VM이 실행될 때 Network가 연결되어야 하기 때문에 DHCP Server에서 IP를 받아옵니다. 그 때에 DNS정보를 받아올 수 있는 옵션으로 사용 되는 것을 추측할 수 있습니다.

 

여기까지 추측이니까 진짜 그렇게 되는지 확인해 보도록 하겠습니다.

 

Custom DNS를 선택 후 Google DNS인 8.8.8.8을 입력하였습니다. 그리고 상단의 Save를 누르니 VNet 정보에 DNS Servers가 Azure Provided DNS service에서 8.8.8.8로 변경된 것을 보실 수 있습니다.

 

 

그런 다음 VM에 접속하여 DNS 정보를 확인해 보았습니다. 좌측은 수정 전, 우측은 수정 후 ipconfig /all 결과값 입니다.

 

 

Azure Console에서 수정한 DNS값이 반영되는 순간을 찾기 위해 이것 저것 확인해 보니 VNet에서 DNS를 가져오는 순간은 NIC가 DHCP에서 IP를 받아올 때 입니다. 제가 테스트한 바로는 DNS server 수정 후 제작, 재부팅, 종료/시작 3가지 경우에서 DNS값이 변경되는 것을 확인하였습니다.

 

VNet 메뉴에서 하단을 보면 devices라는 메뉴도 눈에 들어옵니다.

이 메뉴는 현재 VNet에 연결되어 있는 모든 Resource와 할당된 IP Address를 볼 수 있다는 점이 매력적입니다. 다른 Cloud에서도 이런 기능이 있었다면, 관리자가 broadcast를 이용해서 사용중인 IP를 찾는다는 생각은 안 할 것 같습니다.

 

 

속성 부분도 빠뜨릴 수 없을 것 같습니다. 뭐니뭐니해도 객체를 볼 땐 속성 메뉴를 잘 알아야 한다고 생각합니다. :)

 

 

생각보다 속성 메뉴에는 별게 없네요…?? 라고 생각했는데 눈에 띄는 레이블이 보입니다.

Change subscription이라고 되어있군요. 한번 눌러봅시다.

 

 

아니!? Resource to move라니!? Network를 이동할 수 있단 말인가? 아니 그 하위 리소스들 마저 다른 지역으로 이동이 가능하다는 것인가!? 이것은 정말 해봐야 할 것 같습니다. 그래서 제가 한번 해보겠습니다.

현재 일본 동부에 있으니 서부로 이동을 한번 해 보죠.

 

 

이동하려고 하니 뭔가 문구가 있네요. 자원이 이동하게 되면 Resource IDs가 바뀐다는군요. 뭐 저는 전~혀 상관이 없으니 쿨하게 이동해 보겠습니다.

 

 

시작해 보았습니다 :)

Validating이 끝나고 Success가 떨어지면 이동이 시작됩니다.

 

 

Dashboard에서 기존의 Resource들이 삭제된 것을 볼 수 있습니다.

 

 

이동이 완료되었습니다.

Resource들을 한번 볼까요?

 

Resource Group이 이동한 모습을 보실 수 있습니다.

여기서 한가지 중요한 것은 Location은 이동하지 않았다는 것입니다. 즉, 같은 지역에서 Resource Group만 이동을 한 그림이며, 다른 지역으로 이동을 하지 못한다는 이야기가 됩니다. 이것을 다르게 말하면 제작된 Resource는 Region에 종속된다고 볼 수 있겠네요.

 

소개 드린 내용 이외에도 여러가지 기능들이 있습니다만, AWS와 비교했을 때 Overview에서는 이 정도 차이점이 존재하는 것 같습니다.

 

 

AWS

이번엔 AWS의 네트워크에 대해 살펴보도록 하겠습니다.

 

AWS도 Azure와 마찬가지로 Virtual Private Cloud(VPC)라는 커다란 Virtual Network 안에서 Compute Resource가 할당되는 그림 입니다.

 

지난번 #1 고 가용성의 기준 Region에서 언급했었습니다만, AWS는 하나의 Region에서 2개 이상의 Availability Zone(AZ)가 존재한다고 말씀 드렸었습니다. 이 개념을 이해하셔야 VPC와 Subnet을 설명할 수 있기 때문에, 해당 내용이 잘 이해가 안 되신다면, #1 고 가용성의 기준 Region 또는 http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-regions-availability-zones.html 을 참고하시기 바랍니다.

 

다시 본론으로 돌아와서 AWS의 Network는 VPC라는 커다란 Virtual Network로 시작합니다. VPC는 Region에 종속된 Resource 이며, 이 VPC는 하나의 사설 네트워크를 만든다고 생각하시면 쉽게 이해하실 수 있습니다.

 

 

AWS Console에서의 VPC의 화면을 보면 Network에 대한 모든 설정이 모여있다는 느낌이 드실 겁니다. 근데, 그게 사실입니다. AWS는 Azure와 달리 Resource 기반의 메뉴가 아닌 Service 기반의 메뉴가 보여집니다. 즉, AWS에서 Network에 대한 설정은 VPC 메뉴에서 전부 가능합니다. EC2 메뉴에도 있는 기능들이 몇몇 있습니다만, 어찌됐든 AWS는 Service를 기준으로 UI가 개발되었다는 점을 기억해 주시면 되겠습니다.

 

VPC는 심플합니다. VPC ID는 AWS에서 할당해 주며, Name Tag를 달아줌으로써 Name 속성 값이 들어갑니다. 여기서 중요한 점은 VPC를 만들 때 지정한 CIDR값은 Azure와 다르게 수정이 불가능합니다. 어디에서도 수정할 수 있는 메뉴를 찾아보실 수 없으며, 물론 CLI에서도 찾으실 수 없습니다.

 

 

Azure에서 VNet의 Address space를 이야기할 때 언급 했었습니다만, AWS의 경우 최초 디자인한 VPC가 증설이 필요할 때에는 두 가지 시나리오를 생각할 수 있습니다.

첫째로 VPC에 존재하는 모든 리소스를 다른 VPC로 마이그레이션 하는 것입니다. CIDR값이 수정되지 않기 때문에 증설하려면 어쩔 수 없는 선택지 입니다.

둘째로 별도의 VPC를 제작해 VPC간 연결을 하여 하나의 Network처럼 만들어 줍니다. 이 방법은 그리 추천하지 않습니다. 설정은 쉽기 때문에 서비스에 영향은 전혀 없습니다만, VPC간 Peering은 Traffic Forwarding이 되지 않기 때문입니다. 자세한 내용은 #5 Network Part_2 Traffic Flow&Security때 다루도록 하겠습니다.

 

 

AWS Console에서 VPC를 만들어 보시면 아시겠지만, AWS Console 자체에서는 하나의 Region에서만 모든 서비스 조작이 가능하게 설계되어 있고, VPC를 제작할 때도 Region을 선택하지 않습니다. 그 얘기는 AWS Console 자체에서 Region을 선택했다는 의미가 되며 이를 AWS에서는 Default Region을 지정했다고 합니다.

 

위 내용을 종합해 본다면, 앞서 언급드린 대로 VPC는 Region에 종속되는 Resource라고 할 수 있겠습니다.

 

Tenancy 옵션은 대부분의 사용자들이 Default로 사용을 하셔야 합니다. 해당 옵션은 Dedicated Host를 할당 받으신 고객분들 께서 특정 Host에 EC2 Instance(VM)을 생성하기 위해 제공되는 옵션이기 때문입니다. 적어도 저는 쓸 일이 없겠네요.

 

여러가지 설정들을 보시면 Network ACL이라는 것도 확인하실 수 있으시며, Route table옵션도 보이실 건데요. 이 부분들 역시 #5 Network Part_2 Traffic Flow&Security때 다루도록 하겠습니다.

 

이쯤에서 Powershell을 통한 VPC정보를 확인해 보도록 하겠습니다.

 

PS> Get-EC2Vpc

 

 

보시는 바와 같이 VPC에는 매우 심플한 데이터들만 설정이 되어 있습니다.

 

좀 흥미로운 메뉴가 있는데요. 바로 DHCP options set이라는 부분과 DNS resolution, DNS hostnames 라는 옵션입니다. 이 부분들에 DNS 설정에 대한 부분이 존재합니다.

 

먼저 DHCP Option Sets 메뉴로 이동해 보겠습니다.

 

 

DHCP option은 엄청 간단합니다. Azure에서 설명 드렸던 DNS 설정에 대한 부분을 설정하는 단계라고 생각하시면 되겠습니다. 하지만, DHCP option set을 제작해 보면 조금 다른 내용이 보입니다.

 

 

바로 NetBIOS name servers와 node type이라는 옵션입니다. 솔직히 저 옵션을 쓰시는 분이 계실까? 라는 생각도 들긴 합니다만, 저런 옵션이 있다는 것만 아시면 될 것 같습니다. 재밌는 부분은 NTP Servers도 설정할 수 있다는 점 입니다.

 

해당 DHCP option set을 적용 받으시려면 Azure때와 같이 Compute Resource가 DHCP에서 설정 값을 받아올 때 적용 됩니다. 솔직히 이 내용은 VM의 OS에서 담당하는 영역이어서 어떠한 Cloud Service라도 동일할 것이라 생각합니다.

 

DNS resolution과 DNS hostnames은 EC2 Instance에 Public DNS를 보이게 하려면 해당 설정들이 Yes로 설정되어 있어야 합니다.

 

VPC를 생성했으니 이번엔 Subnet으로 넘어가 보도록 하겠습니다.

 

 

Subnet은 제작할 시 두 가지를 고려하여 설계해야 합니다.

첫째로 CIDR을 고려해야 합니다. 이건 Azure와 마찬가지 인데요. 한번 지정한 CIDR값은 수정할 수 없습니다.

둘째로 Availability Zone(AZ)을 고려해야 합니다. Subnet은 AZ에 종속되는 Resource이기 때문에, 한번 AZ를 지정하게 되면 수정할 수 없습니다. AWS에서 AZ를 지정한다는 것은 HA를 구성하기 위한 최소 단위라고 생각하시면 쉽습니다.

 

Subnet 생성 화면을 보시면 이해가 더 쉬우실 것입니다.

 

 

Subnet 생성 시 AZ옵션을 Default인 No Preference로 설정하시면 랜덤하게 AZ를 지정하여 출력해 줍니다. 이때 랜덤은 진짜 랜덤입니다. Round Robin 형식이 아니라는 의미 입니다.

 

 

AWS에서는 Subnet 별로 Network ACL과 Route Table을 설정할 수 있습니다. 생성시 기본값으로 설정되며, 이 값들은 VPC라는 이름에 걸맞게 Private 접근만 가능하도록 설계되어있습니다. 자세한 내용은 역시나 #5 Network Part_2 Traffic Flow&Security때 다루도록 하겠습니다. AWS에서는 Route Table과 Network ACL을 중요시 여기기 때문에 계속해서 같은 말이 반복됩니다만, 컨셉이 다른 두 서비스를 비교하다 보니 이런 상황이 발생하는 것 같습니다.

 

AWS의 Subnet 역시 VPC의 CIDR값 내에서 쪼개어 사용할 수 있으며, Azure와 다르게 현재 사용하고 있는 IP 리스트는 확인이 어렵습니다. 다만, 해당 Subnet에서 사용 가능한 IP의 개수는 Available IPs라는 속성으로 보여줍니다.

 

AWS는 Public IP를 동적으로 할당을 할 시 EC2 Instance(VM)을 만드는 과정에서 지정하도록 되어있습니다. 이 설정은 제작 후에 수정을 할 수 없으며, 동적 Public IP를 할당할 수 있는 유일한 방법입니다. 그러나, 사용자가 EC2 Instance(VM)를 만들 때 마다 해당 옵션을 설정해야 하기 때문에 실수가 많이 일어났던 것 같습니다. 그래서 AWS에서는 Subnet에 옵션을 주어 자동을 동작 Public IP를 설정하도록 하는 Subnet을 제공합니다. 그 옵션은 Auto-assign Public IP입니다. 기본값은 no로 설정되어 있습니다.

 

Subnet을 Powershell로 확인해 보면 다음과 같습니다.

 

PS> Get-EC2Subnet

 

 

위의 Subnet 속성값과 별반 다를 것이 없기 때문에 설명은 넘어가도록 하겠습니다.

 

 

맺음말

여기까지 우선해서 Network를 비교해 보았습니다.

개인적인 생각으로는 Azure가 Enterprise Network를 설정을 하기에는 더 좋다고 생각합니다. 아무래도 AWS의 Network는 한번 구성하면 변경이 어렵다는 점과 함께 Resource를 각 Region에서 하나씩 확인해야 한다는 점이 아쉬운 부분이라 생각합니다.

하지만, 서비스 입장에서 조작을 할 수 있게 만든 AWS의 경우에는 접근성에서는 Azure보다 좋다고 생각합니다. Network의 모든 설정이 한 눈에 들어오기 때문에 개인적으로는 사용자가 실수할 일도 적다고 생각 합니다.

 

글을 쓰는데 3일이라는 시간이 소요됐습니다만, 다음 주제도 중요한 내용이기에 최대한 시간을 내서 써보도록 하겠습니다. 다음엔 #5 Network Part_2 Traffic Flow&Security 라는 제목으로 블로깅 하도록 하겠습니다.

 

감사합니다.

 

#4 Network Part_1 Overview

#5 Network Part_2 Traffic Flow&Security

#6 Network Part_3 VPN&Peering

#7 Network Part_4 Tag&Cost&Trubleshooting

 

참고자료 :

https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-overview/

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html/