이전에 EC2 게시글에서 웹서버에 외부 사용자가 접근할 때, 로드 밸런서를 통해 접근하게 된다고 서술했다. 오늘은 로드 밸런서의 역할과 aws에서 지원하는 로드밸런서인 ELB를 알아보고자 한다.

로드 밸런서의 역할

요청 분산

단순히 EC2 인스턴스 하나에 접근하기 위해서는 로드 밸런서가 필요할까? 아마 필요없을 것이다. 로드 밸런서는 들어온 요청을 분산하여 여러 인스턴스에 넘겨주는 역할이 크기 때문이다.

그럼 여러 인스턴스가 존재하는 경우가 있을까?

Scale Out

웹서버의 경우 리소스가 부족할 때, 새로운 인스턴스를 생성하여 부담을 나눠가지는 경우가 일반적이다. 이를 Scale Out이라고 한다.

Scale Up

물론 새로운 인스턴스를 생성하지 않고 기존 인스턴스의 사양을 업그레이드 하여 해결할 수 도 있다. 이를 Scale Up이라고 한다.

어느 쪽이 정답이라고는 말할 수 없다. 하지만 두 가지 방법을 적절히 병행하여 사용하는 것이 중요할 것이다. Scale Up으로는 어플리케이션 아키텍처 자체의 한계점이 존재하기 때문에, 성능 상승에 제약이 존재한다.

따라서 어플리케이션의 한계를 끌어내는 지점까지 Scale Up을 하고, 그 이후에 Scale Out을 해야한다. 가용성을 고려해서 여러 가용 영역에 나눠서 Scale Out을 한다면 더 좋을 것이다. 사랑해요 쿠버네티스

SSL/TLS 처리

SSL은 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기 위한 표준 기술이다. 어느 웹사이트는 http로 되어있고, https로 되어있는 웹사이트도 본 적이 있을 것이다. https로 되어있는 웹사이트가 ssl이 적용되어 더 안전하다고 할 수 있다.

이제는 ssl에 기반하여 발전된 형태인 tls를 사용하며, ssl이라고 한다면 tls를 가리킨다고 해도 무방하다. tls는 공개키 방식의 인증서를 통해 이루어지게 된다.

aws에서도 certificate manager 서비스를 통해 해당 인증서를 발급받을 수 있다.

이러한 ssl/tls 처리를 여러 웹 서비스에 각각 구현하게 된다면, 코드 중복과 암호화 복호화 과정의 연산을 수행해야 하기 때문에 로드 밸런서에서 처리하는 것이 여러모로 좋아보인다.

ELB

이러한 로드밸런서를 aws에서는 Elastic Load Balancing라는 서비스로 제공한다. ELB에서 세 가지의 로드 밸런서가 제공된다. glb : 저기 저는요..?

ALB(Aws Load Balancer)

ALB는 L7 LB에 해당하는 로드밸런서이다. 그렇기 때문에 http나 https를 이용한 접근을 분산하는 데 최적화 되어 있으며, SSL 처리, URL 패턴에 따라 분산 처리가 가능하다. 웹사이트 구현을 위해 주로 이용되는 듯 하다.

NLB(Network Load Balancer)

NLB는 L4 LB에 해당하는 로드밸런서이다. IP 프로토콜 데이터에 따라 분산하며, 높은 처리량과 매우 짧은 시간을 유지하면서 많은 접근을 처리하도록 설계되어 있다. 소켓 통신을 통한 실시간 게임 구현을 위해 이용된다.

eks에서는 nlb를 생성하고 ingress controller로 L7 LB 역할을 하는 nginx ingress controller를 두어 L7 LB를 적용하는 경우도 있다.

CLB(Classic Load Balancer)

예전에 ALB나 NLB가 등장하기 이전에 쓰이던 로드 밸런서이다. eks의 LoadBalancer Type의 Service를 생성하는 등 특별한 경우가 아니면 쓰이지 않는다고 한다. glb : 그럼 나를 설명하는게...