1. 부하분산이란
부하분산
- 서버-클라이언트 환경에서 서버가 클라이언트 요청을 받아 처리하는 과정에서 발생하는 부하(연산 작업)에 대해 동일한 목적을 수행하는 다수의 서버에 분산 처리하는 기능
- 고가용성 및 내결함성이 향상되어 장애가 발생할 때 유연하게 대처할 수 있고, 서비스를 안정적으로 유지할 수 있어 클라우드를 구성할 떄 반드시 사용해야 하는 기술
- 이런 부하분산을 로드 밸런싱(load balancing)이라고 하며, 부하분산을 수행하는 대상을 로드 밸런서(load balancer)라고 한다.
2. Amazon ELB 기능
- AWS에는 ELB(Elastic Load Balancing)라는 로드 밸런싱 기술을 제공한다.
- EC2 인스턴스에서 운영 중인 애플리케이션, 마이크로서비스 또는 컨테이너 서비스로 유입되는 트래픽을 자동 분산 처리하는 기술
- ELB는 여러 가용 영역에서 작동하여 애플리케이션 가용성을 향상시키고, HTTP, HTTPS, TCP, SSL 등 다양한 프로토콜을 지원하며, 사용자가 같은 인스턴스에서 세션을 유지할 수 있도록 지원한다.
- AWS의 CloudWatch 기능을 이용하여 로그와 메트릭을 모니터링할 수 있으며, AWS의 오토 스케일링 기능과 결합해서 트래픽이 증가할 때 자동으로 인스턴스를 추가하거나 제거하면서 애플리케이션 가용성을 유지한다.
- ELB는 네트워크 및 응용 프로그램 수준의 로드 밸런싱을 지원하여 다양한 애플리케이션에 적용할 수 있으며, SSL 암호화를 지원하여 애플리케이션의 보안을 강화한다.
1) Amazon ELB 구성요소
로드 밸런서
- 여러 대의 EC2 인스턴스, IP 주소, 람다 등을 사용하여 트래픽을 대상 그룹에 있는 인스턴스로 분산시켜 애플리케이션의 가용성을 유지하는 역할
- 사용자의 요청을 받아 애플리케이션 서버로 전달하고, 애플리케이션 서버의 응답을 사용자에게 반환
대상 그룹
- 로드밸런서에서 분산할 대상의 집합을 정의하는 구성 요소
- 대상 그룹의 인스턴스에 대해 정적 또는 동적으로 구성할 수 있으며, 라우팅 규칙에 따라 요청을 받아들일 대상 그룹을 선택
- 로드밸런서는 대상 그룹에 포함된 대상들의 상태를 정기적으로 확인하여 장애 발생 대상을 자동으로 제외하고, 정상적으로 동작하는 대상에만 요청을 전달
리스너
- 로드 밸런서에서 사용할 포트와 프로토콜을 설정하는 구성 요소
- 리스너는 로드 밸런서에서 클라이언트 요청을 수신하고, 해당 요청을 처리할 대상 그룹을 선택하는 역할을 한다.
- 리스너는 로드 밸런서에 연결된 프로토콜과 포트를 사용하여 클라이언트 요청을 수신하고, 해당 요청을 대상 그룹으로 라우팅한다.
Amazon ELB 구성 요소
2) Amazon ELB 동작 방식
- Amazon ELB를 생성하면 설정한 가용 영역별로 로드 밸런서 노드가 생성되고 앞단에 리스너를 실행한다.
- 리스너는 다양한 프로토콜(HTTP, HTTPS, TCP 등)을 지원하며, 요청에 대한 대상 그룹의 라우팅을 정의한다.
- 이에 따라 로드 밸런선느 가용 영역에 속한 대상 그룹의 인스턴스로 트래픽을 전달한다.
1. 클라이언트 요청 수신
- 로드 밸런서에서 클라이언트 요청을 수신한다. 로드 밸런서는 클라이언트와 연결을 유지하며, 요청을 수신하려고 리스너를 등록한다.
2. 대상 그룹 선택
- 수신한 클라이언트 요청을 처리할 대상 그룹을 선택한다. 대상 그룹은 인스턴스, IP 주소, 람다 함수, ALB 등 여러 유형의 대상으로 구성된다.
3. 트래픽 분산
- 선택된 대상 그룹에서 요청을 처리할 대상을 선택하고 해당 대상으로 요청을 분산한다.
- 이때 로드 밸런서는 각 대상의 가용성 상태를 모니터링하고 가용하지 않은 대상을 제외한다.
4. 응답 반환
- 분산된 요청을 대상에서 처리하고 클라이언트에 응답을 반환하다.
3) Amazon ELB 교차 영역 로드 밸런싱
ELB 교차 영역 로드 밸런싱(cross-zone load balancing)
- 여러 가용 영역에 걸쳐 있는 EC2 인스턴스나 컨테이너 등 대상을 더 효과적으로 로드 밸런싱하는 기능
- 가용 영역별로 인스턴스 수량이 불균형하게 위치할 떄 트래픽 비중을 보정할 수 있으며, 트래픽을 분산하는 기준이 가용 영역이 아닌 대상 그룹에 속한 자원을 기준으로 균일한 비중의 로드 밸런싱 수행 가능
- 교차 영역 로드 밸런싱은 ALB를 사용할 때 기본적으로 활성화되어 있으나 NLB는 비활성화 되어 있다.
4) Amazon ELB 종류
CLB(Classic Load Balancer)
- 4계층과 7계층 프로토콜을 모두 지원
- HTTP / HTTPS 요청에 따른 최신 HTTPv1.2 프로토콜과 TCP의 SSL/TLS 암호화 프로토콜도 지원하며, SSL 인증서를 사용한다,
- 고정 IP 주소를 사용하여 로드 밸런서를 생성하고, 로드 밸런서에 대한 DNS 이름으로 액세스할 수 있다.
- 현재는 NLB와 ALB 같은 새로운 로드 밸런서 서비스가 출시되어 CLB를 대체해서 사용하는 추세이며, CLB는 레거시(legecy) 서비스로 분류된다.
ALB(Application Load Balancer)
- AWS에서 제공하는 L7 로드밸런서로, HTTP/HTTPS 같은 웹 애플리케이션 프로토콜을 지원한다.
- ALB는 대상 그룹 단위로 트래픽을 분산하며, 각 대상 그룹은 ALB가 요청을 전달할 EC2 인스턴스, 람다 함수, 컨테이너 및 IP 주소로 라우팅하는 기능을 제공한다.
특징
- HTTP 헤더를 확인하여 다양한 라우팅 기능을 제공한다.
- 오토 스케일링과 함께 사용하여 확장성 있는 애플리케이션을 구성할 수 있다.
- 대상 그룹 내 인스턴스에 대해 상태 검사를 수행하고, 문제가 발생하면 자동으로 장애 조치를 취할 수 있다.
- Amazon CloudWatch Logs와 통합되어 로그 및 지표 데이터를 수집하고 모니터링 및 분석을 할 수 있다.
NLB(Network Load Balancer)
- AWS에서 제공하는 L4 로드 밸런서로, TCP,UDP,TLS 프로토콜을 지원한다.
- ALB와 달리, 클라이언트와 로드 밸런서 간 연결을 TCP 레벨에서 유지하므로 대규모 트래픽을 처리할 수 있다.
- AWS에서 제공하는 다른 로드 밸런서보다 높은 처리량과 빠른 응답 시간을 보장하므로 게임 서버, VoIP 서비스, 미디어 스트리밍 등에서 사용
특징
- 높은 처리량 : 초당 수백만 개의 연결을 처리 가능
- 빠른 응답 시간 : 빠른 응답 시간을 위해 최적화된 L4 로드 밸런싱 알고리즘을 사용
- 높은 가용성 : 여러 가용 영역에서 인스턴스를 실행하고 매우 빠른 인스턴스 검색을 수행하여 신속하게 장애를 복구
- IP 주소 보존 : 클라이언트 IP 주소를 원래 IP 주소로 보존할 수 있다. 이것은 클라이언트 IP 주소를 유지하면서 로드 밸런싱을 수행할 수 있다는 것을 의미
- 모니터링 : AWS CloudTrail, Amazon CloudWatch Logs 같은 모니터링 기능을 지원
GWLB(GateWay Load Balancer)
- 네트워크 트래픽을 서드 파티의 방화벽/어플라이언스 장비로 부하분산 처리하는 로드 밸런서
- 요청에 따라 트래픽을 확장하거나 축소하면서 다수의 서드 파티 장비에 로드 밸런싱을 처리
- GWLB는 VPC 내에서 실행되는 애플리케이션의 가용성과 확장성을 향상시키는 데 사용되며, TCP 및 UDP 프로토콜을 지원하여 다양한 유형의 애플리케이션에 유연하게 적용할 수 있다.
2. ALB와 NLB를 이용한 로드 밸런싱 구성하기
- Amazon ELB의 ALB와 NLB로 로드 밸런싱 환경을 구성하여 다수의 인스턴스를 이용한 ELB의 동작 및 활용을 확인
실습 단계
- 실습을 위한 기본 인프라를 CloudFormation으로 배포
- 기본 인프라 환경을 검증
- ALB를 생성하고 동작 과정을 확인
- ALB의 경로 기반 라우팅 기능을 이용한 로드 밸런싱 방법을 구성하고 확인
- ALB의 User-Agent를 활용한 로드 밸런싱 방법을 구성하고 확인
- NLB를 생성하고 교차 영역 로드 밸런싱 기능 여부를 동작 과정을 거쳐 확인
- ALB와 NLB의 출발지 IP 보존 방식에 대한 동작 과정을 확인
1) CloudFormation 소개
- 실습 환경을 코드 기반으로 생성하는 기술은 CloudFormation을 사용하여 더 빠르고 정확한 실습 환경을 구성할 수 있다.
- CloudFormation은 IaC(Infrastructuer as Code) 기반으로 AWS 인프라 리소스를 자동으로 생성하는 서비스이다.
- CloudFormation을 사용하면 VPC, EC2 등 리소스를 수동으로 생성할 필요 없이 리소스들을 템플릿(코드)으로 구성하고 스택을 생성하여 해당 서비스의 프로비저닝과 설정을 미리 구성할 수 있다.
구성 요소
- 템플릿 : AWS 인프라를 JSON 또는 YMAL 형식의 코드로 정의하는 파일. 이 템플릿을 이용하여 AWS 인프라의 속성, 관계, 종속성 등을 정의한다.
- 스택 : CloudFormation을 이용하여 생성하는 AWS 인프라의 집합이다.
- 리소스: AWS CloudFormation이 생성하는 AWS 리소스이다.
- 파라미터 : 스택을 생성할 때 전달할 수 있는 매개변수, 이런 파라미터를 사용하면 템플릿을 재사용하여 다른 환경에 대한 스택을 쉽게 생성할 수 있다.
- 이벤트 : CloudFormation 스택에서 발생하는 모든 이벤트를 기록한다. 이런 이벤트는 스택 생성, 변경, 삭제와 관련된 정보를 제공한다. 이런 정보를 활용하여 스택 문제를 해결할 수 있다.
- CloudFormation : 템플릿을 해석하여 스택을 생성하고, 정의된 AWS 인프라르 생성,변경,삭제할 수 있다.
2) CloudFormation으로 기본 인프라 배포하기
- AWS 관리 콘솔에서 서비스 > CloudFormation 서비스로 들어가 스택 생성을 누른다.
- Amazon S3 URL에 URL을 입력하고 다음을 누른다.
- 스택 세부 정보 지정 페이지에서 다음과 같이 설정하고 다음을 누른다.
- 스택 이름은 'elblab'로 입력
- KeyName에서 사용자 키 페어 파일 선택
- AWS CloudFormation 기본 인프라를 배포하고 일정 시간이 지나 스택 상태가 'CREATE_COMPLETE'가 되면 모든 인프라 배포가 정상적으로 완료된 것
3) 기본 인프라 환경 검증하기
- 기본 인프라로 생성된 자원으로 보면 MyVPC와 ELB-VPC가 있다.
- MyVPC에는 MyEC2 서버를 배치하여 ELB에서 제공하는 로드 밸런싱 기능을 테스트하게 한다.
- ELB_VPC에는 실습에 사용되는 서버가 위치하며, ELB_VPC의 첫 번째 서브넷에 한 대, ELB_VPC의 두 번째 서브넷에 두 대 등 총 세 대의 서버를 서비스 제공용으로 배치해서 향후 실습에 활용
HTTP (HyperText Transfer Protocol)
- 인터넷에서 데이터를 주고받을 수 있게 하는 표준 프로토콜로, 웹 서버와 클라이언트 간에 데이터를 주고받을 때 사용한다.
- TCP 프로토콜을 사용하여 신뢰성 있게 데이터를 송수신하며, 80번 포트를 사용한다.
SNMP(Simple Network Management Protocol)
- 네트워크 장비들을 모니터링하고 관리하는 프로토콜
- 네트워크 장비들에 에이전트(agent)를 설치하고, SNMP 관리자와 에이전트 간에 메시지를 주고받는 방식으로 동작
- 일반적으로 MIB(Management Information Base)라는 데이터베이스를 사용하여 네트워크 장비의 상태 정보를 저장하는 데, 이를 OID라고 한다.
- UDP 프로토콜을 사용하며 161번 포트를 사용한다.
- 모든 구간은 퍼블릭 용도의 서브넷으로 구성되며, 인터넷 게이트웨이를 이용하여 외부 구간과 통신이 가능한 환경으로 구성했다.
- SERVER-1.2에 설치된 툴과 파일 확인
(스택 세부 정보에서 각각의 퍼블릭 ip 확인할 수 있음 => 지난 실습들과 동일하게 SSH 접속)
#SERVER-1의 SSH 터미널
#디렉터리(폴더) 트리 구조 출력
tree /var/www/html
#xff.php 파일 정보 확인(웹에서 해당 파일에 접근할 때 접속자 정보가 출력되도록 만든 실습 파일
car /var/www/html/xff.php
# SERVER-2의 SSH 터미널
tree /var/www/html
cat/var/www/html/xff.php
- SERVER-1에는 dev라는 폴더가 생성되었고, SERVER-2,3에는mgt라는 폴더가 생성된 것을 확인할 수 있다. 각 서버에 있는 다른 이름의 폴더는 향후 로드 밸런싱 실습에 사용할 것
- MyEC2에서 SERVER-1.2.3으로 HTTP 서비스와 SNMP 서비스를 확인
#MyEC2의 SSH 터미널
#SERVER-1,2,3의 퍼블릭 IP를 변수에 지정
EC21=3.36.51.69
EC22=43.201.65.82
EC23=13.125.252.129
#변수 지정 확인
echo $EC21
echo $EC22
echo $EC23
#SERVER-1 웹 서비스 확인
curl $EC21
curl $EC21/dev/
curl $EC21/mgt/
curl $EC21/xff.php
#SERVER-1 SNMP 서비스 확인
snmpget -v2c -c public $EC21 1.3.6.1.2.1.1.5.0
snmpget -v2c -c public $EC21 1.3.6.1.2.1.1.3.-
#SERVER 2.3도 동일하게 진행(생략)
4) ALB를 생성하고 동작 과정 확인하기
ALB 생성하기
- EC2 > 로드 밸런싱 > 대상 그룹 메뉴를 선택한 후 출력되는 페이지에서 대상 그룹 생성을 누른다.
- 그룹 세부 정보 지정 페이지에서 다음과 같이 설정하고 다음을 누른다.
- 대상 그룹 이름에 'ALB-TG'를 입력
- VPC에서 ELB-VPC 선택
- 대상 등록에서 실습에 사용할 모든 인스턴스를 체크한 후 아래에 보류 중인 것으로 포함을 누른다.
- 대상 그룹이 생성된 것을 확인 가능
- EC2 > 로드밸런서에 들어가서 로드 밸런서 생성을 누른다.
- 로드 밸런서 유형 선택 페이지에서 Application Load Balancer의 생성을 누른다.
- Application Load Balancer 생성 페이지에서 다음과 같이 설정하고 아래쪽에 있는 로드 밸런스 생성을 누른다.
- [기본 구성] 로드 밸런서 이름을 'ALB'로 입력
- [네트워크 매핑] VPC는 ELB-VPC 선택
- 선택한 VPC에서 사용할 가용 영역을 모두 체크
- [보안 그룹] 보안 그룹을 기존 default를 제거한 후 elbalb-ELBSG-XXXX 선택
- [리스너 및 라우팅] 리스너 HTTP:80 기본값, 대상 그룹은 앞서 설정한 ALB-TG 선택
- 생성된 로드밸런서는 일정 시간이 지나면 프로비저닝 상태에서 활성화 상태로 변경됨
ALB 동작 확인하기
- HTTP 클라이언트 입장인 MyEC2에서 HTTP 서버 입장인 SERVER-1.2.3으로 접근할 때, 각각의 인스턴스로 직접 HTTP 접근을 하지 않고 ALB 도메인 주소로 접근하게 한다. 이때 앞서 정의한 로드 밸런서 리스너 정책에 따라 생성된 ALB를 이용하여 서버로 로드 밸런싱이 된다.
- MyEC2 인스턴스에 SSH로 접속하여 다음 명령어를 입력한다.
- ALB 변수에는 ALB DNS 이름 입력
# MyEC2의 SSH 터미널
# ALB DNS 이름 변수 지정
ALB = ALB DNS 이름
echo $ALB
# dig로 도메인에 대한 질의 수행
dig $ALB +short
- dig 명령어로 ALB DNS 도메인 주소에 대한 질의를 할 때는 두 개의 유동 공인 IP가 출력된다.
즉, 사용자가 ALB 도메인 주소로 접속을 시도하면 DNS 질의 결과인 유동 공인 IP로 번갈아 가며 접속하게 된다.
- curl 명령어를 입력하여 결과를 확인
# curl 접속 테스트 - ALB는 기본 라운드 로빈 대상으로 대상 분산
curl $ALB
#반복문을 활용하여 curl 접속 테스트 (for 문으로 20번 반복 접속을 수행한 후 동일한 결과 값을 모아 출력)
for i in {1..20}; do curl $ALB --silent ; done | sort | uniq -c | sort -nr
#반복문을 활용하여 curl 접속 테스트 (for 문으로 90번 반복 접속을 수행한 후 동일한 결과 값을 모아 출력)
for i in {1..90}; do curl $ALB --silent ; done | sort | uniq -c | sort -nr
- 반복 접속 수행 결과는 ALB 도메인 주소로 접속을 시도하면 세 대의 웹 서버가 배치된 대상 그룹으로 거의 33% 비중으로 균등하게 로드 밸런싱이 되는 것을 보여준다.
- 로드 밸런싱은 기본적으로 라운드 로빈 방식으로 동작하여 각 ALB당 동일한 트래픽을 전달한다.
5) ALB 경로 기반 라우팅 기능을 구성하고 확인하기
# MyEC2의 SSH 터미널
# /dev/index.html 접근 -> 로드 밸런싱 기능으로 SERVER-1만 접근 가능
curl $ALB/dev/index.html --silent
curl $ALB/dev/index.html --silent
curl $ALB/dev/index.html --silent
# /mgt/index.html 접근 -> 로드 밸런싱 기능 때문에 SERVER-2, 3만 접근 가능
curl $ALB/dev/index.html --silent
curl $ALB/dev/index.html --silent
curl $ALB/dev/index.html --silent
- 웹 접근을 할 때 사용되는 경로가 다를 경우에는 해당 경로를 갖지 않는 서버는 로드 밸런싱이 요청한 응답을 오류 메시지로 전달하는 것을 확인할 수 있다.
- 로드 밸런싱의 기본 동작이 라운드 로빈 방식으로 동작하여 ALB를 생성할 때 동일한 대상 그룹에 묶여 있는 서버에 순차적으로 응답을 요청하기 때문이다.
- 이 문제를 해결하기 위해 동일한 경로 서비스를 하는 서버를 각 대상으로 묶고, ALB 경로 기반 라우팅 기능을 활용하여 웹에 접근할 때 HTML 경로에 해당하는 그룹으로 접근하는 규칙을 생성하면 된다.
- DEV-TG ( SERVER-1)와 MGT-TG (SERVER-2,3)로 대상 그룹을 분리
<DEV-TG 대상 그룹>
- EC2 > 로드 밸런싱 > 대상 그룹에 들어가 대상 그룹 생성을 누른다.
- 그룹 세부 정보 지정 페이지에서 다음과 같이 설정하고 다음을 누른다.
- 대상 그룹 이름에 'DEV-TG' 입력
- VPC에서 ELB-VPC 선택
- 대상 등록 페이지에서 실습에 사용할 SERVER-1 인스턴스를 체크한 후 아래에 보류 중인 것으로 포함을 누른다.
<MGT -TG 대상 그룹>
- 대상 그룹 이름에 'MGT-TG' 입력
- VPC에서 ELB-VPC 선택
- 대상 등록에서 실습에 사용할 SERVER-2,3 인스턴스 선택
- 아래 보류 중인 것으로 포함 누르기
- 경로 기반 라우팅 설정을 위한 ALB 리스너 규칙을 추가 하여 접근 경로(URL)에 /mgt/* 경로는 MGT-TG로 전달하고, /dev/* 경로는 DEV-TG로 전달하는 규칙을 생성
- EC2 > 로드 밸런서에서 생성된 ALB를 체크한다. 그런 다음 리스너 및 규칙 탭을 클릭한 다음 생성된 라우팅 규칙에 체크하고 오른쪽에서 규칙 관리 > 규칙 추가를 선택한다.
- 규칙 추가에서는 Name에 'dev'를 입력한 후 다음을 누른다.
- 규칙 조건 정의와 규칙 작업 정의에서 다음과 같이 설정한다.
- 조건 추가 클릭 후 규칙 조건 유형에서 경로 선택
- 값 영역에 '/dev/*' 입력 후 확인 > 다음 클릭
- 작업 유형에서 대상 그룹으로 전달 선택
- 대상 그룹에서 전달에서 DEV 선택 후 다음 클릭
- ALB 리스너 dev 규칙 생성 확인
- /mgt 경로 규칙도 생성
# MyEC2의 SSH 터미널
# dev/index.html 접근
curl $ALB/dev/index.html -- silent
for i in {1..3}; do curl $ALB/dev/ --silent ; done | sort | uniq -c | sort -nr
# /mgt/index.html 접근
curl $ALB/mgt/index.html -- silent
for i in {1..6}; do curl $ALB/mgt/ --silent ; done | sort | uniq -c | sort -nr
# /index.html 접근
for i in {1..9}; do curl $ALB --silent ; done | sort | uniq -c | sort -nr
- 모든 접근이 규칙에 매칭되어 동작 중인 것을 확인 가능
6) ALB의 User-Agent를 활용한 로드 밸런싱을 구성하고 확인하기
- ALB의 고급 라우팅 기능 중에서 HTTP 헤더 기반 라우팅을 구성하고 검증
- HTTP 프로토콜은 HTTP 헤더라는 공간에 다양한 정보를 담아 전달하는데, 그중 User-Agent 필드에는 HTTP 요청을 보내는 클라이언트 프로그램 정보가 포함되어 있다.
- 이 정보를 활용하여 각자 스마트폰의 인터넷 웹 브라우저에서 ALB 도메인 주소로 접근할 때 User-Agent 정보를 확인해서 특정 장치의 접근을 차단하는 실습
- 인터넷 웹 브라우저에 입력해서 접근 확인
- HTTP 헤더의 User-Agent를 통해 특정 스마트폰의 접근을 막는 규칙을 생성한 후 확인
- EC2> 로드 밸런서에서 생성된 ALB를 체크한다. 그런 다음 리스너 및 규칙 탭을 클릭한 후 생성된 라우팅 규칙에 체크하고 오른쪽에서 규칙관리 > 규칙 추가를 선택
- 규칙 추가에는 Name에 'User-Agent'를 입력하고 다음을 누른다.
- 규칙 조건 정의와 규칙 작업 정의에서 다음과 같이 설정
- 조건 추가 클릭 후 규칙 조건 유형에서 HTTP 헤더 선택
- HTTP 헤더 이름에 'User-Agent' 입력
- 값은 *iPhone*으로 입력한 후 새로운 값 추가 클릭, 다음 값은 *Android*로 입력한 후 확인 > 다음 클릭
- [규칙 작업 정의] 작업 유형에서 고정 응답 반환 선택
- 응답 본문에 'iPhone or Android Access Deny' 입력 후 다음 클릭
- ALB 리스너 User-Agent 규칙 동작 확인
- MyEC2 인스턴스에서는 정상적으로 접근하는 것을 알 수 있다.
7) NLB를 생성하고 교차 영역 로드 밸런싱 동작 확인하기
NLB 생성하기
- EC2 > 대상 그룹에서 대상 그룹 생성 클릭
- 그룹 세부 지정 페이지에서 다음과 같이 설정하고 다음 클릭
- 대상 그룹 이름에 'NLB-TG' 입력
- 프로토콜은 UDP 선택, 코드에 '161' dlqfur
- VPC는 ELB-VPC 선택
- 상태 검사 프로토콜은 HTTP 선택
- 고급 상태 검사 설정에서 재정의 선택, '80' 입력
- 대상 등록에서 실습에 사용할 모든 인스턴스를 선택한 후 아래에 보류 중인 것으로 포함을 누른다.
NLB 로드 밸런서를 생성 하기
- EC2 > 로드 밸런서에서 로드 밸런서 생성을 누른다.
- 로드 밸런서 유형 선택 페이지에서 Network Load Balancer의 생성을 누른다.
- Network Load Balancer 생성 페이지에서 다음과 같이 설정
- [기본 구성] 로드 밸런서 이름에 'NLB' 입력
- [네트워크 매핑] VPC는 ELB-VPC 선택
- 선택된 VPC에서 사용할 가용 영역 모두 체크
- [보안 그룹] elblab-ELBSG-XXXX 선택
- [리스너 및 라우팅] 프로토콜은 UDP 선택, 포트에 '161' 입력
- 대상 그룹은 앞서 설정한 NLB-TG 선택
NLB 동작 확인하기
- NLB 로드 밸런서가 생성되면 각각의 NLB로 분산하여 전달하려고 NLB 도메인 주소를 생성한다.
- MyEC2에서 ELB-VPC에 있는 SERVER-1.2.3의 SNMP 정보를 확인할 때는 각각의 인스턴스로 직접 요청하는 것이 아니라 NLB 도메인 주소 및 NLB 로드 밸런서의 IP 주소로 요청한다. 이때 생성된 NLB로 앞서 정의한 로드 밸런서의 리스너 정책에 따라 각 서버로 로드 밸런싱된다.
- MyEC2에서 NLB 도메인 주소로 SNMPGET 명령어를 요청하면 NLB 도메인 주소에 매칭된 각각의 가용 영역에 있는 NLB 로드 밸런서에 전달한다. 그러면 리스너 규칙에 따라 UDP 161번 포트의 트래픽을 대상 그룹으로 전달하게 되며, NLB 로드 밸런서는 대상 그룹에 속한 SERVER1 에는 30회, SERVER-2,3에는 15회씩 전달한다.
- 라운드 로빈 방식으로 동작하는 것을 확인할 수 있다. -> ALB와 다르게 교차 영역 밸런싱이 기본적으로 비활성화 상태임
- NLB의 교차 영역 로드 밸런싱을 활성화하고 로드 밸런싱 동작 확인
- EC2 > 로드 밸런서로 들어가 'NLB'에 체크하고 속성 탭을 클릭한 후 편집을 누른다.
- 교차 영역 로드 밸런싱을 선택하고 변경 내용 저장을 누른다.
- 앞서 확인된 결과와 다르게 가용 영역을 교차해서 응답하는 것을 확인할 수 있다.
8) ALB와 NLB의 출발지 IP 보존 확인하기
- 일반적으로 클라이언트와 서버가 통신을 하면 클라이언트는 IP 헤더에 출발지 IP 주소와 목적지 IP 주소를 기입하고 트래픽을 전달한다.
- 서버 입장에서는 IP 헤더 정보를 바탕으로 어떤 IP 주소를 사용하는 클라이언트가 자신에게 접속했는지 알 수 있다.
- 이 출발지 IP 주소를 알 수 없거나 변경되었다면 원하지 않는 클라이언트의 접근을 제어하는 것이 원칙적으로 불가능할 수 있으며, 각 보안 이슈에 대응이 어려울 수 있다.
<ALB 출발지 IP 보존 방식>
- ALB는 클라이언트가 보내는 트래픽을 ALB가 로드 밸런싱해서 서버에 전달할 때 클라이언트의 출발지 IP 주소를 자신의 프라이빗 IP 주소로 변경해서 전달한다.
- HTTP 헤더에 X-Forwarded_For(XFF) 필드를 이용하여 ALB 환경에서도 서버가 클라이언트 IP 주소를 알 수 있다.
- 외부 사용자 주소를 전달하기 위해 ALB는 HTTP 정보를 전달할 때 사용하는 HTTP 헤더 안에 X-Forwarded-For 필드를 추가하여 클라이언트 IP 주소를 전달하며, 웹 서버는 HTTP 헤더를 읽어 클라이언트 IP 주소를 알 수 있다.
# SERVER-1의 SSH 터미널
# Apache 기본 로그 설정 변경: 196번 줄에 %{X-Forwarde-For}i 추가
vi /etc/httpd/conf/httpd.conf
# 여기서 추가해주고 :wq로 저장하고 빠져나오기
# HTTP reload로 적용
systemctl reload httpd
# 실시간 로그 출력 후 모니터링
tail -f /var/log/httpd/access_log |grep -v "ELB-HealthChecker/2.0"
cf> vi 편집기 사용법
[Linux] vi 편집기 사용법 및 명령어
셀 상에서 vi [파일명]을 입력하면 새로운 문서를 편집할 수 있는 환경이 만들어진다. vi의 세 가지 모드 1. 명령 모드 (command mode) vi 명령어를 통해 vi를 시작할 경우 실행되는 모드. 방향키를 통해
velog.io
- SERVER-1 인스턴스에 SSH로 접속한 후 실시간 로그 모니터링 확인
<NLB 출발지 IP 보존 방식>
- NLB가 클라이언트가 보내는 트래픽을 로드 밸런싱하여 서버에 전달할 때 클라이언트의 출발지 IP 주소를 보존한 채로 전달한다.
'AWS' 카테고리의 다른 글
| [AWS 교과서] 6장 AWS 데이터베이스 서비스 (0) | 2024.08.08 |
|---|---|
| [AWS 교과서] 5장 AWS 스토리지 서비스 (0) | 2024.08.02 |
| [AWS 교과서] 3장 AWS 네트워킹 서비스 (0) | 2024.07.31 |
| [AWS 교과서] 2장 AWS 컴퓨팅 서비스 (0) | 2024.07.29 |
| [AWS 교과서] 1장 AWS란? (0) | 2024.07.28 |
