Amazon Web Services 한국 블로그
Application Load Balancer, 가중치 기반 대상 그룹기반 배포 간소화 기능 출시
클라우드 컴퓨팅의 이점 중 하나는 프로그래밍 방식으로 인프라를 생성하고 더 이상 필요가 없으면 폐기할 수 있다는 것입니다. 이 기능은 개발자가 애플리케이션을 배포하는 방식을 근본적으로 변경할 수 있게 해 줍니다. 개발자가 온프레미스로 애플리케이션을 배포할 때에는 새 버전의 애플리케이션에 기존 인프라를 재사용해야 했습니다. 클라우드에서는 개발자가 새 버전의 애플리케이션을 위해 새 인프라를 생성합니다. 이전 버전은 한동안 함께 실행되다가 폐기됩니다. 이 기법을 블루/그린 배포라고 합니다. 이 기법은 점진적으로 트래픽을 앱의 두 버전 사이에서 전환하고, 새 버전의 비즈니스 및 운영 지표를 모니터링하고, 문제가 발생하면 이전 버전으로 트래픽을 되돌릴 수 있게 해 줍니다.
AWS 고객은 블루/그린 배포의 도입을 위해 두 가지 전략을 사용합니다. 첫 번째 전략은 제2의 로드 밸런서를 포함한 제2의 애플리케이션 스택을 생성하는 것으로 구성됩니다. 개발자는 DNS와 같은 일종의 가중치 기반 라우팅 기법을 사용하여 트래픽의 일부를 각 스택으로 라우팅합니다, 두 번째 전략은 로드 밸런서 뒤에 있는 인프라를 교체하는 것으로 구성됩니다. DNS TTL 및 클라이언트 시스템의 캐싱에 따라 두 전략 모두 버전 간의 트래픽 이동에 지연을 초래합니다. 이는 추가 로드 밸런서 실행에 따르는 추가 비용을 발생시키고 추가 로드 밸런서의 워밍업으로 인한 지연 문제를 유발할 가능성도 있습니다.
대상 그룹은 로드 밸런서에게 EC2 인스턴스, 고정 IP 주소 또는 AWS Lambda 함수 등, 트래픽을 라우팅할 위치를 지시합니다. 로드 밸런서를 생성할 때에는 하나 이상의리스너를 생성하고 단일 대상 그룹으로 트래픽을 라우팅하는 리스너 규칙을 구성합니다.
오늘 AWS에서는 Application Load Balancer를 위한 가중치 기반 대상 그룹을 발표합니다. 이 대상 그룹을 통해 개발자는 애플리케이션의 여러 버전에 트래픽을 분산하는 방법을 제어할 수 있습니다.
복수의 가중치 기반 대상 그룹
이제 리스너 규칙의 전달 작업에 둘 이상의 대상 그룹을 추가하고 각 그룹에 가중치를 지정할 수 있습니다. 예를 들어, 가중치 8과 2가 지정된 두 개의 대상 그룹을 포함하는 규칙을 정의하면, 로드 밸런서가 트래픽의 80%를 첫 번째 대상 그룹으로, 그리고 20%를 두 번째 대상 그룹으로 라우팅합니다.
지금 가중치 기반 대상 그룹을 실험해 보려면 이 CDK 코드를 사용하실 수 있습니다. 이 코드는 EC2 인스턴스로 구성된 두 개의 Auto Scaling 그룹과 이 앞에 배치되는 Elastic Load Balancer를 생성합니다. 또한 이 코드는 인스턴스에 샘플 웹 앱을 배포합니다. 웹 앱의 블루 버전은 블루 인스턴스에 배포되고 웹 앱의 그린 버전은 그린 인스턴스에 배포됩니다. 인프라는 다음과 같은 형태를 가집니다.
CDK 프로젝트에 git clone을 실행하고 npm run build && cdk bootstrap && cdk deploy를 입력하면 위의 인프라를 배포할 수 있습니다. 로드 밸런서를 구성하는 방법을 보여주기 위해 CDK 코드는 Auto Scaling, 로드 밸런서 및 일반 대상 그룹을 생성합니다. 구성을 수동으로 완료하여 각 버전의 애플리케이션에 각각 할당되는 두 개의 가중치 기반 대상 그룹을 생성해 보겠습니다.
먼저 EC2 콘솔로 이동하여 [대상 그룹]을 선택하고 [대상 그룹 생성] 버튼을 클릭합니다. green이라는 이름의 대상 그룹을 생성합니다. 올바른 Amazon Virtual Private Cloud를 선택해야 합니다. CDK 스크립트가 생성한 VPC는 “AlbWtgStack...“으로 시작하는 이름을 가지고 있습니다. 이 이름을 선택한 다음 [생성]을 클릭합니다.
작업을 반복하여 blue 대상 그룹을 생성합니다. My Target Groups 콘솔은 다음과 같은 모양을 가집니다.
다음으로 두 개의 Auto Scalling 그룹을 변경하여 blue 및 green 대상 그룹을 가리키도록 합니다. AWS Management Console에서 [Auto Scaling 그룹]을 클릭하고 두 Auto Scaling 그룹 중 하나를 선택합니다. 선택할 때에는 이름에 주의합니다(‘green’ 또는 ‘blue”를 포함). [작업]을 클릭한 다음 [편집]을 클릭합니다.
[세부 정보 편집] 화면에서 CDK 스크립트가 생성한 대상 그룹을 제거하고 Auto Scaling 그룹의 이름(green 또는 blue)과 일치하는 대상 그룹을 추가합니다. 화면 맨 아래의 [저장]을 클릭하고 다른 Auto Scaling 그룹에 대해 작업을 반복합니다.
다음으로 리스너 규칙을 변경하여 각각 자체의 가중치를 가진 이 두 개의 대상 그룹을 추가합니다. EC2 콘솔의 왼쪽에서 [로드 밸런서]를 선택한 다음 CDK 코드에서 생성한 로드 밸런서(“alb”로 시작하는 이름)를 검색합니다. [리스너]를 클릭한 다음규칙 보기/편집]을 클릭합니다.
CDK 스크립트에서 생성한 규칙이 한 개 있습니다. 상단의 [편집] 아이콘을 클릭한 다음, 규칙 왼쪽의 [편집] 아이콘을 다시 클릭합니다. 휴지통 아이콘을 클릭하여 [전달] 규칙을 삭제합니다.
그런 다음 [+ 작업 추가]를 클릭하여 각각 대상 그룹(blue 및 green)을 가지며 50의 가중치가 지정된 두 개의 [전달] 규칙을 추가합니다.
마지막으로 오른쪽에서 [업데이트]를 클릭합니다. 이제 가중치 기반 로드 밸런싱을 테스트할 준비가 되었습니다.
브라우저에서 로드 밸런서의 DNS 이름을 가리킵니다. 웹 앱의 그린 또는 블루 버전을 볼 수 있습니다. 브라우저의 페이지를 강제로 다시 로드하면 로드 밸런서가 작동을 시작하여 요청의 50%는 그린 애플리케이션으로, 50%는 블루 애플리케이션으로 전송하는 것을 볼 수 있습니다. 일부 브라우저는 페이지를 캐싱하므로 정의된 가중치가 반영되지 않을 수 있습니다. Safari와 Chrome은 Firefox보다 더 캐싱을 적극적으로 사용합니다.
이제, AWS Management Console에서 가중치를 80대 20으로 변경하고 브라우저를 새로 고쳐봅니다. 평균적으로 10번 중 8번은 블루 버전이 표시되는 것을 볼 수 있습니다.
ALB ModifyListener API, AWS CLI(명령줄 인터페이스) 또는 AWS CloudFormation을 통해서도 가중치를 조절할 수 있습니다.
예를 들어, AWS CLI(명령줄 인터페이스)를 다음과 같이 사용합니다.
aws elbv2 modify-listener \
--listener-arn "<listener arn>" \
--default-actions \
'[{
"Type": "forward",
"Order": 1,
"ForwardConfig": {
"TargetGroups": [
{ "TargetGroupArn": "<target group 1 arn>",
"Weight": 80 },
{ "TargetGroupArn": "<target group 2 arn>",
"Weight": 20 },
]
}
}]'또는 다음과 같은 JSON 추출로 AWS CloudFormation 을 사용합니다.
"ListenerRule1": {
"Type": "AWS::ElasticLoadBalancingV2::ListenerRule",
"Properties": {
"Actions": [{
"Type": "forward",
"ForwardConfig": {
"TargetGroups": [{
"TargetGroupArn": { "Ref": "TargetGroup1" },
"Weight": 1
}, {
"TargetGroupArn": { "Ref": "TargetGroup2" },
"Weight": 1
}]
}
}],
"Conditions": [{
"Field": "path-pattern",
"Values": ["foo"]
}],
"ListenerArn": { "Ref": "Listener" },
"Priority": 1
}
}외부 서비스 또는 도구를 사용하여 로드 밸런서를 관리하는 경우, 제공업체가 Application Load Balancer의 가중치 기반 라우팅 구성을 지원하도록 API를 업데이트할 때까지 기다려야 할 수 있습니다.
기타 사용 사례
AWS 고객은 블루/그린 배포 외에도 가중치 기반 대상 그룹을 두 가지의 추가 사용 사례, 즉 클라우드 마이그레이션 또는 서로 다른 AWS 컴퓨팅 리소스 간의 마이그레이션에 이용할 수 있습니다.
온프레미스 애플리케이션을 클라우드로 마이그레이션할 때에는 애플리케이션이 온프레미스 데이터 센터와 클라우드 둘 다에서 실행되는 기간을 가지는 점진적인 마이그레이션이 선호되기도 합니다. 클라우드 버전이 만족스럽게 기능하는 것을 확인했으면 최종적으로 온프레미스 애플리케이션을 완전히 중단할 수 있습니다.
비슷한 예로서, EC2 인스턴스에서 AWS Fargate에서 실행되는 Docker 컨테이너로 워크로드를 이전하는 경우, 새 대상 그룹에서 새 애플리케이션 스택을 시작하고 대상 그룹 가중치를 변경하면 최종 사용자에 대한 서비스 중지 없이 점진적으로 트래픽을 손쉽게 이동할 수 있습니다. Application Load Balancer는 EC2, 컨테이너(Amazon ECS, Amazon Elastic Kubernetes Service, AWS Fargate), AWS Lambda 함수 및 IP 주소와 같은 다양한 AWS 리소스를 대상으로 지원하므로, 이러한 리소스 사이에서 원하는 대로 트래픽을 이동할 수 있습니다.
대상 그룹 고정
지정된 기간 동안 고객이 동일한 버전의 애플리케이션을 경험할 수 있도록 지원해야 하는 상황이 있을 수 있습니다. 또는 현재 앱을 사용 중인 고객이 해당 세션 중에 새로 배포된 버전(green)으로 전환할 수 없도록 하기를 원할 수 있습니다. 이러한 사용 사례를 위해 대상 그룹 고정 기능이 도입되었습니다. 대상 그룹 고정 기능을 활성화하면 지정된 기간 동안 단일 고객의 요청이 모두 동일한 대상 그룹으로 전송됩니다. 기간이 만료되면 요청은 가중치에 따라 대상 그룹으로 분산됩니다. ALB는 대상 그룹 고정성을 유지하기 위해 쿠키를 발급합니다.
대상 그룹 고정은 기존 대상의 고정성(고정 세션)과는 다릅니다. 고정 세션은 고객의 요청이 대상 그룹 내의 특정 대상에 항상 고정되도록 합니다. 대상 그룹 고정은 요청이 특정 대상 그룹으로 전송되는 것만 보장합니다. 고정 세션은 대상 그룹 수준 고정과 함께 사용될 수 있습니다.
AWS CLI(명령줄 인터페이스)에서 대상 그룹 고정을 추가 또는 구성하려면 다음과 같이 TargetGroupStickinessConfig 파라미터를 사용합니다.
aws elbv2 modify-listener \
--listener-arn "<listener arn" \
--default-actions \
'[{
"Type": "forward",
"Order": 1,
"ForwardConfig": {
"TargetGroups": [
{"TargetGroupArn": "<target group 1 arn>", "Weight": 20}, \
{"TargetGroupArn": "<target group 2 arn>", "Weight": 80}, \
],
"TargetGroupStickinessConfig": {
"Enabled": true,
"DurationSeconds": 2000
}
}
}]'가용성
Application Load Balancer는 각각의 가중치를 가진 대상 그룹을 리스너 규칙당 최대 5개까지 지원합니다. 가중치는 API 임계값 제한 내에서 얼마든지 자주 변경할 수 있습니다. 실제 트래픽 가중치가 업데이트될 때가지는 약간의 지연이 있을 수 있습니다.
가중치 기반 대상 그룹은 현재 모든 AWS 리전에서 사용 가능합니다. Application Load Balancer에서 가중치 기반 대상 그룹을 사용할 때에는 추가 비용이 부과되지 않습니다.
PS: AWS 요금이 발생하지 않도록 이 블로그 게시물에서 생성한 예제 인프라를 잊지 말고 삭제하십시오. CDK가 생성한 인프라를 수동으로 수정했으므로 그냥 cdk destroy를 사용하면 인프라가 원상태로 복귀됩니다. 대신 AWS CloudFormation 콘솔을 사용하여 AlbWtgStack을 삭제하십시오. EC2 콘솔에서 blue 및 green 대상 그룹도 수동으로 삭제해야 합니다.