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

저번 ALB 관련 실습에 이어서 NLB 관련 실습을 진행하겠습니다!

 

NLB를 생성하고 교차 영역 로드 밸런싱 동작 확인하기

 

 

NLB 생성하기

 

 

저번 실습과 비슷해서 설명 없이 텍스트 형식으로 호다닥 넘어가보겠습니다!

 

EC2 > 대상 그룹에서 대상 그룹 생성을 누른다

 

 

 

이렇게 설정한 후에 다음을 누르고

 

대상 등록에서 실습에 사용할 모든 인스턴스를 설정한 후 아래에 보류 중인 것으로 포함을 누른다

 

대상 그룹 생성을 누르면 대상 그룹이 생성된 것을 확인할 수 있음

 

 

대상 그룹을 만들었으니 이번에는 로드 밸런서를 만들어보자!

 

EC2 > 로드밸런서에서 로드 밸런서 생성을 누르고

 

로드 밸런서 유형 선택 페이지에서 Network Load Balancer의 생성을 누른다

 

생성 페이지에서는

 

 

이렇게 설정하고 아래쪽에 있는 로드 밸런서 생성을 누르면 NLB 생성이 완료된다

 

 

NLB 동작 확인하기

이제 생성된 NLB 동작을 확인해보자!

 

ALB와 동일한 구조인데 로드 밸런서는 두 개의 가용 영역에 각각 생성되고

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

 

=> 여기에서 NLB의 퍼블릭 IP 주소를 자신이 가진 EIP를 사용하여 IP 주소로 NLB에 접근할 수 있으나, AWS에서 제공하는 퍼블릭 IP 주소를 사용하면 유동적으로 변경될 수 있다

 

기본적으로 ALB는 탄력적 IP 주소를 할당할 수 없다

 

또한, NLB 로드 밸런서가 생성되면 각각의 NLB로 분산하여 전달하려고 NLB 도메인 주소를 생성한다

 

MyEC2에서 ELB-VPC에 있는 SERVER-1,2,3 의 SNMP 정보를 확인할 때는 각각의 인스턴스로 직접 요청하는 것이 아니라 NLB 도메인 주소 및 NLB 로드 밸런서의 IP 주소로 요청한다

 

=> 이때 생성된 NLB로 앞서 정의한 로드 밸런서의 리스너 정책에 따라 각 서버로 로드 밸런싱 된다

 

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

 

# MyEC2의 SSH 터미널
# NLB DNS 이름을 변수로 지정 -> 각자의 NLB DNS 이름 입력

NLB=NLB-d7f696ec220861c4.elb.ap-northeast-2.amazonaws.com

# NLB에 매칭된 공인 IP 주소 확인

dig $NLB +short

# NLB IP를 변수에 지정 -> 앞서 확인한 공인 IP 주소 입력

NLB1=43.202.254.188
NLB2=13.209.113.145


# snmp 서비스 확인

for i in {1..60}; do snmpget -v2c -c public $NLB 1.3.6.1.2.1.1.5.0 ; done | sort | uniq -c | sort -nr

for i in {1..60}; do snmpget -v2c -c public $NLB1 1.3.6.1.2.1.1.5.0 ; done | sort | uniq -c | sort -nr

for i in {1..60}; do snmpget -v2c -c public $NLB2 1.3.6.1.2.1.1.5.0 ; done | sort | uniq -c | sort -nr

 

MyEC2에서 NLB 도메인 주소로 SNMPGET 명령어를 요청하면 NLB 도메인 주소에 매칭된 각각의 가용 영역에 있는 NLB 로드 밸런서에 전달한다

 

=> 저번 ALB 실습과는 다르게 교차 영역 로드 밸런싱이 기본적을 비활성화 상태인 NLB는 기본적인 로드 밸런싱 동작인 라운드 로빈 방식으로 동작하는걸 알 수 있다!

 

ALB : 교차 영역 로드 밸런싱이 활성화 상태

NLB : 교차 영역 로드 밸런싱이 비활성화 상태

 

 

그러면 이제 NLB의 교차 영역 로드 밸런싱을 활성화하고 로드 밸런싱 동작을 확인해보자

 

 

2. EC2 > 로드 밸런서로 들어가서 'NLB'에 체크하고 속성 탭을 클릭한 후 편집을 누른다

 

 

3. 교차 영역 로드 밸런싱을 선택하고 변경 내용 저장을 누른다

 

 

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

 

# MyEC2 인스턴스에 SSH로 접속하여 다음 명령어를 입력한다
# snmp 서비스 확인

for i in {1..60}; do snmpget -v2c -c public $NLB 1.3.6.1.2.1.1.5.0 ; done | sort | uniq -c | sort -nr


for i in {1..60}; do snmpget -v2c -c public $NLB1 1.3.6.1.2.1.1.5.0 ; done | sort | uniq -c | sort -nr

 

 

앞서 확인된 결과와 다르게 가용 영역을 교차해서 응답하는 것을 확인할 수 있음!

 

=> 교차 영역 로드 밸런싱이 활성화 되었음

 

ALB와 NLB의 출발지 IP 보존 확인하기

 

일반적으로 클라이언트와 서버가 통신을 하면 클라이언트는 IP 헤더에 출발지 IP 주소와 목적지 IP 주소를 기입하고 트래픽을 전달한다!

 

서버 입장에서는 IP 헤더 정보를 바탕으로 어떤 IP 주소를 사용하는 클라이언트가 자신에게 접속했는지 알 수 있음!

 

만약 이 출발지 IP 주소를 알 수 없거나 변경되었다면?

 

=> 원하지 않는 클라이언트의 접근을 제어하는 것이 원칙적으로 불가능할 수 있으며, 각 보안 이슈에 대응이 어려움

 

하지만, IP 헤더상에 출발지 IP 주소를 보존하는 것이 꼭 절대적으로 옳은 것은 아니고 상황에 따라 다르다네요..

 

하여튼 이 출발지 IP 주소를 보존하는 것에 대해 ALB와 NLB는 동작이 서로 다른데, 그 차이점을 알아볼 것이다!

 

ALB

 

먼저, ALB는 클라이언트가 보내는 트래픽을 ALB가 로드 밸런싱해서 서버에 전달할 때 클라이언트의 출발지 IP 주소를 자신의 프라이빗 IP 주소로 변경해서 전달한다

 

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

 

# SERVER-1의 SSH 터미널
# 실시간 기록 로그 정보 확인 (MyEC2 에서 curl 해보면 됨)

tail -f /var/log/httpd/access_log | grep -v "ELB-HealthChecker/2.0"

# HTTP 트래픽 확인을 위한 패킷 덤프

tcpdump tcp port 80 -nn

...

# ctrl + c

 

2. MyEC2 인스턴스에 SSH로 접속하여 명령어를 입력하고 결과를 확인한다 (SERVER-1을 켜놓고 동시에 진행)

 

# MyEC2의 SSH 터미널
# MyEC2 서버의 IP 주소 확인

curl ipinfo.io/ip

# 실습을 위해 SERVER-1에 접근할 때까지 반복

curl $ALB

curl $ALB

...

 

결과를 확인해보면

 

 

실제 접속한 MyEC2의 IP 주소가 아닌 ALB의 사설 IP 주소로 전달하는 것을 확인할 수 있다

 

=> 이렇게 ALB는 출발지 IP 주소를 보존하지 않고 동작!

 

하지만 실제로 접근한 클라이언트가 아닌 ALB의 주소만 확인되면 사용자 IP를 기반으로 하는 비즈니스 서비스 활용은 제한되고 보안 이슈가 발생할 수 있음

 

따라서 이런 문제를 해결하기 위해 ALB 환경에서도 서버가 클라이언트 IP 주소를 알 수 있는 방법이 있다

 

HTTP 헤더에 X-Forwarded-For(XFF) 필드를 이용하면 되는데

 

이는 ALB가 외부 사용자 주소를 전달하기 위해 HTTP 정보를 전달할 때 사용하는 헤더 안에 XXF 필드를 추가하여 클라이언트 IP 주소를 전달하며, 웹 서버는 HTTP 헤더를 읽어 클라이언트 IP 주소를 알 수 있다!

 

3. SERVER-1 인스턴스에 SSH로 접속하여 기본 로그 설정 정보를 확인한다

 

# SERVER-1의 SSH 터미널
# Apache 기본 로그 설정 정보 확인

grep -n LogFormat /etc/httpd/conf/httpd.conf

 

 

4. SERVER-1 인스턴스에 SSH로 접속한 후
vi 편집기에서 196번 줄에 %{X-Forwarded-For}i를 추가하고 :wq를 입력해서 빠져나온다

 

# 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"

 

 

이런식으로 편집해주고 :wq로 저장하고 빠져나오면 됩니다!

 

vi 편집기 쓰는법 까먹어서 찾아본건 비밀

 

이제 실시간 로그 출력 후 끄지말고 MyEC2에서
curl $ALB로 SERVER-1이 나올 때 까지 반복 후 확인해보면

 

 

이렇게 X-Forwarded-For 필드에 클라이언트 IP 정보가 담겨있는 것을 확인할 수 있다!

 

=> 이렇게 ALB의 XFF를 이용하여 클라이언트의 IP를 보존한다면 민감 정보가 제공되는 웹 서버의 로그를 기록할 때 실제 접속한 클라이언트의 IP를 수집하는데 도움이 된다

 

 

=> 실습 환경의 경우 각 서버에 xff.php 파일을 구성한 덕분에 이번 실습을 간단하게 사진 처럼 확인 가능함!

 

NLB

 

이제 NLB의 출발지 IP 보존 방식을 알아보자!

 

NLB가 클라이언트가 보내는 트래픽을 로드 밸런싱하여 서버에 전달할 때 클라이언트의 출발지 IP 주소를 보존한다

 

1. 확인을 위해 SERVER-1 인스턴스에 SSH로 접속하여 명령어 수행 후 SERVER-1 인스턴스에서 접근한 후 확인해본다

 

# SERVER-1의 SSH 터미널
# SNMP 트래픽 확인을 위한 패킷 덤프

tcpdump udp port 161 -nn

 

2. MyEC2 인스턴스에 SSH로 접속하여 명령어를 수행하고 확인해본다 (SERVER-1을 켜놓고 동시에 진행)

 

# MyEC2의 SSH 터미널
# MyEC2 서버의 IP 주소 확인

curl ipinfo.io/ip

# 실습을 위해 SERVER-1에 접근할 때까지 반복

snmpget -v2c -c public $NLB 1.3.6.1.2.1.1.5.0

 

 

 

이렇게 패킷을 덤프할 때 클라이언트 IP가 NLB를 경유해서 인입했지만 출발지 IP 주소는 보존 하는 것을 확인했다!

 

=> NLB는 클라이언트 IP를 확인하는 HTTP 헤더의 XFF를 사용할 수 없는데, NLB가 4계층까지 이해하고 통제가 가능하여 HTTP 헤더를 이해하지 못하기 때문이다

 

NLB 환경에서 대상 그룹을 인스턴스가 아닌 IP 대상으로 지정하면 출발지 IP 주소를 보존하지 않는다

 

이렇게 출발지 IP 보존 방식의 ALB, NLB 동작 과정을 확인해보았고 길었던 4장 실습이 끝났습니다..✌️

 

자원을 삭제하고 마무리 하겠습니다!

 

 

1. 로드 밸런서 삭제하기

 

 

 

 EC2> 로드밸런서에서 실습에서 생성한 로드 밸런서를 전부 체크하고 오른쪽에 있는 작업에서 로드 밸런서 삭제를 해준다

 

2. 대상 그룹 삭제하기

 

 

EC2 > 대상그룹에서 생성한 대상을 전부 체크하고 오른쪽에 있는 작업 > 삭제를 선택한다

 

 

3. CloudFormation 스택 삭제하기

 

 

CloudFormation > 스택에서 elblab를 선택한 후 삭제를 누른다

 

=> 이후 열리는 창에서 스택 삭제를 누르고 정상적으로 삭제되었는지 꼭 확인해야 한다!

 

 

4장 실습 끝😎