블록체인
블록체인

ELB(Elastic Load Balancing)

목차

개요

ELB의 확장/축소는 스케일업/스케일다운과 스케일아웃/스케일인이라는 2가지 방식이 상황에 맞게 이루어짐
모두 ELB 접근 IP가 변경되므로, ELB에 접근하는 경우 ELB를 생성할 때에 생성되는 도메인 이름을 사용해 접근하도록 구성해야 함
싱글 AZ 구성과 멀티 AZ 구성 가능

ELB 특징

1.
고가용성
2.
상태확인 : 대상그룹에 대한 Keppalive를 통해 주기적인 상태 확인
3.
보안 기능 : 보안 그룹을 적용 가능(단, NLB는 보안 그룹이 적용되지 않음)
4.
4계층/7계층 로드 밸런싱
5.
운영 모니터링 : ELB 애플리케이션 성능을 실시간으로 모니터링 가능

구성요소

로드밸런서는 리스너와 대상그룹으로 이루어짐

리스너

부하 분산 처리를 위한 서비스 정의
프로토콜 및 포트를 사용하여 연결 요청을 확인하는 프로세스
로드밸런서에서 서비스하고자 하는 프로토콜과 포트를 지정하는 규칙 생성

대상그룹

부하 분산 대상 그룹 정의
하나 이상의 대상을 라우팅하여 부하 분산을 하는 데 사용
대상그룹에 속핸 대상에 대해 주기적으로 확인하는 프로세스를 통해 Health Check를 수행하여 정상적인 상태의 대상에게만 데이터를 전달

ELB 종류

1. Application Load Balancer(ALB)

OSI 계층 7에서 작동
HTTP, HTTPS 트래픽 로드밸런싱
다른 로드 밸런서에 비해 처리 속도가 조금 느림
HTTP(S)에 대해 세부적이고 다양한 정책으로 라우팅 가능
URL 경로 호스팅, 호스트 기반 라우팅, HTTP 헤더 기반 라우팅 등 규칙을 생성하여 포워드, 리다이렉션, 지정 HTTP 응답 등의 작업 수행 가능
Lambda 함수를 호출하여 HTTP(S) 요청 처리 가능

2. Network Load Balancer(NLB)

OSI 계층 4에서 작동
TCP, UDP, TLS 트래픽 로드밸런싱
가장 빠른 처리 속도 가능
고정 IP나 탄력적 IP를 보유 가능
VPC 엔드포인트 서비스로 연결하여 프라이빗 링크 구성 가능

3. Gateway Load Balncer(GLB)

GENEVE를 지원하는 여러 타사 가상 어플라이언스를 배포 및 관리해야 하는 경우 게이트웨이 로드 밸런서를 선택하십시오. 이러한 어플라이언스를 사용하면 보안, 규정 준수 및 정책 제어를 개선할 수 있습니다.

4. Classic Load Balancer(이전세대)

EC2-Classic 네트워크에서 실행 중인 기존 애플리케이션이 있는 경우 사용(AWS는 2022년 8월 15일에 EC2-Classic 네트워크를 중단)

ELB 통신 방식

인터넷 연결

퍼블릭 주소를 가지고 있어 인터넷을 통해 로드 밸런서에 등록퇸 ETC 인스턴스로 라우팅

내부

프라이빗 주소만 가지고 있어 로드 밸런서를 위한 VPC 내부에 액세스하여 등록된 EC2 등 컴퓨터 자원으로 라우팅

SSL 터미네이션

HTTPS 통신에서 사용하는 SSL 증명서를 인증하는 기능
인스턴스들에 따로 SSL 증명서를 설정할 필요 없음

AWS Certificate Manager를 이용하여 추가

AWS Certificate Manager 에서 도메인 선택 후 Route 53에 CNAME 레코드 등록하여 인증서 발급
리스너에 HTTPS 추가 후 인증서 선택

사설인증서 추가

리스너에 HTTPS 추가 후 openssl로 인증서 생성(.key : 프라이빗 키, .crt : 증명서, .csr : 증명서에 서명 추가 ) 후 .key, .crt업로드

스티키 세션

같은 사용자의 요청을 같은 인스턴스에서 처리하게 만드는 기능
최근에는 ELB 아래에 있는 인스턴스들의 세션 정보를 공유하는 시스템(Memcached, Redis, ElastiCache)를 사용
시스템들의 내결함성, 확장성이 더 좋음

로깅

로그를 같은 리전의 S3에 출력 가능
ELB에 대해 s3:PutObject 권한을 부여해야 함

[실습] ALB와 NLB를 통한 로드 밸런싱

1. CloudFormation으로 환경 구성
2. My-EC2 인스턴스에서 ELB-EC2-1, ELB-EC2-2로 HTTP, SNMP 서비스 확인
로드 밸런서 없이 개별 시스템으로 직접적으로 요청하여 서비스 확인
My-EC2 콘솔 [ec2-user@ip-20-0-0-169 ~]$ curl 3.36.61.163/index.html <h1>ELB-EC2-1 Web Server</h1> [ec2-user@ip-20-0-0-169 ~]$ curl 3.36.61.163/dev/index.html <h1>ELB-EC2-1 Dev Web Page</h1> [ec2-user@ip-20-0-0-169 ~]$ snmpget -v2c -c public 3.36.61.163 1.3.6.1.2.1.1.5.0 SNMPv2-MIB::sysName.0 = STRING: ELB-EC2-1 [ec2-user@ip-20-0-0-169 ~]$ curl 13.209.97.240/index.html <h1>ELB-EC2-2 Web Server</h1> [ec2-user@ip-20-0-0-169 ~]$ curl 13.209.97.240/mgt/index.html <h1>ELB-EC2-2 Mgt Web Page</h1> [ec2-user@ip-20-0-0-169 ~]$ snmpget -v2c -c public 13.209.97.240 1.3.6.1.2.1.1.5.0 SNMPv2-MIB::sysName.0 = STRING: ELB-EC2-2 [ec2-user@ip-20-0-0-169 ~]$
Bash
복사
[참고] SNMP는 OID(Object Indentifier)라는 값을 호출하여 디바이스에 대한 정보 파악 가능
Ex) OID 1.3.6.1.2.1.1.5.0 → System Name
[ALB를 통한 로드 밸런싱]
HTTP 서비스에 대한 부하분산
1. 대상그룹 생성
유형(인스턴스 / IP / Lambda 함수) 선택
프로토콜(HTTP), 포트(80) 선택
상태검사 프로토콜, 경로 선택
속할 인스턴스 지정
[참고] 상태 검사에 대한 항목별 의미
프로토콜/경로
- 상태 검사를 수행할 프로토콜과 경로 지정 - ALB에서는 HTTP, HTTPS만 선택 가능 - NLB에서는 TCP, HTTP, HTTPS선택 가능
포트
- 선택한 프로토콜에 대한 포트 정의 - 서비스 용도의 트래픽 포트나 임의의 포트를 지정
정상 임계값
- 비정상 상태에서 정상 상태 확인까지 확인하는 검사 횟수
비정상 임계값
- 대상을 비정상으로 간주하기까지 연속적 검사 실패 횟수
제한 시간
- 상태 검사 실패까지 제한 시간
간격
- 개별 상태 검사의 간격 시간
성공 코드
- 응답 성공을 확인하는 HTTP 코드 번호
2. ALB 생성
체계(인터넷 경계 / 내부) 선택
리스너 선택(프로토콜, 포트, 대상그룹)
가용영역, 서브넷 선택
보안그룹 선택
- ALB 생성하면 대상그룹 내 인스턴스의 상태가 initial → healthy상태로 변경
[참고] ALB의 로드밸런싱 알고리즘은 기본적으로 라운드 로빈 방식(대상에 대해 균일하게 번갈아 수행하는 방식)
3. ALB 동작 확인
ALB DNS 주소로 접속 시도하면 대상그룹 내 2대의 EC2 인스턴스로 부하 분산되는 것을 확인 가능
My-EC2 콘솔 [ec2-user@ip-20-0-0-169 ~]$ curl ALB-TEST-680952564.ap-northeast-2.elb.amazonaws.com/index.html <h1>ELB-EC2-1 Web Server</h1> [ec2-user@ip-20-0-0-169 ~]$ curl ALB-TEST-680952564.ap-northeast-2.elb.amazonaws.com/index.html <h1>ELB-EC2-2 Web Server</h1> [ec2-user@ip-20-0-0-169 ~]$
Bash
복사
4. 경로기반 라우팅 기능 설정
EC2-1은 /dev 페이지, EC2는 /mgt 페이지를 가지고 있으며 가끔 404 응답 돌아올때가 있음. 이를 해결하기 위해 URL 경로 정보를 확인하여 원하는 대상으로 라우팅을 할 수 있도록 설정
1) 대상그룹 분리
대상그룹을 2개만들어서 각각 1개의 인스턴스를 지정
Dev-Group : EC2-1, Mgt-Group : EC2-2
2) ALB에서 경로기반 라우팅 설정(리스너 규칙 추가)
/dev 경로로 향하는 url 주소는 Dev-Group에 속한 인스턴스로 전달하고, /mgt 경로로 향하는 url; 주소는 Mgt-Group에 속한 인스턴스로 전달하라는 의미
[NLB를 통한 로드 밸런싱]
SNMP(UDP/161) 서비스에 대한 부하분산
1. 대상그룹 생성
유형(인스턴스 / IP / Lambda 함수) 선택
프로토콜(UDP), 포트(161) 선택
상태검사 프로토콜, 경로 선택 - 상태검사 프로세스에 UDP는 적합하지 않기 때문에 지원하지 않음
속할 인스턴스 지정
[참고] 상태 검사에 대한 항목별 의미
프로토콜/경로
- 상태 검사를 수행할 프로토콜과 경로 지정 - ALB에서는 HTTP, HTTPS만 선택 가능 - NLB에서는 TCP, HTTP, HTTPS선택 가능
포트
- 선택한 프로토콜에 대한 포트 정의 - 서비스 용도의 트래픽 포트나 임의의 포트를 지정
정상 임계값
- 비정상 상태에서 정상 상태 확인까지 확인하는 검사 횟수
비정상 임계값
- 대상을 비정상으로 간주하기까지 연속적 검사 실패 횟수
제한 시간
- 상태 검사 실패까지 제한 시간
간격
- 개별 상태 검사의 간격 시간
성공 코드
- 응답 성공을 확인하는 HTTP 코드 번호
2. NLB 생성
체계(인터넷 경계 / 내부) 선택
리스너 선택(프로토콜, 포트, 대상그룹)
가용영역, 서브넷 선택
NLB는 ALB 설정과 다르게 보안 그룹 설정 기능 없음(보안정책은 인스턴스 레벨에서 적용하여 보안조치)
- ALB 생성하면 대상그룹 내 인스턴스의 상태가 initial → healthy상태로 변경
3. NLB 동작 확인
NLB DNS 주소로 접속 시도하면 대상그룹 내 2대의 EC2 인스턴스로 부하 분산되는 것을 확인 가능
My-EC2 콘솔 [ec2-user@ip-20-0-0-169 ~]$ snmpget -v2c -c public NLB-TEST-6492d972087ba0a7.elb.ap-northeast-2.amazonaws.com 1.3.6.1.2.1.1.5.0 SNMPv2-MIB::sysName.0 = STRING: ELB-EC2-1 [ec2-user@ip-20-0-0-169 ~]$ snmpget -v2c -c public NLB-TEST-6492d972087ba0a7.elb.ap-northeast-2.amazonaws.com 1.3.6.1.2.1.1.5.0 SNMPv2-MIB::sysName.0 = STRING: ELB-EC2-2
Bash
복사
4. 패킷 확인
EC2-1 콘솔 https://aws.amazon.com/amazon-linux-2/ [ec2-user@ELB-EC2-1 ~]$ sudo tcpdump udp port 161 -nn tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 11:55:24.915190 IP 3.36.97.173.55938 > 10.0.0.174.161: GetRequest(28) .1.3.6.1.2.1.1.5.0 11:55:24.915470 IP 10.0.0.174.161 > 3.36.97.173.55938: GetResponse(37) .1.3.6.1.2.1.1.5.0="ELB-EC2-1"
Bash
복사
NLB IP가 아닌 My-EC2 IP(3.36.97.173)가 패킷에 적혀있는 것을 확인(즉, NLB는 클라이언트IP를 자신의 IP로 대체해서 전달하지 않음)
[참고]
ALB : 클라이언트 IP를 보존하지 않고 자신의 IP로 대체하여 전달
클라이언트 IP를 보존하지 않으면 서버 입장에서 어떤 대상의 IP가 접근했는지 알 수 없기 때문에 ALB에서는 X-Forwarded-For 헤더라는 곳에 클라이언트 IP 정보를 담아서 전달
NLB : 클라이언트 IP를 보존(유형이 인스턴스가 아닌 IP유형이라면 출발지 IP를 보존하지 않음)