Elastic Load Balancer (ELB) : (2)

앞선 포스팅과 이어지는 내용입니다. 

 

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

Elastic Load Balancer (ELB) : (1)

 

우리는 인스턴스를 생성했고 로드밸런서를 생성했으며 타겟그룹까지 생성했고 로드밸런서에 타겟그룹을 라우팅하는 작업까지 끝났습니다. 

 

근데 이러고 보니까 조금 문제가 있습니다. 

 

바로 사용자가 로드밸런서에 접근할 때마다 새로운 애플리케이션으로 연결해주는데 로그인을 했는데도 로그인이 풀려버리는 상황이 생겼습니다. 

 

로드밸런서는 잘못이 없습니다. 로드밸런서는 사용자가 로그인을 했건 말건 새로운 애플리케이션으로 보내주는게 정상이니까요. 

 

세션으로 로그인을 유지한다고 한들 A라는 컴퓨터에 세션을 저장해뒀을테지만 B라는 컴퓨터로 로드밸런서가 보내버리면 저장했던 세션은 무용지물입니다. 

 

이런 사용자의 불만을 잠재우기위해 우리는 고정세션이라는 것을 설정해야합니다. 

 

Sticky Session

말 그대로 세션을 고정하는 것입니다. 이건 실습으로 바로 보여드리겠습니다. 

 

우선 타겟그룹 페이지로 이동합니다. 

 

타겟그룹 선택 > 작업 > 타겟그룹 속성 편집

 

이렇게 누르면 다음과 같은 창이 뜹니다. 

 

그리고 저기 "Turn on stickness"를 클릭하면?

 

이런 창이 새로 뜹니다. 

 

이 고정세션은 쿠키를 이용해서 세션을 고정시키는 것인데 로드밸런서 생성 쿠키와 애플리케이션 기반 쿠키의 차이는 쿠키 이름을 사용자가 직접 정의해줄 수 있냐 없냐의 차이입니다. 

 

저는 로드밸런서 생성 쿠키로 설정했습니다. 

 

그리고 저장을 누릅니다. 

 

적용되는데 시간이 조금 걸립니다. (1~2분)

이제 아무리 눌러도 하나의 애플리케이션에만 연결된 모습입니다. 

 

참고로 아까 타겟 그룹에 보시면

 

여기 로드밸런싱 알고리즘을 선택할 수 있는 곳이 있습니다. 

 

번역이 좀 이상한데 최소 미해결 요청은 Least Connection 인 것 같습니다. 

 

라운드 로빈은 정적 로드밸런싱 알고리즘으로서 DNS에 적혀있는 리스트를 보고 순서대로 트래픽을 분산시키는 방법입니다. 때문에 장애가 발생한 애플리케이션에 트래픽을 보낼 수도 있습니다. 

 

Least Connection은 동적 로드밸런싱 알고리즘으로서 트래픽을 애플리케이션에 보내기 전에 미리 헬스체크를 통해 지연시간을 체크합니다. 그리고 그 지연시간이 짧은 애플리케이션 서버쪽으로 트래픽을 보내줍니다. 

 

이런 알고리즘을 바꾸는건 사실 NginX에서도 설정값 하나만으로 바꿀 수 있는 것이지만 ELB는 역시 로드밸런서답게 "딸깍" 한번으로 설정을 바꿀 수 있습니다. 

 

하지만 다양한 로드밸런싱 알고리즘을 자유롭게 커스텀할 수 없는건 조금 아쉽긴 하네요. 

 

로드밸런싱 알고리즘에 대해서 더 자세히 알고 싶으신 분들은 아래의 링크를 참고해주세요!

 

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

로드 밸런싱 (Load Balancing)

 

Cross Zone Load Balancing

이건 말 그대로 가용영역을 뛰어넘는 로드밸런싱을 의미합니다. 

 

ap-northeast-2a에 존재하는 두개의 인스턴스와 ap-northeast-2b에 존재하는 여덟개의 인스턴스가 있습니다. 

 

만약 이 교차 영역 로드밸런싱을 하지 않는다면 ap-northeast-2a에 존재하는 인스턴스에 트래픽이 몰릴 것입니다.

 

이렇게 되면 한 군데에 더 많은 트래픽이 몰리게 되겠죠. 

 

이를 방지하고자 ALB를 선택하면 가용영역을 뛰어넘는 데이터 이동이 가능해집니다. 

 

ap-northeast-2a로 가야할 트래픽을 ap-northeast-2b로도 보내준다는 것입니다. 사실 AWS에선 가용영역을 넘어서는 데이터 이동은 추가과금이 되도록 설계되어있습니다. 

 

하지만 ALB는 이 Cross Zone Load Balancing이 디폴트 값이기 때문에 과금이 진행되지 않습니다. 

 

물론 다른 로드밸런서인 NLB나 GWLB는 이 설정을 킬 경우 추가 요금이 발생합니다. 물론 추가요금이 발생하는 NLB나 기본적으로 비싼 ALB나 별 차이 없긴 합니다. 

 

로드밸런서를 클릭하고 들어간 다음 속성탭에 들어가보면 위와같이 교차 영역 로드밸런싱이 켜져있는 것을 확인할 수 있습니다. 

 

SSL 인증서

요즘은 SSL이 아니고 TLS라고 해야 맞다고 하던데 저뿐만 아니라 인터넷상의 많은 개발자들이 아직도 이 둘을 묶어 한번에 SSL이라고 많이 부릅니다. 

 

그래서 저도 편의상 SSL이라고 부르겠습니다. 

 

로드밸런서에 SSL 인증서를 설정해두면 이동되는 패킷에 암호화를 진행합니다. 기존 HTTP의 패킷에 SSL을 붙였다하여 우리가 잘 아는 HTTPS 통신이 이루어지는 것입니다. 

 

이 부분의 내용은 해당 포스팅과 너무 벗어난 내용이기 때문에 따로 링크를 첨부해두도록 하겠습니다. 

 

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

ACM + ALB 를 이용해 HTTPS 적용하기 (1)

 

마치며

 

자 여기까지 EC2의 핵심 시스템 중 하나인 로드밸런서에 대해서 알아봤습니다. 사실 실습을 ALB만 했는데 NLB도 똑같습니다. 조금만 찾아보시면 바로 익숙해질 수 있습니다. 

 

여기서 조금 더 보완을 하자면 기존 EC2의 보안그룹을 HTTP의 80포트를 열어둔 것을 기억하시나요? 이는 EC2 인스턴스의 퍼블릭 IP를 알고있다면 얼마든지 EC2에 접근할 수 있다는 얘기입니다. 

 

이는 보안상으로 그리 좋지못한 방법입니다. 

 

때문에 EC2의 보안그룹에 SSH 통신을 제외하고 보안그룹을 로드밸런서로 설정하게 되면 보안상 더 깔끔해집니다. 이 부분은 따로 실습해보시는 것을 추천드리겠습니다. 

 

이번에 ELB를 본격적으로 공부하면서 원래 알고있었던 내용과 새롭게 알게된 내용으로 알찬 공부가 되었던 것 같습니다. 긴 글 읽어주셔서 감사합니다. 오늘도 즐거운 하루 되세요~