[AWS]Gateway Load Balancer #4(Idle Timeout & Failover)

Gateway Load Balancer의 Idle Timeout

• Gateway Load Balancer(이하 GWLB)의 Idle Timeout 값은 TCP 350초, 비 TCP(UDP 포함)의 값은 120초로 고정되어 있음
  • Idle Timeout : Connection(이하 커넥션)가 유휴 상태일 때, 커넥션이 유지되는 시간
• 이는 고정값으로 변경이 불가능함
• GWLB의 고정된 Idle Timeout을 고려하여 부하분산 대상이 되는 Appliance(이하 어플라이언스)의 Idle Timeout 값을 결정해야 함
• 예를 들어 GWLB를 통해 방화벽 인스턴스(어플라이언스)의 부하분산을 실시할 경우, GWLB의 Idle Timeout값인 TCP 350초, 비 TCP 120초보다 낮게 잡는 것이 좋음
• GWLB보다 방화벽의 Idle Timeout이 길다면 350초가 지난 후에 방화벽 인스턴스(어플라이언스)만이 커넥션을 보유하고 GWLB는 커넥션이 없는 비대칭적 상황이 발생할 수 있음

 

Deregistration Delay(Connection Draining)

대상그룹의 세부 정보, Deregistration Delay 부분

• 등록 취소 지연, 소위 Connection Draining(이하 커넥션 드레이닝) 기능
• 사용자가 GWLB의 대상그룹에서 어플라이언스를 고의로 등록 취소(제외)시켰을 경우, 어플라이언스가 보유한 커넥션의 작업이 처리될 때까지 기다리는 시간
• 기본값은 300초로 사용자가 임의로 변경 가능
• 예를 들어, 대상그룹에서 제외된 방화벽 인스턴스(어플라이언스)는 보유한 커넥션을 즉시 끊지 않고 300초까지 기다렸다가 커넥션을 제거함
• 대상그룹에서 제외된 어플라이언스는 대상 항목에서 "Draining"이라는 회색 표시 상태로 전환됨

 

Target Failover

Target Failover(출처 : https://aws.amazon.com/ko/blogs/)

• Health Check(이하 헬스 체크) 실패 혹은 대상그룹에서 등록 취소(제외)된 어플라이언스에 남아 있는 커넥션을 정상적으로 작동 중인 다른 어플라이언스로 재분배하는 기능
• 기본 비활성화된 기능으로 활성화해야 사용 가능
• Target Failover 기능이 있기 전, 위 2가지 상황에 놓인 어플라이언스의 커넥션은 Idle Timeout까지 남아있거나 등록 취소 후에 제거됨
  • 이는 장애 / 등록 취소 상황에 놓인 어플라이언스로 인해 사용자의 요청이 제대로 처리되지 못하고 그저 움켜쥐고 있음을 의미
• 한 가지 주의해야 할 것은 GWLB는 Target Failover를 통한 커넥션 재분배 시 Client(이하 클라이언트)와 어플라이언스에 TCP Reset을 전송하지 않음
  • 기존 커넥션의 존재를 GWLB만 알고 정상 작동 어플라이언스는 모르는 상태에서 어플라이언스가 기존 커넥션의 트래픽이 유입된다면 어플라이언스의 Vendor별로 반응이 다를 것으로 생각(글쓴이 의견)

 

Appliance 장애 발생 시 시나리오(Target Failover 설정)

Health Check 실패 발생

1. 어플라이언스에 대한 헬스 체크 실패 발생시, 실패 확정되기까지 기본 20초 소요(10초 간격 2회 시도)
2. (기존 커넥션) GWLB가 정상 어플라이언스로 재분배 실시(총 20초 소요)
3. (신규 커넥션) 어플라이언스로 유입된 신규 커넥션은 정상 어플라이언스로 Re-routing 되며, 이때 약 50초 정도 소요(총 70초 소요)
* 신규 커넥션에 대한 Re-routing 실제 테스트시 70초 이상 소요됨(글쓴이 경험)

등록 취소 지연 실시

1. 대상그룹에서 어플라이언스에 대한 제외 실시(등록 취소 지연 발생)
2. 어플라이언스의 "Draining" 상태 돌입(기본 300초 소요)
3. (기존 커넥션) 300초 이후, 정상 어플라이언스로 재분배 실시(총 300초 소요)
4. (신규 커넥션) 정상 어플라이언스로 유입(소요 시간 없음)

 

참고문서

• https://aws.amazon.com/ko/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-supported-architecture-patterns/
• https://aws.amazon.com/ko/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/
• https://aws.amazon.com/ko/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-target-failover-for-existing-flows/