AWS 기술 블로그

AWS로의 로드밸런서 마이그레이션: 권장 전략 및 모범 사례

이 글은 AWS Networking & Content Delivery에 게시된 Load Balancer Migration to AWS: Recommended Strategies and Best Practices by Shirin Bano and Darryl Tyau 을 한국어 번역 및 편집하였습니다.

오늘 전세계 조직들은 클라우드가 제공하는 확장성, 비용 효율성 및 민첩성을 활용하기 위해 온프레미스 인프라를 클라우드로 마이그레이션하려는 경향이 커지고 있습니다. 많은 엔터프라이즈 아키텍처의 중요한 구성 요소 중 하나는 들어오는 트래픽을 여러 서버에 분산하는 로드 밸런서입니다. 온프레미스 하드웨어 로드 밸런서를 AWS로 마이그레이션하는 것을 고려하고 있다면, 현재 구성과 요구 사항을 깊이 있게 판단하여 가장 적합한 AWS 로드 밸런싱 솔루션을 결정하는 것이 필수적입니다. 이 블로그에서는 사전 계획 단계를 안내하고, 기존 로드 밸런서 설정을 평가하고 요구 사항에 맞는 Elastic Load Balancer (ELB)의 적합성을 평가하는 방법을 설명합니다. 그리고 특정 요구 사항을 지원하기 위해 다양한 유형의 ELB 및 AWS의 통합된 서비스를 살펴보도록 하겠습니다.

사전 마이그레이션 계획: 기존 로드 밸런서 구성 및 아키텍처 분석

로드 밸런서는 주로 애플리케이션의 진입점 역할을 하며, 단순한 라우팅 요청 처리 뿐만아니라 중요한 구성 요소 역할을 합니다. 온프레미스 로드 밸런서를 클라우드로 마이그레이션하기 전에 현재 로드 밸런서가 제공하는 기능과 성능을 철저히 평가하는 것이 필수적입니다. 기본적인 로드 밸런싱 및 백엔드 서버로의 요청 분산 외에도 기존 로드 밸런서는 공격 방지, 헤더 수정 또는 콘텐츠 기반 라우팅과 같은 추가 작업을 수행하고 있을 수 있습니다.

마이그레이션 전 계획 프로세스의 일환으로 현재 로드 밸런서 설정에 대한 포괄적인 인벤토리를 만듭니다. 다음 체크리스트는 고려해야 할 필수적인 몇 가지 측면을 다루지만, 특정 항목은 온프레미스 로드 밸런서의 유형과 구성에 따라 다를 수 있습니다.

  • 로드 밸런서 유형, 제조사, 모델, 용량 및 중복성 요구 사항(active-passive 또는 active-active)
  • 인터넷 연결(Public) 또는 내부(Private) 로드 밸런서
  • IPv4, IPv6 또는 듀얼 스택(IPv4 및 IPv6) 지원을 포함한 IP 주소 지정 요구 사항
  • 트래픽 패턴, 최대 부하, 트래픽 유형(HTTP/HTTPS, TCP, UDP) 및 세션 지속성 요구 사항
  • 백엔드 구성, 백엔드 수, 상태 검사 및 트래픽 분배 알고리즘(round-robin, least connection, IP hash)
  • SSL/TLS 종료, 방화벽 규칙 및 DDoS 보호와 같은 보안 요구 사항
  • 콘텐츠 기반 라우팅, 로깅, 모니터링 및 알림과 같은 추가 기능
  • FIPS와 같은 특정 표준 준수

클라우드 환경에서 로드 밸런서에 필요한 구체적인 기능을 명확하게 이해하면 요구 사항에 맞는 ELB 제품이 무엇인지, 아니면 맞춤형 로드 밸런싱 솔루션을 구축해야 하는지 판단하는 데 도움이 됩니다. 예를 들어, ‘AWS 클라우드에서 F5 BIG-IP를 F5 BIG-IP VE로 마이그레이션‘ 과 같은 AWS 규범적 지침은 EC2 인스턴스 실행 기반의 F5 BIG-IP에서 F5 BIG-IP VE로 마이그레이션하는 방법을 안내합니다.

AWS는 특정 사용 사례에 맞춰 다양한 로드 밸런싱 제품을 제공하며, 각 제품은 뚜렷한 특징과 성능을 갖추고 있습니다.

Application Load Balancer (ALB)는 HTTP/HTTPS 워크로드에 적합합니다. 지능형 요청 처리를 위한 콘텐츠 기반 라우팅을 지원하고, 보안을 위해 AWS 웹 애플리케이션 방화벽(WAF)과 통합되며, EC2, Lambda 및 컨테이너와 같은 다양한 대상을 지원하고, HAQM Cognito를 통한 인증 오프로드를 허용합니다. 이러한 기능을 갖춘 ALB는 고급 요청 처리, 유연한 통합 및 정교한 트래픽 분산이 필요한 안전하고 지연 시간이 짧은 애플리케이션에 이상적입니다.

Network Load Balancer (NLB)는 4계층에서 동작하는 고성능 TCP/UDP 워크로드에 적합합니다. 온라인 게임과 같이 낮은 지연 시간, 높은 처리량 및 방대한 수의 동시 연결을 요구하는 시나리오에서 탁월합니다. NLB는 정적 IP 주소를 지원하므로 IP 허용 목록이 필요한 워크로드나 IP 변경 없이 원활한 확장성이 필요한 데이터베이스에 적합합니다. 장기간 지속되는 연결을 처리할 수 있는 기능은 엄격한 성능 요구 사항과 지연 시간에 민감한 애플리케이션에 이상적인 선택입니다. NLB를 ALB와 결합하여 ALB의 장점을 활용하면서 고급 7계층 기능의 이점도 누릴 수 있습니다. ALB와 NLB는 모두 TLS 정책을 사용하여 FIPS 140-3 검증된 TLS (Transport Layer Security) 종료를 지원하여 규정 준수 요구 사항을 충족하는 데 도움이 됩니다.

Gateway Load Balancer (GWLB)는 검사 및 보안 목적으로 3계층의 게이트웨이 역할을 합니다. 심층 패킷 검사, 네트워크 가상화 또는 타사 가상 어플라이언스 통합이 필요한 시나리오에서 탁월한 성능을 발휘합니다. GENEVE 프로토콜을 활용함으로써, Gateway Load Balancer는 원래 패킷을 수정하지 않고 트래픽을 캡슐화하여 대상 어플라이언스로 전달하므로 엔드투엔드 연결을 방해하지 않고도 원활한 검사가 가능합니다. 따라서 세부적인 가시성, 트래픽 모니터링 또는 방화벽이나 침입 탐지 시스템과 같은 고급 보안 제어가 필요한 워크로드에 이상적입니다.

ELB 유형에 대한 정보에 입각한 결정을 내리는 데 도움이 되도록 AWS에서는 Elastic Load Balancing 기능 문서에서 다양한 로드 밸런서 유형과 지원되는 기능을 비교한 내용을 제공합니다.

특정 고급 기능이나 역량의 경우 로드 밸런서만으로는 충분하지 않을 수 있으며 다른 AWS 서비스와 통합해야 할 수도 있습니다. 이 블로그의 아키텍처 섹션에서는 원하는 기능을 달성하기 위해 ELB를 추가 AWS 서비스와 통합해야 할 수 있는 특정 사용 사례를 다룹니다.

또한 사전 마이그레이션 계획 프로세스의 일환으로 현재 로드 밸런서의 기능을 평가하고 클라우드 환경에서 실제로 필요한 기능을 파악하는 것이 중요합니다. 종종 기능은 사용 가능하기 때문에 활성화되지만 적극적으로 활용되거나 필요하지 않을 수 있습니다. 불필요한 기능을 제거하여 로드 밸런서 구성을 단순화하면 클라우드에서 관리를 간소화하고 복잡성을 줄이는 데 도움이 될 수 있습니다.

일반적인 로드 밸런서 아키텍처 패턴

1. 웹 애플리케이션 호스팅을 위한 헤더 기반 라우팅

그림 1: 웹 애플리케이션에 대한 호스트 기반 라우팅을 수행하기 위해 Application Load Balancer 사용

주요 아키텍처 포인트:

  • AWS Global Accelerator는 진입점으로 사용되어 정적 IP 주소를 제공하여 가장 가까운 AWS 에지 위치로 트래픽을 라우팅하여 가용성과 성능을 개선합니다.
  • AWS ALB는 주요 로드 밸런서 역할을 하며 HTTP/HTTPS 트래픽을 처리하고 호스트 헤더, HTTP 헤더/메서드, 경로 패턴, 쿼리 문자열과 같은 조건에 따라 고급 라우팅을 수행합니다. ALB는 정의된 조건에 따라 인증, 고정 응답, 전달, 리다이렉션과 같은 작업을 수행할 수 있습니다. ALB는 인증을 위해 Cognito와 통합되고, 인증되지 않은 요청을 Cognito로 리다이렉션하고, Cognito에서 발급한 토큰을 검증하여 액세스를 허용합니다.
  • ALB는 EC2 인스턴스의 자동 확장 그룹을 포함하는 다양한 대상 그룹으로 트래픽을 라우팅하며, 잠재적으로 다양한 애플리케이션 경로(/path1, /path2, /path3)를 위해 라우팅합니다. 다양한 유형의 대상 인스턴스, IP 및 Lambda 함수를 지원합니다.
  • ALB는 허용 목록, 거부 목록 및 일반적인 악용에 대한 보호와 같은 웹 애플리케이션 보안 제어를 위해 AWS WAF와 통합됩니다.
  • AWS Certificate Manager는 SSL/TLS 인증서를 프로비저닝하고 관리하여 Application Load Balancer에서 HTTPS 트래픽에 대한 TLS 종료를 활성화합니다.

2. NLB를 통한 Central ALB 및 PrivateLink를 통한 중앙화된 인바운드 트래픽

그림 2: Network Load Balancer와 함께 Central Application Load Balancer 및 AWS PrivateLink를 사용하여인터넷 애플리케이션을 안전하게 배포

주요 아키텍처 포인트:

온프레미스 로드 밸런서에서 AWS 로드 밸런서로의 트래픽 마이그레이션 전략

프로덕션 트래픽을 AWS로 마이그레이션하기 전에 원활한 전환을 보장하기 위해서는 AWS 로드 밸런서 설정을 철저히 테스트하는 것이 중요합니다. 테스트 과정에는 AWS Load Balancer의 응답 시간이 허용 가능한 수준인지 확인하고 사용자 환경에 큰 영향을 미치지 않는지 확인하는 작업이 포함됩니다. 눈에 띄는 차이점이 있는 경우, 전체 마이그레이션을 진행 하기 전에 A/B 테스트를 진행하여 일부 사용자를 클라우드 환경으로 구성하고, 사용자의 피드백을 수집하고, 필요한 조정을 하는 것을 고려하세요.

또한, 고객 트래픽 볼륨을 시뮬레이션하기 위해 부하 테스트를 수행하고 새로운 설정이 성능이나 가용성을 저하시키지 않고, 예상되는 부하를 처리 할 수 있도록 올바르게 구성되었는지 확인하는 것이 필수적입니다. 부하 테스트를 지원하는 다양한 타사 도구를 사용하여 실제 구성 환경에서 시뮬레이션 할 수 있고, 마이그레이션 전에 잠재적인 병목 현상이나 문제를 식별할 수 있습니다. 이 단계에서 정기적으로 사용자 피드백을 수집하고 성능 메트릭을 모니터링하면 실시간으로 필요한 조정을 할 수 있습니다.

AWS 클라우드에서 애플리케이션의 성능이 수용 할 수 있는 수준인지, 요구 사항들에 충족하는지를 확인한 후 온프레미스 환경에서 새로운 AWS 환경으로 트래픽을 점진적으로 전환할 수 있습니다. 이 점진적 마이그레이션에는 두 가지 방법을 활용 할 수 있습니다.

  1. 현재 로드 밸런서 사용: 기존 온프레미스 로드 밸런서가 여러 환경에 걸친 트래픽 분산을 지원하는 경우, 온프레미스 환경으로의 트래픽을 줄이는 동시에 AWS 로드 밸런서로 전송되는 트래픽 비율을 점진적으로 늘리도록 로드 밸런서를 구성할 수 있습니다.
  2. Route53 가중 DNS 라우팅 사용: HAQM Route53을 사용하면 온프레미스 로드 밸런서와 AWS 로드 밸런서 모두에 대한 가중 엔드포인트 항목이 있는 DNS 레코드를 만들 수 있습니다. 처음에는 온프레미스 엔드포인트에 더 높은 가중치를 할당하여 대부분의 트래픽을 기존 인프라 환경으로 라우팅합니다. 그런 다음 온프레미스 엔드포인트의 가중치를 점진적으로 낮추고 AWS 로드 밸런서 엔드포인트의 가중치를 높여 효과적으로 더 많은 트래픽을 클라우드 환경으로 이동합니다.

이 접근 방식을 따르면 트래픽을 AWS Load Balancer로 제어되고 점진적으로 마이그레이션하여 다운타임이나 성능 문제의 위험을 최소화할 수 있습니다. 마이그레이션 과정 중에 애플리케이션의 성능과 사용자 환경을 지속적으로 모니터링하고 필요한 경우 트래픽 분배를 조정하거나 원복할 준비를 합니다. 잠재적인 문제를 사전에 포착하기 위해 자동화된 알림을 구현합니다.

결론

AWS로의 원활한 마이그레이션을 위해서는 기존 로드 밸런싱 설정에 대한 철저한 계획과 평가가 중요합니다. 특정 요구 사항을 파악하고 올바른 AWS 로드 밸런싱 솔루션을 선택하면 마이그레이션 프로세스를 최적화할 수 있습니다. 마이그레이션을 시작하기 전에 A/B 테스트 및 부하 테스트를 포함한 광범위한 테스트는 필수적입니다. 이 블로그에서 나열된 최적화된 전략과 모범 사례를 따르면 로드 밸런싱 인프라에 AWS 클라우드가 제공하는 확장성, 비용 효율성 및 민첩성 이점을 활용할 수 있습니다.

AWS로의 로드 밸런서 마이그레이션 여정을 시작할 준비가 되었다면 AWS Load Balancer 문서를 살펴보세요. 또한 AWS 파트너 또는 AWS Professional Services와 협력하여 특정 요구 사항에 맞게 성공적인 마이그레이션을 계획, 설계 및 실행하는 데 도움을 받을 수 있습니다.

Jaehyuk Yoo

Jaehyuk Yoo

유재혁 Technical Account Manager는 현재 게임 고객들이 AWS 클라우드에서 효율적인 운영과 최적화된 가이드를 제공함으로써 필요한 도움을 드리고 있습니다. 다양한 규모의 프로젝트에 참여했던 경험을 기반으로 고객에게 최적의 가이드를 제공함으로써 고객 비즈니스가 성장할 수 있도록 지원하고 있습니다.