Amazon VPC 트래픽 미러링을 통해 상용 환경 트래픽을 테스트 환경으로 미러링하기

이 글은 AWS Networking and Content Delivery Blog에 게시된 Mirror production traffic to test environment with VPC Traffic Mirroring by Simone Pomata를 한국어 번역 및 편집하였습니다.

많은 기업에서 최종 사용자의 서비스 사용 경험에 영향을 주지 않으면서 상용 환경 트래픽을 테스트 환경으로 복제하기를 원합니다. 이를 트래픽 미러링(Traffic mirroring) 또는 트래픽 섀도잉(Traffic shadowing)이라고 합니다. 상용 환경 트래픽으로 새 버전의 워크로드를 테스트하는 것은 성공적인 릴리스를 위한 핵심 단계입니다. 일부 테스트에서는 가상으로 만든 트래픽을 사용하기도 하지만, 대부분의 경우 모든 잠재적인 클라이언트 동작을 예측하고 재현하기 어렵기 때문에 실제 트래픽을 활용하는 것이 더 나은 접근이거나 보완적인 접근 방식으로 활용되는 경우가 많습니다.

이번 게시물에서는 먼저 Amazon VPC Traffic Mirroring을 사용하여 HTTP 요청을 테스트 환경에 복제하는 방법을 알아봅니다. 그런 다음 제공된 CloudFormation 템플릿을 사용하여 VPC 트래픽 미러링(Traffic Mirroring) 설정을 진행합니다. 이 접근 방식은 상용 환경에 프록시나 서드 파티 소프트웨어를 추가하지 않기 때문에 위험을 최소화하고 상용 서비스 성능에 영향을 미치지 않습니다.

문제 상황

상용 환경 트래픽으로 테스트하는 방법에는 트래픽 분할(Traffic splitting)방식과 트래픽 미러링(Traffic Mirroring)방식이 있습니다.

그림 1 – 트래픽 분할(Traffic splitting) 및 트래픽 미러링(Traffic Mirroring)

트래픽 분할을 사용하면 일부 요청은 새 버전으로 라우팅하고 나머지 요청은 기본 버전으로 라우팅합니다. 이 접근 방식은 카나리아 릴리스, A/B 테스트, 블루/그린 배포에 사용됩니다. 일반적으로 중복 데이터를 생성하지 않기 때문에 구현하기가 더 쉽습니다. 하지만 일부 클라이언트에게 테스트 중인 새 버전이 노출되므로 새 버전에서 확인하지 못한 문제를 클라이언트가 경험할 수 있습니다.

트래픽 미러링을 사용하면 모든 요청이 기존 버전으로 라우팅되고 새 버전으로 복제됩니다. 클라이언트는 기존 버전의 응답만 수신하고 새 버전의 응답은 무시됩니다. 트래픽 미러링은 모든 클라이언트가 여전히 기존 버전에서 처리되므로 안전하고 영향이 적습니다. 한 가지 사용 사례는 요청이 무손실 요청이나 성능이 저하될 수 없는 워크로드입니다. 예를 들어, 온라인 쇼핑 플랫폼이나 중요한 금융 데이터 수집 워크로드가 이에 해당합니다. 트래픽 분할에 비해 트래픽 미러링은 데이터 중복을 방지해야 하는 추가 요구 사항이 있습니다. 예를 들어, 은행 결제나 온라인 쇼핑의 주문과 같이 중복 요청이 수신되더라도 요청을 한 번만 처리해야 하는 경우에는 비활성화 상태인 애플리케이션이 필요합니다.

AWS에는 트래픽 분할을 위한 여러 가지 도구가 있습니다. DNS 수준에서는 Amazon Route 53에 가중치 정책, 로드 밸런싱을 하는 경우 Application Load Balancer(ALB)의 가중치 기반 대상 그룹, 서버리스 애플리케이션의 경우 Amazon API Gateway에 카나리아 릴리스 배포 등 다양한 도구가 있습니다.

트래픽 미러링의 경우 오픈 소스 솔루션이 존재합니다. 예를 들어, NGINX 미러링 기능이나 마이크로서비스의 경우 Envoy의 RequestMirrorPolicy 기능을 사용할 수 있습니다. 하지만 이러한 솔루션을 사용하려면 상용 워크로드 앞에 프록시를 추가하거나 서버에 에이전트를 설치해야 합니다. 상용 환경에 이러한 구성 요소를 추가하는 것은 불가능하거나 위험할 수 있으며 성능에 악영향을 미칠 수 있습니다.

솔루션

Amazon VPC 트래픽 미러링을 사용하면 HTTP 요청을 복제하는 새로운 접근 방식을 사용할 수 있습니다. VPC 트래픽 미러링은 성능에 영향을 미치지 않고 서버 앞이나 서버에 구성 요소를 추가할 필요 없이 대상 서버의 트래픽을 복제합니다.

다음 다이어그램(그림 2)은 VPC 트래픽 미러링을 사용하는 솔루션의 아키텍처를 보여줍니다.

그림 2 – 아키텍처 다이어그램

이 아키텍처는 세 가지 구성 요소로 이루어져 있습니다.

Production environment: VPC 트래픽 미러링의 소스는 이 환경의 Amazon Elastic Compute Cloud(EC2) 인스턴스의 Elastic Network Interfaces (ENI)입니다. Auto Scaling Group과 같이 동적으로 추가되는 인스턴스를 포함하여 하나 이상의 소스 EC2 인스턴스를 가질 수 있습니다(“다중 인스턴스 환경으로 작업하기” 단계에서 확인 가능).
Replay handler:복제된 패킷이 처리되는 곳입니다. 복제된 패킷의 대상은 Network Load Balancer(NLB)이며, NLB는 다시 EC2 인스턴스에서 실행되는 핸들러 애플리케이션으로 패킷을 전달합니다. 고가용성 및 확장성을 위해 여러 개의 핸들러 EC2 인스턴스를 사용할 수 있습니다. VPC 트래픽 미러링은 VXLAN header로 패킷을 캡슐화합니다. 따라서 제공되는 소스코드는 패킷을 캡슐화 해제하고 HTTP 요청으로 재조립한 후 요청을 테스트 환경에 복제합니다. 테스트 환경의 응답은 핸들러로 전송되며, 핸들러는 이를 무시합니다.
Test environment: 테스트 또는 스테이징 환경입니다. 이 환경의 진입점은 단일 IP 주소 또는 DNS 이름일 수 있습니다. Replay handler는 복제된 요청을 이 진입점으로 보냅니다.

Replay handler는 GitHub에서 오픈소스 CloudFormation 템플릿으로 제공됩니다. 클릭 한 번으로 데모 환경을 구성하거나 제공되는 CloudFormation 템플릿을 활용하여 사용자 지정 환경을 구성할 수 있습니다.

실습

이번 단계에서는 이전 단계에서 제안한 솔루션을 배포합니다.

전제 조건

먼저 인터넷으로 통신하기 위해 NAT Gateway로 라우팅하는 사설 서브넷(Private subnet)이 있는 Amazon VPC가 필요합니다(NAT Gateway를 사용하면 공인 IP가 없는 Replay handler 인스턴스가 인터넷에서 소스 코드를 다운로드할 수 있습니다). 아직 이러한 VPC가 없는 경우 이 CloudFormation 템플릿을 사용하여 생성할 수 있습니다.

상용 환경 및 테스트 환경 구성하기

상용 환경과 테스트 환경의 두 샘플 환경을 구성합니다. 이 단계는 데모 목적으로만 사용됩니다. 이미 기존 환경이 있는 경우 이 단계를 건너뛰고 다음 단계(‘Replay handler 실행‘)로 넘어갈 수 있습니다.

두 개의 동일한 EC2 인스턴스를 생성합니다. Amazon Linux 2 AMI(인스턴스 시작 참조)와 VPC 내에서 포트 80의 TCP 트래픽을 허용하도록 보안 그룹을 설정합니다.
인스턴스의 이름을 변경합니다. 하나는 “Production”, 다른 하나는 “Test”라고 설정합니다.
SSH 또는 Linux 인스턴스에 연결하는 방법 중 하나를 사용하여 두 EC2 인스턴스에 연결합니다.
sudo yum install -y httpd 및 sudo systemctl start httpd를 실행하여 두 인스턴스 모두에서 Apache 웹 서버를 구성합니다.

그림 3 – 새로 생성된 EC2 인스턴스

Replay handler 실행

먼저 AWS CloudFormation 템플릿을 사용하여 Replay handler를 구성합니다.

아래의 “Launch Stack“ 버튼을 클릭합니다.

매개변수를 적절하게 입력 합니다. 이 데모에서는 다음과 같은 매개변수를 설정하였습니다.
1. “HandlerVpcId”에 Replay handler 가 생성될 VPC를 지정합니다. 이 데모를 간단하게 유지하려면 EC2 인스턴스 “Production” 및 “Test”를 생성 시 동일한 VPC를 사용하시기 바랍니다(단, 상용 환경 및 테스트 환경의 VPC에 연결할 수 있는 경우 별도의 VPC를 사용할 수 있습니다).
2. “HandlerSubnetIds”에Replay handler의 서브넷을 지정합니다. “Production” 및 “Test” EC2 인스턴스의 서브넷이 서로 통신하는 경로, 인터넷으로 통신하기 위해 NAT Gateway 로 향하는 경로가 설정된(공용 IP가 없는 Replay handler 인스턴스가 인터넷에서 소스 코드를 다운로드할 수 있도록) 서브넷을 사용합니다. 고가용성을 위해 별도의 가용성 영역에서 최소 두 개의 서브넷을 사용합니다.
3. “RequestsForwardDestination”의 경우 HTTP 프로토콜과 “Test” EC2 인스턴스의 IP 주소를 사용합니다. 다음 형식을 사용합니다: “http://<ip-address>”.
4. “TrafficMirroringVNI”의 경우 1에서 16777215 사이의 정수를 사용합니다. 예: “1234”.
“I acknowledge that AWS CloudFormation might create IAM resources” 체크박스를 체크합니다.
Create Stack을 클릭합니다.
스택의 상태가 “CREATE_COMPLETE”로 전환될 때까지 기다립니다. 그런 다음 출력(Outputs)을 선택하고 출력 값을 기록합니다.

그림 4 – CloudFormation 스택의 출력

상용 환경에서 VPC 트래픽 미러링 구성하기

이제 프로덕션 환경에서 VPC Traffic Mirroring Session을 구성합니다.

VPC Console로 이동합니다.
Traffic Mirroring(트래픽 미러링)에서 Mirror Sessions(미러 세션)으로 이동해 Create traffic mirror session(트래픽 미러 세션 생성) 버튼을 클릭합니다.
Mirror source(미러 소스)는 “Production” 인스턴스의 Elastic Network Interfaces(ENI)를 선택합니다.
Mirror target(미러 대상)은 CloudFormation 스택의 “TrafficMirrorTarget” 출력 값을 선택합니다(이전 단계의 5번을 참조).
Session number(세션 변호)는 1로 입력합니다.
VNI는 CloudFormation 스택의 매개변수로 등록한 TrafficMirroringVNI 값을 입력합니다(이전 단계의 2번을 참조).
Filter(필터)는 CloudFormation 스택에서 출력된TrafficMirrorFilter 값을 입력합니다(이전 단계의 5번을 참조).
나머지는 기본값으로 두고 Create 버튼을 클릭합니다.

그림 5 – Traffic mirror session 만들기

솔루션 테스트

HTTP 요청이 상용 환경으로 전송되면 자동으로 테스트 환경으로 복제됩니다. 이를 확인하기 위해 “Production” 인스턴스와 “Test” 인스턴스의 NetworkIn 지표를 Amazon CloudWatch의 지표 그래프에서 시각화할 수 있습니다.

그림 6 – “NetworkIn” 지표에 대한 CloudWatch 그래프

리소스 정리

이 예제에서 사용한 리소스를 정리하려면 배포한 CloudFormation 스택과 생성한 두 개의 EC2 인스턴스를 삭제 해야합니다. 전제 조건 단계에서 VPC를 생성한 경우 해당 VPC도 함께 삭제합니다.

추가 기능

이 단계에서는 이 솔루션의 몇 가지 추가 기능에 대해 설명합니다. 보다 포괄적인 매개변수 및 기능 목록은 GitHub의 Replay handler 문서에서 확인할 수 있습니다. 이 프로젝트는 오픈 소스 프로젝트이므로 지원되지 않는 기능이 필요한 경우 요청하거나 풀 리퀘스트를 통해 기여할 수 있습니다(기여하기 참조).

다중 인스턴스 환경으로 작업하기

실습 단계에서는 단일 EC2 인스턴스로 복제를 구성했습니다. 그러나 실제 환경에서는 상용 환경과 테스트 환경에는 여러 개의 인스턴스가 있을 수 있습니다. Elastic Load Balancing(ELB)을 통해 Auto Scaling Group으로 생성된 서비스를 예로 들 수 있습니다. 이 솔루션은 미러 소스와 미러 대상을 적절하게 구성하여 다중 인스턴스 환경에서 쉽게 사용할 수 있습니다.

다중 인스턴스 소스의 경우, 이 자동화 솔루션을 사용하여 상용 환경에서 새로 시작된 여러 EC2 인스턴스에서 트래픽 미러링을 구성할 수 있습니다. 이 자동화 솔루션은 리소스 태그, VPC 또는 서브넷을 기반으로 미러 소스를 설정합니다. 예를 들어, 애플리케이션 계층의 Auto Scaling Group에 있는 인스턴스를 식별하는 태그를 지정할 수 있습니다. 자동화 솔루션은 대상 그룹의 모든 인스턴스에 트래픽 미러링을 설정합니다. Auto Scaling Group에 의해 새 인스턴스가 추가되면 자동화 솔루션은 해당 인스턴스에도 트래픽 미러링을 설정합니다.

다중 인스턴스 대상의 경우, CloudFormation 스택을 생성할 때 DNS 이름을 대상으로 지정하기만 하면 됩니다. 예를 들어 테스트 환경의 애플리케이션 계층에 대한 로드 밸런서의 DNS 이름을 제공합니다. 사용할 스택 매개 변수는 “RequestsForwardDestination”입니다. 프로토콜(HTTP 또는 HTTPS)을 포함하여 DNS 이름(예 “https://load-balancer-address.example.com“)을 지정해야 합니다.

요청 받는 트래픽의 일부만 복제하기

Replay handler를 위해 CloudFormation 스택을 배포할 때 선택적으로 추가 매개변수를 지정할 수 있습니다.

예를 들어, 매개변수 “ForwardPercentage”를 사용하여 복제를 요청받는 트래픽의 비율을 정의할 수 있습니다(기본값은 100%). 예를 들어 모든 사용자의 요청이 아닌 일부 사용자의 요청을 복제하는 등 특정 비율의 헤더 값 또는 원격 주소에서 오는 요청만 복제하도록 선택할 수도 있습니다. 이렇게 하려면 스택 매개변수 “PercentageBy”를 “header” 또는 “remoteaddr”로 설정하면 됩니다. “PercentageBy”가 “header”로 설정된 경우 “PercentageByHeader” 파라미터에 헤더 이름을 제공해야 합니다.

결론

VPC 트래픽 미러링은 클라이언트에 영향을 주지 않으면서 상용 환경 트래픽을 사용해 새 버전이 배포된 스테이징 환경을 테스트할 수 있는 안전하고 효과적인 기술입니다. 이 게시물에서는 VPC 트래픽 미러링을 사용하여 상용 환경에서 테스트 또는 스테이징 환경으로 HTTP 요청을 복제하는 방법을 배웠습니다. 이 접근 방식은 상용 서버 자체 또는 그 상용 서버 앞에 어떤 구성 요소도 추가하지 않습니다. 따라서 상용 환경에 위험을 최소화하고 성능에 악영향을 미치지 않으면서 안정적이고 효과적으로 테스트를 진행할 수 있습니다. VPC 트래픽 미러링에 대한 자세한 내용은 공식 문서 그리고 이 웨비나를 참조하시기 바랍니다.

AWS 기술 블로그