aws 교과서 - 부하분산 서비스 (3장) ALB 실습편
부하분산이란 서버-클라이언트 환경에서 서버가 클라이언트가 요청한 작업에 대해
동일한 목적을 수행하는 다수의 서버에 분산 처리하는 기능으로 클라우드환경에서
이런 부하분산을 로드밸런싱 이라고 하며 수행하는 대상을 로드 밸런서 라고 합니다.
로드 밸런서가 왜 필요하냐면
서버 A , B 가 존재할 때
서버 A에 장애가 발생시 부하분산 서비스가 없으면 서버 A가 장애라 응답이 없지만
부하분산 서비스를 제공시 서버B가 응답하여 트래픽 관리가 용이합니다.
흔히 말하는 고가용성 서비스란:시스템이나 서비스가 지속적으로 작동 하도록 기능입니다.
AWS 에서는 ELB 라는 로드 밸런싱 기술을 제공합니다.
ELB는 EC2 인스턴스 에서 운영중인 애플리케이션, 컨테이너 서비스로 유입4되는 트래픽을 자동 분산 처리해주며
여러 가용 영역에서 작동해 가용성을 향상 시키고 HTTP,TCP 등 다양한 프로토콜을 지원합니다.
CloudWatch 기능을 이용하여 로그 와 메트릭 모니터링도 가능하며 오토스케일링을 같이 사용한다면 가용성을 더더욱 유지하기 용이합니다.
이러한 ELB의 구성요소는
로드밸런서 , 대상그룹 , 리스너로 이루어져있으며
동작 방식 순서를 간단하게 설명드리자면
1-클라이언트 요청 수신을 통해 로드밸런서는 클라이언트와 연결을 유지하며 리스너를 등록하고
2-대상 그룹 선택 을 통해 요청을 처리할 대상을 선택합니다.
3-후에 트래픽 분산 과정을 통해 - 요청을 분산하며 로드밸런서는 가용 대상이 아닌 자원을 제외합니다.
4- 분산된 요청을 처리 후 클라이언트에 응답을 반환합니다.
그런데
가용영역에 인스턴스가 불균형하게 존재한다면
비중이 다르게 트래픽이 전송될 것입니다.
이러한 문제를해결하기 위해 ELB 교차 영역 밸런싱이 존재합니다.
교차 영역 밸런싱을 사용하면 가용 영역과 무관하게 대상 자원의 비율을 고려해 효과적으로 로드밸런싱이 가능합니다.
AWS ELB 의 종류로는
CLB - 가장 초기 출시 로드 밸런서 , 4,7계층의 프로토콜 지원 고정 IP 주소 사용 특징
ALB - L7 로드 밸런서 웹 애플리케이션 프로토콜 지원 특징
NLB - L4 로드 밸런서 전송 프로토콜 지원 특징
GWLB - 네트워크 트래픽을 서드 파티의 방화벽/어플라이언스 장비로 부하분산 처리 로드밸런서 특징
여기 까지 부하분산 이론에 대해서 간단하게 공부하였으니 이번엔 실습을 해보겠습니다.
이번 실습에선 실습을 위한 기본 인프라를 CloudFormation 을 이용하여 배포하겠습니다
CloudFormation은 Iac 기반으로 AWS 인프라 리소스를 자동으로 생성하는 서비스 입니다.
IaC: 수동으로 자원 생성이 아닌 선언된 코드 기반으로 자원 생성
AWS 리소스간 종속성 관리 : CloudFormation을 사용하면 리소스간 종속성을 템플릿에 정의할 수 있으므로 수동으로 관리하는 것보다 관리가 쉽습니다.
인프라 관리의 자동화 : CloudFormation 을 사용하면 인프라 구성을 자동화 하여 운영 비용을 줄이고 인프라 관리를 최소화 할 수 있습니다.
CloudFormation 서비스에서 스택 생성을 눌러 스택 생성 URL을 입력해줍니다.
스택 세부 정보 지정에서 키네임에서 키파일을 사용자 키 페어 파일을 선택해 주고 이름은 자유롭게 설정해주세요.
스택 옵션 구성과 검토는 별도 설정없이 완료하고 기본 인프라 구성이 모두 완료되면 크레이트-컴플리트 가 되어 모든 인프라가 정상적으로 잘 배포된걸 확인할 수 있습니다.
배포된 자원 목록입니다.
myVPC 에는 MyEC2 서버를 배치해 로드밸런싱 기능 테스트를 진행하며
ELB-VPC 에서는 실습에 사용 되는 서버가 위치합니다.
server 1,2 에 SSH 접속하여 설치된 툴과 파일을 확인하였습니다.
서버 1에는 dev 라는 폴더가 2에는 mgt 라는 폴더가 생성 되었습니다.
각 서버에 있는 다른이름의 폴더는 로드 밸런싱 실습에 사용됩니다.
MyEC2 에서 서버 1,2,3 으로의 HTTP 서비스와 SNMP 서비스 확인입니다.
변수 지정 및 확인
서버1의 웹서비스 확인 과정입니다.
SERVER1 SNMP 서비스 확인
서버2의 웹서비스, SNMP
서버3의 웹서비스, SNMP 확인 입니다.
앞서 구상된 정보로 ALB를 생성하여 각 가용영역별 로드밸런싱 과정을 확인해보겠습니다.
로드밸런싱 대상그룹 설정 정보입니다.
모든 인스턴스 체크후 아래 보류중인것으로 포함후 그룹생성합니다.
이제 로드밸런서를 생성하겠습니다
애플리케이션 로드밸런서를 생성합니다
밸런서 이름과 사용 VPC 가용영역을 체크합니다.
보안그룹 리스너,라우팅 설정입니다
생성후 프로비저닝 시간을 기다리면 상태가 활성으로 변경됩니다.
ALB 동작 확인을 위한 구성도 그림입니다.
myec2에서 http 서버인 서버1,2,3 에 접근할 떄 직접 접근이 아닌 ALB 도메인 주소로 접근을 하는데
이떄 정의한 리스너정책에 의해 ALB 를이용해 로드 밸런싱이 됩니다.
ALB DNS 이름 변수 지정후
dig로 질의 수행한 모습입니다.
두개의 유동 공인 IP가 출력되는데 번갈아 가며 접속하는 IP입니다.
curl 접속 테스트 결과입니다.
반복물을 사용해 20,90번 접속을 수행후 동일한 결과값을 모은 결과입니다.
조금의 오차는 있지만 수행횟수가 많아질수록 33%의 비중으로 균등하게 로드밸런싱이 되는걸 확인할 수 있습니다.
명령어를 사용해 로드밸런싱 기능에 의해 서버마다 접근 가능을 확인하였습니다.
웹 접근시 사용되는 경로가 존재하지 않는 서버는 로드 밸런싱 이 요청한 응답을 오류메시지로 요청하는것을 확인하였습니다.
로드 밸런싱은 기본적으로 RR 방식이기 떄문에 ALB를 생성할 떄 동일한 대상 그룹에 묶여있는 서버에 순차적으로 요청합니다.
이 문제를 해결하기 위해 동일한 경로 서비스를 하는 서버를 각 대상 그룹으로 묶고 , 경로 기반 라우팅기능을 수행해보겠습니다.
새로 대상그룹을 생성해 서버1만 추가합니다
이후 서버 2,3 만추가한 대상그룹을 하나더 생성합니다.
로드밸런서에서 생성된 ALB 규칙을 추가하였습니다
dev 를 먼저 생성후 임의로 우선순위 부여후 mgt 또한 같은방법으로 생성하였습니다.
터미널에서 경로 기반라우팅이 잘 동작하는지 확인하였으며 규칙에 매칭되어 잘 동작 중인것을 확인하였습니다.
이번에는 user-agent 정보를 확인해 특정장치의 접근을 차단하는 실습입니다.
dig $ALB +short 명령어를 이용해 출력된 IP를 스마트폰의 입력해서 접근해보면
정상적으로 접근이 잘되는것을 확인할 수 있습니다.
이제 user-agent 를 이용해 스마트폰의 접근을 막는 규칙을 생성해보겠습니다.
이제 사용중인 스마트폰으로 접속시 설정한 응답 메세지가 출력되는것을 확인할 수 있습니다.
인스턴스에서는 정상적으로 접근이 됩니다.
다음에는 NLB 로드밸런서를 생성하고 동작을 확인해보겠습니다.