[AWS] 로드밸런서
로드밸런서는 여러개의 서버를 묶어서 하나의 IP나 도메인으로 접속할 수 있게 해주는 중간 시스템을 말한다.
서버의 부하가 늘면 늘수록 당연히 리소스를 늘려야 하는데, 단순히 컴퓨터 사양을 늘리는 것만으로는 한계가 너무 크다. 비싸기도 하고, 비효율적이고... 유연하지 못하기 때문이다.
그래서 서버를 키울 때는 사양을 늘리는 스케일업보단 그냥 서버 수를 잔뜩 늘려버리는 스케일아웃 방식을 사용한다. 늘려버린 다음에 로드밸런서로 합쳐주고 그러는 것이다.
AWS에서 로드밸런서는 EC2 페이지에서 관리할 수 있다.
로드밸런서는 다음과 같이 4가지가 제공된다.
어플리케이션 로드밸런서, 네트워크 로드밸런서, 게이트웨이 로드밸런서, 클래식 로드밸런서다.
이 포스트에서는 어플리케이션과 클래식 2개만 간단하게 다뤄보겠다.
클래식 로드밸런서
이건 말 그대로 구식 기능이다.
EC2로 직접 서버를 하나하나 구성하거나, Elastic Beanstalk 등의 버려진 서비스를 사용할때 가끔 사용한다.
이름을 잘 지어주고, 리스너로 어떤 포트를 연결시킬것인지를 지정한다.
왼쪽과 오른쪽은 서로 포트와 프로토콜이 같아야 한다.
로드밸런서 포트는 말 그대로 로드밸런서의 IP 포트고,
인스턴스 포트는 EC2 인스턴스의 포트다.
저러면 로드밸런서:80 로 접속을 시도할 경우 모든 EC2 인스턴스의 :80 포트로 연결해줄 것이라는 뜻이 된다.
나는 저거 외에도
TCP :3000 -> TCP :3000 리스너를 하나 추가해줬다.
express로 테스트를 해볼 것이기 때문이다.
그다음에는 보안그룹을 할당해주고
상태 검사를 구성해준다.
저걸로 지정한 경로로 핑을 날려서, 정상 동작하면 정상이라고 판단하는 것이다.
그다음에는 로드밸런싱할 EC2 인스턴스들을 지정해준다. 인스턴스는 따로 만들어야 한다.
나는 여기서 하나로 해뒀지만 얼마든지 더 추가할 수 있다.
태그는 지나가고
완성이다.
그러면 다음과 같이 로드밸런서가 생성될 것이다.
자신만의 도메인도 갖는다.
이렇게 해서 잘 연결된다면, EC2의 각각 주소로만 접속 가능하던 것들이
로드밸런서의 도메인으로 접속 가능해진다.
대충 이런식으로 써먹는 것이다.
어플리케이션 로드밸런서
이건 좀더 진화된 형태의 로드밸런서다.
기존의 클래식 로드밸런서는 할수있는게 별로 없다.
EC2에만 달 수 있고, 그마저도 한땀한땀 추가해주고, 삭제해주고, 번거롭게 관리해야 한다.
어플리케이션 로드밸런서는 그와 다르게 좀더 유연한 연결이 가능하고, EC2 뿐만 아니라, 람다, 그냥 IP, ECS 등에도 적용이 가능하다.
어플리케이션 로드밸런서는 다음과 같이 생성할 수 있다.
사용법이 크게 다르지는 않다.
이름을 잘 짓고, 리스너로 노출할 포트를 지정한다.
그리고 라우팅 구성에서 타겟 그룹으로 어떤 대상으로 연결시킬 것인지를 지정한다.
애플리케이션 로드밸런서는 EC2 인스턴스를 바로 꼽는게 아니라, 타겟 그룹이라는 것을 통해서 인스턴스들에 접근할 수 있도록 한다.
나는 EC2 인스턴스의 3000 포트로 연결시킬 것이므로, 위와 같이 설정을 해줬다.
그리고 타겟에 인스턴스를 등록해준다.
그럼 마찬가지로 로드밸런서가 잘 생성될 것이고,
로드밸런서의 도메인으로 인스턴스에 접근이 가능해진다.
그렇다.