AWS 네트워크 계층으로 읽기

시리즈 소개
AWS EC2 Auto Scaling 실습 하나를 OSI 7계층 / TCP/IP 4계층 관점으로 한 챕터씩 뜯어보는 5부작입니다.
#1 VPC·서브넷·라우팅 — L3 토대
#2 보안 그룹 vs NACL — L4 방화벽
#3 (이번 편) ALB 완전 분석 — L7 로드밸런서 (vs NLB) ← 현재 위치
#4 Auto Scaling Group + Launch Template — 자동 증감의 본체
#5 CloudWatch 동적 스케일링 + 부하 테스트로 증명하기

실습 환경: 서울 리전(ap-northeast-2) · CloudFormation(ASG_LAB.yaml) 기반

0. 공통 지도 — OSI 7계층 / TCP/IP 4계층 (매 편 반복)

 

OSI 7계층 TCP/IP 4계층 핵심 단위 대표 예시 이 시리즈에서
7. 응용 4. 응용 데이터 HTTP, DNS ★이번 편: ALB·Listener·헬스체크 경로
6. 표현 4. 응용 데이터 TLS (HTTPS 쓸 때)
5. 세션 4. 응용 데이터 세션 ALB 세션 유지
4. 전송 3. 전송 세그먼트 TCP, UDP, 포트 보안 그룹(2편), NLB
3. 네트워크 2. 인터넷 패킷 IP, 라우팅 VPC·서브넷(1편)
2. 데이터링크 1. 네트워크 접근 프레임 MAC ENI
1. 물리 1. 네트워크 접근 비트 케이블 데이터센터

이번 편의 자리: 최상위 L7(응용 계층). 여기서 처음으로 트래픽의 내용(HTTP) 을 이해합니다.

1. 왜 L7인가 — "내용을 읽는" 분배기

L4 NLB vs L7 ALB 비유 — 봉투만 읽기 vs 내용 읽기

2편의 보안 그룹은 "어느 포트로 왔는가(L4)"만 봤습니다.

80번 포트면 통과, 끝.

그 안에 담긴 HTTP 요청이 /login인지 /images/cat.png인지는 관심 없습니다.

 

그런데 ALB(Application Load Balancer)는 다릅니다.

ALB는 HTTP 요청을 뜯어서 그 내용(URL 경로, 호스트 이름, 헤더, 쿠키)을 읽고 어디로 보낼지 결정합니다.

이게 L7(응용 계층) 로드밸런서의 정의입니다.

 

비유하면:

  • L4 분배기(NLB) = 우체국 분류기. 봉투의 주소(IP·포트)만 보고 지역별로 나눔. 안 열어봄.
  • L7 분배기(ALB) = 비서. 편지를 열어 내용을 읽고 "이건 회계팀, 이건 인사팀" 하고 정확히 전달.

2. ALB 구조 — Listener → Rule → Target Group → Target

ALB 트래픽 흐름 — Listener·Rule·Target Group·EC2

ASG_LAB.yaml이 만든 ALB 구조를 위에서 아래로 봅시다.

ALB:                                   # ① 로드밸런서 본체
  Type: AWS::ElasticLoadBalancingV2::LoadBalancer
  Scheme: internet-facing              # 인터넷에서 접근 가능
  SecurityGroups: [ !Ref VPC1SG ]
  Subnets:                             # 2개 AZ 서브넷에 걸침 (고가용성)
    - !Ref VPC1PublicSN1
    - !Ref VPC1PublicSN2

ALBListener:                           # ② 리스너 — 요청을 받는 귀
  Port: 80
  Protocol: HTTP
  DefaultActions:
    - Type: forward                    # ③ 규칙 — Target Group으로 전달
      TargetGroupArn: !Ref ALBTG

ALBTG:                                 # ④ Target Group — 대상 명단 + 헬스체크
  Type: AWS::ElasticLoadBalancingV2::TargetGroup
  Port: 80
  Protocol: HTTP
  HealthCheckPath: '/HealthCheck.txt'  # ★ L7 헬스체크 (URL 경로!)
  HealthCheckIntervalSeconds: 10
  HealthyThresholdCount: 3
  UnhealthyThresholdCount: 3
  TargetGroupAttributes:
    - Key: deregistration_delay.timeout_seconds
      Value: '60'

흐름을 정리하면:

사용자 HTTP 요청 (:80)
   ▼
[Listener] HTTP:80 — "80번 HTTP 요청을 받는 귀"
   ▼
[Rule] 기본 규칙: 전부 ALB-TG로 forward
   ▼
[Target Group ALB-TG] 건강한 대상에게 분배 + /HealthCheck.txt로 건강검진
   ▼
[Targets] 여러 EC2 웹 서버 (4편 ASG가 자동 등록)

ALB 리소스 맵


EC2 콘솔 > 로드 밸런서 > ASG-ALB > 리소스 맵: 리스너(HTTP:80) → 규칙 → 대상 그룹 → 대상으로 이어지는 화면. 

L7의 결정적 증거 — /HealthCheck.txt

Target Group의 헬스체크 경로가 /HealthCheck.txt라는 URL 경로라는 점에 주목하세요.

경로(path)는 HTTP에만 존재하는 L7 개념입니다.

ALB는 주기적으로 각 서버에 GET /HealthCheck.txt 요청을 실제로 보내서, HTTP 200 응답이 오는지로 건강을 판단합니다.

 

만약 ALB가 L4 장비였다면 "80번 포트가 열려 있나"까지만 봤을 겁니다.

하지만 ALB는 "80번 포트로 실제 HTTP 요청을 보내 200이 오나"까지 봅니다.

이 차이가 L4와 L7을 가릅니다.

Target Group 헬스체크 파라미터 읽기

  • HealthCheckIntervalSeconds: 10 — 10초마다 검사
  • HealthyThresholdCount: 3 — 3번 연속 성공해야 "정상" 등록
  • UnhealthyThresholdCount: 3 — 3번 연속 실패해야 "비정상" 제외
  • deregistration_delay: 60 — 대상을 뺄 때 진행 중인 요청을 위해 60초 기다림(connection draining). 갑자기 끊어 사용자 요청이 끊기는 걸 방지

3. ALB vs NLB vs CLB — 무엇을 보고 분배하나

ALB vs NLB vs CLB 비교

구분 동작 계층 무엇을 보고 분배하나 고정 IP 언제 쓰나
ALB  L7 URL 경로, 호스트명, 헤더, 쿠키 ✗(DNS) 웹/API, 경로 기반 라우팅, 마이크로서비스
NLB  L4 IP + TCP/UDP 포트만 ✓ 초고성능·초저지연, 고정 IP 필요, 비-HTTP(게임·IoT·금융)
CLB (Classic) L4/L7 혼합 (구형) ✗ 레거시. 신규 설계 비권장

이 실습이 ALB를 선택한 이유

만드는 게 웹 서버(HTTP:80) 이고, /HealthCheck.txt라는 경로 기반 헬스체크가 필요하기 때문입니다.

나아가 실무에선 /api는 백엔드로, /img는 이미지 서버로 보내는 경로 라우팅, shop.example.com과 blog.example.com을 나누는 호스트 라우팅 같은 L7 기능이 자주 필요합니다.

전부 ALB의 영역입니다.

 

반대로 초당 수백만 TCP 연결을 고정 IP로 받아야 하거나(게임 서버, 금융 트레이딩), HTTP가 아닌 프로토콜이라면 NLB(L4)가 정답입니다.

즉 "트래픽의 내용을 읽어야 하면 ALB, 주소만 보고 빠르게 넘기면 NLB" 입니다.

 

ALB(L7) vs NLB(L4) 비교 개념도


"ALB는 봉투를 열어 URL을 읽고, NLB는 주소만 보고 넘긴다"를 시각화하면 좋습니다.

4. internet-facing과 다중 AZ

  • Scheme: internet-facing — 공인 IP를 가져 인터넷에서 접근 가능(반대는 internal, VPC 내부 전용).
  • Subnets: [SN1, SN2] — ALB를 2개 AZ 서브넷에 걸쳐 배치. AWS가 각 AZ에 ALB 노드를 두고, 한 AZ가 죽어도 다른 노드가 서비스를 이어갑니다. 1편에서 서브넷을 두 AZ로 나눈 설계가 여기서 빛을 발합니다.

HTTP 503의 의미 (실습 팁)

ASG를 붙이기 전, ALB에 접속하면 HTTP 503이 뜹니다. 이는 "Listener·Rule은 정상인데 Target Group에 건강한 대상이 0개"라는 뜻입니다. 4편에서 ASG가 인스턴스를 등록하고 /HealthCheck.txt가 통과하면 503이 사라지고 정상 응답이 옵니다. 503 = 백엔드 없음으로 기억하면 디버깅이 빨라집니다.

5. 이번 편 계층 종합표

구성요소 YAML 리소스 동작 계층(OSI) TCP/IP 근거 한 줄 역할
ALB ElasticLoadBalancingV2::LoadBalancer L7 응용 HTTP 내용 기반 분배 L7 트래픽 분배기
Listener(HTTP:80) ...::Listener L7 응용 HTTP 프로토콜 수신 요청 받는 귀
Target Group ...::TargetGroup L4~L7 전송~응용 포트(L4)+경로 헬스체크(L7) 대상 명단+건강검진
헬스체크 /HealthCheck.txt HealthCheckPath L7 응용 URL 경로 실제 HTTP 건강검진
(참고) NLB — L4 전송 IP+포트만 TCP/UDP 분배기

 

한 문장 요약: L4가 "포트(문)를 열지"였다면, L7은 "문 안으로 들어온 편지(HTTP)의 내용을 읽고 정확히 배달"하는 계층입니다. ALB가 URL 경로로 헬스체크하고 라우팅하는 것이 그 증거입니다.

6. 실습 핵심 수치 (이번 편)

  • ALB: ASG-ALB, internet-facing, 2개 AZ 서브넷(SN1·SN2)
  • Listener: HTTP:80 → ALB-TG로 forward
  • Target Group: ALB-TG, HTTP:80, 헬스체크 /HealthCheck.txt, interval 10초, threshold 3/3, deregistration delay 60초
  • 대상 0개일 때 → HTTP 503

다음 편 예고

#4에서는 드디어 자동 증감의 본체로 들어갑니다.

Launch Template(서버 붕어빵 틀)으로 "어떤 서버를 찍을지"를 정의하고, Auto Scaling Group이 그 틀로 인스턴스를 자동으로 늘렸다 줄였다 하며, 이번 편에서 만든 ALB Target Group에 자동 등록되는 과정을 다룹니다.

특히 ELB(L7) 헬스체크를 켜는 이유가 핵심입니다.

이번 편 한 줄 복습: L7은 트래픽의 "내용(HTTP)"을 읽는 계층 — ALB는 URL 경로로 헬스체크·라우팅하는 L7 분배기이고, IP·포트만 보는 NLB(L4)와 갈린다.

 

시리즈 #3 끝 · 다음 편: Auto Scaling Group + Launch Template — 자동 증감의 본체

저작자표시 (새창열림)

'클라우드 컴퓨팅 > AWS' 카테고리의 다른 글

[AWS 네트워크 계층으로 읽기 #4] Auto Scaling Group + Launch Template — 자동 증감의 본체  (0) 2026.06.15
[AWS 네트워크 계층으로 읽기 #2] 보안 그룹 vs NACL — L4 방화벽의 원리  (0) 2026.06.15
[AWS 네트워크 계층으로 읽기 #1] VPC·서브넷·라우팅 — 클라우드의 L3 토대 짓기  (0) 2026.06.15
실습 2-4 _ ELB 실습 ④편 — 출발지 IP 보존  (1) 2026.06.09
실습 2-2 _ ELB 실습 ②편 — ALB  (0) 2026.06.08

티스토리툴바