[AWS 교과서] 4장 - AWS 부하분산 서비스(2)

---

ALB 와 NLB를 이용한 로드 밸런싱 구성하기

 

이번 실습은 Amazon ELB의 ALB와 NLB로 로드 밸런싱 환경을 구성하여
다수의 인스턴스를 이용한 ELB의 동작 및 활용을 확인해본다!

 

CloudFormation 소개

앞선 실습에서 다양한 AWS 인프라를 하나씩 수동으로 생성해서 사용했다

=> 실습 환경 구성에 많은 시간이 소요된다

 

이런 문제를 해결하기 위해 실습 환경을 코드 기반으로 생성하는 기술인 CloudFormation을 사용하여 더 빠르고 정확한 실습환경을 구성할 수 있다

 

CloudFormation은 IaC(Infrastructure as Code) 기반으로 AWS 인프라 리소스를 자동으로 생성하는 서비스이다!

 

=> VPC, EC2 등 리소스를 수동으로 생성할 필요 없이 리소스들을 템플릿(코드)으로 구성하고 스택을 생성하여 해당 서비스의 프로비저닝과 설정을 미리 구성할 수 있다

 

=> 인프라 구성을 자동화하여 운영 비용을 줄이고 인프라 관리를 간소화할 수 있고 지속적 배포를 지원하는
CI/CD 파이프라인과 통합할 수 있다

 

CloudFormation을 사용할 때는 템플릿 구조와 코드 형태의 이해가 필요하며, CloudFormation을 이용하여 모든 AWS 인프라를 정의하고 생성할 수 없다!

 

CloudFormation 구성 요소를 살펴보면

 

1. 템플릿 : AWS 인프라를 JSON 또는 YAML 형식의 코드로 정의하는 파일

=> 템플릿을 이용하여 AWS 인프라의 속성, 관계, 종속성 등을 정의

 

2. 스택 : CloudFormation을 이용하여 생성하는 AWS 인프라의 집합

 

3. 리소스 : AWS CloudFormation이 생성하는 AWS 리소스

 

=> Amazon EC2 인스턴스, Amazon RDS 데이터베이스, Amazon S3 버킷 등이 포함됨

 

4. 파라미터 : 스택을 생성할 때 전달할 수 있는 매개변수

 

=> 파라미터를 사용하면 템플릿을 재사용하여 다른 환경에 대한 스택을 쉽게 생성할 수 있다

 

5. 이벤트 : CloudFormation 스택에서 발생하는 모든 이벤트를 기록

 

=> 스택 생성, 변경, 삭제와 관련된 정보를 제공 (이를 활용하여 스택 문제를 해결할 수 있음)

 

6. CloudFormation : 템플릿을 해석해서 스택을 생성하고, 정의된 AWS 인프라를 생성, 변경, 삭제할 수 있음

 

가 있다!

 

동작 순서를 살펴보면

 

1. CloudFormation 템플릿 작성

 

2. 템플릿 업로드

 

3. 업로드한 템플릿으로 스택 생성 또는 업데이트

 

4. 스택 모니터링

 

=> CloudFormation은 스택 생성, 업데이트를 수행하면서 로그와 이벤트를 생성하므로 스택 상태를 모니터링할 수 있음

 

5. 스택 삭제

 

=> 스택을 삭제하면 스택에 속한 모든 AWS 인프라도 함께 삭제

 

이렇게 다섯 단계를 순차적으로 동작한다

 

 

CloudFormation으로 기본 인프라 배포하기

 

기본 실습 동작에 필요한 기본 인프라 자원은 AWS CloudFormation으로 자동 배포한다!

 

 

1. AWS 관리 콘솔에서 서비스 > CloudFormation 서비스로 들어가 스택 생성을 누른다

 

2. Amazon S3 URL에 https://cloudneta-aws-book.s3.ap-northeast-2.amazonaws.com/chapter4/elblab.yaml 를 입력

(템플릿 파일은 URL로 제공)

 

3. 이름과 키페어 파일을 설정해준다

 

4. 스택 옵션 구성 페이지에서는 별도의 설정 없이 다음을 누르고 elblab 검토에서는 별도의 설정 없이 전송을 눌러 스택을 생성한다

 

5. AWS CloudFormation 기본 인프라를 배포하고 일정 시간(약 5분)이 지나 스택 상태가 CREATE_COMPLETE가 되면
모든 인프라 배포가 정상적으로 완료된 것이다

 

 

이렇게 AWS CloudFormation으로 생성된 기본 인프라 자원 정보를 확인할 수 있다

 

기본 인프라 환경 검증하기

 

기본 인프라로 생성된 자원을 보면 MyVPC와 ELB-VPC가 있는데

 

MyVPC에는 MyEC2 서버를 배치하여 ELB에서 제공하는 로드 밸런싱 기능을 테스트하게 하고

 

ELB-VPC에는 실습에 사용되는 서버가 위치하며, ELB-VPC의 첫 번째 서브넷에 한 대(SERVER-1), 두 번째 서브넷에 두 대(SERVER-2, SERVER-3) 등

총 세 대의 서버를 서비스 제공용으로 배치해서 향후 실습에서 활용한다

 

(실습을 위해 구성된 세 대의 인스턴스에는 HTTP와 SNMP 서비스를 미리 설치해 두었다)

 

=> HTTP란

인터넷에서 데이터를 주고받을 수 있게 하는 표준 프로토콜로, 웹 서버와 클라이언트 간에 데이터를 주고받을 때 사용한다!

HTTP는 다양한 메소드를 사용하여 요청과 응답을 일반 텍스트 형식으로 주고받으며,사용하는 메소드로는 GET, POST, PUT, DELETE 등이 있다

HTTP는 TCP 프로토콜을 사용하여 신뢰성 있게 데이터를 송수신하며, 80번 포트를 사용한다

 

=> SNMP란

SNMP는 네트워크 장비들을 모니터링하고 관리하는 프로토콜이다!

이를 위해 SNMP는 네트워크 장비들에 에이전트를 설치하고,SNMP 관리자와 에이전트 간에 메시지를 주고받는 방식으로 동작한다

SNMP는 일반적으로 MIB라는 데이터베이스를 사용하여 네트워크 장비의 상태 정보를 저장하는데, 이를 OID라고 한다
=> 이 정보는 SNMP 관리자가 해당 ID를 요청할 때마다 에이전트가 그에 맞는 자원 정보를 전달하는 방식

SNMP는 네트워크 장비들의 성능 모니터링, 구성 변경, 장애 진단 등 다양한 용도로 사용되며, 이것으로 네트워크의 안정성과 가용성을 높일 수 있다

SNMP는 UDP 프로토콜을 사용하며 161번 포트를 사용한다

 

모든 구간은 퍼블릭 용도의 서브넷으로 구성되며,
인터넷 게이트웨이를 이용하여 외부 구간과 통신이 가능한 환경으로 구성되어 있음

 

이제 직접 기본 인프라 환경을 확인해볼건데 검증에 필요한 툴은 인스턴스의 User-data로 정의해서 미리 설치되어 있다!

 

=> User-data는 인스턴스를 부팅할 때 자동으로 수행하는 명령어 집합을 의미하며,
인스턴스가 초기화되는 동안 필요한 구성, 설치, 설정 등을 수행하는 데 사용된다

 

1. SERVER-1 · 2에 설치된 툴과 파일을 확인해보자

 

SSH로 SEVER-1 과 SERVER-2에 접속하고 명령어를 입력한다

 

(스택 세부 정보에서 각각의 퍼블릭 ip 확인할 수 있음 => 지난 실습들과 동일하게 SSH 접속)

 

No supported authentication methods available (server sent: publickey) 

계속 SSH에 접근하려고 하는데 이런 에러가 떠서 30분동안 열심히 찾아보니

EC2에서 컴퓨터를 빌릴때 기본 사용자가 정해져 있답니다,,,

무슨 소리인지 모르실 수 있으니 간단하게 설명하면

user name을 늘 해오던 ec2-user 가 아니라 SERVER-1 같은 이름으로 설정해서 접속하면 에러가 발생함..

결론 : ec2-user 라는 user name으로 접속하면 해결됨!

 

 

# SERVER-2의 SSH 터미널
# 디렉토리(폴더) 트리 구조 출력

tree /var/www/html

# xff.php 파일 정보 확인(웹에서 해당 파일에 접근할 때 접속자 정보가 출력되도록 만든 실습 파일)

cat /var/www/html/xff.php

 

 

 

이렇게 SERVER 1, 2 를 확인해보면 1에는 dev라는 폴더가 2에는 mgt라는 폴더가 생성된 것을 볼 수 있다

(각 서버에 있는 다른 이름의 폴더는 향후 로드 밸런싱 실습에 사용됨)

 

2. MyEC2에서 SERVER-1,2,3으로 HTTP 서비스와 SNMP 서비스를 확인해보자

 

# MyEC2 SSH 터미널
# SERVER-1,2,3의 퍼블릭 IP를 변수에 지정 -> 아래 EC21, EC22, EC23 IP 정보는 각자의 IP 정보 입력

# (띄어쓰기 하면 안됨!)
EC21=43.201.85.100
EC22=52.78.193.78
EC23=52.78.224.114


# 변수 지정 확인

echo $EC21

echo $EC22

echo $EC23

# SERVER-1 웹 서비스 확인

curl $EC21

curl $EC21/dev/

curl $EC21/mgt/ # SERVER-1 에는 mgt 폴더가 없어서 Not Found 가 뜸!

curl $EC21/xff.php

# SERVER-1 SNMP 서비스 확인

snmpget -v2c -c public $EC21 1.3.6.1.2.1.1.5.0

# SERVER-2, SERVER-3도 동일하게 웹 서비스 확인, SNMP 서비스 확인을 하면 된다

 

 

SNMP에서 정의된 기본 OID 정보

1.3.6.1.2.1.1.1.0 - sysDescr : sysDescr 값은 장비 설명이며, 장비 제조사에 따라 크기에 차이가 있다

=> 장비 정보를 출력할 때는 부가 정보로 출력

1.3.6.1.2.1.1.2.0 - sysObjectID : sysObjectID 값은 장비의 고유한 ID 값을 반환하며, 해당 값을 사용하여 장비 벤더, 장비 종류를 독자적으로 관리할 수 있음

1.3.6.1.2.1.1.3.0 - sysUpTime : sysUpTime 값은 장비가 부팅되어 현재까지 동작한 milli-second 값이며, 쿼리할 때 업데이트되는 정보이다

1.3.6.1.2.1.1.5.0 - sysName : sysName은 사용자가 장비에 설정한 장비 이름으로, 설정하지 않으면 Null 값을 출력한다

=> Null 값을 출력할 때 해당 장비 이름은 IP 주소 혹은 장비 Alias 이름(별칭)으로 출력됨

 

ALB를 생성하고 동작 과정 확인하기

 

앞서 구성된 기본 환경 구성을 바탕으로 ALB를 생성해서 각 가용 영역별 로드 밸런싱 동작 과정을 확인해보자

(ALB를 ELB-VPC 에 구성함)

 

1. ALB 생성하기

 

EC2 > 로드 밸런싱 > 대상 그룹 메뉴를 선택한 후 출력되는 페이지에서 대상 그룹 생성을 누른다

 

 

 

그림처럼 설정해주고 다음을 누른다

 

 

 

대상 등록에서 실습에 사용할 모든 인스턴스를 체크한 후 아래에 보류 중인 것을 포함을 누르고

 

선택한 인스턴스가 대상으로 이동된 것을 확인한 후 대상 그룹 생성을 누른다

 

(대상 그룹이 생성된걸 확인할 수 있음)

 

EC2 > 로드밸런서에 들어가서 로드 밸런서 생성을 누른다

 

로드 밸런서 생성 창에 들어가면

 

[기본 구성]에서 로드 밸런서 이름을 'ALB'로 입력하고

 

[네트워크 매핑]에서 VPC 는 ELB-VPC 선택

 

선택한 VPC에서 사용할 가용 영역을 모두 체크

 

 

[보안 그룹] 보안 그룹은 기존 default를 제거한 후 elblab-ELBSG-XXXX 선택

 

[리스너 및 라우팅] 리스너 HTTP:80 기본값, 대상 그룹은 앞서 설정한 ALB-TG 선택

 

이렇게 한 후에 가장 아래쪽에 있는 로드 밸런서 생성을 누르면 된다

 

생성된 로드 밸런서는 일정 시간(약 5분)이 지나면 프로비저닝 상태에서 활성화 상태로 변경된다!

 

ALB 동작 확인하기

 

지금까지 ALB 로드 밸런서를 생성하였고 이제 생성된 ALB가 어떻게 동작하는지 살펴봐야 한다!

 

앞선 실습에서 ALB-TG 대상 그룹에 인스턴스들을 포함했으며, 생성된 로드 밸런서는 두 개의 가용 영역에 각각 생성된다!

 

=> 이때, 로드 밸런서는 통신을 위한 ENI를 생성하고 퍼블릭 IP 주소를 할당한다

(또한 ALB 로드 밸런서가 생성되면 각각의 ALB로 나누어서 전달할 수 있도록 ALB 도메인 주소가 생성된다)

 

실습을 하기에 앞서 생성된 ALB의 동작을 간단히 설명하자면

 

HTTP 클라이언트 입장인 MyEC2에서 HTTP 서버 입장인 SERVER-1,2,3 으로 접근할 때, 각각의 인스턴스로 직접 HTTP 접근을 하지않고 ALB 도메인 주소로 접근하게 된다

 

=> 이때, 앞서 정의한 로드 밸런서의 리스너 정책(HTTP:80에 대해 대상 그룹으로 전달하는 규칙)에 따라 생성된 ALB를 이용하여 각 서버로 로드 밸런싱이 된다

 

1. MyEC2 인스턴스에 SSH로 접속하여 명령어를 입력한다

 

# MyEC2의 SSH 터미널
# ALB DNS 이름 변수 지정

ALB=ALB-1154727034.ap-northeast-2.elb.amazonaws.com # 각자의 ALB DNS 이름 입력

# dig로 도메인에 대한 질의 수행

dig $ALB +short

 

ALB 변수에는 각자의 ALB DNS 이름을 입력해야 한다

(ALB DNS 이름은 AWS의 로드 밸런서 페이지에서 생성된 로드 밸런서를 클릭하면 알 수 있다)

 

 

이 결과처럼 dig 명령어로 ALB DNS 도메인 주소에 대한 질의를 할 때는 두 개의 유동 공인 IP가 출력된다

(가용 영역당 각각 생성된 ALB의 ENI 유동 IP임)

 

=> 즉, 사용자가 ALB 도메인 주소로 접속을 시도하면 DNS 질의 결과인 유동 공인 IP로 번갈아 가며 접속하게 됨

 

2. curl 명령어를 입력하고 결과를 확인한다

 

 

# MyEC2의 SSH 터미널
# curl 접속 테스트 - ALB는 기본 라운드 로빈 방식으로 대상 분산

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% 비중으로 균등하게 로드 밸런싱이 되는 것을 보여준다

 

=> 이렇게 MyEC2에서 ALB 도메인 주소로 HTTP 접근을 90회 시도하면 ALB 도메인 주소를 IP 주소로 해석해서 각각의 가용 영역에 있는 ALB 로드 밸런서에 전달한다

 

그러면, 리스너 규칙에 따라 HTTP 80번 포트의 트래픽을 대상 그룹으로 전달하며, ALB 로드 밸런서는 로드 밸런싱해서 대상 그룹에 속한 SERVER-1,2,3에 동일한 트래픽을 30회씩 전달한다

 

코드의 주석에 보면 기본적으로 라운드 로빈 방식으로 로드 밸런싱이 동작한다고 되어있는데

이는 쉽게 말해 각 ALB당 동일한 트래픽을 전달한다는 것이다

 

=> 현재 가용 영역에 있는 서버의 수가 다르므로 적은 수의 서버에 더 많은 부하가 발생하는 것이라고 예상할 수 있음

그럼에도 동일한 횟수로 전달되는 이유는 저번에 배웠던 교차 영역 로드 밸런싱 기능 때문이다!

(가용 영역을 교차하여 대상 자원에 균등한 로드 밸런싱을 제공)

 

참고로 ELB 중 ALB는 교차 영역 로드 밸런싱이 기본적으로 활성화된 상태로 동작함

 

ALB 경로 기반 라우팅 기능을 구성하고 확인하기

 

 

MyEC2 인스턴스에 SSH로 접속하여 명령어를 입력해보자!

 

# 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

 

이 실습을 위해 미리 각 서버에 웹 접근을 할 때 사용되는 다른 이름의 HTML 경로를 만들어 두었다!

 

 

위 결과처럼 웹 접근을 할 때 사용되는 경로가 다를 경우에는 해당 경로를 갖지 않는 서버는 로드 밸런싱이 요청한 응답을 오류 메시지로 전달하는 것을 확인할 수 있다

 

=> 로드 밸런싱의 기본 동작이 라운드 로빈 방식이므로 ALB를 생성할 때 동일한 대상 그룹에 묶여 있는 서버에 순차적으로 응답을 요청하기 때문

 

이 문제를 해결하기 위해 동일한 경로 서비스를 하는 서버를 각 대상 그룹으로 묶고, ALB의 경로 기반 라우팅 기능을 이용하여 웹에 접근할 때 HTML 경로에 해당하는 그룹으로 접근하는 규칙을 생성해보자!

 

(대상 그룹 설정은 이미 했었으니 간단하게 텍스트로 넘어가겠음)

 

1. 먼저 DEV-TG 대상 그룹을 만들기 위해 EC2 > 로드 밸런싱 > 대상 그룹에 들어가 대상 그룹 생성을 누른다

 

2.  그룹 세부 정보 지정 페이지에서 대상 그룹 이름에 'DEV-TG', VPC에서 ELB-VPC를 설정하고 다음을 누른다

 

3. 대상 등록 페이지에서 실습에 사용할 SERVER-1 인스턴스를 체크한 후 아래에 보류 중인 것으로 포함을 누른다

 

4. 앞서 선택한 인스턴스가 대상으로 이동된 것을 확인한 후 대상 그룹 생성을 누른다

 

 

5. 다음 사진과 같이 대상 그룹이 생성된 것을 확인할 수 있다

 

6. DEV-TG 대상 그룹을 생성한 방법으로 MGT-TG 대상 그룹도 생성한다

 

(대상 등록에서 실습에 사용할 SERVER-2,3 인스턴스 선택)

 

이렇게 DEV-TG(SERVER-1)와 MGT-TG(SERVER-2,3)로 대상 그룹을 분리했다

 

이어서 경로 기반 라우팅 설정을 위한 ALB 리스너 규칙을 추가해보자

 

 

1. EC2 > 로드 밸런서에서 생성된 ALB를 체크한다. 그 다음,  리스너 및 규칙 탭을 클릭한 후 생성된 라우팅 규칙에 체크하고 오른쪽에서 규칙 관리 > 규칙 추가를 선택한다

 

2, 규칙 추가에서는 Name에 'dev'를 입력한 후 다음을 누른다

 

3. 규칙 조건 정의와 규칙 작업 정의에서

 

=> 조건 추가 클릭 후 규칙 조건 유형에서 경로 선택

 

=> 값 영역에 'dev/*' 입력 후 확인 > 다음 클릭

 

=> 작업 유형에서 대상 그룹으로 전달 선택

 

=> 대상 그룹으로 전달에서 DEV-TG 선택 후 다음 클릭

 

4. 규칙 우선순위 설정에서는 임의로 우선순위를 설정한 후 다음 > 생성을 누르면 규칙이 생성된다

 

5. /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

 

모든 접근이 규칙에 매칭되어 동작 중인 것을 확인할 수 있다!

 

ALB의 User-Agent를 활용한 로드 밸런싱을 구성하고 확인하기

 

이번에는 ALB 고급 라우팅 기능 중에서 HTTP 헤더 기반 라우팅을 구성하고 검증한다

 

=> HTTP 프로토콜은 HTTP 헤더라는 공간에 다양한 정보를 담아 전달하는데, 그중 User-Agent 필드에는 HTTP 요청을 보내는 클라이언트 프로그램 정보가 포함되어 있다!

 

(실제로 이 정보를 이용하여 서비스를 제공하는 서버는 클라이언트 프로그램에 맞는 최적의 데이터를 보낼 수 있음)

 

이번에는 각자 스마트폰의 인터넷 웹 브라우저에서 ALB 도메인 주소로 접근할 때 User-Agent 정보를 확인해서 특정 장치의 접근을 차단하는 실습을 해보자!

 

인데....

 

 

헷갈리는게 생겼습니다 ㅠㅠ

 

일단 실습 과정 부터 살펴보면

 

1. MyEC2 인스턴스에 SSH로 접속하여 명령어를 수행하고 확인한다

 

# MyEC2의 SSH 터미널

dig $ALB +short

 

2. 출력된 IP 주소 중 한 개를 선택하고 스마트폰의 인터넷 웹 브라우저에 직접 입력해서 접근해본다

 

=> 정상적으로 접근하고 있고 이제 HTTP 헤더의 User-Agent를 통해 특정 스마트폰의 접근을 막는 규칙을 생성해보겠음!

 

 

3. 로드 벨런서에서 생성된 ALB를 체크하고 리스너 및 규칙 탭을 클릭한 후 규칙 관리 > 규칙 추가를 선택

 

4. 규칙 추가에서는 Name에 'User-Agent'를 입력한 후 다음을 누른다

 

5. 규칙 조건 정의와 규칙 작업 정의에서 설정을 해준다

 

=> 조건 추가 클릭 후 규칙 조건 유형에서 HTTP 헤더 선택

 

=> HTTP 헤더 이름에 'User-Agent' 입력

 

=> 값을 'iPhone'으로 입력한 후 새로운 값 추가 클릭, 다음 값은 'Android'로 입력한 후 확인 > 다음 클릭

 

 

=> [규칙 작업 정의] 작업 유형에서 고정 응답 반환 선택

 

=> 응답 본문에 'iPhone or Android Access Deny' 입력 후 다음 클릭

 

6. 규칙 우선순위 설정에서는 임의로 우선순위를 설정한 후 다음 > 생성을 누르면 규칙이 생성된 것을 확인할 수 있음

 

7. ALB 리스너에 HTTP 헤더의 User-Agent가 'iPhone' 이나 'Android' 값이면 연결을 거부하는 규칙을 추가했음

 

 

 

Before

 

After

 

인데 

 

책에서 보여주는 실습과 동일하게 진행을 해도 계속 핸드폰으로 접속이 되길래

 

 

이렇게 *iPhone* 으로 앞 뒤에 와일드 카드를 붙였더니 된다......

 

내가 알기로는 값에 iPhone을 적으면 User-Agent 값에 iPhone 이라는 문자가 포함되어 있으면 규칙이 적용되어서

* 를 쓸 필요가 없다고 생각했다

(책에서도 *iPhone*이 아니라 iPhone으로 값을 적음)

 

 

iPhone으로 User-Agent 값을 설정하고 SERVER-2의 로그를 확인해 보면 User-Agent 값에 iPhone 이 포함되어 있어서 책에서 이해한 바로는 규칙이 적용되어야 할 텐데 접속이 너무너무 잘 된다!

 

(그래서 규칙 순서도 1번으로 바꿔보고  이것 저것 찾아보면서 시도하다가 문자열에 iPhone이라는 단어가 섞여있으니
*를  앞 뒤에 붙이니까 해결이 되었음..)

책에서는 그냥 iPhone으로 적고 문자열에 포함되어 있으면 접근을 막아주는 방식인거 같은데

왜 저는 이럴까요,,,?

알려주시면 감사하겠습니다!!

 

 

하여튼 이렇게 스마트폰에서는 접속이 안되는 상황에서

 

 

MyEC2 인스턴스에서는 정상적으로 접근하는 것을 확인할 수 있다

 

이렇게 ALB 리스너는 HTTP 헤더의 User-Agent 정보를 활용하여 접근을 제어할 수 있는데 이는 ALB가 HTTP 정보를 확인할 수 잇는 L7 로드 밸런서이기 때문이다!

 

=> ALB 로드 밸런서는 기본적인 부하분산 기능과 함께 다양한 고급 라우팅을 이용한 동작을 활용할 수 있다

 

 

이번에는 ALB에 관해 실습을 진행하였는데 4장 실습의 내용이 많아서 NLB는 다음에 다루도록 하겠습니다!