Day 4 - 트래픽을 분산하는 layer: ALB·NLB·GWLB, 그리고 Auto Scaling Group

처음 ALB를 만들고 EC2를 두 대 붙여보면 신기하다. 같은 URL로 요청을 보내는데 절반은 A 서버, 절반은 B 서버에 도착한다. CPU가 튀면 ASG가 알아서 인스턴스를 늘리고, 하나가 죽으면 새로 띄운다. 이 마법 뒤에는 health check 알고리즘, target group의 internal state machine, ASG의 reconciliation loop가 정밀하게 동작하고 있다.

오늘은 ALB와 NLB가 정확히 어느 OSI layer에서 어떤 routing 결정을 하는지, ASG가 새 인스턴스를 어떻게 "InService"로 만드는지, Blue/Green 배포가 ALB target group weighted routing으로 어떻게 구현되는지를 본다. 같은 "로드 밸런서"라는 단어 안에 latency·throughput·sticky·SSL termination·cross-zone billing이 모두 다른 trade-off로 들어 있고, 그 차이가 시험에서 정답을 가른다.

ALB는 L7이고 NLB는 L4 — 그 의미를 끝까지 보기

흔한 답은 "ALB는 7계층, NLB는 4계층"이다. 그 차이가 실무·시험에서 정확히 어떻게 갈리는지 정리한다.

ALB(Application Load Balancer) 는 HTTP/HTTPS의 의미를 안다. URL path, host header, query string, HTTP header, cookie를 읽어 routing 결정을 할 수 있다. SSL termination을 ALB에서 하면 backend는 plain HTTP로 받는다. WebSocket upgrade도 지원. ALB는 X-Forwarded-For, X-Forwarded-Proto 헤더를 추가해 backend에 client 정보를 전달한다.

NLB(Network Load Balancer) 는 TCP/UDP/TLS 패킷을 본다. HTTP 의미를 모르므로 path나 header 기반 routing이 안 된다. 대신 client의 source IP가 그대로 backend에 전달(connection passthrough)되므로, backend가 client IP를 직접 본다(ALB는 X-Forwarded-For 헤더를 봐야 함). TLS termination도 가능하지만 더 흔한 패턴은 TLS passthrough(backend가 자체 인증서). 초당 수백만 connection, microsecond-level latency.

GWLB(Gateway Load Balancer), 2020년 출시. L3 GENEVE 프로토콜 기반으로 보안 어플라이언스(방화벽, IDS, DPI)를 투명하게 traffic path에 삽입한다. VPC traffic을 third-party Palo Alto/Fortinet 어플라이언스로 inspection한 뒤 원래 경로로 돌려보낸다. 키워드는 "투명한 보안 어플라이언스 inserting".

ALB의 LCU(Load Balancer Capacity Unit) 과금은 4가지 차원 중 가장 큰 값으로 청구된다. ① 새 연결 25개/초, ② 활성 연결 3000개, ③ 1 GB 처리 데이터, ④ 1000 rule evaluations/초. 그래서 단순 트래픽 양만 보지 말고 connection churn(짧은 connection이 많은지)을 같이 봐야 비용 예측이 정확하다. NLB의 NLCU는 ① 새 flow 800개/초, ② 활성 flow 100K, ③ 1 GB 처리 데이터의 max로 청구되고, ALB보다 connection 한도가 훨씬 크다.

ALB의 routing rule: rule evaluation의 내부

ALB의 listener는 rule list를 priority 순으로 평가한다. 한 rule이 matching되면 그 action이 적용되고 나머지는 평가하지 않는다(short-circuit). 최대 100개 rule 가능(soft limit 1000까지 증액).

import boto3
elbv2 = boto3.client('elbv2', region_name='ap-northeast-2')
 
# Rule 1: path /api/* → api-tg
elbv2.create_rule(
    ListenerArn='arn:aws:elasticloadbalancing:...:listener/app/.../443/abc',
    Priority=10,
    Conditions=[{
        'Field': 'path-pattern',
        'PathPatternConfig': {'Values': ['/api/*']}
    }],
    Actions=[{
        'Type': 'forward',
        'TargetGroupArn': 'arn:aws:...:targetgroup/api-tg/...'
    }]
)
 
# Rule 2: host admin.* → admin-tg
elbv2.create_rule(
    Priority=20,
    Conditions=[{
        'Field': 'host-header',
        'HostHeaderConfig': {'Values': ['admin.example.com']}
    }],
    Actions=[{'Type': 'forward', 'TargetGroupArn': 'arn:...:targetgroup/admin-tg/...'}]
)
 
# Rule 3: Blue/Green canary — 90% Blue, 10% Green
elbv2.create_rule(
    Priority=30,
    Conditions=[{'Field': 'path-pattern', 'PathPatternConfig': {'Values': ['/*']}}],
    Actions=[{
        'Type': 'forward',
        'ForwardConfig': {
            'TargetGroups': [
                {'TargetGroupArn': 'arn:...:blue-tg', 'Weight': 90},
                {'TargetGroupArn': 'arn:...:green-tg', 'Weight': 10}
            ]
        }
    }]
)

이 weighted forward가 ALB-native Canary 및 Blue/Green 배포의 핵심이다. CodeDeploy도 내부적으로 이 weighted target group을 시간에 따라 조정하는 방식으로 동작한다. 시험에 "ALB로 Blue/Green 배포"라는 시나리오가 나오면 답은 "두 target group + weighted forward".

ALB가 지원하는 condition 종류는 host-header, path-pattern, http-request-method, source-ip, http-header, query-string의 6가지. 그 중 http-header 조건은 client가 보낸 임의의 HTTP header(예: X-Tenant-Id)로 routing 가능해서 multi-tenant SaaS의 tenant 분기에 쓰인다. 또 source-ip 조건은 ALB의 LCU 계산에 영향을 주는 무거운 condition이라 너무 많이 쓰면 비용이 튄다.

⚠️ 함정: ALB의 path-pattern은 글로브 패턴이지 regex가 아니다. /api/*는 매치되지만 /api/v[1-2]/* 같은 regex는 안 된다. 또 case-sensitive다(/API/*는 매치 안 됨). 시험에 "ALB rule로 정규식 매칭"이라는 보기가 나오면 오답.

Target Group과 health check: stateful한 상태 머신

Target group은 단순한 backend 목록이 아니라 각 target에 대한 health state machine을 가진다.

[Target lifecycle]

  initial ──▶  registering ──▶  initial(health check 시작)
                                       │
                                       ▼
                               (interval마다 헬스체크)
                                       │
                                       ├──▶ healthy threshold 통과 ──▶  healthy
                                       └──▶ unhealthy threshold 도달 ──▶ unhealthy
                                                                          │
                                                                          ▼
                                                              deregistering(draining)
                                                                          │
                                                                          ▼
                                                                       unused

이 파라미터들의 의미를 알아야 계산 문제를 풀 수 있다. 예를 들어 HealthyThresholdCount=5, IntervalSeconds=30이면 새 인스턴스가 healthy로 인정받는 데 최소 150초가 걸린다. 그래서 ASG의 HealthCheckGracePeriod는 이 값보다 커야 한다(보통 300초).

Deregistration delay (connection draining): target이 unhealthy로 판단되거나 ASG가 scale-in할 때, ALB는 즉시 그 target에 새 요청을 안 보내지만 in-flight 요청이 끝날 때까지 300초(기본) 동안 기다린다. 0으로 설정하면 502 발생 위험, 너무 길면 scale-in이 지연된다. ASG의 lifecycle hook과 결합하면 정확한 graceful shutdown 가능.

Health check의 종류는 두 가지다. ① ELB-based (기본): target group 자체의 health check가 직접 결정. ② ASG-driven: ASG가 HealthCheckType=ELB일 때 ELB의 health 결과를 사용. 후자가 켜져 있으면 ELB가 unhealthy로 판단한 인스턴스를 ASG가 자동으로 종료하고 새 인스턴스를 생성한다. 이게 "self-healing" 동작의 핵심. 켜져 있지 않으면 ELB는 traffic을 안 보내지만 인스턴스 자체는 계속 살아 있어 비용이 낭비된다.

Auto Scaling Group: reconciliation loop의 내부

ASG는 단순히 "인스턴스 수를 늘리고 줄인다"가 아니라 desired capacity를 현재 상태와 일치시키는 reconciliation loop를 돈다. 이 모델은 Kubernetes의 controller pattern과 같은 발상이다.

[ASG reconciliation loop, 매 분]

  현재 InService 인스턴스 수 = N
       │
       ▼
  Desired capacity = D
       │
       ├──▶ N < D : 새 인스턴스 생성 (launch template 사용)
       │         │
       │         ▼
       │     Pending → Pending:Wait (lifecycle hook이 있으면)
       │         │
       │         ▼
       │     사용자 작업 (S/W 설치, warming up)
       │         │
       │         ▼
       │     CompleteLifecycleAction
       │         │
       │         ▼
       │     InService (target group에 등록)
       │
       └──▶ N > D : 인스턴스 종료
                 │
                 ▼
             Terminating:Wait (lifecycle hook이 있으면)
                 │
                 ▼
             사용자 작업 (로그 수집, graceful shutdown)
                 │
                 ▼
             Terminated

Lifecycle Hook의 가치: 새 인스턴스가 부팅되고 user-data가 끝나도, 애플리케이션이 실제로 traffic을 받을 준비가 안 됐을 수 있다(JVM warm-up, cache pre-fill, model loading). lifecycle hook으로 "Pending:Wait" 상태에 일정 시간(또는 명시적 CompleteLifecycleAction까지) 머물게 한 뒤 InService로 보내면, target group에 등록되는 시점에 이미 fully warmed up 상태.

import boto3
asg = boto3.client('autoscaling', region_name='ap-northeast-2')
 
# Lifecycle hook 등록
asg.put_lifecycle_hook(
    LifecycleHookName='warmup-hook',
    AutoScalingGroupName='my-asg',
    LifecycleTransition='autoscaling:EC2_INSTANCE_LAUNCHING',
    DefaultResult='ABANDON',  # 시간 초과 시 인스턴스 폐기
    HeartbeatTimeout=600,  # 10분까지 대기
    NotificationTargetARN='arn:aws:sqs:...:warmup-queue',
    RoleARN='arn:aws:iam:...:role/asg-hook-role'
)
 
# 인스턴스 안에서 warmup 완료 후 호출
asg.complete_lifecycle_action(
    LifecycleHookName='warmup-hook',
    AutoScalingGroupName='my-asg',
    InstanceId='i-0abc',
    LifecycleActionResult='CONTINUE'
)

Scaling Policy의 5가지: 어떤 걸 언제 쓰는가

Target Tracking의 내부: AWS가 운영하는 PID controller 비슷한 알고리즘이 지표를 모니터링하면서 자동으로 desired capacity를 조정한다. 사용자는 "CPU 50%"만 명시하면 끝. 가장 권장되는 정책이고 새 워크로드의 default. 다만 여러 metric에 대해 Target Tracking이 동시에 켜져 있으면 가장 보수적인(=더 많이 키우는) 결정이 채택되므로, "CPU 50%"와 "RequestCount 1000"이 동시에 켜져 있으면 둘 다 만족할 때까지 인스턴스를 늘린다.

Step Scaling이 필요한 경우: 부하 급증 시 단순 +1로는 안 따라잡을 때. 예를 들어 e-commerce sale 시작 시 RPS가 5초 만에 10배가 되면 Target Tracking이 1대씩 추가하다 못 따라잡는다. Step Scaling으로 "임계값 90% 이상이면 +5"처럼 공격적으로 늘리는 게 필요.

⚠️ 함정: Scaling policy의 cooldown period는 다음 scaling action까지 대기 시간이다. Simple Scaling에만 적용되고, Target Tracking/Step Scaling에는 적용 안 된다. 시험에서 "Cooldown이 너무 짧아서 thrashing"이라는 시나리오가 나오면 Simple Scaling을 의심. 또 ASG의 HealthCheckGracePeriod는 cooldown과 다른 개념이다. 새 인스턴스가 unhealthy로 표시되더라도 grace period 안에는 종료되지 않는다(boot 중인 인스턴스를 죽이지 않기 위해).

Predictive Scaling은 2018년 출시. 일주일 분량의 CloudWatch 지표를 보고 같은 요일·시간대의 패턴을 학습한다. 그래서 매일 9시에 traffic이 spike한다는 패턴이 있으면 8:30에 미리 인스턴스를 띄워 traffic이 도착할 때 이미 warmed up 상태. Target Tracking과 결합 가능(Predictive로 미리 띄우고, 예측 못 한 부분은 Target Tracking이 따라잡음). 단 충분한 학습 데이터(최소 24시간)가 필요하고, traffic 패턴이 random하면 효과가 떨어진다.

Mixed Instance Policy: Spot + 온디맨드의 혼합

production에서 Spot 90% 절감을 살리려면 ASG의 Mixed Instance Policy가 필요하다. Base capacity는 안정성을 위해 On-Demand, 그 위 capacity는 Spot으로 채운다.

asg.create_auto_scaling_group(
    AutoScalingGroupName='mixed-asg',
    MinSize=4, MaxSize=20, DesiredCapacity=10,
    MixedInstancesPolicy={
        'LaunchTemplate': {
            'LaunchTemplateSpecification': {
                'LaunchTemplateName': 'web-template',
                'Version': '$Latest'
            },
            'Overrides': [
                {'InstanceType': 'c5.large'},
                {'InstanceType': 'c5a.large'},
                {'InstanceType': 'c5n.large'},
                {'InstanceType': 'm5.large'}
            ]
        },
        'InstancesDistribution': {
            'OnDemandBaseCapacity': 2,           # 최소 2개는 항상 On-Demand
            'OnDemandPercentageAboveBaseCapacity': 30,  # 위에서는 30% On-Demand
            'SpotAllocationStrategy': 'capacity-optimized',  # 가장 안정적인 풀
            'SpotInstancePools': 4  # lowest-price 전략일 때만 의미
        }
    },
    VPCZoneIdentifier='subnet-aaa,subnet-bbb,subnet-ccc'
)

SpotAllocationStrategy의 4가지:

• lowest-price: 가장 싼 풀에서 가져옴. 회수 위험 높음
• capacity-optimized: 가장 capacity가 많은 풀(=회수 가능성 낮은 풀) 선호. 새 워크로드 기본 권장
• capacity-optimized-prioritized: 우선순위 명시 + capacity 우선
• price-capacity-optimized: 2022년 추가. 가격 + capacity 균형. 가장 추천되는 모던 default

SSL/TLS termination과 SNI

ALB의 HTTPS listener는 SSL/TLS termination을 한다. ACM(AWS Certificate Manager)에서 무료 발급한 인증서를 attach하면 자동 갱신까지 된다. SNI(Server Name Indication) 지원으로 한 ALB listener에 여러 도메인의 인증서를 동시 등록 가능 — api.example.com과 app.example.com이 다른 인증서를 쓰지만 같은 ALB로 처리된다.

ALB의 SSL Policy는 TLS 버전과 cipher suite 조합을 결정한다. ELBSecurityPolicy-TLS13-1-2-2021-06은 TLS 1.3 + 1.2를 지원하며 forward secrecy 보장. PCI-DSS·HIPAA 같은 규제 환경에선 명시적으로 TLS 1.2+ 정책 선택해야 한다. ALB는 2023년부터 mTLS(mutual TLS, client certificate validation) 지원. 이전엔 NLB + 자체 TLS termination이 필요했지만 이제 ALB가 직접 client 인증서를 ACM Private CA로 검증.

Cross-Zone Load Balancing: 비용에 직결되는 함정

ALB는 cross-zone load balancing이 기본 ON·무료. NLB는 기본 OFF·활성화 시 cross-AZ data transfer 비용(GB당 $0.01).

[Cross-zone OFF, NLB 기본]
  AZ-a NLB node ── AZ-a target만
  AZ-b NLB node ── AZ-b target만
  → AZ별 target 수가 다르면 불균등 부하

[Cross-zone ON]
  AZ-a NLB node ── AZ-a, AZ-b, AZ-c target 모두
  → 균등 부하, 단 cross-AZ traffic 발생

NLB의 cross-zone OFF 기본값은 latency·비용을 우선하는 선택이지만, AZ별 target 수가 다르면 부하 불균등이 생긴다. ALB는 이미 cross-zone이 무료라 항상 켜져 있다.

Sticky Session: 언제 켜고 언제 끄는가

stateless application이라면 sticky session은 불필요하다. 그러나 session을 backend memory에 저장하는 legacy app, WebSocket connection이 특정 backend에 묶여야 하는 chat·gaming, 큰 model을 lazy load하는 ML inference 같은 경우 sticky가 필요하다.

Application-based는 2019년 추가된 기능으로 ALB가 자기 쿠키를 만들지 않고 백엔드가 보낸 쿠키를 그대로 본다. ALB는 그 쿠키를 hash해 target 결정. 그래서 ALB의 행동을 백엔드 코드에서 통제 가능.

NLB의 source IP affinity는 NAT 뒤의 사용자에게 부정확. 한 회사 사무실의 모든 사용자가 같은 NAT IP로 보이면 한 backend에 부하 쏠림. 또 모바일 사용자는 IP가 자주 바뀌므로 affinity가 깨진다. 이런 경우 sticky 자체를 application layer(JWT, session store)로 옮기는 게 정석.

ALB → Lambda 직접 호출

ALB의 target type으로 Lambda 함수를 등록 가능(2018년 11월 추가). API Gateway 없이 ALB → Lambda로 HTTP API를 노출할 수 있다.

비용은 ALB가 더 저렴한 게 일반적이지만, 외부 공개 API라면 API Gateway의 throttling/key/swagger가 큰 가치를 준다.

ALB → Lambda 통합은 ALB가 HTTP 요청을 Lambda invocation event로 변환해 Lambda를 동기 호출하는 구조다. Lambda는 ALB의 target group에 등록되고, ALB는 Lambda의 RequestResponse mode로 호출한다. Lambda response가 HTTP response로 변환돼 client에 반환된다. 같은 함수를 API Gateway에서도 호출할 수 있고 두 호출의 event 형식이 다르다는 점에 주의한다.

CLI 종합

# ALB 생성 + listener + target group
aws elbv2 create-load-balancer \
  --name web-alb \
  --subnets subnet-aaa subnet-bbb subnet-ccc \
  --security-groups sg-12345 \
  --scheme internet-facing \
  --type application \
  --ip-address-type ipv4
 
aws elbv2 create-target-group \
  --name web-tg \
  --protocol HTTP --port 80 \
  --vpc-id vpc-12345 \
  --health-check-protocol HTTP \
  --health-check-path /healthz \
  --health-check-interval-seconds 15 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 2 \
  --target-type instance
 
aws elbv2 create-listener \
  --load-balancer-arn $ALB_ARN \
  --protocol HTTPS --port 443 \
  --certificates CertificateArn=$ACM_ARN \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --default-actions Type=forward,TargetGroupArn=$TG_ARN
 
# Auto Scaling Group with Mixed Instance Policy
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --mixed-instances-policy file://mixed-policy.json \
  --min-size 2 --max-size 20 --desired-capacity 4 \
  --vpc-zone-identifier "subnet-aaa,subnet-bbb,subnet-ccc" \
  --target-group-arns $TG_ARN \
  --health-check-type ELB \
  --health-check-grace-period 300
 
# Target Tracking scaling policy
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-name cpu-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 50.0,
    "DisableScaleIn": false
  }'
 
# 또는 ALB request count 기준 (더 정확한 traffic-driven scaling)
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-name request-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "app/web-alb/abc/targetgroup/web-tg/xyz"
    },
    "TargetValue": 1000.0
  }'

정리

오늘 본 그림은 세 가지다. 첫째, ALB는 L7 HTTP 의미를 알고 URL·host·header·cookie 기반 routing을 한다. NLB는 L4로 TCP/UDP를 microsecond latency로 passthrough하며 고정 IP를 제공한다. GWLB는 보안 어플라이언스를 투명하게 inserting할 때 쓴다. 둘째, ASG는 desired capacity를 향한 reconciliation loop를 돌고, lifecycle hook으로 warmup·graceful shutdown을 정확히 통제한다. Target Tracking이 새 워크로드의 default scaling policy. 셋째, Mixed Instance Policy + capacity-optimized Spot이 production-grade 비용 최적화의 표준 패턴이다.

다음 글에서는 Week 2 전체를 종합 정리하고, EC2 layer의 진짜 통합 시나리오 — 즉 SG·EBS·ELB·ASG가 한 아키텍처 안에서 어떻게 맞물리는지를 본다.

📌 오늘의 요약

1. ALB는 L7(HTTP path/host/header/cookie routing, ACM 통합, Lambda 타겟), NLB는 L4(TCP/UDP/TLS, 고정 EIP, microsecond latency), GWLB는 보안 어플라이언스 inserting.
2. Target Group은 health check 기반 stateful 상태머신. ASG와 HealthCheckType=ELB로 결합하면 self-healing.
3. ASG는 desired capacity를 향한 reconciliation loop. Lifecycle hook으로 warmup·graceful shutdown 정확 통제.
4. Target Tracking이 새 워크로드의 default scaling policy. Predictive는 패턴이 명확한 워크로드의 보조.
5. Mixed Instance Policy + capacity-optimized/price-capacity-optimized allocation이 Spot production-grade 표준.
6. ALB cross-zone은 기본 ON·무료, NLB는 기본 OFF·켜면 cross-AZ data transfer 비용. Sticky는 ALB는 쿠키 기반(Duration/Application), NLB는 Source IP affinity.