클라우드/AWS 서비스

ELB(Elastic Load Balancing)

비니화이팅 2022. 10. 18. 10:24

개요

  • 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 추가 후 인증서 선택

사설인증서 추가

스티키 세션

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

로깅

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

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

1. CloudFormation으로 환경 구성

http://bit.ly/cnbl0501

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 ~]$

[참고] 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 ~]$

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

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"
  • NLB IP가 아닌 My-EC2 IP(3.36.97.173)가 패킷에 적혀있는 것을 확인(즉, NLB는 클라이언트IP를 자신의 IP로 대체해서 전달하지 않음)

[참고]

  • ALB : 클라이언트 IP를 보존하지 않고 자신의 IP로 대체하여 전달
  • NLB : 클라이언트 IP를 보존(유형이 인스턴스가 아닌 IP유형이라면 출발지 IP를 보존하지 않음)

개요

  • 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 추가 후 인증서 선택

사설인증서 추가

스티키 세션

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

로깅

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

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

1. CloudFormation으로 환경 구성

http://bit.ly/cnbl0501

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 ~]$

[참고] 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 ~]$

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

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"
  • NLB IP가 아닌 My-EC2 IP(3.36.97.173)가 패킷에 적혀있는 것을 확인(즉, NLB는 클라이언트IP를 자신의 IP로 대체해서 전달하지 않음)

[참고]

  • ALB : 클라이언트 IP를 보존하지 않고 자신의 IP로 대체하여 전달
  • NLB : 클라이언트 IP를 보존(유형이 인스턴스가 아닌 IP유형이라면 출발지 IP를 보존하지 않음)

개요

  • 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 추가 후 인증서 선택

사설인증서 추가

스티키 세션

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

로깅

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

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

1. CloudFormation으로 환경 구성

http://bit.ly/cnbl0501

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 ~]$

[참고] 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 ~]$

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

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"
  • NLB IP가 아닌 My-EC2 IP(3.36.97.173)가 패킷에 적혀있는 것을 확인(즉, NLB는 클라이언트IP를 자신의 IP로 대체해서 전달하지 않음)

[참고]

  • ALB : 클라이언트 IP를 보존하지 않고 자신의 IP로 대체하여 전달
  • NLB : 클라이언트 IP를 보존(유형이 인스턴스가 아닌 IP유형이라면 출발지 IP를 보존하지 않음)

개요

  • 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 추가 후 인증서 선택

사설인증서 추가

스티키 세션

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

로깅

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

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

1. CloudFormation으로 환경 구성

http://bit.ly/cnbl0501

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 ~]$

[참고] 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 ~]$

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

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"
  • NLB IP가 아닌 My-EC2 IP(3.36.97.173)가 패킷에 적혀있는 것을 확인(즉, NLB는 클라이언트IP를 자신의 IP로 대체해서 전달하지 않음)

[참고]

  • ALB : 클라이언트 IP를 보존하지 않고 자신의 IP로 대체하여 전달
  • NLB : 클라이언트 IP를 보존(유형이 인스턴스가 아닌 IP유형이라면 출발지 IP를 보존하지 않음)