Load Balancer...

서비스에 로드밸런서가 연결되어 있다.

 

그렇기에 어떠한 이점을 얻고 로드밸런서가 무엇이고 AWS 로드밸런서는 어떤 특징을 가지고 있는지 확인한다.

 

로드 밸런서는 부하 분산 장비 중 하나로 L4, L7 스위치 역할을 한다.

 

어느 계층까지 프로토콜을 이해하여 부하를 분산하느냐에 따라 Layer가 나누어지는데 보통 구분하지 않고 사용한다고 한다.

 

하지만 AWS의 로드밸런서는 L4, L7의 계층을 나누어 제공한다.

이는 Load balancer type에 기재된 정보를 가지고 구별할 수 있다.

 

이러한 L4, L7의 로드밸런서에 대한 설명은 AWS 문서를 참고해 보자.

Load balancer types - Amazon Elastic Container Service

Load balancer types - Amazon Elastic Container Service

 

Application Load Balancer

 

Application 로드 밸런서는 HTTP/HTTPS layer에서 라우팅을 결정한다.

 

이는 path-based 라우팅을 지원한다. path-based 라우팅은 URL에 기반하여 요청을 부하 분산하는 라우팅 기술이다.

 

이는 Classic Load Balancer, Network Load Balancer, Gateway Load Balancer에서는 해당 기능을 사용하지 못한다. 이는 당연하게도 7 계층 정보를 담고 있기 때문에 4 계층 장비로는 해당 프로토콜을 이해하지 못하기 때문이다.

 

Network Load Balancer

 

transport layer, 4 계층 장비로 네트워크 로드 밸런서는 flow 해시 라우팅 알고리즘을 사용하여 기본 규칙의 대상 그룹에서 대상을 선택한다고 합니다.

 

리스너 설정을 기반으로 TCP 통신을 하며, 특정 target과 정해진 port를 사용합니다.  이는 header의 수정 없이 요청을 forward 합니다.

 

AWS에서 ALB와 NLB를 사용할 때 고려할 점.

 

특정 ECS services들에서 ALB와 NLB를 사용할 때 고려해야 할 점을 알려준다.

 

Amazon ECS는 작업을 생성하거나 중지시킬 때 로드 밸런서에 대상을 등록하고 취소하기 위해 필요한 권한을 설정하는 IAM role 서비스가 필요합니다.

 

ALB, NLB를 사용하는 서비스의 경우 5개 이상의 target group을 구성하여 연결할 수 없다고 합니다.

 

awsvpc 네트워크 모드를 사용하는 서비스의 경우 서비스 대상을 생성할 때 반드시 target type 설정을 instance가 아닌 ip로 설정해야 합니다.

 

이는 awsvpc 네트워크 모드를 사용하는 작업이 EC2 인스턴스가 아닌 elastic network interface에 연결되기 때문입니다.

 

만약 ALB를 사용하는데 여러 개의 로드 밸런스의 포트로 접근해야 하는 경우에는 두 개 이상의 listeners를 설정할 수 있습니다.

 

예를 들어 하나의 listener는 요청을 서비스에 전달하기 위해 HTTPS 포트인 443을 수신받을 수 있고

또 다른 listener는 애플리케이션에서 응답하기 위해 80 포트를 listener 받을 수 있습니다.

 

로드 밸런서의 서브넷을 구성하는 경우 반드시 인스턴스 컨테이너가 존재하는 Availability Zones을 설정해야 합니다.

 

서비스를 생성한 후에는 AWS 관리 콘솔에서는 로드밸런스의 설정을 변경할 수 없습니다.

 

이 경우 AWS Copilot, AWS CloudFormation, AWS CLI or AWS SDK를 사용하여 ECS의 rolling deployment controller만 변경이 가능하며, AWS CodeDeploy blue/green 또는 external은 수정할 수 없습니다.

 

만약 로드밸런스 구성을 추가하거나 업데이트 또는 제거하면 Amazon ECS가 업데이트된 Elastic load balancing 구성으로 새 배포를 시작합니다.

 

IP 주소를 대상으로 구성된 네트워크 로드 밸런서를 사용하는 경우 각 요청은 마치 네트워크 로드 밸런서의 private ip주소로 부터 오는 것으로 간주됩니다.

 

즉 대상의 보안 그룹에서 수신 요청 및 health check를 허용하는 즉시 NBL 뒤에 있는 서비스가 전 세계에 open 됩니다.

 

 

Health Check

 

헬스 체크는 로드 밸런서와 연결된 서버들의 상태를 검사하기 위한 기능이다.

헬스 체크를 하는 방식은 매우 다양하다.

 

ICMP를 사용하여 단순하게 서버가 살아있는지 확인하는 Ping 방식이 존재한다.

이는 서버의 상태만 확인하고 실제 애플리케이션이 잘 동작하는지 확인이 불가능하기 때문에 잘 사용하지 않는다고 한다.

 

TCP 방식도 존재한다. 특정 애플리케이션과 3-way-handshake 과정을 통해 health check를 수행하는 방식인데, 해당 방식은 health check로 인한 트래픽 부하가 걸릴 수 있기에 TCP half open이라는 방식으로 기존 3-way-handshake 방식에서 SYN, ACK을 서버에서 전달해 주면 로드 밸런서가 커넥션 리셋을 가진 RST 플래그를 통해 세션을 종료해 버려 부하를 줄이는 방식도 사용한다.

 

실제 애플리케이션이 반환하는 문자열을 포함하는지 여부를 통해 health check도 사용할 수 있다.

 

응답 결과인 Payload에 설정된 값에 따라 health check을 진행하는 방법이다.

이 과정은 서버의 응답코드를 제외하고 설정하게 되면 응답에러 메시지에 특정 메시지가 포함되는 경우 정상 동작하는 서버로 응답하기 때문에 서버의 http status를 포함하여 검사하는 health check를 구성해야 한다.

 

예를 들어 AWS 로드밸런서 생성 시 헬스 체크 설정할 수 있는 옵션을 살펴보자.

 

AWS의 Health check protocol은 HTTP와 HTTPS만 지원한다.

 

ALB는 URL path 기반으로 애플리케이션 동작을 확인하도록 생성하는 것 같다.

보통 Health check용 index.html 파일을 요청하도록 설정하는 것 같다.

 

Advanced health check settings

 

Port 설정 부분의 기본값은 아마 AWS에서 로드밸런서와 targets의 특정 포트를 사전에 구성하여 제공하는 것 같다. 이를 Override 하여 별도의 port로 health check가 가능하다.

 

Healthy threshold는 비정상 상태로 취급되어 트래픽을 받지 않았던 서버가 정상상태로 취급되기까지 필요한 health check 수를 지정한다.

 

Unhealthy threshold는 지정된 횟수만큼 health check가 실패하면 해당 타깃을 unhealth로 취급한다.

 

Timeout은 응답 시간에 대한 설정으로 해당 시간 안에 서버에서 응답하지 않으면 이를 health check를 실패한 것으로 간주한다.

 

Interval은 각 타깃에 대해 지정된 설정 시간만큼 반복적으로 health check를 실행한다.

 

success codes는 HTTP status code를 기반으로 응답 코드에 대한 상태 코드를 범위로 지정한다.

 

 

 

로드밸런스를 구성하는 방식은 구성 위치에 따라 2가지로 나누어질 수 있습니다.

 

원암과 인라인의 구분은 서버로 가는 트래픽이 모두 로드 밸런스를 경유하는지, 경유하지 않아도 되는지에 대한 트래픽 흐름으로 구분합니다.

One-Arm 구성

 

 

원암 구성은 로드 밸런서가 중간 스위치 옆에 연결되는 구성입니다.

원암 구성은 부하 분산을 수행하는 트래픽에 대해서만 로드 밸런서를 경유하고 부하 분산이 필요하지 않은 트래픽은 로드 밸런서를 경유하지 않고 통신할 수 있습니다.

 

원암 구성에서 스위치와 로드밸런서가 물리 인터페이스 하나로 구성되는 것을 의미하지는 않습니다. LACP를 이용하여 다수 인터페이스로 스위치와 연결된 경우에도 스위치 옆에 존재하면 원 암구성이라고 합니다.

더욱이 LACP를 사용하지 않고 여러 물리 인터페이스로 연결되어도 이를 원 암구성이고 실무에서는 투 암이라고 부른다고 합니다.

 

트래픽의 순서를 보면 클라이언트에서 스위치로 스위치에서 로드밸런서를 거칩니다.

이때 부하 분산에 사용되는 서비스 IP 정보를 로드밸런서가 가지고 있기 때문에 부하 분산 여부를 판단할 수 있습니다.

 

원암 구조에서는 SNAT, DNAT도 함께 이루어져야 합니다.

부하 분산 여부를 이용하지 않는 경우 트래픽은 로드밸런서를 거치지 않고 서버와 통신할 수 있습니다. 불필요한 트래픽이 로드밸런서에 유입되지 않아 로드 밸런서의 부하를 줄일 수 있다는 점이 장점입니다.

또한 스위치와 로드밸런서의 대역폭이 부족한 경우 해당 구간만 대역폭을 증설할 수 있기 때문에 인라인 방식보다 확장에서도 유리합니다.

 

다만 로드밸런서와 스위치 간 대역폭을 정할 때 인바운드 트래픽과 아웃바운드 트래픽 모두 수용할 수 있을 정도의 대역폭을 산정해야 합니다.

 

원 암 구성 방식은 다음과 같을 때 고려해 보자.

 

트래픽이 로드밸런서를 통과하지 않아도 되는 트래픽이 섞였다면 원 암 구성방식을 고려해 보자.

 

Inline 구성

 

인라인 구성은 서버로 가는 경로상에 로드밸런서가 연결되는 구성입니다.

 

인라인 구성은 부하 분산을 포함한 모든 트래픽이 로드 밸런서를 경유하는 구성이 됩니다.

 

L3역할을 하는 스위치보다 로드밸런서는 4 계층 이상의 데이터를 처리하기에 처리 가능 용량이 L3 장비보다 적습니다.

 

처리 용량을 커지면 그에 따라 가격도 많이 상승하기 때문에 로드 밸런서를 인라인 구성방식으로 구성하는 경우는 부하에 따른 성능을 고려해야 합니다.

 

인라인으로 로드 밸런서를 선정할 때는 로드 밸런싱 성능과 패킷 스루풋 성능을 구별해 디자인해야 합니다.

• Packet Throughput 이란 시스템에 최대성능의 모듈을 최대로 장착한 이후 64Byte 패킷 기준으로 장비에서 초당 처리할 수 있는 최대 패킷의 개수를 말한다.

추가적으로 VLAN과 VRF를 이용하면 물리적인 원 암을 인라인 구성으로 처리할 수 있습니다.

 

따라서 물리적 구성만 보고 원암과 인라인 구성을 구분하면 안 됩니다.