Skip to main content

TransitGateway 구성하기

아래 내용은 Networking Immersion Day 워크샵을 실습하며 아키텍처를 그리고 실습한 과정입니다.

Beginner Topics​

TransitNetwork1

TransitNetwork2

TransitNetwork3

TransitNetwork4

TransitNetwork5

TransitNetwork6

TransitNetwork7

TransitNetwork8

  • VPC 피어링은 전이적 연결을 지원하지 않습니다.
  • Transit Gateway는 전이적 연결을 지원하며 허브 앤 스포크 모델을 구성할 수 있습니다.

Intermediate Workshop​

이번 세션은 버지니아 북부 또는 아일랜드에서 선택하시길 바랍니다. 다른 리전을 선택할 시에 AMI 이미지가 달라서 클라우드 포메이션 리소스 생성과정 중 에러가 발생할 수 있습니다.

템플릿 생성 후 아키텍처​

TransitNetwork9

TransitNetwork10

  • 전송 가상 게이트웨이의 라우팅 테이블에 따라 네트워크를 격리합니다. (연결)
  • NP1-tgw, NP2-tgw (테스트 VPC)
  • DCS1-tgw (공유 VPC)
  • P1-tgw (프로덕션 VPC)
  • DC1-tgw (온프레미스 및 데이터센터 VPC)
  • 그린 라우트 테이블 - DCS1-tgw, P1-tgw
  • 블루 라우팅 테이블 - P1-tgw
  • 레드 라우팅 테이블 - NP1-tgw, NP2-tgw

각 VPC마다 Transit Gateway Attachment가 생성되어 있고 각각 NP1Attach, NP2Attach, DCS1Attach, **P1Attach**가 있습니다. 데이터센터 VPC는 온프레미스를 가장하고 시뮬레이션되므로 VPC Attachment를 생성하지 않고 VPN Attachment를 생성하여 Transit Gateway와 연결합니다.

현실세계에서는 고가용성을 위해서 각각 물리적 게이트웨이에 VPN 연결을 두 개 생성하여 연결하지만 여기서는 게이트웨이 역할을 하는 EC2 인스턴스에 두 개의 VPN 연결을 생성합니다. 즉 4개의 VPN 터널이 생성되며 두 쌍의 VPN 터널은 모두 Active-Active로 가동됩니다.

본 워크샵에서는 Non-Prod는 테스트 환경에서의 배포이고 DCS는 온프레미스 데이터 센터와 다른 모든 VPC에서 모두 접근 가능한 공유 VPC이며 Production VPC는 프로덕션 VPC로 각각의 VPC들은 배포 환경으로 분리되어 격리되어야 합니다. 마찬가지로 이러한 환경 구성에서 테스트 환경의 VPC와 프로덕션 VPC는 서로 통신할 수 없어야 합니다.

이렇게 논리적으로 네트워크 격리가 가능하다는 점에서 여러 VPC를 워크샵 처럼 배포 환경이나 개발 부서 파트 또는 운영 부서 파트처럼 조직 단위로도 분리할 수도 있어 하이브리드 네트워킹에 최적화된 기능이 아닌가 싶습니다.

블루 라우팅 테이블​

TransitNetwork11

레드 라우팅 테이블​

TransitNetwork12

그린 라우팅 테이블​

TransitNetwork13

  • 그린 라우팅 테이블에 생성된 VPN 연결을 생성한 뒤 전파를 생성합니다. 레드 및 블루 라우팅 테이블에는 VPN 전파만을 생성합니다.
  • 사전 공유키를 다르게 입력할 경우 sh ip int br 명령 실행시 Protocol이 down되어 사용할 수 없게 됩니다.

TransitNetwork14

☝🏻 NP1 to NP2
  • NP1 VPC 내에서 EC2 인스턴스를 떠나는 패킷은 로컬 VPC 프라이빗 라우팅 테이블에 따라 TGW를 통해 라우팅됩니다. NP1 attachment는 Red Route Table과 연결되어 있으므로 이 곳에 패킷이 도착하고 이 Red Route Table에서 새로운 IP 조회가 발생하고 결과적으로 패킷이 NP2 attachment로 전달됩니다.

NP1 to DCS1

  • NP1 VPC 내의 EC2 인스턴스를 떠나는 패킷은 VPC의 로컬 프라이빗 라우팅 테이블에 따라 TGW를 통해 라우팅됩니다. NP1 첨부 파일이 Red Route Table과 연결되어 있으므로 패킷이 이 곳에 도착하고 Red Route Table에서 새로운 IP 조회가 발생하고 그 결과 패킷이 DCS 첨부 파일로 전달됩니다.

뒤에서 Route Analyzer를 통해 트래픽을 살펴보겠지만 NP1의 인스턴스에서 NP2의 인스턴스로 IGMP 패킷을 보낼 때 TGW의 라우팅 테이블인 레드 라우팅 테이블을 경로로 하여 IP 조회를 한 후 패킷이 NP2 Attachment로 전송되지만 응답 시 동일한 경로로 전송되지 않습니다.

프로덕션 VPC와 테스트 VPC 격리​

  • 여기 파트까지 진행하셨다면 테스트 VPC에 있는 인스턴스와 프로덕션 VPC에 있는 인스턴스와의 통신이 가능하다는 것을 알 수 있습니다. 하지만 두 VPC는 격리되어야 하는 게 맞습니다. 두 VPC를 격리하기 위해서 각 VPC가 속한 전송 가상 게이트웨이의 라우팅 테이블에 통신되지 않아야 하는 상대 인스턴스 IP를 포함하는 CIDR를 블랙홀로 설정합니다.

Blue Route Table​

TransitNetwork15

  • 테스트 VPC에서 구동중인 EC로 트래픽이 전달되는 것을 방지하기 위해서 Non-Prod EC2 CIDR 대역을 블루 라우팅 테이블에 블랙홀로 생성합니다. 이로써 프로덕션 환경에서 테스트 환경으로의 트래픽이 차단됩니다.

Red Route Table​

TransitNetwork16

  • 프로덕션 VPC에서 구동중인 EC2로 트래픽이 전달되는 것을 방지하기 위해서 Prod EC2 CIDR 대역을 레드 라우팅 테이블에 블랙홀로 생성합니다. 이로써 테스트 환경에서 프로덕션 환경으로의 트래픽이 차단됩니다.

Route Analyzer​

TGW 라우팅 테이블 확인​

TransitNetwork17

(프로덕션 → Blue → 데이터센터 → Green → 프로덕션)​

TransitNetwork18

(테스트 → Red → 공유 → Green → 테스트)​

TransitNetwork19

(테스트 → Red → 데이터센터 → Green → 테스트)​

TransitNetwork20

Gateway Load Balancer​

템플릿 생성 후 Architecture​

TransitNetwork21

GWLB 생성​

TransitNetwork22

라우팅 테이블 수정 및 엔드포인트 연결​

TransitNetwork23

  • 엔드포인트 서비스 생성
  • 엔드포인트 생성
  • 엔드포인트 서브넷 라우팅 수정
  • 엣지 연결 생성

Gwlblab-VPC1 라우팅 GWLB 엔드포인트 생성 및 라우팅 테이블 경로 수정​

TransitNetwork24

TransitNetwork25

Gwlblab-VPC1 → Gwlblab-VPC2 트래픽 흐름​

TransitNetwork26

TransitNetwork27

Transit Gateway Multicast​

👨🏻‍💻 가상 게이트웨이 정적 경로 구성​

워크샵에서는 멀티캐스트 도메인과 연결생성에서 **VPC A - AZ1**과 VPC A - AZ2 서브넷과의 연결만을 설정하였는데 VPC B - AZ2 서브넷에 위치한 Multicast Member2 인스턴스를 멀티캐스트 멤버로 추가하기 위해서는 VPC B - AZ2 서브넷 또한 추가해줘야 합니다.

  • 멀티캐스트시에 Transit Gateway가 라우터 역할을 합니다.
  • 멀티캐스트 소스 - Multicast Source
  • 멀티캐스트 멤버 - Multicast-Member-1
  • 멀티캐스트 멤버 - Multicast-Member-2

ImmersionDay-NetworkBase Architecture​

TransitNetwork28

ImmersionDay-Multicast-Lab1 Architecture​

TransitNetwork29

TGW Attachment 생성 및 연결​

TransitNetwork30

멀티캐스트 그룹 소스 EC2 → 멀티캐스트 그룹 멤버 EC2 트래픽 전달​

TransitNetwork31

멀티캐스트 ECMP 테스트 영상​

👨🏻‍💻 동적 연결 생성 결과 아래 멤버 IP가 자동으로 생성됩니다. (그룹 - 멤버)​

멀티 캐스트 그룹에 두 멤버가 모두 조인시​

  • 224.0.0.1
  • 224.0.0.1
  • 239.0.0.100
  • 239.0.0.100

멀티 캐스트 그룹에 한 멤버가 LEAVE시​

  • 224.0.0.1

  • 239.0.0.100

  • 멀티캐스트 동적 도메인에서 동적으로 멤버의 JOIN 및 LEAVE를 관찰할 수 있다.

  • Transit Gateway는 자동으로 224.0.0.1(모든 시스템) 멀티캐스트 그룹에 가입하고 멀티캐스트 그룹 구성원을 추적할 수 있도록 구성원 쿼리 패킷을 모든 IGMP 구성원에게 보냅니다.

Static Connection(정적 도메인 연결) vs Dynamic Connection(동적 도메인 연결)​

  • mcast_app 명령을 중지하고 sudo tcpdump -i eth0 -n port 8123을 실행하니 정적 경로에서 설정했던 것과는 다르게 동적 경로에서는 아무 내용도 찍히지 않는다. 전송 게이트웨이 도메인의 그룹을 보니 해당 인스턴스가 멤버에서 삭제되어 있는 것을 확인할 수 있다.
  • 동적 도메인에서 멀티캐스트 트래픽은 JOIN 메시지가 수신될 때만 구성원에게 전송되며 LEAVE 메시지가 수신되면 구성원은 도메인에서 자동으로 제거되고 멀티캐스트 트래픽이 더 이상 전송되지 않습니다.

CloudWatch Log를 통한 유니캐스트 vs 멀티캐스트 부하 비교​

유니캐스트​

유니캐스트는 클라이언트와 서버 간의 일대일 연결입니다. Unicast는 세션 기반 프로토콜인 TCP(Transmission Control Protocol) 및 UDP(User Datagram Protocol)와 같은 IP 전달 방식을 사용합니다. Windows Media Player 클라이언트가 유니캐스트를 사용하여 Windows Media 서버에 연결할 때 해당 클라이언트는 서버와 직접적인 관계를 갖습니다. 서버에 연결하는 각 유니캐스트 클라이언트는 추가 대역폭을 차지합니다. 예를 들어 10개의 클라이언트가 모두 100Kbps(초당 킬로비트) 스트림을 재생하는 경우 해당 클라이언트는 그룹으로 1,000Kbps를 사용합니다. 100Kbps 스트림을 재생하는 클라이언트가 하나만 있는 경우 100Kbps만 사용됩니다.

멀티캐스트​

멀티캐스트 소스는 멀티캐스트 지원 라우터에 의존하여 클라이언트가 수신 대기하는 모든 클라이언트 서브넷으로 패킷을 전달합니다. 클라이언트와 Windows Media 서버 사이에는 직접적인 관계가 없습니다. Windows Media 서버는 멀티캐스트 스테이션이 처음 생성될 때 .nsc(NetShow 채널) 파일을 생성합니다. 일반적으로 .nsc 파일은 웹 서버에서 클라이언트로 전달됩니다. 이 파일에는 Windows Media Player가 멀티캐스트를 수신하는 데 필요한 정보가 포함되어 있습니다. 이것은 라디오에서 방송국을 튜닝하는 것과 유사합니다. 멀티캐스트를 수신하는 각 클라이언트는 서버에 추가 오버헤드를 추가하지 않습니다. 실제로 서버는 멀티캐스트 스테이션당 하나의 스트림만 보냅니다. 하나의 클라이언트만 수신하든 1,000개의 클라이언트만 수신 중이든 서버에서 동일한 로드가 발생합니다. 모든 라우터가 멀티캐스트를 지원하는 기업 환경의 멀티캐스트는 대역폭을 상당히 절약할 수 있습니다.