Route53 Weighted의 Evaluate Target Health를 통한 트래픽 제어

Published in

Spoonlabs

10 min readMar 20, 2024

안녕하세요. SpoonRadio SRE팀에서 DevOps 업무를 담당하고 있는 Daniel(남태윤)입니다. 현재 SpoonRadio에서는 다양한 AWS 서비스를 사용 중에 있습니다. 그중 Route53으로 Weighted routing policy(가중치 기반 정책)를 활용한 트래픽 제어 중 잘못 알고 있었던 부분을 정리하고자 합니다.

Route53이란

우선 Route53은 가용성과 확장성이 뛰어난 DNS 서비스로써 3가지 주요 기능을 제공 합니다.

도메인 이름 등록 : 웹 사이트 또는 웹 애플리케이션 도메인 이름 등록
인터넷 트래픽을 도메인 리소스로 라우팅 : 도메인에 연결되어 있는 실제 서비스 리소스로 연결
리소스 상태 확인 : 도메인 대상 리소스의 정상 작동 중인지 확인하고, 비정상인 경우 다른 곳으로 트래픽을 자동 라우팅

일반 DNS 서비스와 동일하지만, 리소스의 상태 확인에 따라 트래픽을 제어하는 것은 Route53의 큰 장점 중 하나라고 볼 수 있습니다. 리소스의 상태 확인에 따라 DNS 장애 조치 구성으로 단순 및 복잡한 리소스의 트래픽 제어가 가능하기 때문입니다. 리소스의 상태 확인 구성 방법은 Alias 생성 여부에 따라 다릅니다.

별칭 레코드(Alias records) : AWS 리소스(ex. ELB, CloudFront …)의 대상 상태 평가(Evaluate Target Health)를 활성화
비별칭 레코드(Non-alias records) : 리소스에 상태 확인 요청을 전송할 수 있도록 사용할 프로토콜(HTTP, HTTPS, TCP), IP 주소 및 포트, 도메인 이름 및 경로를 지정. 즉, Health Check가 가능한 엔드포인트 정보 제공

서비스 요구사항

동일한 도메인을 기반으로 2개의 ALB를 사용한다.
특정 ALB에서는 2개의 TargetGroup을 사용한다
가중치 설정을 손쉽게 할 수 있다.
서비스 이상 발생 시(ex. TargetGroup Unhealthy) 트래픽을 자동으로 전환시킨다.

위와 같은 요구사항이 발생한 이유로는 기존 서비스를 신규 서비스로 트래픽을 점차적으로 늘려가기 위함이며, 이에 따라 복잡한 리소스 구성을 손쉽게 관리할 필요가 있었습니다. 해당 목적에 가장 부합한 Route53은 동일한 도메인으로 트래픽을 컨트롤 할 수 있었으며, Weighted routing policy의 “Evaluate Target Health” 옵션을 통해 TargetGroup-Unhealthy 발생 시 자동적으로 트래픽을 전환시킬 수 있습니다.

요구사항을 도식화 하면 다음과 같습니다.

Evaluate Target Health란

“Evaluate Target Health”는 Alias Record가 가능한 AWS 리소스(ex. Load Balancer, S3 등)의 상태를 평가하는 기능입니다.

여러 개의 인스턴스가 하나의 TargetGroup으로 묶여있을 때, 이 그룹이 여러 지역 또는 여러 가용 영역에 걸쳐 분산되어 있을 수 있습니다. 인스턴스 중 일부가 작동하지 않거나 장애가 발생한 경우, 사용자 트래픽을 Unhealthy 서버로 보내지 않도록 해야 합니다. 여기서 “Evaluate Target Health”가 필요합니다.

Evaluate Target Health는 다음과 같은 기능을 제공합니다.

대상 상태 평가 : 설정된 TargetGroup의 상태를 주기적으로 확인하고 각 대상의 상태를 평가합니다.
트래픽 라우팅 결정 : 대상 그룹 내의 Healthy 상태인 서버로만 트래픽을 라우팅합니다. 즉, 장애가 발생한 서버 또는 인스턴스에 대한 요청을 피할 수 있습니다.
자동 복구 및 장애 조치 : 인스턴스가 Healthy 상태로 복구될 때 자동으로 다시 트래픽을 전송합니다. 이것은 자동 복구 기능으로써, 사용자가 장애 조치를 취할 필요 없이 시스템이 자동으로 회복될 수 있도록 합니다.

이러한 기능들을 통해 Evaluate Target Health는 애플리케이션의 가용성과 신뢰성을 유지하고, 장애 발생 시 빠르게 대응할 수 있도록 도와줍니다.

적용 방법

적용 방법은 간단합니다. 레코드를 생성할 때, 라우팅 정책을 “Weighted”로 선택하고 원하는 가중치를 지정합니다. Evaluate target health는 Alias가 가능한 AWS 리소스로 선택 시 활성화할 수 있으며, 기본적으로 Yes로 설정됩니다.

Routing Policy(Weighted) 지정 & Evaluate Target Health

중복된 Record name으로 가중치 지정(Differentiator)

적용 결과

적용 방법은 매우 간단했으나 예상과 다르게 동작했습니다. 가중치 100%로 지정한 TargetGroup 방향으로 서비스가 동작하지 않았기 때문입니다. 오히려 가중치를 0%로 설정 했음에도 v1.0 ALB로 트래픽이 유입되는 것을 확인할 수 있었습니다.

원인 분석

앞서 도식화된 내용을 좀 더 설명하자면, v2.0 ALB에 존재하는 TargetGroup의 경우 Unhealthy인 상태가 지속되었습니다. 해당 TargetGroup(Unhealthy)의 가중치를 0%로 지정했으나 “Evaluate Target Health” 옵션은 해당 가중치를 고려하지 않고 Unhealthy 상태만을 확인하기 때문에 v1.0으로 트래픽을 전송합니다.

AWS 문서에서도 ALB 가중치에 대한 언급은 없고, 오직 인스턴스 리소스의 상태 체크만을 설명하고 있습니다.

만약 Evaluate Target Health를 모두 비활성화 시킨 경우 TargetGroup Unhealthy인 상태를 고려하지 않습니다. 이런 경우 최초 원했던 v2.0 ALB로 트래픽이 유입되지만, 요구사항 중 하나인 “서비스 이상 발생 시(ex. TargetGroup Unhealthy) 트래픽을 자동으로 전환시킨다.”를 만족시키지 못합니다.

원하는 목적지(B-1. Target Group)로 트래픽을 향하게 만들기 위해서는 UnHealthy Target Gruop(B-2. Target Group)을 제거 또는 정상 상태로 변경해야 합니다.

더 나아가

ALB별로 “Evaluate target health”를 각각 다르게 설정한 경우, 트래픽 이동이 다르다는 것을 확인할 수 있었습니다.

v2.0 ALB의 Evaluate target health 비활성화 시킨 경우 v1.0 ALB의 상태와 관련없이 트래픽이 (B-1) Target Group으로 이동합니다.

v1.0 ALB — Evaluate Target Health 활성화 / v2.0 ALB — Evaluate Target Health 비활성화

반대로 v1.0 ALB의 Evaluate target health를 비활성화 시켰을 때 아래와 같이 트래픽이 이동하며, 이때 중요한 점은 v2.0 ALB Evaluate target health의 조건에 따라 트래픽 방향이 결정 된다는 점입니다.

v1.0 ALB — Evaluate Target Health 비활성화 / v2.0 ALB — Evaluate Target Health 활성화

추가로 TargetGroup 내 여러 인스턴스 중 한 개 인스턴스만 Unhealthy인 경우. 의도한 가중치대로 트래픽이 전송되는 것을 확인할 수 있었습니다.

정리하자면, Route53의 Evaluate Target Health는 ALB TargetGroup 전체 상태만을 고려합니다. 내부 가중치를 고려하지 않습니다. ALB내에 특정 Target Group만으로 향하도록 가중치를 100% 설정 했음에도 가중치 0%인 Target Group의 모든 리소스 상태가 UnHealthy인 경우 Fail Open(고장이 났음에도 특정 요소가 열려있는 상태)이라고 인식하고 트래픽을 모두 차단합니다.