1. Timeout Error 상황의 리소스 현황 및 Data Flow

 

 

 

1-1. 리소스 현황

  • 활성화된 로드밸런서 가용영역 : private-2a, private-2c

  • 대상 그룹 : private-2a와 private-2c subnet에 있는 인스턴스 ip address

  • 리스너 : HTTP 80

  • 목적지 : Tomcat 8080

  • Public ip는 오직 public subnet의 인스턴스만 할당.

  • IGW 및 NAT 서브넷 연결현황은 다음과 같다.

    • IGW : public-2a, public-2c
    • NAT : private-2a, private-2c, db subnet

 

 

1-2. Data Flow

1. 사용자는 Public DNS를 통해 ALB에 접근한다.

2. ALB의 트래픽은 IGW를 통해 VPC내로 들어온다.

3. 트래픽은 활성화된 로드밸런서 가용영역 subnet만 참조하게 된다.

3-1. 활성화 된 로드밸런서 가용영역 subnet은 private subnet이다.

3-2. private subnet안에 있는 로드밸런싱 대상의 인스턴스는 public 주소 또는 탄력적 ip가 없다.

3-3. public ip 또는 탄력적 ip없이는 외부와 통신을 할 수 없다.

3-4. 로드밸런서는 계속해서 활성화된 로드밸런서 가용영역 서브넷으로 브로드캐스트 주소로 패킷을 전송하다 유휴제한시간을 초과한다.

3-5. 최종적으로 사용자에게 timeout error을 출력한다.

 

 

 

2. Issue 해결 솔루션 및 Data Flow

 

 

 

2-1. 문제점 분석 및 해결법

먼저 로드밸런서 가용영역에 대해 알아보자. 로드밸런서 가용영역이란, 일반적인 우리가 알고 있는 AZ가 아닌 로드밸런서가 접근할 수 있는 subnet을 의미 한다. 이에 대해서는 다음 캡쳐본을 참고한다.

 

현재 로드밸런서는 활성화된 가용 영역(서브넷)이 private subnet이다. private subnet은 igw와 연결되어있지 않으며, 로드밸런싱 대상은 public ip 또는 탄력적 ip가 할당되어 있지 않기 때문에 외부 트래픽을 다룰 수 없게 된다.

이를 해결하기 위해서는 로드밸런서의 활성화된 가용영역(서브넷)을 public subnet으로 설정해준다. public 서브넷은 외부와는 물론 내부 서브넷과 통신이 가능하므로 public subnet을 거쳐 로드밸런싱 대상으로 트래픽을 전달하면 쌍방으로 통신이 가능해지기 때문에 위와 같은 이슈를 해결 할 수 있다.

 

 

2-2. Data Flow Diagram

다음과 같이 public subnet을 통해서 private subnet의 인스턴스로 접근하게 설정해준다.

 

 

3. 참고문헌

http://thebluenode.com/exposing-private-ec2-instances-behind-public-elastic-load-balancer-elb-aws

https://aws.amazon.com/ko/premiumsupport/knowledge-center/public-load-balancer-private-ec2/?nc1=h_ls

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html

https://docs.cloud.oracle.com/iaas/Content/Balance/Concepts/balanceoverview.htm

+ Recent posts