Server를 공부하던 중에 Load Balancer에 대해 알게되었다. 개인 프로젝트를 진행할 때에는 LB가 필요없겠지만 현업에서는 무엇보다도 중요한 개념이라 생각하여 포스팅하게 되었다...
먼저 AWS의 ELB 서비스를 알기 전에 Load Balancing의 개념을 알고 가자.
아무리 뛰어난 성능의 서버여도 모든 트래픽을 감당할 수 없는 법. 이에 기업들은 서버를 추가로 구비하고 여러 대의 서버에 동일한 데이터를 저장해 수많은 트래픽을 효과적으로 분산시키게 된다.
이에 여러 대의 서버를 구축하였다고 생각해보자. 단순히 다수의 서버를 구축 및 운영한다고 해서 모든 클라이언트의 요청에 일관성 있게 응답할 수 없다. 왜냐하면 쏟아지는 트래픽을 여러 대의 서버로 분산해주는 기술이 없기 때문이다. 모든 트래픽이 한 대의 서버에 몰리는 현상이 발생할 것이다. 이 때 필요한 기술이 Load Balancing
이다!
(Ex) 주차장 A, B, C가 있다고 가정하자. A는 차가 꽉 차있고 B, C는 비어있다. 주차요원이 추가로 오는 차들을 B, C로 안내하지 않고 A에만 안내한다면 뒤에 차들을 주차하지 못하고 기다리기만 할 것이다. 위 글이 이러한 상황과 유사하다고 생각하면 쉽다. (
제가 생각한 예시가 상황과 맞지 않는 예시라면 댓글로 말해주세요...)
Load Balancer
는 서버에 가해지는 부하(Load)를 분산(Balancing)해주는 장치 또는 기술을 통칭한다. Client와 Server pool(분산 네트워크를 구성하는 서버들의 그룹) 사이에 위치하며, 1대의 서버로 부하가 집중되지 않도록 트래픽을 관리해 각각의 서버가 최적의 성능을 발휘하도록 한다. (Balancing은 기술, Balancer는 장치를 의미하는 것 같다...)출처 : 링크
그렇다면 서버를 구축할 때 Load Balancer는 항상 쓰는 것이 좋을까라는 생각을 하였다...
기업이나 개인이 서비스 런칭 초기 단계라면 Client의 수가 적기 때문에 굳이 사용할 필요는 없다고 한다.(서버 1대로 요청, 응답이 가능) 하지만 그 규모가 커지게 되면 당연히 Client의 수도 증가하기 때문에 LB를 써야 정상적인 서비스가 가능하고 많은 트래픽에 대처할 수 있다. (통상적인 답인 것 같다...) 이처럼 많은 트래픽에 대처할 수 있는 방법은 크게 2가지이다.
1. Scale-up (스케일업)
서버 하드웨어의 성능을 업그레이드 시키는 것을 의미한다. 예를 들어 PC의 그래픽카드를 GTX750 -> GTX2080으로 업그레이드 하는 것과 같다.
스케일업
하는동안 서비스가 중지되는 단점이 있다.
2. Scale-out (스케일아웃)
서버의 개수를 늘리는 것이라 생각하면 쉽다. 기존의 서버와 동일하거나 낮은 성능의 서버를 추가로 구축하여 운영하는 것을 의미한다. 예를 들어 그래픽카드가 GTX750인 PC를 여러 대 추가로 구입 및 운영하는 것과 같다.
만약 Scale-out
방식을 사용한다면 반드시 Load Balancing
이 필요하다. 여러 대의 서버로 트래픽을 균등하게 분산시켜 주어야 하기 때문이다.
스케일아웃
을 하면 서버가 늘어날 때마다 Domain이 새로 필요하다는 단점이 있다.
RR 방식 (Round Robin)
서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식이다. Client의 요청을 순서대로 분해하기 때문에 여러 대의 서버가 동일한 스펙을 갖추고, 서버와의 연결(세션)이 오래 지속되지 않는 경우에 적합하다.
WRR 방식 (Weight Round Robin)
각각의 서버마다 가중치를 매기고 가중치가 높은 서버에 Client의 요청을 우선적으로 배분한다. 주로 서버의 트래픽 처리 능력이 차이가 날 경우 사용되는 부하 분산 방식이다.
(Ex) 서버A의 가중치가 5 / 서버B의 가중치가 2 라면 Load Balancer는 RR 방식으로 서버A에 5개, 서버B에 2개 요청을 전달!
IP Hash 방식
Client의 IP 주소를 특정 서버로 Mapping하여 요청을 처리하는 방식이다. 사용자의 IP를 해싱하여 임의의 길이를 지닌 데이터를 고정된 길이의 데이터로 Mapping한다. 트래픽을 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장한다.
LC 방식 (Least Connection)
요청이 들어온 시점에 가장 적은 연결상태를 보이는 서버에 먼저 트래픽을 부여한다. 세션이 많이 길어지거나 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합한 방식이다.
LR 방식 (Least Response)
서버의 현재 연결상태와 응답시간을 모두 고려하여 트래픽을 배분하는 방식이다. 가장 적은 연결상태와 가장 짧은 응답시간을 보이는 서버에 우선적으로 트래픽을 부여한다.
Amazon Web Service가 제공하는 Load Balancer로 ELB라 한다. 기본적으로 Logging, Cloud Watch를 통해 로깅, 장애 복구, 추적, Health Check(서버 응답 체크)와 같은 기능을 제공한다.
'유연하게(Elastic) 시스템의 부하(Load)를 여러 대의 PC에 분산할 수 있도록(Balancing) 해주는 장치'
트래픽과 밀접한 관련이 있다. --> 사용자가 증가하는 것에 따라 시스템의 부하가 달라지며 부하에 따라 여러대의 컴퓨터를 ELB에 붙여 트래픽을 분산시키는 것이기 때문이다. (Load Balancing의 개념과 같다!!)
트래픽 분산 (AWS가 스케일을 관리해준다.)
자동 확장
인스턴스의 상태를 자동으로 감지해서 오류가 있는 시스템은 배제 --> 인스턴스가 회복되면 LB가 자동으로 감지하여 인스턴스에 트래픽을 보내준다.
사용자 세션을 특정 인스턴스에 고정 --> 자신이 이전에 접속했던 인스턴스로 다시 접속할 수 있도록 해준다.
SSL 암호화 지원
IPv4, IPv6 지원
Cloud Watch 등을 통해 모니터링 및 추적 가능
ELB 서비스는 CLB(Classic Load Balancer)
/ ALB(Application Load Balancer)
/ NLB (Network Load Balancer)->나온지 얼마 안됨
3가지 종류가 있다.
Load Balancer
는 Layer 4계층에서 작동하는 CLB(Classic Load Balancer)
와 Layer 7계층에서 작동하는 ALB(Application Load Balancer)
가 있다.
Layer 4계층은 라우터, 스위치 등 물리적인 HW 영역으로 데이터 변경/수정이 안되고, Layer 7계층은 애플리케이션 계층으로 포트, 헤더 등의 수정이 가능하다고 가볍게 이해고 넘어가자.
가장 기본적인 형태이자 초기에 제공되던 서비스이다. 단순히 ELB를 CLB로 보는 경우가 많다.
CLB의 단점은 서버의 기본주소가 바뀌면 Load Balancer를 새로 생성해야하며 하나의 주소에 하나의 대상그룹으로 보내게 된다. (대상그룹, EC2 인스턴스를 오토스케일링 할 수 있는 단위)
또한, Layer 4계층에서 작동하기 때문에 데이터를 수정/변경할 수 없어 포트, 헤더 등의 변경을 하지 못한다.
이러한 구조는 서버의 구성과 아키텍처가 커지고 복잡해진다. 이에 Load Balancer의 필요 개수, 비용이 증가하게 된다.
(Ex) 쿠팡에서 회원관리 인스턴스와 주문 인스턴스가 따로 존재한다고 하자. 로그인 후 주문을 하기 위해서는 각각 다른 Load Balancer를 거쳐 해당 인스턴스로 접속해야 하므로 서버 개수, 비용이 증가하게 된다!
반대로 ALB는 포트 등에 따라 다른 대상그룹으로 Mapping이 가능하다. 특히 포트 단위로 연결하는 장점은 Docker Container 환경에서 활용성이 높아 잘 작동하며 하나의 대상그룹에 더 많은 Container를 넣어 비용을 최적화할 수 있다.
또한, EC2 인스턴스, 람다, IP 에 연결이 가능하며 특정한 요청에 대해서는 서버없이 직접 응답메시지를 작성할 수 있기 때문에 서버 구성 측면에서도 좋다.
NLB는 AWS에서 가장 최근에 나온 매우 높은 성능의 Load Balancer 이다. Load Balancer에 Elastic IP (고정 IP)를 부여할 수 있는 유일한 LB이다. TCP Layer까지만 지원한다. 따라서 HTTP, Cookie 방식의 sticky는 지원하지 않으며, TCP 세션은 350초 유지한다고 한다.
Client의 요청에 대해 낮은 대기 시간으로 빠른 응답 및 처리가 가능한 장점이 있다. NLB는 또한 기존 ELB에서 발생하는 짧은시간 내 스파크성 트래픽에 대응이 가능하여 ELB의 단점을 해소해준다. (가장 최근에 나와서 그런지 이에 대한 글이 많이 없다...ㅠㅠ)
밑의 그림을 통해 기존 CLB/ALB와의 차이와 이해를 도울 수 있다고 생각한다.
출처 : https://m.post.naver.com/viewer/postView.nhn?volumeNo=27046347&memberNo=2521903
https://nesoy.github.io/articles/2018-06/Load-Balancer
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
https://jins-dev.tistory.com/entry/AWS-%EC%9D%98-%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%84%9CLoad-Balancer-%EC%82%AC%EC%9A%A9%ED%95%B4%EB%B3%B4%EA%B8%B0-ELB-ALB
https://opentutorials.org/course/608/3008
https://www.bespinglobal.cn/tech-blog-171114-aws-nlb2/
https://blog.leedoing.com/116
https://iamondemand.com/blog/elb-vs-alb-vs-nlb-choosing-the-best-aws-load-balancer-for-your-needs/