Azure 클라우드에서의 네트워킹
하이브리드 네트워킹을 어떻게 정의해야 할 것인가. '가상네트워크로의 연결'이라는 맥락에서 정의한다면 이는 ExpressRoute의 프라이빗 피어링이나 VPN 연결과 같이 프레미스 자원과 하나 이상의 가상네트워크(VNet)들의 연결이라 할 수 있다. 이 모든 것들은 잘 작동하고 있으며 우리는 이것들을 어떻게 사용하는지 잘 알고 있지만, 이것들은 클라우드 안에서 대체 어떻게 움직이는 것일까. 여기에는 Azure에 내장된 세 가지 이상의 방식이 작동한다. 이 포스팅을 통해 그것들을 간략하게나마 설명하고자 한다.
- 하이브리드 네트워킹 연결 옵션
- 클라우드 내부 연결 옵션
- 옵션 종합
하이브리드 네트워킹 연결 옵션
기본적으로 4 가지 옵션이 있다.
- 인터넷 연결
- 점 대 사이트 연결 VPN (Point-to-site VPN)
- 사이트 간 연결 VPN (Site-to-Site VPN)
- ExpressRoute
인터넷 연결
이름 그대로, 인터넷 연결은 가상 네트워크 내부에 위치한 다른 퍼블릭 엔트포인트를 노출시킴으로써 여러분의 워크로드를 인터넷을 통해 접근가능하도록 해 준다. 이를 위해 인터넷에 연결되어있는 부하분산장치를 이용하거나 아니면 단순하게 VM NIC의 ipconfig 오브젝트에 퍼블릭 IP를 할당함으로써 목적을 달성할 수 있다. 이를통해 인터넷상의 모든 것이 해당 가상 컴퓨터에 도달 가능해지며 호스트의 방화벽, 네트워크 보안 그룹(NSG) 및 사용자 정의 경로를 통해 해당 가상 컴퓨터에 연결할 수 있다. 결론적으로 이 옵션을 이용해 인터넷을 통한 애플리케이션 공개가 가능하다.
점 대 사이트 연결 VPN 혹은 사이트 간 연결 VPN
이 둘은 같은 범주에 속한다. VNet의 VPN 게이트웨이로 워크스테이션에서 직접 VPN 클라이언트를 이용해 점 대 사이트로 연결하거나 온프레미스 VPN 디바이스의 Site-to-Site VPN 종말장치 기능을 이용해 연결하며, 이를통해 온프레미스 장치들이 VNet 내부의 자원들로 접근 가능해진다. 아래에서 클라우드 내부에서의 연결에 대해 다시 다룰 것이다.
ExpressRoute
이 연결은 ExressRoute 기술 개요에 자세히 설명되어 있다. 사이트 간 VPN 옵션과 마찬가지로 ExpressRoute을 사용하면 하나 이상의 VNet에 퍼져 있을 수 있는 리소스에도 연결할 수 있다. SKU에 따라 하나 이상 열 개 이하의 VNet 연결을 허용하며 프리미엄 애드온 이용시 대역폭에 따라 최대 100개 까지 연결 가능하다. 이 내용 또한 아래의 클라우드 내부 연결 옵션에 다시 설명하겠다.
VNet의 개념을 설명한 문서에 따르면, 이는 '사용자의 니즈에 맞게 Azure 내에 만들어진 고립된 네트워크'로 요약할 수 있다. 예를 들어, 가상 머신을 온 프레미스에서 Azure로 이동하기 시작한다면 이 작업이 필요할 것이다. 당신이 IP 주소 공간을 선택하므로 클라우드로 이전하기 전에 IP 주소 할당을 계획하는 것이 중요하다. Azure로 당신 회사의 데이터센터를 확장한다면 당신은 IP CIDR 블록 혹은 클래스리스 도메인 간 라우팅 등에 대해서 고려해야 할 것이다.
이제 VNet이 무엇인지 조금 더 이해했다. 그럼 왜 여러개의 VNets이 도움이 되는 것일까? 기업은 서로 분리해두어야 할 필요가 있는 여러 비즈니스 라인을 보유하고 있는 경우가 있기 때문이다. 이것은 다른 비즈니스 단위로 인보이스를 발행하거나 서로 다른 가상 네트워크 및 관련 요소들 (네트워크 보안 그룹, 사용자정의 경로 등)을 각각 관리해야 하는 이슈 등이 관련되어 있다.
클라우드 내부 연결 옵션
비즈니스 라인들 간의 데이터 교환 혹은 가상 네트워크 간 IP 연결 시에 Azure는 3 가지 네이티브 옵션을 제공한다.
- VPN을 통한 VNet to VNet (VNet-to-VNet 연결)
- ExpressRoute를 통한 VNet to VNet
- VNet 피어링과 VNet 전달을 통한 VNet to VNet
위 방법들이 갖는 기능과 효과를 비교해 보자.
VPN을 통한 VNet-to-VNet
VPN을 통해 2 개의 VNets가 서로 연결되어 있는 경우 두 가상 네트워크의 라우팅 테이블은 다음 그림과 같다.
2 개의 VNet 만으로도 흥미롭지만, 좀 더 스케일을 키워보자.
VNet4와 VNet5의 라우트 테이블은 VNet3에 도달하는 경로를 나타낸다. 하지만 VNet4는 VNet5에 접근할 수 없는데, 이를 해결할 두 가지 방법이 있다.
- Full Mesh VNet-to-VNet
- BGP enabled VPN 사용
이 두 가지 방법을 사용하면 3 개의 VNet 모두가 서로에게 접근할 수 있다. 당연히 이는 더 많은 수의 VNet을 구성하는 경우에도 확장가능하다.
ExpressRoute를 통한 VNet-to-VNet
하나 이상의 VNet을 동일한 ExpressRoute 서킷에 연결할 때 재미있는 부작용을 초래한다. 예를 들어 동일한 ExpressRoute 서킷에 연결된 2 개의 VNets가 있는 경우의 라우팅 테이블은 다음과 같다.
흥미롭게도 두 VNets는 MSEE (Microsoft Enterprise Edge) 라우터를 벗어나지 않고 서로 통신할 수 있는데, 이는 서로간의 통신을 위해 Microsoft 백본을 떠날 필요가 없다는 것을 의미한다. 이것이 왜 중요한가. 이는 VNets간 통신시 추가적인 요금부과가 없도록 해 준다. 요컨대, ExpressRoute Premium 서킷을 사용할 경우 동일한 지역 또는 글로벌 범위에서 VNets간에 통신하는 것이 가능하다. 즉, 전세계의 Microsoft 백본을 사용하여 여러 VNets를 함께 연결할 수 있으며, 이렇게 동일한 ExpressRoute 서킷에 연결된 VNet-to-VNet 트래픽은 요금이 부과되지 않는다. 아래 그림은 동일한 ExpressRoute 서킷에 연결된 3개의 VNet을 보여준다.
위의 그림에서 각 VNet의 서브넷의 Effective Route Table에 나타나는 여러 경로를 볼 수 있다.
가상 네트워크 피어링을 이용한 VNet-to-VNet
복수 VNet 연결을 위한 마지막 선택지는 단일 Azure 리전 내에서 사용 가능한 가상 네트워크 피어링이다. 2 개의 VNet 간 피어링 배열은 두 VNet이 본질적으로 1 개의 큰 가상 네트워크 인 것처럼 작동하지만 NSG 및 라우트 테이블을 사용하여 통신을 제어 할 수 있다.
이를 허브와 스포크 형태의 토폴로지로 표현하면 다음과 같다.
피어링은 VNet을 넘어 전파되지 않으므로 HR VNet은 Marketing VNet과 직접 대화 할 수 없지만 HR, 마케팅 및 엔지니어링의 세 VNet 모두 도메인 컨트롤러, 모니터링 시스템, 방화벽 또는 기타 Network Virtual Appliance (NVA) 등과 같은 공유 리소스를 포함하는 허브 VNet과 대화 할 수 있다.
그러나 VPN의 경우와 같이 VNet이 서로 통신 할 수 있어야 한다면 다음과 같은 토폴로지를 참고할 수 있다. 명확한 이해를 위해 완전히 메쉬되지 않은 형태의 토폴로지를 준비했다. (이 경우 HR VNet은 Engineering VNet과 직접 대화 할 수 없다). 이것으로부터 아이디어를 얻을 수 있을 것이다.
VNet 피어링을 사용할 때 공유 가능할 수 있는 중요한 리소스 중 하나는 게이트웨이(VPN 및 ExpressRoute 모두)이다.
이 방식을 이용해 각각의 스포크 VNet에 ExpressRoute 또는 VPN 게이트웨이를 배포하지 않고도 허브 VNet으로 보안 스탬프 및 게이트웨이 액세스를 중앙 집중화 할 수 있다.
옵션 종합 정리
이러한 여러 방법과 옵션들은 개별적으로 충분히 흥미롭지만 함께 결합되어 강력한 기능을 제공한다.
게이트웨이 공유를 이용한 VNet 전파
아래의 토폴로지는 간단한 허브 및 스포크 토폴로지를 보여준다. VNet 피어링 자체에서 전파가 불가능하더라도 게이트웨이(VPN 및 ExpressRoute)를 통해 중계 라우팅이 가능하다. VNet 피어링과 게이트웨이 공유를 사용하며 Express Route를 사용하는 예는 다음과 같다.
게이트웨이 공유를 이용한 VNet 전파, 2개 리전의 1개 ExpressRoute 서킷
하나 이상의 Azure 리전(VNet 피어링은 단일 리전에 만들어진다.)과 결합하기 위해서는 다음과 같은 토폴로지를 사용할 수 있다.
위의 이미지에서 서부 미국 및 동부 미국 내 모든 VNet은 SKU에 따라 1, 2, 혹은 10Gbps의 속도로 Microsoft 백본 네트워크 내에서 서로 통신한다. 미국 동부 리전을 향하는 패킷은 미국 서부 리전과 시카고 사이에서 물리적으로 라우팅 된다는 점을 주목하자. 이는 시카고가 두 리전 사이에 위치하기 때문이다.
게이트웨이 공유를 통한 VNet 전파, 2개 리전의 2개 ExpressRoute 서킷
시카고보다 ExpressRoute에 대한 연결이 필요한 곳인 경우 혹은 단일 ExpressRoute로는 탄력성이 부족할 경우 다음과 같은 토폴로지를 만들 수 있다.
프레미스들이 미국 서부 및 동부에 위치할 경우 프레미스 간 연결이 더 나은 지연 시간을 가질 수 있다. 또한, 동서부 각각에 위치한 VNet 간에 패킷이 전달될 수 있는 2 개의 ExpressRoute가 있다. 이러한 리전들은 서킷 위치와 가깝기 때문에 조금의 레이턴시가 추가되어도 큰 문제가 되지 않는다. 게다가 이러한 구조는 별개의 두 위치에서 별개의 두 ExpressRoute 회로를 사용하기 때문에 더 높은 가용성을 보장한다.
게이트웨이 공유를 통한 VNet 전파, 3개 리전의 3개 ExpressRoute 서킷
이 모델은 더 많은 서킷과 더 많은 리전으로 확장 될 수도 있으며 Azure Networking 툴박스를 사용하여 만들 수 있는 토폴로지에 대한 이해를 돕기에도 적절하다.
최적의 라우팅을 위해서는 로컬 서킷이 중요하다. 이에 대해 ExpressRoute 라우팅 최적화에 관련된 글을 참고하는 것이 좋다. 이 글에서는 미 서부에서 출발해 북유럽을 향하는 패킷이 도쿄의 ExpressRoute 서킷을 통과하지 않도록 설정하는 등 가상네트워크 최적의 라우팅 설정에 대해 서술하고 있다. 연결에 대해 가중치를 부여함으로써 이러한 목적달성이 가능하다.
BGP 활성화된 VPN 게이트웨이의 공유와 VPN 전파 라우팅을 통한 VNet 전파
아래의 토폴로지는 BGP 라우팅을 사용하는 VPN 전송의 또 다른 재미있는 사례를 보여준다. 자세한 내용은 Azure VPN 게이트웨이 BGP 개요에서 확인 가능하다.
이 그림에서는 프록시와 같은 매커니즘 없이 Azure의 백본을 효과적으로 사용함으로써 두 개의 시설을 연결하고 있는데, 미 서부 온프레미스 환경에 위치한 사용자가 VPN을 통해 북유럽 VNet에 연결된 VPN 사용자에 접근할 수 있도록 작동한다.
번역된 컨텐츠입니다.
Microsoft Azure. by Olivier Martin, Global Black Belt - Azure Networking. https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud/, https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud-part-2/, https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud-part-3/
Translated article.
Microsoft Azure. by Olivier Martin, Global Black Belt - Azure Networking. https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud/, https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud-part-2/, https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud-part
