이어서 Direct Connect(DX) 도 검증!
아키텍처와 공통설정은 앞선 "Site-to-Stie VPN" 과 동일함.

 


 

Scenario 2. Direct Connect(DX) 구현 (P2P 경로 최적화 검증)

 

# Scenario 2을 수행하기 전 check

Direct Connect 방식은 물리적 전용 회선 인입이 필요한 설계 구조이므로, 본 시나리오에서는 AWS 콘솔 절차를 숙지한 후 Tailscale 기반 성능 비교로 기술 검증만 수행함.

 

- 목적 : 인터넷 중계 서버(Relay)를 배제하고 온프레미스와 AWS 간 1:1 P2P(Direct) 경로를 수립하여, 물리적 전용선(Direct Connect) 수준의 고성능/저지연 통신 환경을 재현함.

 

- 검증 가설 : "의도적으로 UDP 통신을 제한한 Relay 모드와 최단 경로인 Direct 모드의 레이턴시(ms) 차이를 비교함으로써, DX가 하이브리드 아키텍처에서 제공하는 '직결성'과 '저지연'의 기술적 타당성을 입증할 수 있을 것이다."


- 검증 항목 :

  • Relay 환경: tailscale의 relay-only 설정을 통해 중계 서버(DERP)를 경유하는 통신의 지연 시간 측정.
  • Direct 환경: P2P 수립 후 중계 서버를 거치지 않는 최단 경로의 성능 수치 측정.
  • 성능 격차: 두 모드 간의 지연 시간 차이 및 패킷 안정성 비교.

- 방법 :

  • AWS Console 작업
    ** 본 시나리오에서는 AWS 서비스 신규 생성 작업은  없음 ** 
    1. Direct Connect Connection: 전용선 신청 메뉴(Create Connection)를 통해 물리적 포트 할당 및 LOA-CFA 발급 절차를 분석하고, 이를 Tailscale 가상 인터페이스 설정과 논리적으로 매핑할 수 있도록 숙지함.
    2. Private VIF 생성: Virtual Interfaces 메뉴에서 사설 통신용 VIF 생성 절차(BGP ASN, VLAN ID 설정 등)를 숙지함.
  • Local(Tailscale) 연동 구현
    1. Direct 상태 확인 : tailscale status 명령어로 EC2와 로컬 PC 간 P2P 직결 여부 확인 (default가 direct mode)

    2. Relay 모드 설정 : UDP 41641 차단
    sudo iptables -A OUTPUT -p udp --dport 41641 -j DROP
    sudo iptables -A INPUT -p udp --sport 41641 -j DROP
    # -> Relay 전환 후 ping 측정 (평균 80~100ms)

    3. Direct 복구 : 차단 규칙 제거 후 Tailscale 재기동
    sudo iptables -D OUTPUT -p udp --dport 41641 -j DROP
    sudo iptables -D INPUT -p udp --sport 41641 -j DROP
    sudo tailscale down && sudo tailscale up
    # → Direct 재수립 후 ping 측정 (평균 15~20ms)

    4. 결과 정리 : Relay는 중계 경유로 지연 증가, Direct는 P2P 직결로 저지연 유지 → 직결 경로 성능 우위 확인

- AWS 아키텍처 : 시나리오 1과 동일


- 검증 결과
:

  • Relay 모드 : 평균 80~100ms, 중계 서버 경유로 지연 증가 및 응답 편차 발생
    relay 모드 결과
  • Direct 모드 : 평균 15~20ms, P2P 직결로 저지연 및 안정적 응답 유지
    direct 모드
  • 결론 : Direct 전환 시 약 4~6배 레이턴시 개선 확인 → 직결 경로 확보가 성능에 결정적 영향 미침을 실험적으로 검증

+ Recent posts