Load Balancing

왜 로드 밸런싱을 사용해야 할까?

우선 로드 밸런싱을 사용하지 않는다면 다음 그림과 같이 우리는 각 EC2 인스턴스에 고정된 아이피를 부여해야 한다. 문제는 하나의 인스턴스에 하나의 도메인밖에 연결할 수 없는데, 서버에 많은 트래픽이 몰리면 서버의 사양을 올리는 스케일 업, 서버의 개수를 늘리는 스케일 아웃을 고려해야 한다는 것이다. 이때, 로드 밸런싱을 사용하지 않는다면, 스케일 업의 경우 인스턴스를 업데이트하는 동안에 서비스를 할 수 없는 문제가 발생하고, 스케일 아웃을 하면 서버가 늘어날 때마다 도메인이 새로 필요하다는 문제점이 발생한다.

 

이때, 로드 밸런싱을 사용하게 되면 다음 그림과 같이 한 곳의 엔드포인트로 들어오는 트래픽을 각 인스턴스로 분산시킨다.

 

이러한 로드밸런싱은 크게 Layer 4에서 동작하는 클래스 로드밸런싱과 Layer 7에서 동작하는 어플리케이션 로드밸런싱으로 나눌 수 있는데, 클래식 로드밸런서가 동작하는 Layer 4에서는 라우터, 스위치 등 물리적인 하드웨어 영역이기 때문에 데이터를 변경 및 수정할 수 없고, 애플리케이션 로드밸런서가 동작하는 Layer 7에서는 포트나 헤더 등이 수정이 가능하다는 특징을 집고 넘어가자.

 

Classic Load Balancer (ELB)

대상그룹 혹은 타겟그룹이라는 개념이 나오는데, 이는 EC2 인스턴스를 오토 스케일링할 수 있는 단위로 사용된다. 이러한 ELB의 단점은 서버의 기본 주소가 바뀌면 로드밸런서를 새로 생성해야 하고, 하나의 주소에 하나의 대상그룹으로 보내게 된다는 점이 있다. 또한 4 Layer에서 동작하기 때문에 데이터를 수정, 변경할 수 없기때문에 포트나 헤더를 변경할 수 없다. 그리고 ELB 구조의 문제점은 서버의 구성이 비대해지고, 마이크로 아키텍쳐를 구성하기 어렵다는 점이 있어, 회원 모듈을 처리하는 인스턴스와 쇼핑 모듈을 처리하는 인스턴스가 따로 존재하면 2개의 로드밸런서가 필요하고, 비용도 2배로 들어가게 된다는 점이 있다.

 

Application Load Balancer (ALB)

반면에 ALB는 path나 port 등에 따라 다른 대상그룹으로 매핑할 수 있다는 장점이 있다. 특히, 포트단위로 연결해줄 수 있는 것은 도커 컨테이너 환경에서 아주 유용하게 동작할 수 있고, 하나의 대상 그룹에 더 많은 컨테이너를 넣어서 비용을 최적화할 수 있다. 뿐만 아니라 대상을 EC2 인스턴스, lambda, IP로도 연결이 가능하기 때문에 특정한 요청에 대해 서버없이 직접 응답 메시지를 작성할 수 있어 마이크로 아키텍쳐를 구성하기에 좋다.

 

Load Balancing 용어

상태확인

Load Balancer에서는 상태 확인을 할 수 있다. 상태 확인은 대상 그룹에 원하는 경로와 포트를 설정하여 정상적으로 원하는 HTTP 응답이 오는지 확인하게 해준다. 그리고 만약 정상적으로 응답이 오지않는 인스턴스가 있으면 비정상태의 인스턴스를 제외한 다른 인스턴스로만 트래픽을 분산한다.

 

대상그룹

대상그룹은 일반적으로 오토 스케일링을 위한 단위인데, 각각의 대상그룹에 있는 인스턴스들은 정의된 상태검사를 수행한다.

 

이렇게 클래스 로드밸런서는 단순한 형태여서 요청을 어느 대상그룹으로 보낼지정도만 알면 되지만, 애플리케이션 로드밸런서는 다소 복잡하다. 각각의 포트에 따라 다르게 구성할 수 있으며 동일한 포트라도 path 등에 따라서 다르게 분기할 수도 있다. 그럼 이러한 ALB에 추가용되는 용어를 알아보자.

Listener, Rule

ALB에는 리스터를 포트와 프로토콜 별로 분기 처리할 수 있다. 그리고 하단에 있는 룰은 path별 혹은 AWS_ARN별로 다른 분기를 처리할 수 있다.

 

인용

https://medium.com/harrythegreat/aws-%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%8B%B1-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0-9fd0955f859e

[AWS] 로드밸런싱 알아보기