ALB와 Auto Scaling으로 트래픽 받기

요약: 로드밸런서와 자동 수평 확장으로 HTTPS 트래픽을 프라이빗 앱 인스턴스에 나누는 구성을 정리한다.

---

1. 언제 ALB와 Auto Scaling인가

ALB는 Application Load Balancer, HTTP/HTTPS 7계층 로드밸런서다. Auto Scaling은 인스턴스(또는 컨테이너 태스크) 수를 메트릭에 따라 늘리고 줄인다.

이 조합이 맞는 경우:

• 사용자 트래픽이 웹·API로 들어오고, 인스턴스를 직접 인터넷에 노출하고 싶지 않을 때
• 배포 중에도 헬스체크가 통과한 타깃만 받고 싶을 때
• CPU·요청 수에 따라 용량을 조절하고 싶을 때

맞지 않는 경우:

• 정적 파일만이면 CloudFront + S3가 더 단순하다
• TCP 비 HTTP면 NLB를 검토한다. NLB는 Network Load Balancer다
• 단일 개발 인스턴스에 SSH로만 붙는 실험. ALB 시간당 요금이 아깝다

기본 토폴로지:

사용자 → ALB(퍼블릭 서브넷, 443) → 타깃 그룹 → EC2/ECS(프라이빗)

---

2. 핵심 개념

리스너. 포트와 프로토콜. 443에 ACM 인증서를 붙인다. ACM은 AWS Certificate Manager, 공개 인증서 발급·갱신이다. HTTP 80은 443으로 리다이렉트한다. 인증서를 인스턴스에 직접 복사하지 않아도 된다.

타깃 그룹. 실제 앱 포트(예: 8080)와 헬스체크 경로. /health는 인증 없이 가볍고, DB까지 물면 배포마다 빠질 수 있다. 의존성 검사는 내부 프로브로 나눈다.

헬스체크. 주기, 성공 코드, 연속 실패 횟수. 실패하면 트래픽이 빠진다. 배포 때 드레인(deregistration delay)을 맞춘다. 너무 짧으면 진행 중 요청이 끊긴다.

ASG. Auto Scaling Group. 최소·희망·최대 용량. 시작 템플릿에 AMI, 보안 그룹, IAM 역할, 유저 데이터가 들어간다. 그룹이 새 인스턴스를 켜도 설정이 같아야 한다.

스케일 정책. CPU 60% 5분 → +1, CPU 20% 15분 → −1처럼 아웃은 빠르게, 인은 보수적으로. 요청 수(RequestCountPerTarget)가 웹에 더 잘 맞을 때가 있다.

상태. 세션·업로드 파일을 인스턴스 로컬에만 두면 스케일 아웃이 사용자를 다른 박스로 보낸다. 세션은 Redis나 DB, 파일은 S3.

---

3. 최소 구성 예

1. ACM에서 도메인 인증서를 발급한다. DNS 검증.
2. ALB를 퍼블릭 서브넷 두 AZ에 둔다. SG: 443 인터넷, 80 리다이렉트.
3. 앱 SG: ALB SG만 8080.
4. 타깃 그룹: HTTP 8080, 헬스 /health.
5. 시작 템플릿 + ASG 최소 2(프로덕션). 개발은 1도 가능하나 AZ 장애를 감수한다.
6. 스케일 정책 하나와 CloudWatch 알람.

헬스 엔드포인트 예. 비밀 없음.

GET /health → 200 {"status":"ok"}

보안 그룹 요약:

ALB SG : 0.0.0.0/0 → 443
App SG : sg-ALB    → 8080

확인:

aws elbv2 describe-load-balancers --query "LoadBalancers[].{n:LoadBalancerName,s:State.Code}"
aws elbv2 describe-target-health --target-group-arn arn:aws:elasticloadbalancing:REGION:YOUR_ACCOUNT_ID:targetgroup/app/YOUR_ID

타깃이 unhealthy면 보안 그룹, 포트, 앱 바인드 주소(127.0.0.1만 듣고 있으면 ALB가 못 붙는다), 헬스 경로를 본다.

WAF는 로그인·공개 API에 검토한다. 처음부터 전체 차단 규칙을 켜면 정상 트래픽이 죽는다. 로그 모드로 시작한다.

---

4. 운영 시 주의

비용. ALB는 시간 + LCU(처리량 단위). 개발용 ALB를 여러 개 방치하지 않는다. ASG 최대치를 높게 두면 트래픽 스파이크가 곧 청구서다. 최대 용량에 상한을 둔다. 예산 알람과 같이 본다.

보안. 앱 SG에 인터넷 8080을 직접 열지 않는다. TLS는 ALB에서 끝내는 구성이 흔하다. 내부까지 TLS가 필요하면 별도 인증서를 운영한다. HTTP만 인터넷에 두지 않는다.

연결. Keep-alive·유휴 타임아웃이 앱과 안 맞으면 504가 난다. ALB 타임아웃보다 앱이 긴 작업을 동기 HTTP로 하지 않는다. 큐로 보낸다.

배포. 인플레이스 SSH 수정은 ASG가 새 박스를 켜면 사라진다. AMI 또는 사용자 데이터 + 아티팩트 배포. 롤링 또는 블루/그린을 정한다.

콜드 스타트. 스케일 아웃 직후 헬스 통과까지 시간이 있다. 최소 용량을 0으로 두면 첫 요청이 길다. 프로덕션 최소는 1 또는 2.

스틱니스. 세션 스티키는 예외다. 기본은 무상태 앱이다.

타임아웃. ALB idle timeout 기본은 60초 근처다. 앱이 90초 걸리는 동기 작업을 하면 504다. 작업을 큐로 보내거나 타임아웃을 문서화한다. 클라이언트가 먼저 끊어도 앱은 계속 일할 수 있다. 취소를 전파할지 합의한다.

액세스 로그. ALB 액세스 로그를 S3에 켜면 5xx 디버깅이 빨라진다. 수명주기를 같이 켠다. 로그 버킷도 퍼블릭이면 안 된다.

용량 예약. 이벤트 전에 ASG 희망 용량만 올려 두는 편이 스팟·스케일 정책보다 예측 가능하다. 이벤트 후 내린다. 안 내리면 그게 고정 비용이 된다.

---

5. 정리

ALB + ASG는 서버를 여러 대 켜는 일이 아니다. 헬스체크가 통과하는 동일한 타깃을 만드는 설계다. 상태는 밖으로 빼고, 인터넷은 ALB만, 용량 상한과 알람을 같이 둔다.

체크리스트

• 443 + ACM을 쓰고 80은 리다이렉트한다. 평문 HTTP 운영은 자격 유출 위험이 있다.
• 앱은 프라이빗이고 SG 소스는 ALB뿐이다. 우회 포트는 로드밸런서를 무의미하게 한다.
• /health가 빠르게 200을 반환한다. 무거운 헬스체크는 정상 배포를 실패로 만든다.
• 세션·파일을 인스턴스 밖으로 뺀다. 로컬 상태는 스케일 때 사용자를 잃는다.
• ASG 최댓값과 스케일 알람을 정한다. 무한 스케일 아웃은 비용 사고다.

연습

1. 타깃 헬스를 CLI로 조회해 healthy가 되는지 확인한다.
2. 인스턴스 하나를 강제 unhealthy로 만들고 ALB가 트래픽을 빼는지 본다.
3. CPU 또는 요청 수 정책의 최소/최대 용량을 표로 적어 상한이 있는지 검사한다.

리스너 규칙으로 경로를 나눌 수 있다. /api/*는 앱 타깃, /static/*는 쓰지 말고 CloudFront+S3가 더 싸다. ALB에서 정적 파일을 오래 서빙하면 LCU가 는다.

헬스체크 경로를 인증 뒤로 두면 ALB가 전부 unhealthy가 된다. 공개 GET이어야 한다. 내부 시크릿을 쿼리스트링으로 넣지 않는다. 로그에 남는다.

시작 템플릿 버전을 올린 뒤 ASG가 새 버전을 쓰는지 확인한다. 인스턴스 새로고침(instance refresh)으로 점진 교체할 수 있다. 수동으로 한 대만 고치면 다음 스케일 아웃이 옛 AMI를 켠다.

인증서 만료는 ACM 자동 갱신이 전제다. DNS 검증 레코드를 지우면 갱신이 실패한다. 만료 알람을 ACM·CloudWatch에서 한 번 더 둔다.

타깃 그룹 포트와 컨테이너 호스트 포트가 어긋나면 헬스는 영원히 실패한다. ECS면 동적 포트를 ALB가 따라가게 한다. EC2면 보안 그룹 포트와 앱 listen이 같아야 한다. localhost만 바인드하면 실패한다. 0.0.0.0이어야 ALB가 도달한다.

---

---