로드벨런싱이란?
위키피디아에서 발하는 로드밸런싱이란, 둘 이상의 처리장치, 혹 저장 장치 등의 컴퓨터 자원들에게 작업을 나눔으로써 가용성 및 응답시간을 최적화 시키는 것으로써, 보통 내부 네트워크를 이용한 병렬 처리에 사용된다고 한다. 이러한 점을 웹 서버에 적용하여, 하나의 서버로만 감당하기 어려운 양의 트래픽을 다수의 서버로 분산시켜 처리함으로 응답성을 높이고 여러개의 서버 중 하나의 서버가 작동 불능일 떄에도 다른 서버들이 처리를 해줌으로써 전체 가용성을 높일 수 있는 장점이 있다.
로드벨런서는 3개의 주요 기능을 통해서 로드밸런싱을 처리하는데, NAT와 Tunneling, Direct Serve Return(DSR)으로써 각 기능에 대해서 간단하게 설명하자면
NAT는 외부에서 공인 IP로 접근하는 패킷을 내부의 사설 IP로 다시 전송해주고, 이 중에 목적지의 TCP/UDP 포터 넘버와 소스 및 목적지의 IP주소등을 재기록하고, 체크섬을 다시 계산하여 재기록함으로써 외부 네트워크아 내부 네트워크 간 라우터를 통해 네트워크 트래픽을 주고 받는 기술을 말한다. 우리 일상 생활에서 가장 가깝게 볼 수 있는 NAT를 활용한 기기는 공유기가 되지 않을까 싶다.
터널링은 발신자에서 송신한 패킷을 수신 노드에서만 알아볼 수 있게 터널링하는 것으로서, 사전에 정의된 방법과 키로 패킷을 인터넷을 통해서 보내고 받을때 데이터가 안전하게 지켜질 수 있도록 지원한다.
DSR은 요청에 대한 응답을 할 때 로드밸런서가 아닌 클라이언트의 IP로 응답하게 하는 기술으로써, 네트워크 스위치를 거치지 않고 바로 클라이언트로 찾아갈 수 있도록 한다.
참조
!!위의 글에서는 DSR을 Dynamic Sourece Routing Protocol로 기술하였지만, 해당 글의 댓글에서 DSR이 Direct Server Return이 맞지 않냐는 댓글을 통해서 알려주신 바와 같이 찾아보았을때 Direct Server Return이 더 올바른 기술인듯 하다.참조
AWS에서 제공하는 ELB(Elastic Load Balancing)
ELB는 둘 이상의 가용 영역(EC2 인스턴스, 컨테이너, IP주소 등 여러 대상)에 수신되는 트래픽을 자둥으로 분산하고, 등록된 대상의 상태를 모니터링하면서 상태야 양호한 대상(가용 영역)으로만 트래픽을 라우팅 한다.
ELB는 수신 트래픽의 응답 속도에 따라 로드밸런서를 확장하고, 트래픽에 따라 자동으로 조정할 수 있다.
링크
AWS가 제공하는 ELB의 종류
AWS에서는 4개의 로드벨런서를 제공하고 있다.
- Application Load Balancer
- Network Load Balancer
- Gateway Load Balancer
- Classic Load Balancer
하지만 이 4개의 로드 벨런서는 OSI 계층 중 7 레이어에서 작동하는 어플리케이션 로드 벨런서와, 4 Layer에서 작동하는 네트워크, 게이트웨이, 클래식 로드 벨런서로 구분할 수 있다.
4개의 로드벨런서 전체에 대해서 소개하는 것 보다, 이 두개의 로드벨런서의 차이점에 대해서 자세하게 소개하는게 더 유익할 것 같아 클래식 로드 벨런서와 어플리케이션 로드 밸런서의 차이점에 대해서 조금 더 상세하게 들어가 보도록 하겠다.
Classic Load Balancer
클래식 로드 벨런서는 수신하는 어플리케이션을 여러개의 가용영역의 복수의 EC2인스턴스로 분배한다. 이 작업으로 어플리케이션이 에러가 발생함에도 더 많은 관용성을 제공하게 되고, 로드 벨런서는 인스턴스의 건강 상태(인스턴스가 정상적으로 작동하고 있는지를 확인 후 가용한 인스턴스에만 트래픽을 보내게 된다.
로드벨런서는 클라이언트에게 단일 포인트(하나의 서버로 동작하는 것처럼)으로 작동하고 필요가 있을 시 로드 밸런스 하단의 인스턴스를 추가하거나 제거함으로 서버의 스케일을 필요할 때 조정할 수 있다.
로드 밸런서 하단의 리스너는 클라이언트로부터 오는 연결 요청을 프로토콜이나 포트를 통하여 포워딩해 줄 수 있고, 하나 이상의 리스너를 통해서 어떠한 인스턴스에서 처리할 것인지 구성할 수 있다.
Application Load Balancer
어플리케이션 로드 벨런서는 단일 포인트에서 데이터를 수신하고, 여러 가용 영역에 수신 어플리케이션 트래픽을 분산한다. 이때에 로드벨런서 하단에 여러개의 리스너를 만들고 각 룰을 지정할 수 있으며, 이 리스너 아래에 ec2와 같은 인스턴스나 람다 등으로 수신한 데이터를 처리할 수 있도록 구성한다. 이때 이 가용 영역들을 묶어 타겟 그룹으로 설정하고, 이 타겟 그룹당 헬스 체크를 통하여 해당 영역이 정말 가용한 영역인지를 확인할 수 있는 기능을 제공하게 된다.
ALP의 특징
ALP는 OSI모델의 일곱번째 계층인 어플리케이션 계층에서 작동하기 때문에 패킷과 HTTP(S) 헤더에 접근하여 데이터를 분석하고 좀 더 정교한 부하 분산 작업이 가능하다.
그렇기 때문에 이전 L4 라우팅에서 제공하지 못하는 접근 경로를 기반으로 한 라우팅이 가능해진다. 예를 들어서 x.x.x.x/teacher와 x.x.x.x/student 두 경로로 접근하는 요청들이 있을때, 기존의 L4 라우팅에서는 이 두 요청을 구분하여 라우팅해주는 것이 불가능하지만 L7 라우팅에서는 /teacher경로로 접근하는 요청을 가용 영역 A에, /student로 접근하는 요청을 가용 영역 B로 라우팅하는 것이 가능해진다.
하지만 L7라우팅은 L4라우팅에 비해서 접근하는 데이터의 수와 깊이가 깊어지기 때문에 비교적으로 라우팅하는데에 필요한 시간과 자원이 많아질 수 밖에 없고, 마이크로 서비스 구조에서 URL 패스 별로 각 마이크로 서비스로 라우팅이 필요한 API 게이트웨이는 ALB를 사용한다고 한다.
2차 출처
본 출처: 2019 AWS Summit