[AWS]Gateway Load Balancer #1(개요)

틀린 부분이 있다면 지적 부탁드립니다!

Gateway Load Balancer(GWLB)를 사용하면 방화벽, 침입 탐지 및 방지 시스템, 심층 패킷 검사 시스템과 같은 가상 어플라이언스를 배포, 확장 및 관리할 수 있습니다. 투명한 네트워크 게이트웨이(즉, 모든 트래픽에 대한 단일 진입 및 종료 지점)를 결합하고 수요에 따라 가상 어플라이언스를 조정하면서 트래픽을 분산합니다.

출처 : AWS 설명서(https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/gateway/introduction.html)

• On-premise(이하 온프레미스)에서 사용되는 네트워크 장비 혹은 보안 장비 등의 OS Image를 AWS EC2에 올려 장비의 고유 기능을 AWS에서 활용할 수 있음
• 다시 말해 AWS에 3rd Party Solution을 생성하여 활용하는 것을 의미함
• 많이 사용되는 기능으로 방화벽(FW)과 웹방화벽(WAF), L4/L7 스위치 등이 있음
• 온프레미스에서 오랜 시간 다양한 기능을 발전시켜 온 네트워크/보안 장비를 그대로 사용할 수 있다는 장점이 있음
  • AWS에서 자체 제공하는 로드밸런서나 FW, WAF는 뛰어난 성능과 더불어 조작 난이도가 낮은 대신 기능이 다양하지 않고 숙련된 운영자가 조작하기엔 기능에 아쉬운 점이 있음
• AWS의 자체 기능이 아닌 온프레미스의 장비 기능을 EC2에 올려 사용하는만큼 부하 분산과 이중화에 기능이 없어 사용에 끊임없는 제동이 걸림
• Gateway Load Balancer는 3rd Party Solution에 부하 분산과 Health Check(이하 헬스체크), 확장을 제공하기 위해 만든 로드밸런서
• Gateway Load Balancer 탄생 이전부터 3rd Party Solution를 부하 분산하고자 다양한 시도가 이루어졌으며 이에 Application Load Balancer/Network Load Balancer가 사용되었으나 결국 Gateway Load Balancer가 세상에 나오게 됨

 

Application/Network Load Balancer를 두고 왜 Gateway Load Balancer를 만들어 부하부산을 하는가?

• Application Load Balancer(이하 ALB)를 통해 3rd Party Solution의 부하 분산을 실시한다고 가정해 보겠음
• ALB는 부하 분산을 실시하여 패킷을 통과시킬 때 Source IP인 Client(이하 클라이언트)의 IP를 자신의 Interface IP로 Source NAT(이하 SNAT)를 실시함
• ALB에서 SNAT를 실시하게 되면 ALB 하단의 3rd Party Solution은 클라이언트의 IP를 확인할 길이 없음
  • 다시 말해 패킷을 제대로 통제할 수 없다는 것을 의미함
  • 해결할 수 없는 방법이 아예 없는 것은 아님, ALB는 HTTP Header인 X-Forwarded-For에 Client IP를 기재할 수 있으며 3rd Party Solution는 이를 확인할 수 있지만 이것 또한 감당해야 할 "작업"에 해당함
• Network Load Balancer(이하 NLB)를 통해 3rd Party Solution의 부하 분산을 실시한다고 가정해 보겠음
• NLB는 ALB와 다르게 패킷이 로드밸런서를 통과할 때 SNAT를 실시하지 않음
• 3rd Party Solution은 클라이언트의 IP를 확인할 수 있음
• AWS VPC(Virtual Private Cloud)에서 생성되는 모든 서브넷의 Default Gateway는 "x.x.x.1/32"로 끝나는 Virtual Router(사용자에겐 보이지 않는 라우터)로 라우팅 테이블을 제어하는 역할을 함
• NLB와 3rd Party Solution을 거쳐 내부 목적지로 향하여 패킷이 처리된 후, 다시 응답 패킷을 클라이언트에게 보내는데 이때, 3rd Party Solution가 아닌 Default Gateway와 Internet Gateway를 통해 외부로 나아가게 됨
  • 참조 : AWS Network Load Balancer 쉽게 이해하기 #1
  • 3rd Party Solution은 요청 패킷이 자신을 통해 처리되었으나 응답 패킷은 자신을 거치지 않는 것을 보고 정합성이 깨졌다고 판단, 패킷을 모두 Drop시킴(3-way handshake도 해당함)
    • 참조 :  L4 스위치 쉽게 이해하기 #5(Source IP NAT 문제)
• 이를 해결하기 위해서는 3rd Party Solution에서 SNAT를 실시하여 응답 패킷으로 하여금 강제로 3rd Party Solution로 돌아오도록 할 수 있지만 이렇게 된다면 내부 목적지에서 클라이언트 IP를 확인할 길이 없음
  • 다시 말해 패킷을 제대로 통제할 수 없다는 것을 의미함
• 이러한 연유로 Gateway Load Balancer가 탄생하게 됨

 

Gateway Load Balancer의 개요와 특징

• Gateway Load Balaner는 위와 같은 ALB/NLB의 문제점을 처리하면서 3rd Party Solution의 부하 분산과 헬스 체크 기능을 제공하기 위해 만들어진 로드밸런서
• 특정 서비스를 제공하기 위한, 특정 포트를 통해 부하분산하는 것이 아닌 3rd Party Solution의 부하 분산을 목적으로 만들어졌기 때문에 Layer 4도, Layer 7도 아닌 Layer 3(에서 동작하는) 로드밸런서로 만들어짐
• GWLB에 Endpoint(AWS VPC Endpoint Service)를 두는 방식으로 요청 / 응답 라우팅을 모두 엔드포인트로 향하도록 하여 모든 패킷이 3rd Party Solution을 거치게 함으로써 위에서 언급되는 ALB/NLB의 문제인 SNAT를 해결함
  • GWLB 구성 참조

GWLB의 구성(출처 : https://aws.amazon.com/ko/blogs/korea/introducing-aws-gateway-load-balancer-easy-deployment-scalability-and-high-availability-for-partner-appliances/)

• ALB/NLB와 마찬가지로 대상그룹(Target Group)을 두고 인스턴스를 추가하는 방식으로 부하분산과 헬스체크를 실시
• Geneve Protocol(https://datatracker.ietf.org/doc/html/rfc8926)을 사용하여 GWLB와 3rd Party Solution 사이에 터널을 생성하여 트래픽을 주고 받으며 UDP 6081 포트를 사용함
  • Geneve를 활용해 패킷을 Encapsulation(이하 캡슐화)하여 전송하기 때문에 "터널"이라 표현함
• GWLB와 대상그룹을 연결하기 위해서는 대상그룹의 프로토콜을 GENEVE(UDP : 6081)을 사용해야 함
• 헬스체크는 기본적으로 TCP, 80 포트를 사용하여 실시하게 됨
• 3rd Party Solution의 보안 그룹에서 반드시 UDP 6081 포트를 열어두어야 GWLB와 3rd Party Solution 간에 패킷 이동이 가능해짐