[Devops] Application Load Balancer

 AWS에서 ALB(Application Load Balancer)를 만드는 방법에 앞서 Load Balancer의 개념부터 알아보도록 한다.

 

Load Balancer Concept

 Elastic Load Balancing은 둘 이상의 가용 영역(Availability Zone) 에서 EC2 인스턴스, 컨테이너, IP 주소 등 여러 대상에 걸쳐 수신되는 트래픽을 자동으로 분산한다. 등록된 대상의 상태를 모니터링하면서 상태가 양호한 대상으로만 트래픽을 라우팅합니다. Elastic Load Balancing은 수신 트래픽이 시간이 지남에 따라 변경됨에 따라 로드 밸런서를 확장한다. 대다수의 워크로드에 맞게 자동으로 조정할 수 있다.

 AWS에서 Elastic Load Balancing은 다음 로드 밸런서를 지원하는데 그 종류로는 다음과 같다. Application Load Balancers, Network Load Balancers, Gateway Load Balancers 및 Classic Load Balancer 각자 필요에 따라 가장 적합한 로드 밸런서 유형을 선택할 수 있다. 이 글에서는 ALB (Application Load Balancer)에 대해서만 다뤄본다.

 

ALB (Application Load Balancer)는 개방형 시스템 간 상호 연결(OSI) 모델의 일곱 번째 계층인 애플리케이션 계층에서 작동합니다. 로드 밸런서는 요청을 받으면 우선 순위에 따라 리스너 규칙을 평가하여 적용할 규칙을 결정한 다음, 규칙 작업의 대상 그룹에서 대상을 선택합니다. 애플리케이션 트래픽의 콘텐츠를 기반으로 다른 대상 그룹에 요청을 라우팅하도록 리스너 규칙을 구성할 수 있습니다. 대상이 여러 개의 대상 그룹에 등록이 된 경우에도 각 대상 그룹에 대해 독립적으로 라우팅이 수행됩니다. 대상 그룹 레벨에서 사용되는 라우팅 알고리즘을 구성할 수 있습니다. 기본 라우팅 알고리즘은 라운드 로빈입니다. 다른 알고리즘으로는 최소 미해결 요청 라우팅 알고리즘을 지정할 수 있습니다.

 

 애플리케이션에 대한 요청의 전체적인 흐름을 방해하지 않고 필요에 따라 로드 밸런서에서 대상을 추가 및 제거할 수도 있다. 애플리케이션에 대한 트래픽이 시간에 따라 변화하므로 Elastic Load Balancing은 로드 밸런서를 확장합니다. Elastic Load Balancing은 대다수의 워크로드에 맞게 자동으로 조정할 수 있다.

 로드 밸런서가 정상적인 대상에만 요청을 보낼 수 있도록 등록된 대상의 상태를 모니터링하는 데 사용되는 상태 확인을 구성할 수 있다.

 

ALB(Application Load Balancer) 생성 - AWS

 우선, EC2 서비스에서 "로드밸런싱" 란의 "대상그룹(Target Group)"을 선택해서 대상 그룹을 생성한다. 

그리고 Application load balancer는 프로토콜에서 HTTP, HTTPS만을 지원하기 때문에 HTTP, HTTPS 이외의 프로토콜을 사용하게 되면, Application Load Balancer를 이용할 수 없게 된다. 

 또한 Application Load Balancer는 Health check(상태 검사) 를 통해 Target이 되는 인스턴스의 상태가 정상적인지 지속적으로 체크하게 된다. 여기에서는 Health Check에서 path를 따로 주지 않고 서버(인스턴스)가 제대로 동작하고 있는지 수시로 확인하게 된다. 

 

 그리고 로드밸런싱 타겟 그룹에 넣을 인스턴스를 선택한 다음 Target group을 생성한다. 

 

그리고나서 "로드밸런싱"의 "로드밸런서"에 들어가서 로드밸런서를 생성한다. 아래의 사진과 같이 로드밸런서 유형 중 만들고 싶은 로드밸런서의 유형을 선택한다. 지금은 Application Load Balancer를 만들도록 한다.

 

 

 

 

로드 밸런서를 만들 때에 "Network mapping"은 어느 가용 영역(availability zone)에, 어느 서브넷(subnet)으로 트래픽을 보낼지 결정하는 곳이다. 

 

 또한 ALB는 타겟이 되는 인스턴스와의 통신을 하기 위해서, 보안 그룹(Security Group)을 사용하게 된다. 보안 그룹에서 Inbound rule에서 HTTP만 열어주고 다른 것들은 닫는다. 

 

 리스너 및 라우팅에서는 어느 타겟 그룹으로 트래픽을 전달할지를 결정한다. 타겟 그룹을 만들 때에도 프로토콜과 포트번호를 지정했는데, 타겟 그룹을 만들 때 지정한 프로토콜과 포트번호는 타겟이 되는 인스턴스와 ALB 사이의 통신에 대한 프로토콜과 포트번호였다. 하지만 해당 단계에서의 프로토콜과 포트번호를 지정하는 것은 외부 및 ALB 사이의 통신에 대한 프로토콜과 포트번호를 지정하는 것이다! 

 

 이렇게 로드밸런서를 만들고 나면 로드밸런서의 DNS name 링크를 통해서 새로고침 될 때마다 다른 인스턴스가 조회되는 것을 알 수 있다. 

 

 

 하지만, 이렇게 외부와 직접적인 통신이 가능한 Public 영역에 웹 서버를 두는 것은 실제 웹서비스를 제공하는 데에 있어서는 보안 측면에서 그렇게 적절한 방법은 아니다. 그렇기에 웹 서버를 Private 영역에 두고 ALB를 Public 영역에 두고 트래픽을 분산시키면서 웹 서비스를 제공하는 환경을 구성해보겠다.

• 사전에 Public IP 주소가 없는 인스턴스 2개를 생성하고, 인스턴스 2개를 같이 묶은 Target Group(대상그룹)을 생성해놓고 실습하도록 한다.
• 위에서 한 것과 같은 방법으로 대상그룹만 다르게 설정한 뒤 로드밸런서를 생성해주면 Private 영역에 있는 인스턴스를 그룹으로 한 로드밸런서에도 잘 동작함을 알 수 있다.

 

 즉, 로드밸런서를 활용할 때 권장되는 방식으로는 Private 영역에 인스턴스를 두고, Public 영역에 로드밸런서를 둬서 트래픽을 분산시키고 웹 서비스를 제공하는 환경을 구성하는 것이다.