[AWS] ELB 정리

🎯 ELB(Elastic Load Balancer) 란 ?

---

트래픽을 여러 대상에 자동으로 분산시켜 안정적인 서버 운용을 도와주는 서비스 입니다. ELB 는 서로다른 EC2 인스턴스에 대한 하나의 엔드 포인트를 제공합니다. 그래서 사용자는 실제 요청이 처리되는 백엔드 인스턴스에 대한 고려 없이, 동일한 엔드포인트로 요청을 전송할 수 있다. 뿐만 아니라 부하 분산에 대한 헬스 체크, 고정 세션, SSL Offload, 헬스 체크를 통한 다운서버 제외등이 가능합니다.

 

로드 밸런싱은 크게 두가지 기능을 제공합니다. 부하 분산 처리와 엔드포인트 역할을 제공합니다. 각각 무엇을 의미하는지 알아봅시다. 

 

부하 분산 처리

 

부하 분산이란 네트워크 기술의 일종으로 여러개의 중앙 처리 장치 또는 저장 장치와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미합니다. 즉 부하를 분산해 트래픽이 한곳에 과도하게 쏠리는 현상을 막기 위한 기술입니다. 

 

 

 

엔드포인트 역할 제공

 

로드밸런싱은 스케일 아웃에 대한 하나의 엔드포인트를 제공합니다. 엔드포인트란 클라이언트가 실제로 요청을 보내는 최종 주소 입니다. 만약 로드밸런싱이 없다면 클라이언트는 EC2에 서버에 직접 접근할텐데 이때 엔드포인트는 EC2 의 IP 주소 또는 도메인 주소가 될 수 있습니다. 이런경우 서버가 죽으면 서비스가 다운되거나 트래픽이 많아지면 감당하지 못하게됩니다. 뿐만아니라 외부에서 EC2에 바로 접근할 수 있다면 보안적으로 취약해지죠.

 

일반적으로, 오토스케일링 그룹을 통해 다수의 인스턴스를 생성하고 관리함으로써 고가용성을 확보할 수 있습니다. 하지만 유저 입장에서는 모드 다른 컴퓨터 IP 주소를 갖고 있을테고, 이들을 관리하기 위해선 모든 주소를 각각 관리하면서 접속해야 합니다. 뿐만 아니라 인스턴스가 바뀌거나 없어진다면 이에 따른 추가적인 관리가 필요합니다. 그래서 오토스케일링 그룹 자체는 부하 분산을 해주는 서비스 없이는 활용할 수 없습니다. 그래서 나온 서비스가 바로 Elastic Load Balancing 입니다.

 

 

로드 밸런서에서 트래픽을 하나의 경로로 받아서 다수의 인스턴스에 분산하고, 유저 입장에서는 하나의 주소로 접속해 관리할 수 있습니다. 인스턴스가 없어지거나 장애가 발생해도 로드밸런스에서는 Health Check 를 통해 트래픽을 보낼 수 있는 인스턴스를 선별해 자동으로 분산합니다.

 

 

🎯 ELB 구성 요소

---

리스너

로드밸랜서가 어떤 포트와 프로토콜로 요청을 받을지 정하는 입구 입니다. 리스너는 외부의 요청을 받기 때문에 로드밸런서는 최소 1개 이상의 리스너가 필요하고, 최대 10개까지 설정할 수 있습니다. 뿐만 아니라 SSL 인증서를 게시해 SSL Offload 를 실시할 수 있습니다. 때문에 VPC 내부에있는 private 서브넷 내부 EC2로 보낼때 별도의 SSL 인증서가 필요 없고, 로드밸런서에서만 SSL 인증서를 관리하면 됩니다.

 

위 리스너 설정에서는, 외부에서 HTTP 8080 포트로 접속하면 리스너에서 이를 리스닝해 대상그룹 HTTP 80포트로 보내줍니다.

 

 

규칙(Rule)

들어온 요청을 어떻게 분기할지 정하는 조건입니다.(ALB만 있음, NLB에는 거의 없음) 즉, 리스너와 타켓그룹 사이의 트래픽 분배를 위한 규칙 입니다. 우선순위, 액션, 조건등의 정보를 포함할 수 있고 path, host, http header 등의 직접 커스텀한 조건이 만족되었을때, 지정된 액션을 수행합니다.

위 리스너 규칙에서는, /admin 경로로 접속하면 funny-run-admin-tg(타켓그룹) 으로 트래픽을 전송하고, 별다른 설정이 없으면 funny-run-api-tg 으로 트래픽을 전송합니다. 요렇게 분기를 설정해 관리자 페이지 트래픽과 api 트래픽을 구분했습니다.

 

 

대상 그룹(Target Group)

대상그룹은 리스너가 전달한 요청을 처리하기 위한 부하 분산 대상들의 모임입니다. 즉, ELB 가 분산을 할때 어디로 트래픽을 넣을지 모아두는 서버 묶음입니다. 대상그룹에는 EC2 인스턴스, 컨테이너, IP 주소, Lambda 등을 등록할 수 있습니다. ALB 가 대상그룹으로 트래픽을 보낼 수 있는 상태인지 확인하기 위해 헬스 체크(Health Check) 기능과 대상 그룹에 요청 처리가 가능한 EC2가 몇개인지 확인하는 모니터링 기능이 있습니다. 

 

즉, 오토 스케일링을 하기 위해서 인스턴스들을 그룹으로 묶어 오토 스케일링 그룹으로 만든 것처럼, 로드 밸런싱을 하기 위해서 대상 인스턴스들을 묶어 놓은 그룹이 바로 대상 그룹입니다. 

 

 

유휴 제한 시간 

 

유휴 제한 시간은 연결이 아무 작업 없이 유지될 수 있는 최대 시간 입니다.(보통60초) 즉, 클라이언트가 연결을 열어두고 아무 요청도 하지 않아 일정 시간이 지나면 ELB 가 연결을 끊습니다. 유휴 제한 시간은 불필요한 연결 점유와 리소스 낭비를 방지합니다. 

 

 

🎯 ELB  기능 및 장점

---

고가용성

ELB 는 접속 부하에 맞게 자동으로 리소스의 확장/축소를 진행합니다. 대량의 요청이 발생해도 ELB 로 인한 병목 현상이 거의 일어나지 않는 것이 가장 큰 장점입니다. 하지만 순간적으로 접근이 증가하면 리소스 자동 확장까지 일정 시간이 걸려 요때 잠깐? 느려질 수 있다고 하네요. 또한 ELB 는 여러 가용영역(AZ)에 걸쳐 동작하기 때문에 하나의 AZ 에서 장애가 발생하도 나머지 AZ로 트래픽을 전달합니다. 때문에 ALB 는 최 두개 이상의 가용영역에 있는 EC2를 연결하는것이 의미가 있습니다.( 1개만 두면 로드 밸런서를 쓰는 의미가 거의 없음 )

 

 

도메인 기반 접근

ELB는 IP 주소가 지속적으로 바뀌어 IP 고정이 불가능합니다. 때문에 도메인 기반으로 사용해야 합니다. 자동 확장/축소됨에 따라 ELB 접근 IP가 변경되므로 ELB에 접근하는 경우 ELB를 생성할 때에 생성되는 도메인 이름을 사용해 접근하도록 구성해야 합니다. 즉 DNS 이름을 통해 접속하면 ELB 는 요청을 대상 그룹에 전달합니다.

 

 

ELB 요청 처리 과정 

1. 사용자가 로드밸런서에 접근하기 위해 DNS 서버에 로드밸런서의 도메인 해석 요청
2. DNS 서버가 로드밸런서 노드 IP 리스트를 사용자에게 전달 
3. 사용자는 전달받은 IP중 하나를 선택해 로드 밸런서에 접근
4. 사용자는 로드 밸런서의 리스너에 접근하게 되며 리스너는 이 요청을 받아들여 적절한 대상그룹으로 전달 
5. 리스너로부터 전달받은 요청을 EC2가 처리한 후 다시 사용자에게 반환

 

 

Cross-Zone Load Balancing

로드밸런서가 모든 가용영역에 있는 서버들에게 트래픽을 균등하게 분산하는 기능 입니다. 

 

Cross-Zone Off 일때 

AZ-a : EC2 1개
AZ-b : EC2 3개

 

그리고 트래픽이 AZ 별로 각각 50% 씩 들어오면 AZ-a 는 한개의 EC2개 50%의 트래픽을 모두 감당하고, AZ-b 는 3개의 EC2가 50% 트래픽을 가져갑니다. 즉 AZ-a 서버는 과부하가 올 수 있습니다.

 

하지만 Cross-Zone 를 이용하면 ELB가 AZ 구분없이 전체 서버 기준으로 분산합니다. 총 서버가 4개면 가용영역에 상관없이 서버의 개수를 기준으로 균등하고 25% 씩 분배합니다. 즉, Cross-Zone Load Balancing 은 부하 불균형을 방지하고 서버수가 적은 AZ 가 터지는 현상을 방지합니다. 

 

특히, 오토스케일링 사용하고 AZ별 인스턴스 수가 달라질 수 있을때 거의 필수적으로 사용합니다. ALB 는 Cross-Zone 을 활성화해도 추가 비용이 없지만, NLB 는 AZ 간 트래픽 비용이 발생할 수 있는점을 참고하면 좋을 것 같습니다.

 

 

 

Health Check(상태 검사)

 ELB에 연결된 인스턴스에 직접 트래픽을 발생시켜 인스턴스가 살아 있는지 확인하는 기능입니다. 헬스체크를 통해 살아 있는 EC2를 선별해 트래픽을 보냅니다. 이를 통해 장애가 전파되는 것을 방지해 고가용성을 확보할 수 있고, 상태 확인 개선을 통해 상세한 오류 코드를 구성할 수 있습니다. 또한 새로운 지표로 EC2 인스턴스에서 실행되는 각 서비스의 트래픽을 파악할 수 있습니다.

 

 

 

고정 세션(Sticky)

로드밸런서의 근본적인 딜레마는 세션 지속성입니다. 사용자 A의 첫번째 요청이 서버1로 갔다면, 두번째 요청도 같은 서버로 가야 로그인 상태가 유지됩니다.

 

고정 세션은 클라이언트(사용자)가 로드밸런서를 통해 요청을 보낼 때 항상 같은 백엔드 서버(EC2) 로 연결되도록 세션을 고정 하는 기능입니다. 즉, 사용자를 항상 같은 서버에 붙잡아두는 기능입니다. 그렇다면 왜 고정 세션이 필요할까 ?

 

다음과 같은 상황이 있다 가정해 봅시다.

 

EC2 두대가 있고 ALB 가 라운드 로빈 방식으로 분산하는 상황입니다.

요청 1 -> EC2 A
요청 2 -> EC2 B
요청 3 -> EC2 A

 

만약 EC2 A 가 세션 정보를 들고 있고 EC2 B 가 그 세션 정보를 모르는 상황이면 사용자는 매 요청마다 로그아웃되는 상황이 발생할 수 있습니다. 그래서 특정 사용자에게는 계속 같은 서버에 요청을 보내게 고정해야 하는 상황이 있고, 이를 돕는 기능이 바로 고정 세션(Sticky Seccion) 입니다. 

 

물론, 단일 서버 환경에서는 이런 문제가 발생하지 않습니다. 하지만 서비스가 점차 커져 scale-out 을 하게 된다면 충분히 발생할 수 있기에 ELB 에서 고정 세션은 반드시 알아야 하는 개념입니다.

---