로드벨런서 생성

# 개념

로드벨런서라는건 여러 인스턴스로 랜덤하게 연결해주는 단일진입점이다.

그림으로 표현하면,

클라이언트는 로드벨런서의 IP나 DNS로 진입하면, 로드벨런서는 이 트래픽을 첫번째 EC2나 두번째 EC2로 랜덤하게 연결해준다. 확률상으론 50대 50인거다.

일반적으로 로드벨런서가 없으면 한 인스턴스에 트래픽이 몰려서 부하가 생기고 서버가 터져버리지만, 로드벨런서가 있고 같은 기능을하는 EC2 인스턴스가 두 대가 있다면 이 트래픽을 반반으로 나눠 보내주기떄문에 서버가 터지지 않는다.

이러한 로드벨런서를 aws에서 구현해볼거다.

 

 

# 일단 EC2 두 개를 만들자.

이렇게 두개의 muzzi-web-1, muzzi-web-2를 만들었다.

각각은 웹서버로 동작하고 index.html에는 hello muzzi world 1, hello muzzi world 2라는 내용을 넣어줬다.

브라우저로 테스트 해보면, 

 

두 인스턴스를 웹서버로 동작하는 웹사이트가 잘 생성되었다. 

로드밸런서를 만들어서 이 두 EC2웹서버의 단일진입점을 만들어 줄거다.

 

 

 

 

# 로드 밸런서 생성

EC2콘솔에서 로드밸런서탭에 들어가자.

그리고 '로드밸런서 생성' 버튼을 눌러주자.

 

이런 로드밸런서 종류를 선택할 수 있는 창이 뜬다.

난 Application Load Balancer로 선택할거다.

사실 Network Load Balancer을 선택해도 만드는 방법은 크게 차이는 없다.

이 두가지 로드밸런서의 큰 차이는 네트워크의 계층차이다.

ALB(application load balancer)는 어플리케이션계층까지 가서 로드밸런싱을 해준다. 즉 7계층까지 가는거고, NLB(network load balancer)는 3계층까지만 가서 로드밸런싱을 해준다.

ALB가 더 높은 계층까지 올라갔다 내려오니 더욱 많은 기능을 설정할 수 있으나, 그만큼 더욱 작업이 무겁고, NLB는 3계층까지만 올라갔다오니 작업은 가볍지만 상대적으로 기능의 한계가 있다.

우리가 보통 VM을 파서 squid같은걸로 로드밸런싱을 해준다면 이건 어플리케이션까지 간다. 네트워크계층까지만 보려고 한다면 라우터 장비단을 만져야하는데 우리같은 개인은 사실 힘들다. 

aws의 장점이라고 볼 수 있는 특징이다.

마지막 게이트웨이 로드벨런서는 잘모르겠음..

암튼 ALB생성버튼을 눌러주자.

 

로드밸런서를 생성하는 설정을 해주는 페이지로 넘어가는데 난 이 로드밸런서 이름을 muzzi-web-alb로 만들거다.

아래는 체계, 아이피 주소유형이 나오는데 그냥 두면된다.

체계는 인터넷경계에서 로드밸런서를 만들거냐, 아니면 VPC내에서 만들거냐인데 난 그냥 default vpc에서 만들어볼거라 상관없다. 주소유형은 당연히 IPv4ㄱㄱㄱ

 

그다음 이제 네트워크 매핑이 있는데 이게 중요하다.

VPC는 따로 만들지않고 default로 할거라 따로 만질게 없지만

가용영역을 두개 이상 체크해줘야한다. 

일단 새로운 페이지를 띄워서 EC2 인스턴스들을 보자.

저렇게 가용영역이 나와있다.

둘다 2c라는 가용영역에 만들어진 인스턴스이므로 위에 선택할 가용영역중 2c로 끝나는 영역은 필수로 해주고 두개 이상 체크해줘야하니 나머지 하나는 아무거나 선택해주면 된다.

난 2c는 필수로 선택해줬고, 2a는 두개이상 선택해줘야해서 선택해놨다.

 

 

++ 가용영역이 뭐고 가용영역을 선택하는 이유는?

난 지금 서울리전에서 리소스들을 생성중인데, 이러한 리전마다 최소 세 개 이상의 가용영역이 있다. 서울리전은 현재 네 개가 있어서 저렇게 네 개의 가용영역이 뜬거다.

예시를 들어보자면

가용영역에 데이터베이스 센터가 있다.

이렇게 가용영역별로 각각 EC2 인스턴스가 띄워져있다고 생각해보자.

근데 가용영역2번의 데이터센터가 불이났다.

그러면 가용영역에 있던 모든 리소스들이 사용불가가 되는데, 그럼 로드벨런서가 헬스체크를 하고 가용영역 1번에 있는 EC2인스턴스에만 트래픽을 보내고 서비스는 유지가 될거다.

때문에 가용영역을 선택하는것이다.

 

 

 

 

다시 돌아가서,

다음으로 보안그룹을 선택해야하는데 로드밸런서도 80번 포트로 접속해야하니 80번 포트 http가 열려있는 보안그룹을 선택해주면된다. 아까 EC2인스턴스 만들었던 보안그룹을 선택하면 된다.

다음으로 이제 대상그룹을 선택해야하는데, 대상그룹이란 우리가 로드밸런싱을 할 두가지 인스턴스를 하나로 묶은걸 대상그룹이라고 한다.

그러나 현재 우리는 대상그룹을 만든적이 없다.

때문에 저기 '대상 그룹 생성'이라는 링크를 클릭해서 만들어주자.

링크를 클릭하면 새로운 웹페이지가 새창으로 뜨게된다.

 

이 그룹은 인스턴스가 모인 그룹이다. 기본으로 설정되어있다.

난 이름을 muzzi-web-instances로 정해줬다.

그리고 VPC는 default로 그냥 따로 안만졌다.

상태검사라고 만져줘야하는데 웹서버 이므로 /index.html파일을 대상으로 검사하겠다는거다.

이게 뭐냐면 로드밸런서는 만약 한 인스턴스가 병신이 되면 이곳에는 트래픽을 보내주지 않는다. 이걸 상태검사한다고 하는데 라운드로빈은 이러한 상태검사가 없어서 특정 클라이언트는 병신된 웹서버로 가게되므로 랜덤 복불복이 되어버린다.

로드밸런서의 헬스체크라고도 한다.

아래 '고급 상태 검사 설정'을 보게되면

이것저것 복잡한게 나오는데, 난 그냥 대충 저렇게 넣어줬다.

정상임계값 : 상태검사가 두번이상 성공하면 이건 살아있는 인스턴스다.

비정상임계값 : 상태검사가 두번이상 실패하면 이건 병신 인스턴스로 취급한다.

제한시간 : 상태검사 트래픽 보냈을때 답장 없으면 걍 병신인스턴스 취급하겠다.

간격 : 상태검사는 5초마다 한번씩 하겠다

성공코드 : 웹서버니까 200번 응답이 오면 성공으로 취급하겠다.

뭐 이런거다.

이제 최종적으로 다음 버튼을 눌러주면 

이러한 페이지로 넘어가게 되는데, 어떤 인스턴스를 넣을거냐라는거다.

대상그룹을 만들었어도 이 대상그룹에 어떤 인스턴스가 웹서버인지 정확하게 구분해줘야하기때문에 설정을 해줘야한다.

난 뭐 인스턴스 두개만 만들었으니까 이 두개 체크하고 아래에 보류중인걸로 포함버튼을누르자.

만약 vpc나 대상그룹 설정이 이상하게되어있으면 여기에 인스턴스가 안뜰수도 있다..

포함 버튼을 누른 후 아래 목록에 해당 인스턴스들이 내려가게된다.

최종적으로 '대상 그룹 생성'버튼을 눌러주자.

 

 

다시 로드밸런서 생성페이지로 돌아와

저기 새로고침 버튼을 누르면 아까 만든 대상그룹이 생긴다. 해당 대상그룹을 선택하자.

이제 '로드밸런서 생성' 버튼을 누르면 최종적으로 로드밸런서가 만들어진다.

이어지는 페이지에서 '로드밸런서보기' 버튼을 누르자.

막 생성한 muzzi-web-alb가 프로비저닝 상태이다. 

로드밸런서 여러번 만들어봤는데 하여튼 졸라 오래걸린다 항상.

활성이 될때까지 기다리자.

이제 로드밸런서가 활성화 되었다.

저기 로드밸런서 이름 링크를 클릭하고 들어가보면,

만든 로드밸런서 정보가 나오는데, 저기 DNS이름을 복사하자.

저 링크로 들어가면 로드밸런서 단일진입점으로 동작하고

로드밸런서에 연결한 muzzi-web-1, muzzi-web-2 인스턴스가 각각 웹서버로써 동작하고 각각 50%확률로 접속될거다.

 

브라우저에서는 hello muzzi world 2가 뜨고 멈추는데 아무래도 캐시때문인것 같다.

curl로 쳐보니 제대로 뜬다.

로드밸런서 dns로 curl요청을 하는데 hello muzzi world 1과 hello muzzi world 2가 랜덤으로 뜨는걸 볼 수 있다.