로드 밸런싱과 오토스케일링

로드 밸런서 3종 — 계층이 선택을 결정한다 SAA 빈출

Elastic Load Balancing은 현재 세 가지 로드 밸런서를 제공합니다. API의 타입 값도 정확히 세 개(application, network, gateway)입니다. 셋을 가르는 것은 이름이 아니라 어느 계층에서 트래픽을 보는가이고, 그 결과가 지원 프로토콜로 드러납니다.

Application Load Balancer — 요청 내용을 보고 나눈다

ALB는 HTTP 요청을 열어 보고 라우팅합니다. 그래서 경로 기반(/api/*는 API 타깃 그룹, /static/*은 정적 타깃 그룹)과 호스트 기반(a.example.com과 b.example.com을 한 로드 밸런서로) 분기가 가능합니다. 같은 이유로 TLS 종료, Amazon Cognito · OIDC 인증 연동, HTTP에서 HTTPS로의 리디렉션, 고정 응답 반환 같은 L7 기능이 여기에 붙습니다.

ALB의 로드 밸런싱 알고리즘은 기본이 라운드 로빈(round_robin)이고, least_outstanding_requests(미처리 요청이 가장 적은 대상)와 weighted_random을 고를 수 있습니다. 요청마다 처리 시간이 크게 다른 애플리케이션에서는 미처리 요청 기준이 더 고르게 분산됩니다. 유휴 제한 시간(idle_timeout.timeout_seconds)은 기본 60초이고 1초에서 4000초 사이로 조정합니다.

Network Load Balancer — 고정 IP가 필요하면 여기

NLB는 TCP · UDP · TLS 수준에서 동작하므로 HTTP가 아닌 프로토콜을 그대로 통과시킵니다. 시험에서 NLB를 지목하는 결정적 신호는 두 가지입니다. (1) HTTP가 아닌 프로토콜, (2) 고정 IP 주소 요구입니다. API 문서는 NLB에 대해 "인터넷 경계 로드 밸런서에 고정 IP 주소가 필요하면 서브넷당 Elastic IP 주소 1개를 지정할 수 있다"고 명시하는 반면, ALB에 대해서는 "서브넷에 Elastic IP 주소를 지정할 수 없다"고 명시합니다.

"방화벽 허용 목록에 IP를 등록해야 한다", "클라이언트가 DNS 이름이 아니라 IP로 접속한다"는 제약이 붙으면 ALB 선택지는 그 자리에서 소거됩니다. ALB 앞에 굳이 고정 IP를 두고 싶다면 AWS Global Accelerator를 붙이는 별도 설계가 되며, 이는 14장 엣지와 DNS에서 다룹니다.

Gateway Load Balancer — GENEVE가 보이면 이것

GWLB는 서드파티 가상 어플라이언스(방화벽, 침입 탐지 · 방지 시스템, 심층 패킷 검사)를 트래픽 경로에 투명하게 끼워 넣기 위한 로드 밸런서입니다. 어플라이언스와는 GENEVE 프로토콜, 포트 6081로 통신하며, 이 프로토콜은 세 로드 밸런서 중 GWLB만 지원합니다. 따라서 문항에 GENEVE나 6081이 등장하면 다른 선택지를 볼 필요가 없습니다.

타깃 그룹 — 로드 밸런서가 실제로 트래픽을 보내는 곳

로드 밸런서 자체는 대상을 직접 알지 않습니다. 리스너가 요청을 받고, 규칙이 조건을 평가해 타깃 그룹으로 넘기고, 타깃 그룹이 헬스체크를 통과한 대상에게 보냅니다. 이 세 단계를 분리해 두었기 때문에 대상을 바꿔도 리스너 설정을 건드리지 않습니다.

대상 유형 네 가지

하나의 타깃 그룹에는 한 가지 대상 유형만 쓸 수 있습니다. 인스턴스와 IP를 한 그룹에 섞을 수 없으므로, 마이그레이션 중 두 형태가 공존한다면 타깃 그룹을 나누고 리스너 규칙으로 가중치를 나눠 보내는 구성이 됩니다.

리스너 규칙은 우선순위 순으로 평가된다

규칙은 우선순위 값이 낮은 것부터 평가되고, 조건이 맞는 첫 규칙의 동작이 수행됩니다. 어느 규칙에도 걸리지 않으면 기본 규칙의 동작이 수행됩니다. 같은 우선순위를 가진 규칙 두 개는 존재할 수 없습니다. 조건으로 쓸 수 있는 필드는 host-header, path-pattern, http-header, http-request-method, query-string, source-ip이고, 동작에는 forward, redirect, fixed-response, authenticate-cognito, authenticate-oidc가 있습니다.

여기서 자주 나오는 사고가 넓은 규칙을 낮은 번호에 두는 것입니다. /*를 우선순위 1에 두면 그 뒤의 /api/* 규칙은 영원히 평가되지 않습니다. 규칙은 좁은 것부터 배치합니다.

aws elbv2 create-target-group \
  --name app-tg \
  --protocol HTTP \
  --port 8080 \
  --vpc-id vpc-0123456789abcdef0 \
  --target-type instance \
  --health-check-protocol HTTP \
  --health-check-path /healthz \
  --health-check-interval-seconds 10 \
  --health-check-timeout-seconds 5 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 2 \
  --matcher HttpCode=200 \
  --region ap-northeast-2

헬스체크 · 연결 드레이닝 · 고정 세션

헬스체크가 장애 감지 속도를 정한다

로드 밸런서는 대상마다 주기적으로 헬스체크를 보내고, 연속 실패 횟수가 임계치에 닿으면 대상을 unhealthy로 표시해 트래픽에서 뺍니다. 즉 장애가 트래픽에서 제거되기까지 걸리는 시간은 검사 간격과 비정상 임계치의 곱에 좌우되고, 이 두 값이 곧 설계 파라미터입니다.

헬스체크 경로는 애플리케이션이 실제로 요청을 처리할 수 있는지를 반영해야 합니다. 정적 파일 하나를 반환하는 경로로 검사하면, 데이터베이스 연결이 끊긴 인스턴스가 계속 정상으로 표시되어 트래픽을 받아 오류를 냅니다. 반대로 헬스체크에서 하위 의존성까지 전부 확인하면 의존성 한 곳의 순간 지연이 전체 대상을 한꺼번에 비정상으로 만들 수 있으므로, 검사 범위는 의도적으로 정합니다.

대상 상태 값은 initial, healthy, unhealthy, unhealthy.draining, unused, draining, unavailable입니다. 상태가 unused라면 대상이 등록은 되었지만 어떤 리스너에도 연결되지 않았거나 중지 상태라는 뜻이므로, 헬스체크 실패와는 원인이 다릅니다.

등록 취소 지연 — 흔히 연결 드레이닝이라 부르는 것

대상을 뺄 때 즉시 끊으면 처리 중이던 요청이 실패합니다. 그래서 로드 밸런서는 대상을 draining 상태로 두고 새 요청은 보내지 않되 진행 중인 요청은 끝나게 합니다. 이 대기 시간이 deregistration_delay.timeout_seconds이며 범위는 0 – 3600초, 기본값은 300초입니다.

이 값이 배포 속도와 직결됩니다. 요청이 짧은 웹 서비스라면 300초를 기다릴 이유가 없어 값을 낮추고, 업로드나 장시간 응답이 있는 서비스라면 값을 늘립니다. Auto Scaling 그룹이 인스턴스를 축소할 때도 이 지연을 거치므로, "스케일인이 왜 이렇게 느린가"의 답이 여기 있는 경우가 많습니다.

고정 세션 — 필요악이라는 사실을 함께 가르친다

고정 세션(sticky session)은 같은 클라이언트를 같은 대상으로 계속 보내는 기능입니다. 기본값은 비활성(stickiness.enabled는 false)이고, 방식은 로드 밸런서마다 다릅니다.

ALB의 쿠키 기반 고정 세션 유지 기간은 1초에서 1주일 사이이고 기본값은 1일입니다. 문제는 고정 세션이 부하 분산을 망가뜨린다는 점입니다. 특정 대상에 세션이 몰리면 스케일아웃을 해도 새 인스턴스로 트래픽이 옮겨 가지 않고, 그 대상이 죽으면 거기에 묶여 있던 사용자만 세션을 잃습니다.

교차 영역 로드 밸런싱 — 기본값이 다르다

교차 영역 로드 밸런싱(cross-zone load balancing)이 켜져 있으면 각 가용 영역의 로드 밸런서 노드가 모든 가용 영역의 대상에 트래픽을 보냅니다. 꺼져 있으면 노드는 자기 가용 영역 안의 대상에만 보냅니다.

여기서 기본값이 갈립니다. API 문서는 Network Load Balancer와 Gateway Load Balancer의 기본값은 false, Application Load Balancer의 기본값은 true이며 변경할 수 없다고 명시합니다. 따라서 가용 영역마다 대상 수가 다른 상태로 NLB를 쓰면 대상이 적은 가용 영역의 인스턴스에 트래픽이 몰립니다. NLB를 쓸 때 가용 영역별 대상 수를 맞추거나 교차 영역을 켜야 하는 이유입니다.

Auto Scaling 그룹 — 용량을 선언하고 유지시킨다

Amazon EC2 Auto Scaling은 "인스턴스를 몇 대 유지할 것인가"를 선언하면 그 상태를 계속 맞춰 주는 서비스입니다. 인스턴스가 죽으면 새로 띄우고, 부하가 늘면 정책에 따라 더 띄우고, 줄면 종료합니다. 자동 복구와 자동 확장이 같은 장치에서 나온다는 점이 핵심입니다.

시작 템플릿 — 무엇을 띄울지의 정의

Auto Scaling 그룹은 시작 템플릿(launch template) 또는 시작 구성(launch configuration)으로 인스턴스의 사양을 받습니다. AMI, 인스턴스 타입, 보안 그룹, IAM 인스턴스 프로파일, 사용자 데이터, 블록 디바이스 매핑, 인스턴스 메타데이터 옵션이 여기에 들어갑니다. 시작 템플릿은 버전을 가지므로 변경 이력을 남기고 되돌릴 수 있고, 온디맨드와 스팟을 섞는 혼합 인스턴스 정책도 시작 템플릿에서만 구성할 수 있습니다. 새로 만들 때는 시작 템플릿을 씁니다.

최소 · 원하는 · 최대 용량

원하는 용량은 최소 이상, 최대 이하여야 합니다. 시험에서 "트래픽이 급증했는데 확장이 되지 않았다"는 시나리오의 원인 후보 1번이 최대 용량에 이미 도달한 상태입니다.

다중 가용 영역 배치 SAA 빈출

Auto Scaling 그룹에는 VPCZoneIdentifier로 여러 가용 영역의 서브넷을 지정합니다. 그러면 Auto Scaling이 가용 영역 사이에 인스턴스를 고르게 배치하려 시도하고, 한 가용 영역이 통째로 사라져도 남은 가용 영역에서 용량을 다시 채웁니다. 가용 영역 하나에 인스턴스를 여러 대 두는 것은 고가용성이 아닙니다 (1장 가용 영역).

고가용성 웹 계층의 표준 조합은 결국 세 가지입니다 — 여러 가용 영역의 서브넷 + Auto Scaling 그룹 + 로드 밸런서. 이 조합이 성립하려면 인스턴스가 언제 죽어도 되는 상태 비저장 설계가 전제입니다. 세션과 업로드 파일이 인스턴스 로컬 디스크에 있으면 인스턴스 교체가 곧 데이터 손실이 됩니다.

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  WebAsg:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      MinSize: '2'
      MaxSize: '10'
      DesiredCapacity: '2'
      VPCZoneIdentifier:
        - subnet-0123456789abcdef0   # 가용 영역 A 프라이빗 서브넷
        - subnet-0abcdef1234567890   # 가용 영역 C 프라이빗 서브넷
      LaunchTemplate:
        LaunchTemplateId: !Ref WebLaunchTemplate
        Version: !GetAtt WebLaunchTemplate.LatestVersionNumber
      TargetGroupARNs:
        - !Ref WebTargetGroup
      HealthCheckType: ELB
      HealthCheckGracePeriod: 120
      DefaultInstanceWarmup: 60

  ScaleOnCpu:
    Type: AWS::AutoScaling::ScalingPolicy
    Properties:
      AutoScalingGroupName: !Ref WebAsg
      PolicyType: TargetTrackingScaling
      TargetTrackingConfiguration:
        PredefinedMetricSpecification:
          PredefinedMetricType: ASGAverageCPUUtilization
        TargetValue: 50

Auto Scaling 헬스체크 유형 — ELB를 켜야 하는 이유

Auto Scaling 그룹의 헬스체크 유형은 EC2, ELB, EBS, VPC_LATTICE이며 EC2가 기본이고 끌 수 없습니다. 문제는 EC2 헬스체크가 인스턴스와 시스템 상태 확인만 본다는 점입니다. 운영체제는 멀쩡한데 애플리케이션 프로세스만 죽은 경우, EC2 헬스체크는 정상이라고 보고 인스턴스를 교체하지 않습니다.

HealthCheckType에 ELB를 추가하면 로드 밸런서의 헬스체크 실패가 곧 인스턴스 교체로 이어집니다. 로드 밸런서 뒤의 Auto Scaling 그룹에서는 사실상 항상 켜야 하는 설정입니다.

함께 보는 값이 헬스체크 유예 기간(HealthCheckGracePeriod)이고 기본값은 0초입니다. 부팅과 애플리케이션 기동에 시간이 걸리는데 유예가 0이면, 아직 준비되지 않은 인스턴스가 비정상으로 판정되어 종료되고 다시 시작되는 교체 루프에 빠집니다. 기동 시간을 재서 그보다 넉넉하게 잡습니다.

스케일링 정책 — 언제, 얼마나 늘릴 것인가

정책이 하나도 없으면 Auto Scaling 그룹은 원하는 용량을 유지하기만 합니다. 자동으로 늘고 줄게 하려면 정책을 붙여야 하고, 정책 유형은 다음과 같습니다.

조정량을 어떻게 해석할지는 AdjustmentType이 정합니다 — ChangeInCapacity(증감), ExactCapacity(절대값), PercentChangeInCapacity(비율). 단계별과 단순 정책에서만 씁니다.

대상 추적에서 바로 쓸 수 있는 사전 정의 지표는 ASGAverageCPUUtilization, ASGAverageNetworkIn, ASGAverageNetworkOut, ALBRequestCountPerTarget입니다. 웹 계층에서는 CPU보다 대상당 요청 수가 부하를 더 정확히 반영하는 경우가 많습니다.

이 밖에 예측 스케일링(PredictiveScaling)이 있어 과거 패턴으로 미리 용량을 올려 둘 수 있습니다. 위 네 가지를 먼저 확실히 구분한 뒤에 보조 수단으로 이해하면 충분합니다.

워밍업과 쿨다운 — 진동을 막는 두 장치

새로 시작한 인스턴스는 부팅과 애플리케이션 기동 동안 CPU가 높거나 요청을 받지 못합니다. 이 값을 그대로 그룹 평균에 넣으면 지표가 왜곡되어 필요 없는 인스턴스를 더 띄웁니다. 그래서 워밍업(DefaultInstanceWarmup)을 두어 새 인스턴스가 안정될 때까지 지표 집계에서 제외합니다.

쿨다운(DefaultCooldown)은 단순 스케일링 정책에만 적용되며 조정 하나가 끝나고 다음 조정이 시작되기까지의 간격입니다. 기본값은 300초입니다. 대상 추적과 단계별 정책은 쿨다운 대신 워밍업을 씁니다. 정책마다 워밍업을 따로 주고 싶으면 EstimatedInstanceWarmup으로 덮어쓸 수 있고, 그룹 기본 워밍업이 비어 있으면 이 값이 기본 쿨다운으로 대체됩니다.

수명주기 훅 — 시작 직후와 종료 직전에 끼어들기

수명주기 훅은 인스턴스를 대기 상태에 붙잡아 두고 그동안 우리가 할 일을 하게 합니다. 전환 지점은 두 개입니다.

• autoscaling:EC2_INSTANCE_LAUNCHING — 스케일아웃 시. 설정 파일 내려받기, 캐시 예열, 등록 작업을 끝낸 뒤 트래픽을 받게 합니다.
• autoscaling:EC2_INSTANCE_TERMINATING — 스케일인 시. 로그 회수, 진행 중 작업 마무리, 외부 시스템에서 등록 해제를 합니다.

대기 시간은 HeartbeatTimeout으로 정하며 범위는 30 – 7200초, 기본값은 3600초입니다. 작업이 더 필요하면 RecordLifecycleActionHeartbeat로 시간을 연장하고, 끝나면 CompleteLifecycleAction으로 즉시 다음 단계로 넘깁니다. 시간이 다 지나면 DefaultResult가 적용되며 기본값은 ABANDON입니다. 기본 한도는 Auto Scaling 그룹당 훅 50개입니다.

확장의 방향 — 수직인가 수평인가

시험에서 탄력성 · 확장성 · 고가용성이 요구되면 답은 수평 확장입니다. 수직 확장이 정답이 되는 경우는 수평으로 나눌 수 없는 워크로드일 때입니다 — 단일 쓰기 노드인 관계형 데이터베이스, 라이선스가 노드 수에 묶인 소프트웨어 같은 경우입니다. 데이터베이스 계층의 확장 판단은 10장 RDS와 관계형 데이터베이스에서 다룹니다.

단일 장애점을 남기지 않는 조립법

안정성(Reliability, 신뢰성으로도 번역됨)의 기준은 단순합니다. 어느 구성 요소 하나가 사라져도 서비스가 계속되는가입니다. Auto Scaling 그룹과 로드 밸런서를 붙여 놓고도 서비스가 통째로 멈추는 구성이 흔한데, 원인은 대개 아래 다섯 가지 중 하나입니다.

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --min-size 2 --max-size 6 --desired-capacity 2 \
  --vpc-zone-identifier "subnet-0123456789abcdef0" \
  --launch-template LaunchTemplateId=lt-0123456789abcdef0,Version='$Latest'

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --min-size 2 --max-size 10 --desired-capacity 2 \
  --vpc-zone-identifier "subnet-0123456789abcdef0,subnet-0abcdef1234567890" \
  --target-group-arns "$TARGET_GROUP_ARN" \
  --health-check-type ELB \
  --health-check-grace-period 120 \
  --default-instance-warmup 60 \
  --launch-template LaunchTemplateId=lt-0123456789abcdef0,Version='$Latest'

흔한 오해

시험 포인트 정리

확인 문제

이 장의 핵심을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

이어서 볼 곳

• 5장 · EC2와 컴퓨트 Auto Scaling 그룹이 띄우는 인스턴스 자체의 이야기입니다. 구매 옵션과 배치 그룹, 시작 템플릿에 들어가는 사용자 데이터와 IMDSv2를 다룹니다. 기본개념
• 10장 · RDS와 관계형 데이터베이스 웹 계층을 다중 AZ로 만들어도 데이터베이스가 단일 인스턴스면 소용이 없습니다. Multi-AZ와 읽기 전용 복제본의 차이를 정면으로 다룹니다. 기본개념 · SAA 최우선
• 12장 · 서버리스와 애플리케이션 통합 스케일아웃이 못 따라가는 급증을 큐로 흡수하는 방법. 느슨한 결합이 왜 복원력의 다른 이름인지 이어서 봅니다. 기본개념 · SAA 최우선
• 실습 2 · ALB + ASG 웹 티어 이 장의 구성을 직접 만들어 헬스체크 실패와 스케일링 동작을 눈으로 확인합니다. 실습
• 케이스 7 · 트래픽 급증에 스케일아웃이 못 따라갔다 최대 용량, 워밍업, 예약 스케일링, 큐 완충 중 무엇이 답인지 시나리오로 판단합니다. 아키텍처 케이스
• 복원력 있는 아키텍처 설계 (26%) 과제 진술 2개가 26%를 차지하는 도메인입니다. 이 장의 내용이 그 중심에 있습니다. 시험 대비

공식 문서 출처

이 장의 설정값 · 기본값 · 동작은 모두 아래 문서에서 확인했습니다.

• Elastic Load Balancing API 레퍼런스 — CreateLoadBalancer — 로드 밸런서 타입 세 가지, ALB가 가용 영역 2개 이상의 서브넷을 요구한다는 점, NLB만 서브넷당 Elastic IP를 지정할 수 있다는 점
• Elastic Load Balancing API 레퍼런스 — CreateTargetGroup — 대상 유형 네 가지, 헬스체크 간격 · 제한 시간 · 임계치의 범위와 기본값, 프로토콜별 성공 코드 범위
• Elastic Load Balancing API 레퍼런스 — ModifyTargetGroupAttributes — 등록 취소 지연 기본 300초, 고정 세션 기본 비활성과 로드 밸런서별 방식, 느린 시작 범위
• Elastic Load Balancing API 레퍼런스 — ModifyLoadBalancerAttributes — 교차 영역 로드 밸런싱 기본값이 ALB는 켜짐(변경 불가), NLB · GWLB는 꺼짐이라는 서술과 ALB 유휴 제한 시간 기본 60초
• Elastic Load Balancing API 레퍼런스 — CreateRule — 규칙이 우선순위가 낮은 값부터 평가된다는 점과 조건 필드 목록
• Application Load Balancer 사용 설명서 — 리스너 · 규칙 · 타깃 그룹의 관계와 L7 라우팅
• Network Load Balancer 사용 설명서 — L4 동작과 고정 IP 구성
• Gateway Load Balancer 사용 설명서 — GENEVE 프로토콜과 가상 어플라이언스 삽입
• Amazon EC2 Auto Scaling API 레퍼런스 — CreateAutoScalingGroup — 원하는 용량을 생략하면 최소값이 기본이라는 점, 기본 쿨다운 300초, 헬스체크 유형과 유예 기간 기본 0초, 종료 정책 목록
• Amazon EC2 Auto Scaling API 레퍼런스 — PutScalingPolicy — 정책 유형 네 가지와 API 기본값, 조정 유형, 대상 추적 사전 정의 지표 목록, 워밍업이 쿨다운으로 대체되는 조건
• Amazon EC2 Auto Scaling API 레퍼런스 — PutLifecycleHook — 두 가지 수명주기 전환, 하트비트 제한 시간 30–7200초와 기본 3600초, 기본 결과 ABANDON, 그룹당 훅 50개
• Amazon EC2 Auto Scaling API 레퍼런스 — PutScheduledUpdateGroupAction — 예약 스케일링이 최소 · 최대 · 원하는 용량을 일정에 따라 바꾼다는 점
• Amazon EC2 Auto Scaling 사용 설명서 — 그룹 · 시작 템플릿 · 스케일링 정책의 전체 구성