[AWS] ALB Target Optimizer 구성 방법

애플리케이션 로드 밸런서(ALB)에 Target Optimizer 기능이 공식 출시되면서, 이제 각 타깃(EC2, ECS, EKS 등)이 동시에 처리할 수 있는 요청 수를 정확하게 제한할 수 있게 되었습니다. 단순한 트래픽 분배를 넘어, 워크로드의 실제 처리 능력에 맞춰 최적의 요청 흐름을 만들어내는 방식입니다.

특히 LLM·이미지 생성 모델, GPU 기반 인퍼런스, 동시성 1~N 수준으로 매우 낮은 애플리케이션, 타깃별 성능이 크게 다른 환경에서 큰 효과를 체감할 수 있습니다.

[AWS] ALB Target Optimizer 구성 방법

준비 사항

Target Optimizer는 ALB의 기존 Target Group과 별도로 동작하는 기능이므로, 아래 두 가지가 필요합니다.

• Target Optimizer Agent 설치
• Target Control Port가 설정된 전용 Target Group 생성

애플리케이션 코드를 수정할 필요는 없습니다. 구조상 Agent가 Sidecar 또는 Proxy 형태로 동작하며 ALB와의 제어 채널을 대신 처리해 줍니다.

1. Target Optimizer Agent 설치

EC2 환경 기준 절차

1. EC2 인스턴스에 접속합니다.
2. AWS에서 제공하는 Agent 패키지를 설치합니다. (현재 RPM, DEB 형태로 제공)
3. 설치 후 설정 파일(/etc/target-optimizer/config.yaml 등)에 다음 값을 지정합니다.
   • controlPort: ALB와 통신할 포트
   • maxConcurrency: 해당 인스턴스가 동시에 처리 가능한 요청 수
   • healthCheck: ALB가 확인할 상태 엔드포인트

예시:

# yaml 파일
controlPort: 9000
maxConcurrency: 1
healthCheck: http://127.0.0.1:8080/health

 

 

예를 들어 LLM 모델처럼 동시 “1개”만 처리 가능한 경우 maxConcurrency: 1로 설정하면 됩니다.

2. Target Optimizer용 Target Group 생성

Target Group은 기존 방식과 유사하지만, Target Optimizer용으로 다음 값을 반드시 지정해야 합니다.

• Target type: instance, ip, lambda 중 선택
• Protocol: HTTP 또는 HTTPS
• Target Control Port 설정
• Health check path

AWS Console 기준 절차:

1. EC2 콘솔 → Target Group 생성 페이지 이동
2. “Application Load Balancer용” Target Group 선택
3. Target Type 선택
4. Additional settings → Target Optimizer 활성화
5. Control Port 입력 (예: 9000)
6. Health check 경로 입력

이 Target Group은 기존 Target Group과 병행해 사용할 수도 있으며, 점진적 전환이 가능합니다.

3. 타깃 등록

Agent가 설치된 인스턴스를 Target Group에 등록합니다.

등록 후 ALB는 타깃에게 직접 요청을 보내지 않습니다.
대신 타깃(Agent)이 ALB로부터 “받아올 수 있을 때 pull 방식으로 요청을 가져옵니다.”

이 구조 덕분에 과부하가 걸릴 가능성을 원천적으로 차단할 수 있습니다.

 

AWS 명령 예:

aws elbv2 register-targets \
  --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-2:123456789012:targetgroup/gpu-inference/abc123 \
  --targets Id=i-0123456789abcdef0

4. Listener 설정 및 트래픽 전환

기존 Listener에 기존 Target Group이 연결되어 있다면, 아래처럼 전환할 수 있습니다.

1. ALB Listener에서 Forward 규칙 수정
2. Default 또는 특정 Path 기반 규칙을 새 Target Group으로 변경
3. 트래픽이 정상적으로 분배되는지 확인

기존 Target Group과 병행해 가중치 기반 조정도 가능하므로, 무중단 전환이 필요한 경우 안전하게 진행할 수 있습니다.

5. CloudWatch로 동작 상태 확인

Target Optimizer는 별도의 CloudWatch 메트릭을 제공합니다.

확인해야 할 주요 지표는 다음과 같습니다.

• ChannelStatus: ALB와 타깃 간 제어 채널 상태
• QueueDepth: 타깃이 처리 대기 중인 요청 수
• RejectedRequests: Concurrency 제한으로 거부된 요청 수
• ProcessingTime: 각 타깃의 평균 처리 시간

이 지표들을 기반으로 실제 maxConcurrency 값을 조정하면 성능을 더욱 안정적으로 맞출 수 있습니다.

6. 구성 시 자주 발생하는 문제와 해결 방법

6.1. 제어 채널 연결 불가

• Control Port가 EC2 보안 그룹에서 열려 있는지 확인합니다.
• Agent 실행 권한 및 서비스 등록 여부를 재확인합니다.

6.2. 요청이 분배되지 않는 문제

• Agent 설정 파일에 오타가 없는지
• HealthCheck가 정상 응답하는지
• ALB Listener 규칙이 새 Target Group을 가리키는지 확인합니다.

6.3. 타깃별 처리량 차이

• 성능이 다른 인스턴스를 혼합 구성한 경우 각 인스턴스마다 maxConcurrency 값을 다르게 지정해야 합니다.
• GPU 워크로드의 경우 처리 속도에 따라 변경 폭이 큽니다.

7. 구성 권장 패턴

아래는 실제 운영 환경에서 많이 사용하는 구성 패턴입니다.

패턴 1. LLM 또는 GPU 인퍼런스 서비스

• maxConcurrency: 1
• Agent controlPort만 열어두고 ALB와 pull 방식으로 처리
• Spot 인스턴스 혼합 시에도 효과적

패턴 2. 서로 다른 스펙의 인스턴스를 하나의 Target Group에 사용

• cpu.large → maxConcurrency: 4
• cpu.xlarge → maxConcurrency: 12
• gpu.xlarge → maxConcurrency: 1~2

패턴 3. 오류율이 높은 API 서비스 안정화

• 재시도 폭주 문제 해결
• 타깃 과부하로 인한 5XX 문제 완화

---

정리

Target Optimizer는 단순한 트래픽 분산 기능이 아니라, 애플리케이션의 실제 처리 능력에 맞춰 ALB가 요청 배분을 자동 조절하는 모델입니다.
특히 동시성 제약이 있는 워크로드에서는 기존 방식과 비교해 성능과 안정성이 크게 개선되는 것을 확인할 수 있습니다.