Elastic Load Balancer (ELB) : (1)

이번 포스팅에선 AWS의 핵심 시스템 중 하나인 Elastic  Load Balancer 줄여서 ELB에 대해서 알아보도록 하겠습니다. ELB는 개발자에게 그리고 AWS에게도 빠질 수 없는 중요한 시스템인데요. 

 

만약 개발자에게 "AWS에서 제공하는 로드밸런서의 기능을 직접 구현해라"라고 하면 구현하는 것도 만만치 않은데다 유지보수 하는것도 쉽지 않을 것입니다. 

 

또한, 기껏 직접 로드밸런서를 만들었다고 하더라도 다른 시스템과 연동하는건 또 다른 이야기이죠. 이 로드밸런서를 각각의 애플리케이션과 연결하고 관리하는건 개발자로 하여금 막대한 기술부채를 안겨다주죠. 

 

AWS도 ELB라는 구현하기 쉽고 유지보수하기 쉬운 시스템을 내면서 다양한 AWS의 시스템과 ELB를 연동시킬 수 있게 함으로써 더욱 다양한 AWS의 시스템을 개발자들이 이용하게끔 유도합니다. 그러면서 수입도 짭짤하게 나오죠. 

 

자 이제 본격적으로 AWS의 ELB에 대해서 알아보도록 하겠습니다.

 

가용성과 확장성

우선 Availability라고 부르는 가용성과 Scalability라고 부르는 확장성에 대해서 잠시 짚고 넘어가도록 하겠습니다. 

 

먼저 확장성부터 살펴보죠. 

 

확장성

확장성에는 수직적 확장과 수평적 확장이 있습니다. 수직적 확장은 쉽게 설명해서 EC2 인스턴스의 크기를 키우는 것입니다. 만약 인스턴스가 t2.micro로 작동하고 있었다면 이를 t2.large로 바꾸는 것이죠. 

 

이렇게 하면 인스턴스 각각이 수행할 수 있는 능력이 향상될 것입니다. 이것을 예시로 쉽게 설명해보자면 전화업무를 진행하는 A/S 센터에서 신입이 처리할 수 있는 전화업무와 경력직이 처리할 수 있는 전화업무는 크게 차이가 있을건데요. 

 

만약 신입이 5개의 전화업무를 처리할 수 있다면 경력직은 같은시간에 10개의 전화업무를 처리할 수 있을겁니다. 전화업무를 처리하는 개인의 역량이 늘어난 것이죠. 

 

이를 수직적 확장, Scale Up이라고 부릅니다. 

 

수평적 확장은 EC2 인스턴스의 개수를 늘린겁니다. 원래라면 1개에서 처리해야할 부하를 2개, 3개에서 처리하면 그만큼 전체적인 부하가 줄어들겠죠? 

 

전화업무로 다시 예를 들자면 10개의 전화업무를 처리하려면 경력직 한명을 고용하는 것도 방법이지만 신입 두명을 고용하는 것도 방법입니다. 

 

여기까지가 확장성에 대한 내용입니다. 이제 가용성에 대해서 보죠. 

 

가용성

가용성은 확장성과 궤를 같이하는 개념이지만 살짝 다른 핀포인트가 있습니다. 가용성은 장애가 발생했을 때도 시스템이 돌아가는 것에 초점을 둡니다. 

 

만약 전화업무를 처리하는 지부가 서울지부 부산지부 이렇게 두개가 있는 상황에서 문제가 생겨서 부산지부가 먹통이 되는 상황에 놓였다고 해봅시다. 

 

이 때 부산지부는 문제가 생겼지만 서울지부가 아직 살아있기 때문에 전화업무는 그대로 유지할 수 있을 것입니다. 

 

 

자 가용성과 확장성이 ELB와 무슨 상관이냐 하시겠지만 ELB가 잘하는 업무중에 가용성과 확장성이 들어있기 때문입니다. 이것은 포스팅 마지막 즈음 소개드릴 오토 스케일링 그룹 (ASG)를 설명할 때 본격적으로 등장합니다. 

 

 

ELB의 종류

AWS에서는 다양한 로드밸런서를 소개하고 있습니다. 대표적으로 소개하는 로드밸런서는

 

• Classic Load Balancer (CLB) - deprecated
• Application Load Balancer (ALB)
• Network Load Balancer (NLB)
• Gateway Load Balancer (GWLB)

이렇게 네가지를 소개합니다. 

 

하지만 AWS에선 CLB의 사용을 지양하라고 가이드라인이 있는데요. CLB가 버전1이고 뒤에 나온 ALB, NLB, GWLB가 버전 1인 CLB의 속성을 거의 다 포함하고 있기 때문이죠. 

 

그래서 이번 포스팅에서도 CLB는 제쳐두고 ALB, NLB, GWLB에 대해서 설명드리겠습니다. 

 

ALB (Application Load Balancer)

ALB는 말 그대로 애플리케이션을 위한 로드밸런서입니다. 주로 HTTP, HTTPS 트래픽을 분산시키기 위해 만들어진 로드밸런서입니다. 

 

ALB는 OSI 7계층인 애플리케이션 계층에 존재하는 로드밸런서입니다. 7계층 로드밸런서인만큼 어떤 패킷이 오고 가는지 확인해볼 수 있기 때문에 위조/변조된 패킷을 분리해내는데 특화되어 있습니다. 이는 보안이 훌륭하다는 의미이죠. 

 

하지만 뒤에 설명할 NLB인 4계층 로드밸런서에 비해 속도가 느리고 4계층 로드밸런서에 비해 많은 것들을 확인해야하기 때문에 비용이 더 비싸다는 단점이 있습니다. 

 

이 두가지에 대한 차이점은 아래의 링크에 자세히 설명해두었으니 참고해주세요!

 

https://coding-review.tistory.com/319

로드 밸런싱 (Load Balancing)

 

NLB (Network Load Balancer)

NLB는 앞서 설명드렸다시피 OSI 7계층 중 4계층 전송계층에서의 트래픽을 담당합니다. 4계층 로드밸런서인만큼 패킷을 확인할 수 없기 때문에 보안에 취약하지만 속도가 매우 빠르고 비용이 저렴하다는 특징이 있습니다. 

 

성능차이는 기본적으로 ALB가 400ms 성능을 보여주는 반면에 NLB는 100ms로 약 네배정도 성능이 뛰어납니다. 

 

때문에 AWS에서도 NLB는 높은 성능을 요구하는 로드밸런서를 위해 만들어진 것이라고 쓰여있습니다. 

 

 

GWLB

GWLB는 OSI 7계층 중 3계층인 네트워크 계층에서 작동하는 로드밸런서로 AWS에서 소개하는 로드밸런서 중 가장 낮은 계층에서 활동하는 로드밸런서입니다. 

 

참고로 3계층은 IP 패킷이 왔다갔다하는 과정입니다. 

 

GWLB는 들어오는 트래픽에 대해 방화벽을 반드시 통과해야 한다거나 모든 트래픽을 다 잡아내어 분석한다던가 하는 경우에 사용할 수 있습니다. 

 

 

타겟그룹 (target group)

AWS의 ELB를 사용하면서 가장 많이 보게될 단어인 타겟 그룹에 대해서 잠시 짚고 넘어가도록 하겠습니다. 타겟 그룹은 로드밸런서가 바라봐야할 대상을 가리킵니다. 

 

즉, 타겟그룹은 EC2 인스턴스가 될 수도 있고, 온프레미스 서버가 될 수도 있다는 의미입니다. 보통 저희는 EC2 인스턴스를 바라보게 할것이지만요. 

 

또한, 로드밸런서가 바라보는 대상이 EC2 인스턴스와 온프레미스 그리고 또 다른 로드밸런서일 수 있습니다. 

 

이렇게 로드밸런서를 계층화하면 보안을 더 신경쓸 수도 있고 트래픽을 분석할 수도 있습니다. 

 

실습

간단한 예시와 함께 ELB를 실습해보도록 하겠습니다. 이번 실습은 EC2 인스턴스를 만드는 것에 어느정도 익숙해져있다는 가정하에 진행됩니다. 따라서 생략되는 부분이 있을 수도 있습니다. 

 

1. EC2 인스턴스 생성

우선 EC2 인스턴스를 두개 생성할겁니다. EC2 인스턴스는 다음과 같은 설정을 진행했습니다. 

 

• AMI는 Amazon Linux
• 키페어는 없이 진행
• 보안 그룹은 ssh와 HTTP만 허용
• EBS 루트볼륨은 gp3에 8GB
• User Data에 초기값 설정

다른건 몰라도 User Data는 조금 생소하신 분들이 있을텐데 EC2인스턴스를 만들면 맨 아래 세부사항을 설정할 수 있는 것이 있습니다. 

 

 

맨 아래 User Data에 해당 내용을 입력하시면 퍼블릭 IP로 들어갔을 때 해당 내용이 출력됩니다. 

 

자 이제 로드밸런서를 만들어봅시다. 

 

2. 로드밸런서 생성

ALB를 선택해주시고 로드밸런서 이름, 네트워크 매핑은 모든 가용영역을 선택해주세요. 

 

그리고 사전작업으로 보안그룹을 만들어줍니다. 

 

HTTP 하나만 인바운드 규칙으로 생성해줍니다. 

 

그리고 우리가 만든 보안그룹을 선택합니다. 

 

그리고 타겟그룹을 만들어줘야합니다. "대상 그룹 생성" 클릭

 

3. 타겟그룹 만들기

타겟그룹 유형은 인스턴스, 타겟그룹 이름을 입력한 뒤 다음으로 넘어갑니다. 

우리가 방금 만든 인스턴스를 모두 선택하고 "아래에 보류중인 것으로 포함" 클릭 그리고 다음을 누릅니다. 

 

이렇게 타겟그룹을 만들었고 다시 로드밸런서 생성창으로 갑니다. 

마지막으로 로드밸런서를 생성해주면 끝입니다. 

 

그리고 조금 기다려야하는데 ELB는 타겟그룹이 사용가능한 정상적인 인스턴스인지 확인하기위해 헬스체크 구간을 거칩니다. 이 구간에서 실패가 뜨면 로드밸런서가 정상적인 인스턴스로 판단할 수 없기 때문에 트래픽을 운반하지 않습니다. 

 

헬스체크는 기본값이 루트 주소 (/) 로 가게 되어있고 30초마다 한번씩 헬스체크를 하며 총 5번의 200 상태코드가 내려와야 정상적인 인스턴스로 판단합니다. 

 

이 주기를 짧게 해줄 수 있지만 그냥 기다리면 되는 것이니 일단은 넘어가겠습니다. 그렇기 때문에 조금 기다려야합니다. 

 

이렇게 우리가 만든 타겟그룹을 라우팅해줍니다. 

 

로드밸런서가 프로비저닝 하는 시간도 있기 때문에 조금 기다려주시면 활성화가 됩니다. 그리고 보안그룹에 가보면?

 

헬스체크까지 완벽합니다. 

 

이제 우리가 만든 로드밸런서 안으로 들어옵니다. 그리고 DNS를 복사합니다. 

 

우리가 작성한 DNS구요 잘 뜹니다. 새로고침을 눌러보면?

 

네 잘되네요. 

 

포스팅이 너무 길어져서 뒤에 내용은 다음 포스팅에서 진행하도록 하겠습니다. 다음 포스팅에서 봬요!