AMI / LB

AMI(Amazon Machine Image)의 세부적인 작동 방식

AMI는 서버(EC2 인스턴스)의 전체 환경(OS, 설정, 애플리케이션, 데이터)를 이미지화하여, EC2 인스턴스를 동일한 상태로 복제 & 배포할 수 있도록 해준다.

 

Imaging ??

이미지화 Imaging 는 시스템 (운영 체제, 설정, 애플리케이션, 데이터 등)의 상태를 정확히 캡처하여 저장한 후 필요할 때 동일한 상태로 복원하거나 복제할 수 있도록 하는 기술이다.

Snapshot 과 Image의 차이

Snapshot : 특정 시점의 디스크 상태를 캡처한 데이터 ( 보통의 EBS Volume 의 상태)

Image: 디스크 상태뿐만 아니라 OS 설정, 애플리케이션 등 전체적인 환경을 포함하는 배포가 가능한 형태

 

Imaing 의 원리

현재 운영 중인 서버의 OS, 애플리케이션, 설정을 캡처
해당 데이터를 압축 및 최적화하여 저장 (예: AMI, ISO, VMDK 등)
필요할 때 동일한 설정을 가진 새로운 인스턴스를 생성 가능

 

Imaing의 목적

배포 자동화: 동일한 환경의 서버를 신속하게 복제하여 여러 개 배포 가능
백업 및 복구: 특정 시점의 상태를 저장하고, 장애 발생 시 복원 가능
일관성 유지: 모든 인스턴스를 동일한 설정으로 유지 가능

 

이미지화의 주요 기술

Docker 이미지(Container Image)
애플리케이션과 관련된 모든 환경(코드, 라이브러리, 설정)을 하나의 컨테이너 이미지로 패키징
실행 환경이 달라도 동일한 컨테이너 이미지로 배포 가능 (예: Kubernetes, ECS)

디스크 이미지(Disk Imaging)
운영 체제(OS)와 모든 데이터를 포함한 디스크 전체를 이미지화하여 백업 및 복원
대표적인 포맷: ISO, VMDK(VMware), VHD(Azure)

AWS AMI(Amazon Machine Image)
EC2 인스턴스의 전체 환경을 캡처하여 동일한 상태로 배포 가능
AWS 내부에서 효율적인 스냅샷 관리 및 복제 지원

 

AMI의 내부 작동 원리 

EC2 인스턴스의 상태를 캡처하여 AMI로 저장
AMI에는 OS, 애플리케이션, 설정 정보, 스토리지(Volume) 정보가 포함됨
AMI를 사용하여 새로운 EC2 인스턴스를 생성할 때, 동일한 구성을 빠르게 복원
AMI를 다른 리전으로 복사하여 글로벌 배포 가능

AMI의 주요 구성 요소

AMI는 단순한 파일이 아니라, 여러 개의 구성 요소로 이루어져 있다.

구성 요소

Root Volume (루트 볼륨)	OS 및 기본 애플리케이션이 설치된 EBS 볼륨
Block Device Mapping	추가적인 EBS 볼륨, 스냅샷 정보, 디스크 설정 포함
Launch Permissions	특정 AWS 계정 또는 퍼블릭으로 AMI 공유 가능
Virtualization Type	HVM 또는 PV 방식으로 가상화 지원
Kernel ID	AMI가 사용하는 커널 정보 포함 (일부 커스텀 AMI)

AMI는 단순한 ISO 파일이 아니라, EC2 인스턴스의 상태를 그대로 복제하는 종합적인 스냅샷이다.

 

---

 

AMI의 생성 & 배포 과정

AMI 생성 → 저장 → 배포 → 실행의 과정

AMI 생성 과정

기본적으로 AMI는 EC2의 스냅샷을 기반으로 생성됨.

1. EC2 인스턴스 실행 (사용자가 원하는 상태로 설정)
2. AWS에서 루트 EBS 볼륨을 스냅샷(snapshot)으로 캡처
3. EBS 스냅샷을 기반으로 AMI 메타데이터를 생성 (OS, 애플리케이션 설정 포함)
4. AMI 생성 완료 후, AWS S3 내부에서 AMI 메타데이터 저장

AMI 생성 시의 핵심 동작

sh
복사편집
aws ec2 create-image --instance-id i-xxxxxxxxxxxx --name "MyCustomAMI"

 

결과적으로 AMI는 "이미지 + EBS 스냅샷"의 형태로 저장됨.
동일한 설정의 EC2 인스턴스를 빠르게 복제할 수 있음.

 

---

 

AMI 저장 & 관리 (S3와 EBS( Elastic Block Store ) 스냅샷 활용)

AMI 자체는 S3에  Metadata 형태로 저장되고, 실제 OS 및 데이터는 EBS 스냅샷으로 저장된다.

저장 위치설명

EBS Snapshot	OS, 애플리케이션, 데이터 포함
S3 (Metadata Storage)	AMI 정보, 권한, Block Device Mapping 포함

EBS 스냅샷은 비용이 발생하며, 필요 없는 스냅샷은 삭제

AMI를 삭제할 때는 AMI뿐만 아니라 연결된 EBS 스냅샷도 삭제해야 완전한 정리 가능.

sh
복사편집
aws ec2 deregister-image --image-id ami-xxxxxxxxxxxx aws ec2 delete-snapshot --snapshot-id snap-xxxxxxxxxxxx

 

 

 

---

 

AMI를 사용한 EC2 인스턴스 생성 과정

1. AMI 선택 후, 새로운 EC2 인스턴스를 실행
2. AMI가 가지고 있는 EBS 스냅샷을 기반으로 새로운 EBS 볼륨을 생성
3. 새로운 EC2 인스턴스에 해당 EBS 볼륨을 연결
4. 부팅 후, AMI에 포함된 설정과 애플리케이션을 그대로 복원
5. EC2 인스턴스가 정상적으로 실행됨 (기존 환경과 동일한 상태 유지)

CLI로 EC2 실행

sh
복사편집
aws ec2 run-instances --image-id ami-xxxxxxxxxxxx --instance-type t3.micro

 

결과적으로, EC2 인스턴스가 원본 AMI의 환경과 동일한 상태로 실행됨!

 

 

---

 

AMI를 리전 간 복사하여 글로벌 배포

AWS에서는 AMI를 여러 리전에 복사할 수 있습니다.

sh
복사편집
aws ec2 copy-image --source-image-id ami-xxxxxxxxxxxx \ --source-region us-east-1 \ --destination-region ap-northeast-2 \ --name "MyAMI-Copy"

 

AP-Northeast-2 (서울 리전)에서도 동일한 AMI로 EC2 인스턴스를 실행 가능!
여러 리전에서 같은 환경을 유지할 때 매우 유용!

 

---

 

AMI의 내부 동작 과정 요약

EC2의 EBS 볼륨을 스냅샷으로 저장 (AMI 생성)
AMI 메타데이터가 AWS S3에 저장됨
AMI에서 EC2를 실행할 때, EBS 스냅샷을 복제하여 새로운 EC2에 적용
서버 환경을 그대로 유지하면서 빠르게 인스턴스를 생성 가능
AMI는 다른 리전으로 복사 가능하여 글로벌 확장에 활용 가능

---

 

결론: AMI는 어떻게 동작하는가?

AMI는 EC2 인스턴스를 이미지화하여, OS + 애플리케이션 + 설정을 포함하는 환경을 저장함.
AMI 내부적으로는 EBS 스냅샷을 기반으로 동작하며, 메타데이터는 S3에 저장됨.
AMI를 사용하면 동일한 환경을 빠르게 배포하고, 여러 리전에서 동일한 인프라를 유지할 수 있음.

AMI는 "서버 환경의 완벽한 스냅샷"이라고 볼 수 있음.
이를 활용하면 서버 확장, 복구, 테스트 환경 표준화 등을 쉽게 할 수 있음.

 

---

ELB(Elastic Load Balancer) & ALB(Application Load Balancer) 개요

ELB (Elastic Load Balancer) 는 AWS에서 제공하는 트래픽 분산 서비스이다.
여러 개의 EC2 인스턴스(서버)로 트래픽을 자동으로 분산하여, 고가용성(HA)과 확장성(Scalability)을 보장할 수 있다.

---

ELB의 주요 역할

트래픽 분산 → 여러 EC2 인스턴스에 부하를 나눠서 처리
자동 확장 (Auto Scaling)과 연계 가능
고가용성 제공 → 특정 인스턴스 장애 발생 시 자동으로 다른 인스턴스로 트래픽을 라우팅
보안 강화 → AWS WAF(Web Application Firewall) 및 SSL/TLS 인증서 적용 가능
서버 상태 체크 (Health Check) → 정상적인 인스턴스만 트래픽을 받도록 설정

 

---

ELB의 종류

AWS ELB에는 3가지 유형이 있습니다.

ELB 종류 설명 주요 용도

ALB (Application Load Balancer)	HTTP(S) 레벨에서 요청을 라우팅	웹 애플리케이션, API 서버
NLB (Network Load Balancer)	TCP/UDP 레벨에서 트래픽을 분산	고속 처리, 게임 서버, 금융 시스템
CLB (Classic Load Balancer)	구버전 ELB (ALB와 NLB로 대체됨)	❌ 사용 지양

일반적인 웹 애플리케이션에서는 ALB를 사용하는 것이 가장 적절합니다.
NLB는 초고속 네트워크 트래픽을 처리해야 할 때 사용합니다.

 

---

 

ALB(Application Load Balancer)란?

ALB는 OSI 7계층(애플리케이션 계층)에서 작동하는 부하 분산 서비스이다.
HTTP(S) 트래픽을 기반으로 특정 URL, 도메인, 쿠키 등에 따라 트래픽을 분산 가능하다.

 

ALB의 주요 기능

URL 기반 라우팅 (/api, /user 등 특정 경로에 따라 트래픽을 다른 서버로 보낼 수 있음)
호스트 기반 라우팅 (도메인에 따라 트래픽을 분산)
HTTPS 지원 및 SSL/TLS 종료
WebSocket 및 HTTP/2 지원
자동 Health Check 기능 내장

ALB는 웹 애플리케이션을 위한 고급 트래픽 관리 기능을 제공함.

 

---

 

ELB(ALB)와 AMI를 어떻게 연결할까?

AMI + ELB(ALB)를 결합하면, 확장 가능한 고가용성 시스템을 구축할 수 있습니다.

AMI와 ALB(ELB)를 연결하는 방법

1. AMI를 기반으로 Auto Scaling Group(ASG) 생성
   • AMI를 사용하여 EC2 인스턴스를 자동으로 생성 & 확장
   • 예: 서버 트래픽이 증가하면 새로운 EC2가 자동으로 추가됨
2. Auto Scaling Group(ASG)을 ALB에 연결
   • ALB는 Auto Scaling Group과 연결되어 자동으로 EC2 인스턴스를 추가 & 제거
   • ASG 내 인스턴스가 늘어나면, ALB가 트래픽을 자동으로 분산
3. ALB가 요청을 여러 EC2 인스턴스로 분산
   • 사용자는 ALB의 도메인(예: myapp.example.com)을 사용하여 접속
   • ALB는 요청을 Health Check가 정상인 인스턴스로 라우팅

 

---

 

AMI + ALB + Auto Scaling Group(ASG) 아키텍처

이 구조를 사용하면, 사용자가 증가해도 자동으로 서버를 확장하고, 부하를 분산할 수 있음.

 AMI를 기반으로 Auto Scaling Group 생성

aws autoscaling create-launch-template --launch-template-name MyAppTemplate \
    --image-id ami-xxxxxxxxxxxx --instance-type t3.micro

Auto Scaling Group을 만들고 ALB에 연결

aws autoscaling create-auto-scaling-group --auto-scaling-group-name MyAppASG \
    --launch-template LaunchTemplateName=MyAppTemplate \
    --min-size 2 --max-size 5 --desired-capacity 2 \
    --target-group-arns arn:aws:elasticloadbalancing:ap-northeast-2:xxxxx:targetgroup/MyTargetGroup

ALB에서 트래픽을 Auto Scaling Group으로 전달

aws elbv2 create-load-balancer --name my-application-lb --type application \
    --subnets subnet-xxxx subnet-yyyy \
    --security-groups sg-xxxxxx

ALB와 Target Group을 연결

aws elbv2 create-target-group --name MyTargetGroup --protocol HTTP --port 80 \
    --vpc-id vpc-xxxxxx

ALB가 Auto Scaling Group을 통해 AMI 기반 EC2 인스턴스에 트래픽을 분배함.
트래픽 증가 시 새로운 EC2가 자동 생성되며, 장애 발생 시 자동 대체됨.

 

결론

1. ELB(ALB)를 사용하면 트래픽을 여러 EC2 인스턴스로 분산할 수 있음.
2. AMI를 사용하면 동일한 환경의 서버를 빠르게 배포 가능.
3. Auto Scaling Group(ASG)과 ALB를 조합하면 서버를 자동 확장 가능.
4. 이 조합을 사용하면 확장성(Scalability)과 고가용성(High Availability)을 쉽게 구현 가능.

"AMI + ALB + Auto Scaling"을 조합하면 자동화된 대규모 서버 인프라를 구축할 수 있음! 

 

---

 

ELB(ALB)에서 요청이 매번 분산되지 않는 이유

현재 ALB(Application Load Balancer) 를 사용하여 2개의 EC2 인스턴스로 트래픽을 분산하고 있다.
하지만 테스트 결과, "매번 번갈아가면서" 바뀌는 것이 아니라, 일정 횟수 이상의 요청을 보내야 바뀌는 것처럼 보인다는 문제가 발생했습니다.

이러한 이유는 ALB의 로드 밸런싱 방식과 세션 유지 정책 때문입니다.

 

---

 

ALB의 기본 로드 밸런싱 방식 (Round Robin vs Least Outstanding Requests)

 

1. ALB의 기본 알고리즘은 "Least Outstanding Requests (LOR)"

ALB는 기본적으로 "Least Outstanding Requests (LOR)" 알고리즘을 사용하여 트래픽을 분산합니다.

• 현재 요청이 적게 처리되고 있는 인스턴스로 트래픽을 우선적으로 보냄
• 완전히 균등하게 번갈아 가면서 (Round Robin 방식) 배분되는 것이 아님
• EC2 인스턴스의 처리 속도나 응답 시간이 다르면, 일부 인스턴스에 트래픽이 더 몰릴 수 있음

요청이 많아질수록 부하가 적은 서버로 트래픽이 이동하게 되어, 번갈아가며 연결되지 않을 수 있음.

수동으로 "Round Robin" 방식처럼 작동하게 하려면?

aws elbv2 modify-target-group-attributes --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-2:xxxxx:targetgroup/web-tg \
    --attributes Key=load_balancing.algorithm.type,Value=round_robin

• LOR 방식 → Round Robin 방식 변경
• 이렇게 하면 매 요청마다 번갈아 가면서 다른 EC2로 트래픽을 분배하도록 설정 가능

 

---

 

세션 유지 (Sticky Sessions) 설정 여부 확인

Sticky Sessions이 활성화되어 있으면 한 EC2에 지속적으로 연결됨

ALB는 기본적으로 클라이언트와 특정 EC2 간의 연결을 유지하는 "Sticky Sessions" 기능을 제공할 수 있음.

• 세션을 유지하는 동안 같은 인스턴스에 요청이 지속적으로 전송됨
• 따라서 새 요청이 발생하더라도 이미 연결된 인스턴스가 있으면 그대로 유지됨

Sticky Sessions 비활성화 방법 (CLI)

aws elbv2 modify-target-group-attributes --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-2:xxxxx:targetgroup/web-tg \
    --attributes Key=stickiness.enabled,Value=false

Sticky Sessions 기능이 꺼지고, 요청이 더 균등하게 분산됨.

 

---

 

브라우저 캐싱 영향 가능성

웹 브라우저는 HTTP 요청을 캐시(Cache) 하는 경우가 많음.

• 동일한 요청을 보낼 때 브라우저가 다시 요청하지 않고 이전 응답을 그대로 보여주는 경우가 있음.
• 이로 인해 로드 밸런서가 요청을 번갈아 가며 전달하는 것처럼 보이지 않을 수 있음.

 

해결 방법

• 브라우저 캐시 비활성화
• 시크릿 모드(Ctrl + Shift + N)에서 테스트
• curl 명령어 사용하여 직접 확인

curl -I http://your-load-balancer-url

반복해서 실행하면서 응답이 번갈아 나오는지 확인 가능.

 

---

 

클라이언트 IP 기반 라우팅 문제 (ALB의 기본 설정)

ALB는 기본적으로 클라이언트 IP를 기반으로 라우팅할 수도 있음.
같은 클라이언트(같은 IP)에서 요청하면 같은 EC2로 보내질 가능성이 높음.

확인 방법

1. 다른 기기(또는 VPN)에서 테스트
2. curl로 여러 번 요청 시 테스트

for i in {1..10}; do curl -I http://your-load-balancer-url; done

요청을 보낼 때마다 응답이 번갈아 나오는지 확인 가능.

 

---

 

결론: 왜 매 요청마다 번갈아 바뀌지 않는가?

ALB는 기본적으로 "Least Outstanding Requests (LOR)" 알고리즘을 사용 → 번갈아 가며 분산하지 않고, 부하가 적은 서버로 우선 전달됨

• Round Robin으로 변경하면 해결 가능

Sticky Sessions (세션 유지) 기능이 켜져 있으면 같은 서버로 계속 요청이 감

• Sticky Sessions를 비활성화하면 해결 가능

웹 브라우저가 요청을 캐시하고 있을 가능성 있음

• 시크릿 모드 또는 curl 명령어로 직접 확인 필요

ALB가 클라이언트 IP를 기반으로 같은 서버로 연결할 가능성 있음

• VPN 또는 다른 네트워크에서 테스트 필요

 

 

---

 

질문

지금 로드 밸런스의 NLB 를 구현해서 서로 다른 public sub 1 과 2 에 위치한 web 1, web2 에 테스트를 해보면서 로드밸런스가 어떻게 작동하는 지 그리고 NLB 에 대해서 학습하고 있는 데 NLB 를 설정할때 target group을 만들잖아 근데 NLB에서 port number 를 설정하고 target group 에서도 port number 를 설정하잖아그러면 이 port number 들은 원할한 통신으로 설정하기 위해서는 서로 동일해야한다고 배웠는 데 맞나? 그리고 그 다음에 테스트 해본 것은 web1,2의security group 에서 22번 포트에 대한 접근을 닫은 다음에 NLB 와 target group 에서의 포트번호를 22로 바꾸어서 접속해보니 접속이 안되더라고 근데 만약 NLB와 target group 의 포트번호는 동일하게 22번으로 유지하고 web 에서는 http 즉 80 번 포트번호로 접속하고 싶을 때 이것도 가능할까?

 

NLB의 포트 설정 & Target Group과 EC2 간 통신 방식

NLB(Network Load Balancer)를 설정하면서 포트와 Security Group의 동작 방식을 테스트

---

 

NLB에서 설정하는 포트와 Target Group의 포트는 동일해야 하나?

반드시 동일할 필요는 없다.
하지만, 일반적으로 동일하게 설정하는 것이 기본적인 동작 방식입니다.

NLB와 Target Group의 포트 동작 방식

포트 설정 위치 역할

NLB Listener 포트	외부 요청을 수신하는 포트 (예: 22, 80, 443)
Target Group 포트	NLB가 백엔드 EC2로 트래픽을 전달하는 포트

 

두 개의 포트가 다른 경우 & 동일한 경우

• (1) 동일한 경우 (기본적인 방식)
  ex)
  • NLB에서 22번 포트 → Target Group도 22번 포트
  • NLB에서 80번 포트 → Target Group도 80번 포트
  • 트래픽이 그대로 백엔드 EC2로 전달됨.
• (2) 서로 다른 경우 (포트 변환 가능)
  ex)
  • NLB에서 22번 포트를 받고, Target Group에서 80번 포트로 전달 가능
  • 즉, 클라이언트는 22번으로 연결하지만, 실제로 EC2에서는 80번 포트로 서비스됨.

🔹 포트 번호는 반드시 동일할 필요는 없지만, 어떻게 설정하느냐에 따라 동작 방식이 달라진다.

 

---

 

Security Group에서 22번 포트를 차단했을 때 NLB를 통한 SSH 접속이 안 되는 이유

NLB를 통해 EC2에 연결하더라도, EC2 자체에서 해당 포트를 허용하지 않으면 연결이 차단된다.
Security Group에서 EC2의 22번 포트를 차단하면 SSH가 차단됨.

이유

• NLB는 단순히 트래픽을 전달하는 역할을 할 뿐, EC2의 보안 규칙(Security Group)을 무시하지 않음.
• 따라서, EC2에서 22번 포트를 허용하지 않으면 NLB를 통해 들어오는 트래픽도 차단됨.

 

해결 방법

1. EC2의 Security Group에서 22번 포트를 열어야 SSH 접속 가능

aws ec2 authorize-security-group-ingress --group-id sg-xxxxxx --protocol tcp --port 22 --cidr 0.0.0.0/0

1. EC2에서 방화벽(UFW)을 확인하고 포트를 열어야 함

sudo ufw allow 22
sudo ufw reload

 

 

---

 

최종 정리

질문 답변

NLB와 Target Group의 포트는 동일해야 하나?	아니요, 다르게 설정할 수도 있음. 하지만 일반적으로 동일하게 설정함.
NLB에서 SSH(22번 포트) 트래픽을 받아서 EC2의 HTTP(80번 포트)로 전달할 수 있나?	가능함! NLB에서 22번 포트 → Target Group에서 80번 포트로 변경 가능.
EC2의 Security Group에서 22번을 닫으면 NLB를 통한 SSH 접속이 가능한가?	아니요. Security Group이 차단하면 NLB를 통해서도 접근 불가능.
EC2가 80번 포트에서만 서비스할 경우, NLB에서 22번으로 받도록 설정하면?	NLB에서 포트 변환 가능 (22 → 80).

---

 

 

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html

 

---

 

Application Load Balancer(ALB)와 Network Load Balancer(NLB) 모두에서 리스너 포트, 대상 그룹(Target Group) 포트, 인스턴스 포트는 서로 다르게 설정할 수 있으며, 이러한 설정으로도 원활한 통신이 가능하다.

포트 설정의 유연성

- 리스너 포트: 로드 밸런서가 클라이언트로부터 수신하는 포트다.
- 대상 그룹 포트: 로드 밸런서가 트래픽을 대상(예: EC2 인스턴스)으로 전달할 때 사용하는 포트다.
- 인스턴스 포트: 대상 인스턴스에서 실제로 서비스가 운영되는 포트다.

로드 밸런서는 리스너 포트로 수신한 요청을 대상 그룹 포트로 전달하며, 대상 그룹은 해당 요청을 인스턴스의 지정된 포트로 라우팅합니다. 따라서, 각 포트는 서로 다르게 설정되어도 통신에 문제가 없다.

ex)

1. ALB의 경우:
   - 리스너 포트: 80 (HTTP)
   - 대상 그룹 포트: 8080
   - 인스턴스 포트: 8080

   이 설정에서는 ALB가 80번 포트로 수신한 HTTP 요청을 대상 그룹을 통해 8080번 포트로 전달하며, 인스턴스는 8080번 포트에서 해당 요청을 처리하다.

2. NLB의 경우:
   - 리스너 포트: 443 (TCP)
   - 대상 그룹 포트: 8443
   - 인스턴스 포트: 8443

   이 설정에서는 NLB가 443번 포트로 수신한 TCP 요청을 대상 그룹을 통해 8443번 포트로 전달하며, 인스턴스는 8443번 포트에서 해당 요청을 처리하다.

설정방법

- 대상 그룹 생성 시: 대상 그룹의 포트를 지정할 수 있으며, 이 포트는 로드 밸런서가 트래픽을 대상에게 전달할 때 사용하는 포트이다.
- 인스턴스 등록 시: 대상 그룹에 인스턴스를 등록할 때, 각 인스턴스의 포트를 개별적으로 지정할 수 있다.

로드 밸런서의 리스너 포트, 대상 그룹의 포트, 그리고 인스턴스의 포트를 필요에 따라 다르게 설정하여 유연한 트래픽 관리가 가능하다/

---

**참고 자료**:
- [Network Load Balancer 대상 그룹](https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/network/load-balancer-target-groups.html)
- [AWS 로드 밸런서 컨트롤러의 Ingress 공유 및 대상 그룹 바인딩 자세히 살펴보기](https://aws.amazon.com/ko/blogs/tech/a-deeper-look-at-ingress-sharing-and-target-group-binding-in-aws-load-balancer-controller/)

 

 

 

AWS의 **Application Load Balancer(ALB)**와 **Network Load Balancer(NLB)**는 각각의 특성과 용도로 사용되는 로드 밸런서입니다. 아래 표를 통해 두 로드 밸런서의 주요 차이점을 정리하였습니다.

특징Application Load Balancer (ALB)Network Load Balancer (NLB)

OSI 계층	7계층 (애플리케이션 계층)	4계층 (전송 계층)
지원 프로토콜	HTTP, HTTPS, gRPC	TCP, UDP, TLS
라우팅 기능	- 호스트 기반 라우팅 - 경로 기반 라우팅 - HTTP 헤더 및 메서드 기반 라우팅 - 쿼리 문자열 및 쿠키 기반 라우팅	- 단순한 레벨의 라우팅
대상(Target) 유형	- EC2 인스턴스 - 컨테이너 (ECS) - Lambda 함수 - IP 주소	- EC2 인스턴스 - IP 주소 - ALB
지연 시간(Latency)	애플리케이션 계층에서의 처리로 인해 상대적으로 높음	패킷 수준에서의 처리로 인해 매우 낮음
고정 IP 지원	지원하지 않음	Elastic IP를 통해 고정 IP 지원
사용 사례	- 웹 애플리케이션 - 마이크로서비스 - 컨테이너화된 애플리케이션	- 초당 수백만 요청을 처리해야 하는 애플리케이션 - 낮은 지연 시간이 중요한 애플리케이션 - 고정 IP가 필요한 경우

ALB는 HTTP/HTTPS 트래픽에 대한 고급 라우팅 기능을 제공하여 웹 애플리케이션에 적합하며, NLB는 TCP/UDP 트래픽을 고속으로 처리하고 고정 IP를 제공하여 낮은 지연 시간과 고성능이 요구되는 애플리케이션에 적합합니다.

 

https://aws.amazon.com/ko/compare/the-difference-between-the-difference-between-application-network-and-gateway-load-balancing/

 

---

 

 

Application Load Balancer(ALB)와 Network Load Balancer(NLB)는 각각 7계층(애플리케이션 계층)과 4계층(전송 계층)에서 동작하며, 트래픽 분산 방식과 세션 처리 방식에서 차이가 있다.

 

ALB의 트래픽 분산 및 세션 처리

• 트래픽 분산: ALB는 HTTP/HTTPS 프로토콜의 헤더 정보를 기반으로 요청을 분석하여, 라운드 로빈(Round Robin) 방식 등으로 트래픽을 여러 대상(Target) 서버에 분산한다.
• 세션 처리: ALB는 스티키 세션(Sticky Session) 기능을 지원하여, 특정 클라이언트의 요청을 동일한 대상 서버로 지속적으로 전달할 수 있다. 이는 ALB가 자체적으로 생성한 쿠키를 통해 구현되며, 이를 활성화하면 사용자의 세션이 유지되어 매 요청마다 동일한 서버로 연결된다.

스티키 세션(Sticky Session)은 AWS Application Load Balancer(ALB)에서 특정 사용자의 요청을 동일한 백엔드 인스턴스(타겟)에 지속적으로 전달하도록 하는 기능

이를 통해 세션 유지가 필요한 웹 애플리케이션(예: 로그인 상태 유지, 쇼핑 카트 데이터 유지 등)에서 세션 데이터의 일관성을 유지할 수 있다.

 

NLB의 트래픽 분산 및 세션 처리

• 트래픽 분산: NLB는 TCP/UDP 프로토콜의 연결 정보를 기반으로 트래픽을 분산한다. 기본적으로 소스 IP 주소와 포트, 대상 IP 주소와 포트, 그리고 TCP 시퀀스 번호 등의 조합을 해시하여 특정 대상 서버로 트래픽을 전달한다.
• 세션 처리: NLB는 고정성(Stickiness) 기능을 제공하여, 클라이언트의 소스 IP 주소를 기반으로 동일한 클라이언트의 요청을 동일한 대상 서버로 전달할 수 있다. 그러나 이 기능은 기본적으로 비활성화되어 있으며, 활성화하더라도 세션 유지 시간에 제한이 있다.

 

요약

• ALB: HTTP/HTTPS 헤더 정보를 기반으로 트래픽을 분산하며, 스티키 세션을 통해 클라이언트의 세션을 유지할 수 있다.
• NLB: TCP/UDP 연결 정보를 기반으로 트래픽을 분산하며, 소스 IP 기반의 고정성 기능을 통해 동일한 클라이언트의 요청을 동일한 서버로 전달할 수 있지만, 세션 유지 시간에 제한이 있습니다.

따라서, ALB는 웹 애플리케이션과 같이 세션 유지를 필요로 하는 서비스에 적합하며, NLB는 낮은 지연 시간과 고성능이 요구되는 서비스에 적합하다.