AWS ELB

Elastic Load Balancer? 🍪

Elastic Load Balancer : 들어오는 애플리케이션 트래픽을 Amazon EC2인스턴스, 컨테이너, IP주소, Lambda 함수와 같은 여러 대상에 자동으로 분산시킨다.

• 다수의 서비스에 트래픽을 분산 시켜주는 서비스

• Health Check : 직접 트래픽을 발생시켜 살아있는지 확인함

• Autoscaling과 연동 가능

• 여러 가용영역에 분산 가능

• 지속적으로 IP가 바뀌어 IP고정 불가능 : 항상 도메인 기반 사용

• Application Load Balancer : 어플리케이션 레벨에서 동작 ( 똑똑함 )

• Network Load Balaner : 네트워크 레벨에서 동작, TCP기반, Elastic IP할당 가능 ( 빠름 )

• Class Load Balaner : 옛날에사용

• Gateway Load Balaner : 먼저 트래픽을 체크함, 가상어플리케이션 배포/확장 관리를 위한 서비스

---

Target Group

• ALB가 라우팅할 대상의 집합

• Instance, IP(private), lambda, ALB

---

사용해보기

이미 만들어놓은 로드밸런서를 사용하기 위해 기존의 1번 인스턴스에 더해 2번 인스턴스를 만들어보았다.

1번 인스턴스 : Docker[redis], Docker[nodejs-server]

2번 인스턴스 : Docker[nodejs-server]

여러개의 서버에서 채팅이 잘 연결되는지 확인하기위한

실험용으로 로드밸런서를 사용하려고 만든거라 구조가 조금 이상하다.(이해바람)

추후 제대로 배포를 한다면

1번 인스턴스 : Docker[redis]

2번 인스턴스 : Docker[nodejs-server]

3번 인스턴스 : Docker[nodejs-server]

이렇게 쭉쭉 만들어서 1번 인스턴스를 제외한 나머지만 target group으로 만들어 로드밸런서를 돌리는게 나을것같다.

(그러면 1번 인스턴스만 메모리를 크게 설정하면 되기때문)

채팅서버는 redis의 pub/sub기능을 이용하기에 2번의 인스턴스는 1번 인스턴스의 redis에 연결해줘야한다.!

(즉 같은 redis서버를 공유해야함)

서로 연결이 되는지 핑을 쏴보자.

아마 안될것이다.ㅠㅠ

2번인스턴스에서 1번인스턴스의 redis를 연결하기 위해서는 보안그룹을 이용할 것이다.

2번 인스턴스의 보안그룹에 인바운드규칙에 1번 인스턴스의 인바운드규칙을 넣으면 된다.

(1 -> 2도 동일하게 인바운드규칙에 추가)

자. 이제 연결이 되었으니 redis서버에 연결을 해주자

그리고 로드밸런서의 target group에 인스턴스를 넣어주자.

healthy check가 두개다 성공으로 뜬다면

이제 클라이언트가 요청을 보낼때마다 1,2번 서버에서 번갈아가며 응답을 해줄것이다.

성공!

---

*****************************삽질한것*****************************

분명 로드밸런서는 잘돌아가고있고

graphql도 응답을 잘하고 있다..

하지만 채팅서버만 message: "Session ID unknown"을 뱉어내며 연결이 되지않았다.

대체 무엇이 문제지? 또 반나절 구글링하며 삽질을 해본다.

사실 저 에러 메세지를 찾는데 반나절이 걸렸다고 보는게 맞는거같다..

그전까진 로드밸런서가 문제인가? 보안그룹이 문제인가? 계속 이것저것 바꿔보았다.

에러메세지로 찾아본 결과

https://github.com/socketio/socket.io/issues/1739#issuecomment-64244359

이곳에서 정답을 얻게되었다.

 var socket = io.connect('https://www2.wecode.buzzntrend.com', {
   transports: ['websocket'],
 });

이렇게 선언해주니 잘 작동하였다.

이제 에러가 났던 이유를 알아보자.

공식홈페이지에서 이유를 찾아보니 HTTP 롱 폴링 전송이 Socket.IO 세션의 수명 동안 여러 HTTP 요청을 보내기 때문이라고 한다.

말이 조금 어려워서 내가 생각한대로 다시 말해보자면 빨간네모친상자를 보면 요청이 성공,실패를 반복하고 있다.

이러한 반복형태를 보이는 이유는 HTTP 롱 폴링 전송은 클라이언트의 요청이 항상 같은 서버에 도착해야되는데

로드밸런서의 라운드-로빈 알고리즘을 통해 매 순간 실시간 요청을 여러개의 서버에 뿌려주기 때문발생하는 것이다.

그렇다면 이문제를 해결하기 위해서는 target group에 있는 스티키세션을 활성화 시키면 된다.

스티키세션이란 첫 요청에 응답해준 서버에만 껌딱지 처럼 요청을 보내는것이다.

하지만 이부분은 나의 테스트 목적과 맞지 않기에 보류해 두었고 위처럼 transports:[‘websocket’] 을 적어줌으로써 폴링요청을 비활성화 시켜 해결하였다.

끝!