반응형
AWS에서 제공하는 로드밸런서 서비스 중 가장 많이 사용되는
"ELB와 NLB의 차이점과 NAT 동작 원리에 대해 자세히 알아보겠습니다."
특히,
1. SNAT와 DNAT의 개념을 중심으로 실제 동작 방식을 이해하고
2. 실습을 통해 직접 확인해보는 방법까지 다루겠습니다.
1. ELB와 NLB의 기본 개념
1-1. ELB(Elastic Load Balancer)의 특징
- Layer 7(Application Layer)에서 동작
- HTTP/HTTPS 프로토콜 지원
- 경로 기반, 호스트 기반 라우팅 가능
- 콘텐츠 기반의 고급 라우팅 지원
- 어플리케이션 레벨 처리로 인한 약간의 지연시간 존재
1-2. NLB(Network Load Balancer)의 특징
- Layer 4(Transport Layer)에서 동작
- TCP, UDP, TLS 프로토콜 지원
- 고성능, 낮은 지연시간 제공
- IP 주소와 포트 기반의 라우팅
- 초당 수백만 개의 요청 처리 가능
2. NAT(Network Address Translation)의 이해
2-1. SNAT(Source Network Address Translation)
- 내부 네트워크에서 외부로 나가는 트래픽의 출발지 IP를 변경
- 주로 사설 IP를 공인 IP로 변환할 때 사용
- 예시: 내부 네트워크 PC(192.168.1.10)가 인터넷 접속 시 공인 IP(203.0.113.1)로 변환
2-2. DNAT(Destination Network Address Translation)
- 외부에서 내부로 들어오는 트래픽의 목적지 IP를 변경
- 주로 공인 IP를 사설 IP로 변환할 때 사용
- 예시: 외부에서 웹서버 접속 시 공인 IP(203.0.113.1)를 내부 서버 IP(192.168.1.100)로 변환
3. AWS 로드밸런서의 NAT 동작 방식
3-1. ALB의 NAT 동작
- DNAT 동작
- 클라이언트에서 로드밸런서로 들어오는 트래픽의 목적지 주소를 내부 타겟의 private IP로 변환
- 필수적으로 수행되는 동작
- SNAT 동작
- 로드밸런서가 자동으로 Source NAT 수행
- 타겟으로 가는 트래픽의 출발지 IP가 로드밸런서의 IP로 변경
- 원본 클라이언트 IP는 X-Forwarded-For 헤더에 보존
- 백엔드 서버는 로드밸런서의 IP만 확인 가능
3-2. NLB의 NAT 동작
- DNAT 동작
- ALB와 동일하게 목적지 주소 변환 수행
- 클라이언트에서 들어온 트래픽을 내부 타겟으로 전달
- SNAT 미수행
- NLB는 Source NAT를 수행하지 않음
- 클라이언트의 원본 IP가 보존되어 타겟으로 전달
- 백엔드 서버에서 클라이언트의 실제 IP 확인 가능
- Layer 4 수준에서 동작하기 때문에 가능
- DSR 구조는 아님
4. Load Balancer NAT 동작 이해하기 실습
4-1. 준비사항
- AWS 계정
- 실습 리전: ap-southeast-1 (싱가포르)
- 예상 비용: $1-2 (모든 리소스 꼭 삭제 필요)
1단계: VPC 및 서브넷 생성
VPC 생성:
- Name: lb-test-vpc
- CIDR: 10.0.0.0/16
서브넷 생성:
- Public Subnet 1: 10.0.1.0/24 (AZ-a)
- Public Subnet 2: 10.0.2.0/24 (AZ-c)
- Private Subnet 1: 10.0.3.0/24 (AZ-a)
- Private Subnet 2: 10.0.4.0/24 (AZ-c)2단계: 인터넷 게이트웨이 & 라우팅 테이블 설정
1. 인터넷 게이트웨이 생성 및 VPC 연결
2. 퍼블릭 서브넷 라우팅 테이블:
- 0.0.0.0/0 -> 인터넷 게이트웨이
3. 프라이빗 서브넷 라우팅 테이블:
- 0.0.0.0/0 -> Nat 게이트웨이3단계: EC2 인스턴스 생성
1. 백엔드 서버 생성 (프라이빗 서브넷)
- Name: backend-1, backend-2
- AMI: Amazon Linux 2023 AMI
- Instance type: t2.micro
- 네트워크: Private Subnet 1, 2
- 사용자 데이터:
#!/bin/bash
sudo yum update -y
sudo yum install -y httpd
sudo -i
echo "<h1>Backend Server $(hostname -f)</h1>" > /var/www/html/index.html
systemctl start httpd
systemctl enable httpd
2. 테스트 서버 생성 (퍼블릭 서브넷)
- Name: test-client
- AMI: Amazon Linux 2023 AMI
- Instance type: t2.micro
- 네트워크: Public Subnet 14단계: ALB 설정 및 테스트
1. Application Load Balancer 생성
- Name: test-alb
- 인터넷 경계
- 리스너: HTTP:80
- VPC: lb-test-vpc
- 서브넷: Public Subnet 1, 2
- 보안 그룹: HTTP 허용
2. 타겟 그룹 생성
- Name: alb-target
- Protocol: HTTP:80
- 타겟: backend-1, backend-25단계: NLB 설정 및 테스트
1. Network Load Balancer 생성
- Name: test-nlb
- 인터넷 경계
- 리스너: TCP:80
- VPC: lb-test-vpc
- 서브넷: Public Subnet 1, 2
2. 타겟 그룹 생성
- Name: nlb-target
- Protocol: TCP:80
- 타겟: backend-1, backend-26단계: NAT 동작 테스트
##### ALB 테스트
# test-client에서 실행
# 1. ALB로 요청 보내기
curl http://<ALB-DNS-NAME>
# 2. 백엔드 서버에서 액세스 로그 확인
sudo tail -f /var/log/httpd/access_log
# -> 로드밸런서 IP가 source IP로 보임
# -> X-Forwarded-For 헤더에서 실제 클라이언트 IP 확인
##### NLB 테스트
# test-client에서 실행
# 1. NLB로 요청 보내기
curl http://<NLB-DNS-NAME>
# 2. 백엔드 서버에서 액세스 로그 확인
sudo tail -f /var/log/httpd/access_log
# -> 실제 클라이언트 IP가 source IP로 보임7단계: 정리
1. ALB 삭제
2. NLB 삭제
3. EC2 인스턴스 삭제
4. VPC 및 관련 리소스 삭제5. 실제 사용 시 고려사항
5-1. IP 주소 보존이 필요한 경우
- NLB 사용 권장
- 클라이언트 IP 기반의 처리나 로깅이 필요한 경우 유용
- 보안 정책상 원본 IP 확인이 필요한 경우에 적합
5-2. 어플리케이션 레벨 기능이 필요한 경우
- ALB 사용 권장
- 경로 기반 라우팅이 필요한 경우
- HTTP/HTTPS 프로토콜 지원이 필요한 경우
- 헤더 기반의 라우팅이 필요한 경우
** [ALB, NLB 선택 기준 및 아키텍처 특징 비교] - 참고
참고
https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/introduction.html
반응형
'AWS > EC2' 카테고리의 다른 글
| AWS Load Balancer 완벽 가이드 - ALB, NLB 선택 기준 및 아키텍처 특징 비교 (1) | 2025.02.01 |
|---|