Category: Elastic Load Balancing*


애플리케이션 로드 밸런서(ALB) 기반 서버 이름별(SNI) 다중 TLS 인증서 지원

오늘부터 우리는 애플리케이션 로드 밸런서(ALB)에서 서버 이름 표시(SNI)를 사용해 다중 TLS/SSL 인증서 지원을 시작합니다. 이제 단일 로드 밸런서 뒤에서 각각 자체 TLS 인증서를 갖는 다수의 TLS 보안 애플리케이션을 호스팅할 수 있습니다. SNI는 로드 밸런서에서 동일한 보안 리스너로 다수의 인증서를 바인딩하기만 하면 사용할 수 있습니다. 그러면 ALB가 각 클라이언트마다 최적의TLS 인증서를 자동으로 선택합니다. 이러한 새로운 기능은 추가 요금 없이 제공됩니다.

새로운 기능의 사용 방법에 대한 TL;DR을 찾고 있다면 여기를 클릭하십시오. 저처럼 TLS(Transport Layer Security)에 대해서 약간 서툴다고 생각한다면 아래 이어지는 내용까지 계속해서 읽어주십시오.

TLS? SSL? SNI?

SSL과 TLS는 기술적으로 약간 다르기는 하지만 동일한 용어로 사용되는 경우가 많습니다. 기술적인 측면에서 SSL은 TLS 프로토콜의 이전 형태라고 할 수 있습니다. 하지만 쉽게 이해할 수 있도록 이번 포스트에서는 TLS라는 용어를 사용하겠습니다.

TLS는 암호, 쿠키, 신용 카드 번호 같은 데이터를 안전하게 전송하기 위한 프로토콜입니다. 이를 위해 전송되는 데이터의 프라이버시, 인증 및 무결성을 지원합니다. TLS는 인증서 기반 인증 방식을 사용합니다. 여기에서 인증서는 웹사이트에서 ID 카드와 같은 역할을 합니다. 즉 인증서에 서명하여 발급하는 사람, 즉 인증 기관(CA)을 신뢰하기 때문에 인증서 데이터의 정확성까지 신뢰하게 됩니다. 브라우저가 TLS를 지원하는 ALB에 연결되면 ALB가 사이트의 공개 키가 포함된 인증서를 제출합니다. 이 공개 키에는 CA의 서명이 암호화되어 있습니다. 이러한 방식으로 클라이언트는 실제 서버라는 사실을 신뢰하고 사이트의 공개 키를 사용하여 안전하게 연결을 구성합니다.

SNI 지원이 시작되면서 이제는 동일한 ALB에 인증서를 1개 이상 쉽게 사용할 수 있게 되었습니다. 다수의 인증서가 필요한 가장 공통적인 이유는 동일한 로드 밸런서로 여러 도메인을 처리해야 하기 때문입니다. ALB에 와일드카드 인증서와 SAN(Subject-Alternate-Name) 인증서를 사용하는 것은 항상 가능했지만 몇 가지 제약이 따릅니다. 와일드카드 인증서는 단순 패턴이 일치하는 하위 도메인에서만 사용 가능합니다. 또한 SAN 인증서가 다수의 여러 도메인을 지원하기는 하지만 동일한 인증 기관이 각 도메인을 인증해야 합니다. 이 말은 새로운 도메인을 추가할 때마다 인증서를 다시 인증하고 프로비저닝해야 한다는 것을 의미합니다.

포럼과 reddit, 그리고 저의 이메일 수신함으로 가장 자주 도착하는 요청 중 하나가 바로 TLS의 서버 이름 표시(SNI) 확장을 사용하여 클라이언트 인증서를 선택할 수 있도록 해달라는 것이었습니다. TLS는 HTTP 아래 단계인 전송 레이어에 속하기 때문에 클라이언트가 요청하는 호스트 이름을 알지 못합니다. 이때 클라이언트가 처음 연결 시 서버에게 “이것이 내가 인증서를 원하는 도메인입니다”라고 지정할 수 있도록 도와주는 것이 바로 SNI입니다. 그러면 서버가 올바른 인증서를 선택하여 클라이언트에게 응답할 수 있습니다. 오늘날 모든 웹 브라우저와 대다수 클라이언트는 SNI를 지원합니다. 실제로 CloudFront에 연결되는 클라이언트의 99.5% 이상이 SNI를 지원하고 있습니다.

ALB의 스마트 인증서 선택

ALB의 스마트 인증서 선택은 SNI보다 한 걸음 더 나아갑니다. 유효한 도메인 이름 목록이 저장되는 것 외에도 키 교환 유형과 서버가 지원하는 암호화, 그리고 인증서 서명에 사용되는 알고리즘(SHA2, SHA1, MD5)이 인증서에 설명되어 있습니다. TLS 연결을 구성하려면 먼저 클라이언트가 프로토콜 버전, 확장자, 암호 그룹, 압축 방법 등 클라이언트의 기능을 간략히 나타낸 “ClientHello” 메시지를 전송하여 TLS 핸드섀이크를 시작합니다. 그러면 ALB의 스마트 선택 알고리즘이 각 클라이언트가 지원하는 기능에 따라 연결에 적합한 인증서를 선택하여 클라이언트에게 보냅니다. ALB는 고전적인 RSA 알고리즘과 최근에 등장하여 더욱 빠른 속도를 자랑하는 타원 곡선(Elliptic-curve) 기반 ECDSA 알고리즘을 모두 지원합니다. ECDSA 지원이 SNI만큼 클라이언트 사이에 널리 퍼진 것은 아니지만 오늘날 모든 웹 브라우저에서는 이미 지원되고 있습니다. 속도가 더욱 빠를 뿐만 아니라 CPU 사용량도 적기 때문에 지연 시간이 매우 낮은 애플리케이션에 유용할 뿐만 아니라 모바일 애플리케이션에서 사용되는 배터리 양을 절약하는 데도 매우 효과적입니다. ALB가 TLS 핸드섀이크를 통해 각 클라이언트가 지원하는 기능을 알 수 있기 때문에 RSA 인증서와 ECDSA 인증서를 동일한 도메인에 모두 업로드할 수 있습니다. 그러면 ALB가 각 클라이언트마다 가장 알맞은 인증서를 자동으로 선택합니다.

ALB와 SNI의 사용

여기에서 2개의 웹사이트인 VimIsBetterThanEmacs.comVimIsTheBest.com를 예로 들겠습니다. 저는 이 두 도메인을 구매하여 Amazon Route 53에 호스팅한 후 각 도메인에 사용할 인증서 2개를 AWS Certificate Manager(ACM)에 프로비저닝하였습니다. 이때 단일 ALB를 통해 두 사이트를 모두 안전하게 운영하고 싶다면 콘솔에서 인증서 2개를 빠르게 추가할 수 있습니다.

먼저 콘솔에서 내 로드 밸런서를 선택한 후 리스너 탭으로 이동하여 “view/edit certificates”를 선택합니다.

그런 다음 왼쪽 상단 모퉁이에 있는 “+” 버튼을 사용하여 인증서를 선택한 다음 “Add” 버튼을 클릭합니다.

이제 다 끝났습니다. GUI 사용에 익숙하지 않다면 AWS 명령줄 인터페이스(CLI)(또는 SDK)를 사용하여 새로운 인증서를 쉽게 추가하는 방법도 있습니다.

aws elbv2 add-listener-certificates --listener-arn <listener-arn> --certificates CertificateArn=<cert-arn>

알아야 할 것들

  • ALB 액세스 로그에는 클라이언트가 요청한 호스트 이름과 사용한 인증서 ARN이 포함됩니다. “hostname” 필드가 비어있다면(“-“로 표시) 클라이언트가 요청에서 SNI 확장을 사용하지 않았기 때문입니다.
  • ACM 또는 IAM에서는 어떤 인증서든 사용할 수 있습니다.
  • 동일한 도메인이라고 해도 다수의 인증서를 보안 리스너로 바인딩할 수 있습니다. 그러면 ALB가 클라이언트 기능을 포함하여 여러 가지 요인에 따라 최적의 인증서를 선택합니다.
  • 클라이언트가 SNI를 지원하지 않으면 ALB가 기본 인증서(리스너 생성 시 지정한 인증서)를 사용합니다.
  • 새로운 ELB API 호출은 AddListenerCertificates, RemoveListenerCertificates, DescribeListenerCertificates 등 세 가지가 있습니다.
  • 로드 밸런서 1개당 바인딩이 가능한 인증서는 최대 25개입니다(기본 인증서 제외).
  • 이번에 새롭게 추가된 기능은 처음부터 AWS CloudFormation에서 지원됩니다.

새로운 기능의 사용 예는 저의 동료인 Jon Zobrist가 만든 웹사이트(https://www.exampleloadbalancer.com/)에서 찾아볼 수 있습니다.

저는 개인적으로 이 기능을 사용할 예정이며 수많은 AWS 사용자들 역시 커다란 이점을 경험하게 될 것입니다. AWS 사용자들을 위해 이처럼 멋진 기능을 개발하느라 수고해 주신 Elastic Load Balancing 팀에게 깊은 감사를 드립니다.

Randall;

이 글은 Application Load Balancers Now Support Multiple TLS Certificates With Smart Selection Using SNI 한국어 번역입니다.

신규 Network Load Balancer 출시 – 초당 수백만 요청을 처리 확장성 제공

ELB (Elastic Load Balancing)Auto ScalingAmazon CloudWatch 등 3종 세트는 AWS 초기 부터 매우 중요한 부분입니다. 그 이후로 많은 기능이 추가하였고, Application Load Balancer는 컨테이너에서 실행되는  애플리케이션의 콘텐츠 기반 라우팅을 지원하도록 설계하여 마이크로서비스, 스트리밍 및 실시간 서비스 등에 최적화되어 있습니다.

오랫 동안 AWS 고객은 ELB를 사용하여 T2 인스턴스에서 실행하는 단순한 웹 사이트에서부터 다수의 고급 인스턴스에서 실행되는 복잡한 애플리케이션에 이르기까지 다양한 규모의 서비스에 활용하여 방대한 양의 트래픽을 처리 할 수 있었습니다. ELB는 배후에서 트래픽을 모니터링하고, 수요에 맞게 자동으로 확장합니다. 몇년 간 높은 반응 속도를 보이도록 개선 한 결과, ELB를 사용한 온라인 생중계, 깜짝 판매 이벤트 등의 이벤트성 서비스에도 잘 동작합니다. 그러나, 리전 간 순간적인 페일 오버 또는 극히 까다로운 워크 로드와 같은 일부 상황에서 트래픽 급상승을 예상하는 경우 ELB를 사전에 미리 설정해 두고(pre-warm)으로 제공하는 옵션을 제공했습니다.

신규 네트워크 로드 밸런서 출시
오늘 네트워크 로드 밸런서 (NLB)를 새롭게 소개합니다. 본 서비스는 낮은 대기 시간에 높은 처리량을 유지하면서 초당 수천만 건의 요청을 처리 할 수 있도록 설계되었습니다. NLB는 대상 그룹에 대해 API 호환성이 높은 ALB입니다. 아래는 주요 기능을 소개합니다.

  • 고정 IP 주소 – 각 NLB는 각 VPC 서브넷마다 하나의 IP 주소를 제공합니다. us-west-2a의 서브넷에 대상이 있고 us-west-2c의 서브넷에 있는 다른 대상이 있는 경우 NLB는 두 개의 IP 주소(서브넷 당 하나)를 만들고 관리합니다. 해당 IP 주소에 대한 연결은 서브넷의 인스턴스간에 트래픽을 분산시킵니다. 각 서브넷에 대해 기존의 Elastic IP를 지정할 수도 있습니다. IP 주소를 완전히 제어하면 IP 주소를 DNS 레코드, 고객 방화벽 규칙 등에 하드 코딩해야하는 상황에서 NLB를 사용할 수 있습니다.
  • Zonality – 서브넷 당 고정 IP 기능은 향상된 성능으로 지연 시간을 줄이고 격리 및 내결함성을 통해 가용성을 향상 시키며 NLB 클라이언트에서 바로 사용 가능합니다. 또한, NLB는 자동 장애 조치를 통해, 특정 소스의 일련의 요청을 단일 서브넷의 대상으로 라우팅합니다.
  • 소스 주소 보존 – NLB를 사용하면 들어오는 연결의 원래 소스 IP 주소 및  포트가 수정되지 않으므로 응용 프로그램 소프트웨어는 X-Forwarded-For, 프록시 프로토콜 또는 다른 해결 방법을 지원할 필요가 없습니다. 이는 VPC 보안 그룹을 포함한 일반 방화벽 규칙을 대상에서 사용할 수 있습니다.
  • 장기 연결 유지 및 실행 – NLB는 내결함성을 내장한 연결을 처리하고 몇 달 또는 몇 년 동안 커넥션을 처리 할 수 있으므로 IoT, 게임 및 메시징 응용 프로그램에 매우 적합합니다.
  • 장애 조치 Route 53 상태 검사에 의해 작동되는 NLB는 리전 내 및 리전 간 IP 주소 간의 장애 조치를 지원합니다.

Network Load Balancer 만들기
EC2 콘솔에 가면, 새로운 Load Balancers항목에서 Create Load Balancer를 클릭합니다.

네트워크 로드 밸런서를 선택하고 만들기를 클릭 한 다음 세부 정보를 입력합니다. 대상 VPC의 각 서브넷에 대해 Elastic IP 주소를 선택할 수 있으며, 태그를 지정할 수 있습니다.

그런 다음 라우팅 구성을 클릭하고 새 대상 그룹(Target Group)을 만듭니다. 이름을 입력 한 다음 프로토콜과 포트를 선택합니다. 트래픽 포트와 상태 확인 방법을 설정할 수 있습니다.

Register Targets를 눌러 EC2 인스턴스를 설정 한 후, Add to registered:를 클릭합니다.

모든 것이 잘 설정 되었으면, Create를 선택합니다.

신규 로드 밸런서가 완료 되면 몇 분 후 provisioning에서 active로 바뀝니다.

테스트 목적으로 콘솔에서 Load Balancer의 DNS 이름을 가져옵니다 (실제로는 Amazon Route 53 와 좀 더 친숙한 이름을 사용합니다.)

이제 대량 트래픽을 한번 보내 볼 때입니다.

Bash
$ while true;
> do
>   wget http://nlb-1-6386cc6bf24701af.elb.us-west-2.amazonaws.com/phpinfo2.php &
> done

몇 가지 트래픽 흐름을 허용하기 위해, CloudWatch 지표를 확인하면 갑작 스러운 트래픽을 잘 처리 할 수 ​​있음을 확인했습니다.

또한, EC2 인스턴스를 보고 부하가 어떻게 작동하는지 확인했습니다.

AWS 개발팀에서 위의 것 보다 더 나은 테스트를 해 보았고, 수백 대의 EC2 인스턴스로 클러스터에서 초당 150 만 건의 요청을 시작으로 신속하게 초당 300만 건의 요청과 총 대역폭의 30Gbps를 달성했습니다.

Load Balancer 선택하기
로드 밸런서를 선택할 때, 여러분의 애플리케이션 요구 사항을 고려해야합니다. 다음은 몇 가지 지침입니다.

  • Network Load Balancer (NLB) – TCP 트래픽 로드 밸런싱에 이상적인 NLB는 초저 대기 시간을 유지하면서 초당 수백만 건의 요청을 처리 할 수 ​​있습니다. NLB는 가용성 영역 당 하나의 고정 IP 주소를 사용하면서 갑작스럽고 불안정한 트래픽 패턴을 처리하도록 최적화되어 있습니다.
  • Application Load Balancer (ALB)HTTP 및 HTTPS 트래픽의 고급 로드 밸런싱에 이상적인 ALB는 마이크로서비스 및 컨테이너 기반 응용 프로그램을 포함한 최신 응용 프로그램 아키텍처를 지원하는 고급 요청 라우팅을 제공합니다.
  • Classic Load Balancer (CLB) – EC2-Classic 네트워크 내에 구축 된 애플리케이션에 이상적입니다.

좀 더 자세한 사항은 Elastic Load Balancer 세부 정보 테이블을 살펴 보시기 바랍니다.

현재 Classic Load Balancer를 사용 중이고 Network Load Balancer로 마이그레이션하려면 Load Balancer Copy Utility를 살펴보십시오. 이 Python 도구를 사용하면 기존의 Classic Load Balancer와 동일한 구성으로 NLB를 만들 수 있습니다. 기존로드 밸런서를 사용하여 기존 EC2 인스턴스를 등록 할 수도 있습니다.

가격 및 가용 방법
Application Load Balancer와 마찬가지로 가격 책정은 Load Balancer Capacity Unit 또는 LCU를 기본으로합니다. 청구액은 다음 측정 기준에서 가장 높은 값을 기준으로 한 LCU 당 0.006 달러입니다.

  • 대역폭 – LCU 당 1GB.
  • 신규 연결 – LCU 당 800.
  • 활성 연결 – LCU 당 100,000.

대부분의 애플리케이션은 대역폭에 따라 달라 지고, 기존의 ALB와 비교할 때 약 25%의 비용 절감 (로드 균형 조정)이 있습니다. 네트워크로드 밸런서는 현재 China (Beijing)를 제외한 AWS CloudFormation, Auto ScalingAmazon ECS 등을 지원되는 모든 AWS 상용 리전에서 사용할 수 있습니다.

Jeff;

이 글은 New Network Load Balancer – Effortless Scaling to Millions of Requests per Second의 한국어 번역입니다.

Application Load Balancing을 통한 온-프레미스 서버 연결 기능 출시

작년에 새로운 Application Load Balancer 출시와 함께 네트워크 레이어 7의 애플리케이션 라우팅을 통해 EC2 인스턴스 및 콘테이너에서 실행하는 마이크로 서비스 구현 방법을 설명했습니다.

어떤 고객은 AWS로 장기간 이전 중인 하이브리드 애플리케이션을 구축하고 있습니다. 이들 고객은 단일 Application Load Balancer를 사용하여 기존 사내의 리소스와 AWS 클라우드에서 실행 중인 신규 리소스를 결합하여 트래픽을 분산할 필요가 있습니다. 또 다른 고객은 둘 이상의 가상 사설망(VPC)에 분산되어 있는 웹 서버 또는 데이터베이스 서버에 트래픽을 분산시키고, 동일한 인스턴스에서 중복되지 않는 고유 IP 주소를 사용하지만 공통 포트 번호를 사용하여 SNI (Server Name Indication)를 지원하지 않는 클라이언트 용 가상 기반 가상 호스팅을 통해 여러 서비스를 하기도 합니다. 또한, 여러 인터페이스와 보안 그룹을 사용하여 세분화 된 접근 제어를 구현하는 동시에 동일한 인스턴스(예: 컨테이너)에 여러 서비스 인스턴스를 호스팅하기도 합니다.이러한 상황은 엔터프라이즈 기업의 하이브리드, 마이그레이션, 재해 복구 및 사내 구축 환경의 사용 사례 및 시나리오에서 발생합니다.

이러한 상황은 엔터프라이즈 기업의 하이브리드, 마이그레이션, 재해 복구 및 사내 구축 환경의 사용 사례 및 시나리오에서 발생합니다.

IP 주소로 라우팅 하기
이러한 사용 사례를 해결하기 위해 Application Load Balancer는 이제 트래픽을 IP 주소로 직접 라우팅 할 수 있습니다. 이 주소는 ALB와 동일한 VPC, 동일한 리전의 피어 VPC, ClassicLink를 통해 VPC에 연결된 EC2 인스턴스 또는 VPN 연결 또는 AWS Direct Connect 연결 지점 내 사내 자원에있을 수 있습니다.

ALB는 이미 대상을 대상 그룹을 지정하고 있고, 오늘 부터 각 대상 그룹에는 오른쪽 그림 같이 Target Type 속성이 있습니다.

  • instance – 대상은 이전과 마찬가지로 EC2 인스턴스 ID를 통해 등록됩니다.
  • ip – 대상은 IP 주소로 등록됩니다. 로드 밸런서의 VPC 내의 대상에 대한로드 밸런서의 VPC CIDR과 RFC 1918 범위 (10.0.0.0/8, 172.16.0.0/12 및 192.168.0.0/16)의 IPv4 주소 또는 RFC 부하 분산 장치의 VPC 외부에있는 대상 (여기에는 Peered VPC, EC2-Classic 및 직접 연결 또는 VPN을 통해 도달 할 수있는 온 프레미스 대상 포함)에 대한 RFC 6598 범위 (100.64.0.0/10)가 있습니다.

각 대상 그룹에는 로드 밸런서 및 상태 확인 구성이 있으며, 항상 그렇듯이 CloudWatch에 지표를 게시합니다.

AWS 클라우드 마이그레이션의 전환 단계에 있거나 EC2 인스턴스로 AWS를 사용하여 사내 리소스를 확장하려는 경우, 애플리케이션 트래픽을 AWS 및 사내 구축 형 리소스 모두에 배포해야한다고 가정해 보겠습니다. 모든 리소스(AWS 및 사내 구축 형)를 동일한 대상 그룹에 등록하고 대상 그룹을로드 밸런서와 연관 시키면 이러한 기능을 수행 할 수 있습니다.

또한, 두 개의 로드 밸런서, 즉 AWS용 로드 밸런서 하나와 사내 구축 리소스용 로드 밸런서 하나를 사용하여 AWS 및 사내 구축 리소스에서 DNS 기반 부하 로드 밸런싱을 사용할 수 있습니다. 애플리케이션-A는 백 엔드가 VPC에 있고, 애플리케이션-B 백엔드가 온-프레미스 위치에 있는 시나리오에서 각 애플리케이션에 대한 백엔드를 다른 대상 그룹에 넣고 콘텐츠 기반 라우팅을 사용하여 트래픽을 각각 라우팅 할 수 있습니다.

Target Group 생성하기
다음은 Application Load Balancer를 생성하는 과정의 일부로 일부 IP 주소로 트래픽을 보내는 대상 그룹을 만드는 방법입니다. 여기서 이름 (ip-target-1)을 입력하고 대상 유형으로 ip를 선택합니다.

그런 다음 IP 주소 대상을 입력합니다. 로드 밸런서를 호스팅하는 VPC에서 가져올 수 있습니다.

또는 로드 밸런서를 호스팅하는 VPC 외부 대상에 대해 위에 나열된 개별 범위 중 하나로다른 개인 IP 주소일 가능성도 있습니다.

설정을 검토하고 로드 밸런서를 만든 후, 상태 확인을 통과하자마자 지정된 IP 주소로 트래픽이 전송됩니다. 각로드 밸런서는 최대 1000 개의 대상을 수용 할 수 있습니다.

타겟 그룹을 검토하고 언제든지 타겟 세트를 편집 할 수 있습니다.

위에서 처럼 스크린 샷을 찍었을 때, 타겟 중 하나가 문제 가 생긴 경우, (이것은 의도적으로 설계임) 각 대상 그룹에 대한 통계가 CloudWatch에 게시됩니다. 콘솔에서 볼 수 있으며 CloudWatch Alarms를 만들 수 있습니다.

정식 출시
이 기능은 현재 사용 가능하며 모든 AWS 리전에서 즉시 사용할 수 있습니다.

Jeff;

AWS Application Load Balancers – 호스트 기반 라우팅 규칙 신규 기능 지원

작년에 AWS Application Load Balancer 출시하면서 HTTP 요청 URL의 경로를 기반으로 들어오는 HTTP 및 HTTPS 트래픽을 라우팅 설정 방법을 소개하였습니다. 이러한  경로 기반 라우팅을 사용하여  /api로 들어오는 요청 모두를 /mobile이라는 다른 서버로 라우팅할 수 있습니다. 이러한 방식으로 트래픽을 분류하면 각 요청 카테고리에 대한 처리 환경을 제어 할 수 있습니다. 예를 들어, /api 요청은 컴퓨팅 작업을 위한 인스턴스에서 처리하고, /mobile 요청은 메모리 기반 인스턴스에서 처리할 수 있습니다.

호스트 기반 라우팅 및 기타 규칙
오늘은 추가적인 라우팅 옵션을 소개해 드리고자 합니다. 오늘 부터 호스트 헤더에 지정된 도메인 이름을 기반으로 들어오는 트래픽을 라우팅하는 Application Load Balancer 규칙을 만들 수 있습니다. 예를 들어, api.example.com에 대한 요청은 하나의 대상 그룹에 보내고 mobile.example.com에 대한 요청은 다른 그룹에 보낼 수 있으며, 다른 모든 요청은 (기본 규칙을 통해) 다른 서버로 보낼 수 있습니다. 호스트 기반 라우팅과 경로 기반 라우팅을 결합하는 규칙을 만들 수도 있습니다. 이렇게하면 api.example.com/productionapi.example.com/sandbox로 요청을 다른 대상 그룹으로 라우팅 할 수 있습니다.

과거에는 고객이 프록시 서버를 직접 설치 운영하면서 호스트 기반 라우팅에 사용했습니다. 오늘 출시한 신규 Application Load Balancer 규칙을 사용하여 라우팅을 수행 할 수 있으므로, 과거와 같이 프록시 서버가 더 이상 필요하지 않습니다. 이를 통해 서비스 아키텍처가 단순해지고, 추가 프록시 서버 운영 오버 헤드가 줄어 듭니다.

Application Load Balancer는 포트 맵핑, 상태 점검 및 서비스 검색 등 콘테이너 응용 프로그램을 지원하는 몇 가지 기능을 제공합니다. 호스트와 경로 모두에서 라우팅 할 수 있으므로, 개별 Amazon EC2 Container Service 콘테이너에서 실행되는 마이크로 서비스 기반 애플리케이션을 구축 및 확장할 수 있습니다. 호스트 기반 라우팅을 사용하면 서비스 이름과 콘테이너 이름을 정렬하여, 서비스 검색 메커니즘을 더욱 단순화 할 수 있습니다.

Application Load Balancer당 최대 규칙 수를 10개에서 75개로 늘리고, 새로운 규칙 편집기를 도입했습니다. 직접 한번 살펴보겠습니다.

Load Balancing Console 관련된 리스너가 표시됩니다. 여기에서 View/edit rules을 클릭하여 새 규칙 편집기에 접근할 수 있습니다.

이미 모든 요청을 web-target-production 대상으로 전달하는 기본 규칙이 있습니다.

삽입 아이콘 ( “+”기호)을 클릭하고 위치를 선택합니다. 규칙은 표시된 순서대로 처리됩니다.

Insert Rule을 클릭하고 새 규칙을 정의합니다. 규칙은 호스트, 경로 또는 둘 다를 참조 할 수 있습니다.

호스트 기반 라우팅을 위한 두 가지 규칙을 추가하면, 다음과 같이 보입니다.

프로덕션 및 샌드 박스 트래픽을 별개 대상으로 라우팅하려는 경우, 해당 경로를 참조하는 새 규칙을 만들 수 있습니다. 첫 번째는 다음과 같습니다.

몇 번의 클릭과 약간의 타이핑으로 강력한 규칙 집합을 만들 수 있습니다.

호스트 헤더와 일치하는 규칙에는 최대 3 개의 “*”(0 자 이상 일치) 또는 “?”(1 자 일치) 와일드 카드가 포함될 수 있습니다. 대형 고객의 경우, 추적 용도로 고유한 호스트 이름을 부여한다고 가정 해 보겠습니다. 호스트 이름의 마지막 부분에 관계없이 모든 요청을 동일한 대상 그룹으로 라우팅하는 규칙을 작성할 수 있습니다. 다음은 간단한 예입니다.

규칙 편집기의 연필 아이콘을 사용하면 규칙 순서를 변경할 수 있습니다. 규칙을 선택하고 새 규칙으로 이동 한 다음 업데이트 된 순서로 저장합니다.

존 규칙을 편집하거나 불필요한 규칙을 삭제할 수도 있습니다.

정식 출시
본 기능은 서울 리전을 포함하여 15개 AWS 모든 리전에서 사용할 수 있습니다.

첫 10 가지 규칙 (호스트 기반, 경로 기반 또는 둘 다)에 대한 추가 요금은 없습니다. 그 이후, 규칙 수에 따라 비용이 청구됩니다 (이전 게시물에서 설명한 Load Balancer Capacity units (LCU) 모델에 추가 된 새로운 부분입니다). 각 LCU는 최대 1000 개의 규칙 평가를 지원합니다. LCU의 4가지 차원에서 데이터를 측정하지만, 주어진 시간대에 가장 많이 사용되는 차원에 대해서만 비용이 청구됩니다. 구성되었지만 처리되지 않은 규칙은 비용이 청구되지 않습니다.

Jeff;

이 글은 New – Host-Based Routing Support for AWS Application Load Balancers의 한국어 번역입니다.

AWS IPv6 업데이트 – 서울 리전 포함 글로벌 및 지원 서비스 확대

AWS는 이미 Elastic Load Balancing, AWS IoT, AWS Direct Connect, Amazon Route 53, Amazon CloudFront, AWS WAF, S3 Transfer Acceleration 기능을 시작으로 지난 몇 년 동안 여러 가지 AWS 여러 부분에 IPv6 지원을 추가하기 위해 노력해 왔습니다. 지난 달 (오하이오 리전을 시작으로) VPC 기반 EC2 인스턴스의 IPv6 지원을 시작하였습니다.

오늘 부터 VPC에서 EC2 인스턴스에 대한 IPv6 지원은 총 15 개 리전에서 사용 가능하며, 9 개 리전에서 IPv6에 대한 Application Load Balancer 지원이 제공됩니다.

이제 IPv6 주소를 사용하여 서버, 개체 저장소, 부하 분산 및 콘텐츠 배포 서비스와 통신 할 수 있는 응용 프로그램을 손쉽게 구축하고 배포 할 수 있습니다. Apple 및 다른 모바일 기기 공급 업체의 IPv6 지원에 대한 최신 지침에 따라 모바일 응용 프로그램은 AWS와 통신 할 때 IPv6 주소를 사용할 수 있습니다.

총 15개 리전에서 IPv6 지원 시작
기존 및 신규 VPC에서 EC2 인스턴스에 대한 IPv6 지원은 현재 미국 동부 (버지니아 북부), 미국 동부 (오하이오), 미국 서부 (캘리포니아 북부), 미국 서부 (오레곤), 남아메리카 (상파울루), 캐나다 아시아 태평양 (서울), 아시아 태평양 (시드니), 아시아 태평양 (뭄바이), AWS (아시아 태평양 지역), 아시아 태평양 지역 GovCloud (미국) 리전에서 사용 가능합니다.

새 VPC를 만들 때 AWS 관리 콘솔에서 IPv6을 활성화 할 수 있습니다.

Application Load Balancer 지원
미국 북동부 (버지니아 북부), 미국 서부 (캘리포니아 북부), 미국 서부 (오레곤), 남아메리카 (상파울루), EU (아일랜드), 아시아 태평양 (도쿄), 아시아 태평양 (싱가포르), 아시아 태평양 (Sydney) 및 AWS GovCloud (US) 리전은 IPv6를 듀얼 스택 모드로 지원하므로 IPv4 또는 IPv6을 통해 접근 할 수 있습니다 (몇 주 이내에 나머지 리전에 대한 지원이 추가 될 예정입니다).

ALB를 구성 할 때 dualstack 옵션을 활성화 한 다음 보안 그룹이 요구 사항에 따라 IPv6 트래픽을 허용하거나 거부하는지 확인하십시오. 듀얼 스택 옵션을 선택하는 방법은 다음과 같습니다.

set-ip-address-type 명령을 실행하거나 SetIpAddressType 함수를 호출하여 옵션을 활성화 할 수도 있습니다. 이 새로운 기능에 대한 자세한 내용은 Load Balancer Address Type 설명서를 참조하십시오.

AWS IPv6 지원 현황 요약
VPC에서 EC2 인스턴스에 대한 IPv6 지원 시작에 앞서 이미 다양한 IPv6 지원을 제공하고 있으며, 상세 내용은 다음과 같습니다.

  • Amazon CloudFront, WAF 및 S3 Transfer Acceleration -개별 CloudFront 배포 지점에 IPv6 지원을 사용할 수 있습니다. 새로 생성 된 배포 지점은 기본적으로 IPv6을 지원하며, 기존 배포판은 업그레이드 할 수 있습니다 (Route 53 별칭 레코드를 사용하는 경우 도메인에 AAAA 레코드도 추가해야 합니다). IPv6 지원을 사용하면 새 주소가 CloudFront Access Logs에 표시됩니다.  AWS WAF를 사용하여 IPv4 또는 IPv6 주소를 통해 오는 요청을 검사하고, S3 Transfer Acceleration을 위한 새로운 이중 스택 엔드 포인트를 사용할 수도 있습니다.
  • Amazon Route 53 -IPv6을 통한 DNS 쿼리에 대한 지원을 추가했습니다. (필수 AAAA 레코드에 대한 지원이 이미 마련 있습니다). IPv6 엔드 포인트 상태 검사를 지원하므로 엔드 포인트의 상태를 모니터링하고 DNS 장애 조치를 조정할 수 있습니다.
  • AWS IoT -인터넷 연결 장치와 AWS IoT 간의 메시지 교환을 위한 IPv6 지원을 제공합니다.
  • Amazon S3 –  듀얼 스택 엔드 포인트를 통한 S3 버킷 접근 지원이 가능합니다.
  • Elastic Load Balancing – Elastic Load Balancer를 위해 공개라우팅 가능한 IPv6 주소를 지원합니다.
  • AWS Direct Connect – 공개 및 비공개 VIF (가상 인터페이스)에서 단일 및 이중 스택 구성을 지원합니다.

Jeff;

이 글은 AWS IPv6 Update – Global Support Spanning 15 Regions & Multiple AWS Services의 한국어 번역입니다.

AWS Web Application Firewall을 통한 Application Load Balancer 보호하기

오늘은 작년에 출시한 주요 서비스 중 AWS Web Application Firewall(WAF) 및 AWS Application Load Balancer라는 두 가지 서비스에 대한 업데이트입니다.

AWS Web Application Firewall – 애플리케이션 가용성에 영향을 미치거나 과도한 자원을 소비 할 수 있는 외부 공격을 보호하는 서비스로서, 이전 출시 소식 에서 볼 수 있듯이 HTTP  요청 허용 여부 및 IP 주소를 정의하는 접근 제어 목록 (ACL), 규칙 및 조건을 사용할 수 있습니다. 선택적으로 웹 응용 프로그램의 특정 경로에 대한 접근를 허용하거나 거부 할 수 있으며, 다양한 SQL 주입 공격을 차단할 수 있습니다. 본 서비스는 Amazon CloudFront를 지원합니다.

AWS Application Load Balancer – Elastic Load Balancing에서 상위 애플리케이션 계층을 지원하는 신규 서비스로서 콘테이너 또는 EC2 인스턴스 웹 서비스 경로를 기반으로 하는 라우팅 규칙을 정의 할 수 있습니다. Application Load Balancer는 HTTP/2 및 WebSocket을 지원하며 대상 콘테이너 및 인스턴스 상태를 자세히 볼 수 있습니다. 자세한 내용은 이전 출시 소식를 참조하십시오.

WAF 및 ALB 상호 연동 하기
작년 연말 AWS WAF를 통해 Application Load Balancer 기반 응용 프로그램 보호 기능을 제공할 것이라고 발표하였으며, 오늘부터 이를 매우 빠르게 설정할 수 있으며 내부 및 외부 응용 프로그램과 웹 서비스를 모두 보호 할 수 있습니다.

예를 들어, 아래 ALB 뒤에 세 개의 EC2 인스턴스가 있습니다.

같은 리전에 접근 목록(ACL)을 간단하게 만들고 ALB와 연결합니다. 먼저 ACL의 이름을 지정하고, WAF에 지정된 CloudWatch 측정 항목에 제공하도록 설정합니다.

그런 다음 ACL에 원하는 조건을 추가합니다.

예를 들어, 질의 문자열에 대해 몇 가지 SQL 주입 필터(Injection Match)를 쉽게 설정할 수 있습니다.

필터를 만든 후에 이를 규칙 만드는 데 사용합니다.

그런 다음 규칙을 사용하여, 조건과 일치하는 요청을 차단합니다.

이를 모두 함께 사용하려면, 아래처럼 설정을 검토한 다음 ACL을 만드십시오.

Confirm and create을 클릭하면 새 규칙이 활성화되고, WAF가 내 ALB 뒤에 있는 응용 프로그램을 보호합니다.

이렇게 하면 WAF를 통해 Application Load Balancer 뒤의 EC2 인스턴스와 콘테이너를 보호할 수 있습니다.

자세히 알아보기
WAF 및 ALB를 함께 사용하는 데 대한 부분을 더 자세히 알고 싶으시면, re:Invent 중 Secure Your Web Application With AWS WAF and Amazon CloudFront 세션을 참고하시기 바랍니다.

Jeff;

이 글은 AWS Web Application Firewall (WAF) for Application Load Balancers의 한국어 번역입니다.

AWS 기반 웹 및 애플리케이션 서버 부하 테스트: A to Z

사용자가 이용하고 있는 온라인 서비스로부터 예상치 못한 느려짐을 겪거나, 접속 불가로 인해 서비스 이용 조차 할 수 없다면, 서비스에 중요한 재방문율(Retention Rate)과 유료 전환율(Conversation Rate)을 하락 시켜 비지니스에 큰 손실을 야기 할 수 있습니다. 이런 성능 관련 문제를 예방하기 위해 성능 테스트, 특히 부하 테스트에 대한 중요성이 크게 증가하고 있으며, 더불어 관련  도구 및 서비스의 다양성 또한 증가하고 있습니다.

이번 글은 AWS 클라우드에서 어떻게 웹/애플리케이션 서버의 부하 테스트를 하는지 모범 사례를 알려드리기 위한 것으로, 부하테스트 목적과 고려 사항 그리고 단계 및 도구 등을 대해 다루고자 합니다.

부하 테스트의 목적
일반적으로 부하 테스트는 서비스 개발 이후, 운영을 하기 직전 수행하는 테스트 중 하나로서, 실제 요구되는 부하를 서비스가 수용할 수 있는지를 확인하기 위한 작업 입니다. 사용자 활동을 시뮬레이션 하고 인프라 및 서버의 동작을 모니터링 함으로써, 전부는 아닐지라도, 많은 부분의 병목 현상(Bottleneck)을 제거할 수 있습니다.

부하 테스트의 목적으로는 보통 다음 세가지가 있습니다.

  • 현재 서비스 구성의 제한(limit)을 찾기 위함
  • 원하는 부하를 수용할 수 있게끔 구성되었는지 확인하기 위함
  • 병목 지점을 찾고 병목 현상을 제거하기 위함

부하 테스트 전 고려되어야 할 점
실제 성능 테스트 시, 부하 테스트를 비중 있게 여기지 않는 경우가 많으며, ApacheBenchJMeter 와 같은 도구를 다운로드 한 뒤, 특정 시나리오를 기반으로 하여 도구를 실행하는 것만으로 충분하다고 생각하는 경우가 있습니다. 하지만, 실제 워크로드는 다양한 변수와 시나리오를 가지고 있기 때문에, 부하 테스트를 진행할 때 충분히 이점을 반영 하여 야지만 실제 서비스에서 예상 가능한 결과를 가져올 수 있다는 것은 분명한 사실 입니다.

그럼 실용적인 부하 테스트를 위해 어떤 부분들을 고려해야 할까요?

  • 충분한 테스트용 서버 자원 확보: 최대의 트래픽을 생성하여 테스트 하기 위해서는 충분한 서버 자원이 요구되며, 부족할 경우 적절한 테스트가 이루어지기 힘듭니다.
  • 테스트 시, 블랙박스 혹은 격리된 환경 제어: 부하 테스트는 많은 요청과 패킷을 생성하기 때문에 사내 인프라의 많은 부분을 포화 상태로 만들기 쉽습니다. 이를 방지하기 위해 제한된 자원만 할당된 블랙 박스 혹은 격리된 환경에서 테스트를 수행하는 경우가 많습니다.
  • 글로벌 기반의 부하 생성: 글로벌 서비스의 경우, 전 세계 각 지역에서 부하를 생성하여 테스트를 진행하여야만 실제 사용 패턴에 가까운 시나리오가 될 수 있습니다. 이를 통해 글로벌 커버리지를 확인할 수 있으며, 실제 워크로드에서 얻을 수 있는 유사한 각종 성능 관련 지표도 얻을 수 있습니다.
  • 높은 비용과 불규칙적인 사용성에 대한 주의: 격리된 환경과 더불어 여러 리전을 커버하기 위한 테스트 환경은 때로 높은 비용을 요구합니다. 구성된 환경은 짧은 기간 동안만 집중적으로 사용되기도 하며, 안정적인 서비스가 유지될 땐 드물게 사용되기도 하기 때문에, 사용하지 않을 때도 유지하여야 하는 등의 자원을 효율적으로 사용하지 못해 불필요한 비용이 발생 하기도 합니다.
  • 높은 아키텍처 복잡성에 대한 주의: 상기 언급된 부분들을 고려하여 부하 테스트 환경을 구성한다면 꽤나 높은 복잡성이 요구 됩니다. 나아가 반복적인 테스트를 위해, 가상의 가짜(Dummy) 데이터 등에 의해 지저분해진 환경을 초기화 시켜줄 수 있는 방안도 필요 합니다.

AWS 클라우드 기반 부하 테스트의 장점
AWS 클라우드는 부하 테스트를 진행하기 위해 고려할 사항에 대한 적절한 해답을 가지고 있습니다.  AWS 클라우드에서 부하 테스트 하게 된다면 어떤 특징을 가지고 있을까요?

  • 사용한 만큼 지불하는 비용 효율성: Amazon EC2 인스턴스는 사용한 만큼만 비용이 발생하기 때문에, 테스트 조건에 맞는 인스턴스 타입을 선택하여 비용 효율성을 높일 수 있습니다. 예를 들어, 정식 부하 테스트를 진행하기 전에 저렴한 마이크로 인스턴스 수십~수백대를 활용하여, 서버 워밍업을 저렴한 비용으로 할 수 있습니다. 또한, 인스턴스 사용이 끝나면 즉시 종료할 수 있어 불필요한 비용 발생을 줄일 수 있습니다.
  • 충분하고 유연한 컴퓨팅 자원 제공: AWS가 제공하는 컴퓨팅 자원을 활용한다면, 필요한 규모의 부하에 대해 자유롭게 테스트를 수행할 수 있습니다. 또한, 오토스케일링(Auto Scaling)을 통해 부하 테스트 시 자원을 자동으로 증설 혹은 감소 시킬 수 있습니다.
  • 글로벌 리전(Region)으로부터의 부하 생성: AWS가 제공하는 글로벌 인프라를 통해 전 세계 각 리전으로부터의 부하 생성을 손쉽게 할 수 있습니다.
  • 쉽고 단순한 아키텍처 구성 및 관리: AWS CloudFormation 을 비롯한 다양한 배포 자동화 서비스 및 기능을 통해 프로덕션과 테스트 용 환경을 동일한 방법으로 손 쉽게 구성할 수 있습니다. 뿐만 아니라 관리형 서비스를 활용하여 운영 측면에서의 부담도 줄일 수 있어, 테스트 환경 구축에 관한 복잡성을 줄일 수 있습니다.

부하 테스트의 단계
부하 테스트는 서비스 전체 스택을 대상으로 진행할 수도 있지만, 최근에는 마이크로서비스(Microservices) 나 서비스 지향 구조(Service-Oriented Architecture) 등의 형태로 서비스를 디자인하는 경우가 많아, 전체 스택을 구성하고 있는 작은 컴포넌트들부터 진행되는 경우가 많아지고 있습니다.

또, 빠른 병목 현상 발견과 수정을 위해, 애플리케이션 로직이 적용되기 전 순수한 인프라 수준에서 시작하여 작은 컴포넌트들, 솔루션, 그리고 애플리케이션 순으로 부하 테스트를 확대해 나갈 수도 있습니다.

아래는 일반적으로 수행할 수 있는 부하 테스트 단계 입니다.

  • 비결합(Loosely Coupled)된 개별 컴포넌트에 대한 부하 테스트: 이를 통해 각 컴포넌트 별 병목 현상을 보다 빠르게 발견하고 수정할 수 있습니다.
  • 내부 서비스에 대한 부하 테스트: 로그 기록 서비스와 같이 높은 처리량이 요구되는 서비스나, 결제 서비스와 같이 전체 서비스 품질에 있어 중요한 내부 서비스를 대상으로 테스트를 진행 합니다.
  • 외부 서비스에 대한 부하 테스트: Facebook, Twitter 등의 소셜 서비스나 Google 등의 플랫폼에 대한 서비스들, 또는 푸시 알림 서비스 등의 외부 서비스를 대상으로 테스트를 진행 합니다.
  • 전체 스택에 대해 부하 테스트: 개별 컴포넌트들에 대한 테스트를 완료한 뒤, 컴포넌트간의 상호작용을 알기 위해 처음부터 끝까지 전체 스택에 대해서 테스트 진행 합니다.

단계별 부하 테스트 수행 방법
앞서 언급한 것처럼, 부하 테스트는 전체 스택에 대해서도 수행 가능하지만, 작은 비결합된 컴포넌트나 기능 단위로도 수행 가능합니다. 그리고 작은 단위로 수행될 수록 더 분명하게 병목 지점을 파악하기에 수월 합니다. 그렇기에, 가능한 작은 단위부터 단계별로 진행하는게 원하는 결과를 얻어내는데 효율적입니다.

다음은 전형적인 3단계(3-tier) 웹 서비스에 대해 단계별로 부하 테스트를 진행하는 것을 설명하고 있습니다.

load-test-image001

  1. 최초 ‘WEB’ 을 출력하는 웹 페이지를 대상으로 동시 연결성에 대한 테스트 수행 → 결과 평가→최적화 진행 (Client →Web Server)
  2. 웹 서버를 통해 애플리케이션 서버에서 넘겨 받은 ‘APPLICATION’ 을 출력하는 웹 페이지를 대상으로 동시 연결성에 대한 테스트 수행→ 결과 평가 → 최적화 진행 (Client →Web Server → App Server – w/o Logic)
  3. 데이터베이스에서 최소한의 쿼리 결과를 전달 받아 출력하는 웹 페이지를 대상으로 동시 연결성에 대한 테스트 수행 →결과 평가 → 최적화 진행
    (Client →Web Server → App Server – w/o Logic → Database)
  4. 3-tier 스택 전체를 대상으로 애플리케이션 로직이 적용된 페이지에 동시 연결성에 대한 테스트 수행 → 결과 평가 → 최적화 진행
    (Client → Web Server → App Server – with Logic →Database)
  5. 4번을 기반으로 다양한 시나리오를 지정하여 테스트 수행 → (얻고자 하는 지표 기준에 대해서) 결과 평과 → 최적화 진행

부하 테스트 시, 각 레이어별 고려하여야 할 사항
부하 테스트를 수행한 뒤 각 레이어별로 발생할 수 있는 상황과 고려하여야 할 부분에 대해서 알아보도록 하겠습니다.

  1. 네트워크 용량 확인: 테스트 환경이 구성된 인프라와 관련하여 여러가지 지표를 확인할 수 있지만, 대표적으로 아웃바운드 연결이 예상되는 최대의 부하를 처리할 수 있는지 확인할 필요가 있습니다. Amazon EC2 의 경우 인스턴스 타입 마다 서로 다른 네트워킹 성능을 제공하고 있기에, 부하에 따른 적절한 인스턴스 타입 선택이 중요 합니다. 또 사내 인프라와 프라이핏하게 연결되어 있다면, VPN 관련 네트워킹 성능에 대해서도 확인을 하여야 합니다.
  2. 부하 생성 클라이언트: 앞서 설명하였듯이 부하 테스트의 요구사항 중 하나로, 필요한 만큼의 부하를 생성할 수 있는 충분한 인스턴스의 확보가 요구됩니다. 하지만, 설정 및 구현 방식에 의해 하나의 부하 생성 클라이언트가 처리할 수 있는 동시성에 큰 제한이 있다면, 필요 이상으로 복수개의 인스턴스가 요구되어 비용이 증가할 수 있습니다. 이럴 땐 Thread 기반의 툴 보다는 높은 동시성을 제공하는 Async IO 기반의 툴을 사용하여 테스트를 진행하는게 좋습니다.
  3. 로드 밸런싱: ELB(Elastic Load Balancing)는 서비스 전체 부하를 백엔드에 등록된 복수개의 인스턴스로 분산하는 기능을 제공합니다. 부하 테스트를 수행할 때 다양한 이유로 기대치 보다 낮은 결과나 5xx 에러가 발생하는 것을 볼 수 있습니다. 이 때, ELB 가 제공하는 다양한 모니터링 지표들을 확인하면, 어느 곳에서 병목 현상이나 에러가 발생되는지 확인하는데 도움이 됩니다. 가장 자주 발생하는 문제는, 503 Server Unavailable 이나 504 Gateway Timeout 에러 발생과 동시에, ELB 의 모니터링 지표에 SurgeQueueLength 가 1024 로 기록되고 SpilloverCount 가 0 보다 높을 경우 입니다. SurgeQueueLength 는 ELB 에 등록된 백엔드 인스턴스가 요청을 처리하지 못하여 쌓이게 되는 ELB 의 큐 이며, 앞서 언급한 것처럼 1024가 큐의 최대 크기 입니다. 이 최대 크기를 넘어서면 요청을 한 클라이언트에 5xx 에러를 보내게 되고, 동시에 SpilloverCount 가 기록 됩니다. 이 문제를 해결하기 위해서는 적시에 Auto Scaling 이 일어날 수 있도록 적절한 지표를 기준으로 알람을 발생 시킬 수 있도록 해야 합니다. 백엔드 인스턴스에서 동작하는 시스템이 어떤 자원을 더 많이 사용하는지 확인을 하고, 그 자원의 지표를 기준으로 Auto Scaling 을 설정하는 것이 좋습니다. SurgeQueueLength 를 기준으로 알람이 발생하게 하는 것도 한 가지 방법 입니다. ELB 가 제공하는 지표들은 여기에서 확인할 수 있습니다.
    추가로 ELB 도 발생하는 부하에 따라 Auto Scaling 을 통해 규모가 변화되도록 설계 되어 있습니다. 만약, 매우 급격한 트래픽 증가가 일어날 때 ELB 가 확장되는 속도가 증가하는 트래픽을 수용하지 못한다면 5xx 에러가 발생할 수 있습니다. 이를 방지 하기 위해, 미리 점차적으로 증가하는 부하 테스트를 통해 어느정도 ELB 를 확장 시켜 둘 수 있습니다. 또한, ELB 에 등록된 백엔드 인스턴스에서 Keep-Alive 기능을 활성화 시켜, ELB 와 백엔드 인스턴스간에 불필요한 연결 수립이 일어나는 것을 방지한다면 더 높은 성능을 기대할 수 있습니다.
  4. 서버 인스턴스: 서버 인스턴스의 설정 값에 따라 웹/애플리케이션 서버의 자원 사용 효율성이 달라 집니다. 대표적으로 Linux 서버의 open files 숫자를 늘려 두지 않으면, 동시 접속이 기본값인 1024 개로 제한되어 서버 인스턴스를 효과적으로 사용할 수 없습니다.
  5. 애플리케이션 서버: 애플리케이션 서버의 종류마다 다르지만, 일반적으로 Tomcat 등의 Thread 기반의 애플리케이션 서버일 경우, Thread Pool 의 크기가 너무 작다면 처리 되어야할 요청들이 기다리는(waiting) 상태가 길어져 전체 부하 테스트의 효율성을 떨어뜨릴 수 있습니다. 최근에는 Thread 기반의 애플리케이션 서버가 가지고 있는 제약으로 인해, Event 기반의 비동기 형태의 애플리케이션 서버가 자주 사용되어 집니다.
  6. 애플리케이션: 애플리케이션 코드와 프레임워크 둘로 나누어 생각해 볼 수 있습니다. 애플리케이션 코드 내에서 잘못된 방식으로 프레임워크나 API 를 사용할 수 있으며, blocking 코드가 포함되어 있다거나, 불필요한 연산을 진행, 또 테스트 코드를 삭제하지 않았다는 등의 문제가 있을 수 있습니다. 이 때에는 적절한 Unit Test 와 Lint 등을 통해 문제를 조기에 발견할 수 있어야 합니다.  사용하는 웹 프레임워크나 ORM(Object-relational mapping)과 같은 라이브러리가 가지고 있는 버그로 인하여 문제가 발생할 수도 있습니다. 애플리케이션 관련 다양한 문제를 해결하기 위해 APM(Application Performance Monitoring) 을 활용하여 성능을 모니터링 하는 것도 한가지 방법 입니다.
  7. 데이터베이스: CPU 사용률과 응답 시간(response time) 등을 확인할 필요가 있습니다. 특히 데이터베이스를 설정한 방법에 따라 더 요구되는 자원을 눈 여겨 볼 필요가 있습니다. 최근에는 성능을 향상 시키기 위해 메모리를 적극 활용하게끔 설정을 하는 경우가 많으며, 이때에는 메모리 사용률이 특정 수치 이상으로 넘어갈 경우, 알람을 발생 하도록 설정하여 병목 지점 확인이 가능 하겠습니다.

부하 테스트 관련 도구 및 서비스
부하 테스트를 위해 사용할 수 있는 다양한 툴과 서비스들이 존재 합니다. 간단한 소개와 함께 특징들을 살펴보겠습니다.

  • ApacheBench (http://httpd.apache.org/docs/2.2/en/programs/ab.html): 일반적으로 HTTP 웹 서버의 성능을 측정하기 위해서 자주 사용되는 툴입니다. 기본적인 HTTP 연결에 대해서 테스트를 할 때 자주 사용되는 툴이지만, HTTP/1.1 을 지원하지 않고, 한번에 하나의 대상 URL로 테스트가 가능한 것 등의 제한이 있습니다.
  • Siege (https://www.joedog.org/siege-home/): HTTP 부하 테스트와 벤치마킹 유틸리티 입니다. 한번에 복수개의 URL 로 테스트가 가능하고, Basic 인증을 지원하며 HTTP와 HTTPS 프로토콜로 테스트가 가능하는 등 ApacheBench 의 제한을 어느정도 해소 해 줍니다. 또 ApacheBench 와 비슷한 인터페이스를 가지고 있어 다른 툴과의 연계가 자유로운 편입니다. 하지만 Thread 기반으로 구현되어 있어 동시성에 제한이 있으며, 미미할 수 있지만 Context Switching 등으로 인하여 성능에도 영향이 있습니다.
  • JMeter (http://jmeter.apache.org/): 1998 년 부터 시작된 프로젝트로서 오랫동안 기능 강화를 지속해오고 있는 Java 기반의 부하 테스트 툴 입니다. HTTP 뿐만 아니라 다양한 프로토콜을 지원하며, 많은 기능을 가진 GUI 를 제공 합니다. 실제 워크로드를 시뮬레이션 하기 위해 다양한 방법으로 커스터마이징이 가능합니다. 하지만 앞서 언급한것처럼 Thread 기반으로 구현되어 있어 성능과 동시성에 대해서 제한이 있습니다. 이를 해결하기 위해, 복수개의 인스턴스에서 실행시켜 테스트를 수행할 수 있는 Remote Testing 기능을 지원 합니다. 복수개의 EC2를 활용하거나, BlazeMeterFlood.io 와 같은 JMeter 를 지원하는 부하 테스트 서비스를 사용할 수도 있습니다.
  • The Grinder (http://grinder.sourceforge.net/): Java 기반의 부하 테스트 프레임워크 입니다. Agent 가 지정한 값을 기반으로 부하를 생성하며, IDE 형태의 콘솔에서 Agent 들을 제어 및 결과 모니터링이 가능합니다. 마찬가지로 Thread 기반으로 구현되어 있어 성능과 동시성에 대해 제한이 있습니다.
  • Gatling (http://gatling.io/): Akka 와 Netty 기반의 Scala 로 개발된 부하 테스트 프레임워크 입니다. Thread 기반이 아닌 Event 와 Async IO 기반으로 구현되어, 높은 성능을 제공하며 HTML 보고서 생성 기능은 물론 시나리오를 DSL 로 작성하여 부하 테스트에 사용할 수 있는 기능을 제공하고 있습니다.
  • Tsung (http://tsung.erlang-projects.org/): Erlang 으로 개발된 부하 테스트 툴로서, HTTP는 물론 Websocket 이나 인증 시스템, 데이터베이스, MQTT 와 같은 TCP 기반의 다양한 프로토콜을 지원합니다. 동시성 지향 프로그래밍 언어 (concurrency-oriented programming language) 인 Erlang 이 가지고 있는 장점으로 인해, 성능과 확장성, 내결함성(Fault Tolerance)에서 큰 이점을 제공하고 있습니다. GUI 를 제공하지 않아 CLI 또는 Script 를 활용하여야 합니다.
  • Bees (https://github.com/newsapps/beeswithmachineguns): AWS 의 장점을 적극 활용한 오픈 소스 부하 테스트 툴로서, 부하를 분산 생성하기 위해 사용자의 AWS 계정에서 EC2 인스턴스를 지정한 개수만큼 생성하여 부하 테스트 대상에 테스트를 진행합니다. 비용을 줄이기 위해 스팟 인스턴스를 생성하여 활용할 수 있는 옵션도 제공하고 있습니다. 부하 테스트를 위해 ApacheBench 를 사용하기 때문에 ApacheBench 가 가지고 있는 제한을 그대로 가지고 있습니다.
  • Vegeta (https://github.com/tsenart/vegeta): Go 언어로 개발된 오픈소스 HTTP 부하 테스트 툴이며 CLI 로 사용하거나 라이브러리로 사용 가능합니다. 보통의 다른 툴과 다르게 초당 일정한 속도로 특정 수치의 요청을 지속하는데 초점을 맞추고 있어, 예상되는 최대 트래픽이 지속적으로 발생하였을 때 서비스와 인프라의 상태가 어떻게 변화하는지 확인하는데 적합한 툴 입니다.
  • RedLine13 (https://www.redline13.com/): AWS 의 Advanced Technology Partner 중 하나로서, AWS 기반의 부하 테스트를 수행하는 서비스 입니다. 사용자의 AWS 계정에서 IAM 을 생성하여 RedLine13 과 연동을 하면, 사용자의 AWS 계정에서 Agent 가 포함된 인스턴스가 실행되어 테스트가 진행 됩니다. 스팟 인스턴스를 활용할 수 있어 비용을 줄일 수 있습니다. 여기에서 RedLine13 과 Apache JMeter 를 활용하여 모바일 애플리케이션을 테스트 하는 데모를 보실 수 있습니다.
  • Loader.io (https://loader.io/): 클라우드 기반의 부하 테스트 서비스로서, 웹 페이지에서 대상 서버를 선택하고 원하는 동시성 등을 지정할 수 있으며, 그 결과를 보기 좋게 표시해 줍니다. 또한, 진행한 테스트를 추후에 리플레이 할 수도 있습니다.
  • Goad (https://goad.io/): AWS Lambda 를 활용하여 부하를 분산 생성하여 테스트를 수행하는 오픈 소스 툴로서 Go 언어로 개발 되었습니다. 실제 AWS 의 이점과 AWS Lambda 의 강력함을 잘 활용한 툴 입니다. 툴을 실행하면 AWS Lambda 함수를 생성 (혹은 갱신) 하여, 대상 URL 에 동시적으로 부하 테스트를 시작합니다. 그리고 각 결과는 AWS SQS 로 보내어지고, 최종적으로 최초 실행한 툴에서 결과를 취합하여 보여줍니다.
    load-test-image003

그밖에도 다양한 AWS Marketplace에서도 다양한 파트너들의 부하 테스트 솔루션을제공하고있습니다.

부하테스트 시 유용한 팁 모음
AWS 클라우드 기반으로 부하 테스트를 진행하는데 있어서 알아두면 도움이 되는 팁들을 간단하게 소개해 드리고자 합니다.

  • 로그 기록과 확인: 부하 테스트를 진행할 때, 로그 작성은 File IO 를 요구하는 작업이기에, 미미하게 테스트 수행 능력에 영향을 미칠 수 있습니다. 특히나 테스트 환경에서는 로그 수준을 낮추어(verbose 또는 debug) 더 많은 로그가 기록되도록 하는 경우가 많아, 실제 프로덕션에 비해 성능에 미치는 영향이 더 클 수 있습니다. 하지만 가능한 로그를 기록하는게 추후 발생하는 문제 파악에 도움을 줄 수 있기 때문에 기록을 하는게 권장 됩니다. 또는, 최초의 워밍업을 진행할 때 로그를 활성화하여 진행을 하고, 이후의 테스트에 대해서는 로그를 비활성화하여 진행할 수도 있겠습니다. 만약 그 결과가 기대에 미치지 않는다면, 다시 로그를 활성화 한 뒤 테스트를 진행하고, 생성되는 로그를 통해 문제를 파악할 수 있겠습니다.
  • 적절한 인스턴스의 선택: EC2 인스턴스는 요구되는 워크로드에 맞추어 선택할 수 있도록 다양한 종류가 준비되어 있습니다. 사용하는 웹/애플리케이션/데이터베이스에 따라 상대적으로 더 요구되는 자원은 다를 수 있으며, 그에 맞추어 인스턴스를 선택하는 것이 비용도 절약하며 더 적합한 성능을 발휘할 수 있겠습니다. 예를 들어, 특별한 연산이 수행되지 않고 다른 서비스와 통신이 주 목적이라면, 적은 CPU 자원과 적절한 Memory 자원, 그리고 높은 Bandwidth 와 Enhanced Networking 을 제공하는 인스턴스가 비용과 성능 관점에서 좋은 선택일 수 있습니다.
  • 비용 최소화: 유의미한 결과를 얻기 위해 부하 테스트 대상 환경을 가능한 실제 환경과 비슷하게 구성할 필요가 있습니다. 물론, 실제 프로덕션 환경에서 테스트를 수행할 수도 있지만, 이는 가상의 가짜(Dummy) 데이터를 생성하여 프로덕션 환경을 어지럽히고 라이브 서비스의 안정성을 헤치는 등의 위험성이 있기에 적극적으로 피해야 합니다. 실제 프로덕션 환경과 비슷한 환경을 구성하여 부하 테스트를 수행하는데 있어서 가장 먼저 고려하여야 할 사항은 비용 입니다. 일반적으로 최대 부하에 대한 테스트 진행을 위해, 수십에서 수백 대의 인스턴스가 필요할 수 있으며, 큰 규모의 부하를 생성하기 위해서도 많은 인스턴스가 요구되기 때문입니다. 이 때, 비용을 최소화 하기 위해 스팟 인스턴스를 활용할 수 있습니다. 스팟 인스턴스는 EC2 컴퓨팅 예비 용량에 입찰을 통해 온디맨드 요금과 비교하여 할인된 요금으로 사용할 수 있는 방법을 제공하며, 일반적으로 50~90% 저렴한 비용으로 사용할 수 있습니다. 자세한 내용은 여기를 참조 하시기 바랍니다.
  • 다양한 도구와 서비스의 복합적 활용: 앞서 부하 테스트를 위한 다양한 툴과 서비스에 대해서 알아 보았습니다. 부하 테스트를 진행할 때, 어떤 특정 툴 또는 서비스 하나만 선택해서 사용 할 필요는 없습니다. 각 툴과 서비스 별로, 목적성과 고유의 특징을 가지고 있기에, 용도에 맞게 복합하여 사용하는게 더 효율적일 수 있습니다. 예를 들어, GUI 의 완성도가 높고 다양한 시나리오를 설정할 수 있는 JMeter 는 웹 애플리케이션 내에서 사용자의 행동 흐름에 대해 부하 테스트를 하는데 적합할 수 있습니다. 그 이외의 툴과 서비스들도 특징들이 있으며 다음과 같이 활용할 수 있겠습니다.
    도구 명 활용 방법
    JMeter 웹 애플리케이션 내에서 사용자의 행동 흐름에 대해 부하 테스트를 하고 싶을 때
    Tsung API 가 수용할 수 있는 최대치의 부하를 알고 싶을 때
    Vegeta 어떤 API 에 대해 초당 특정 수치의 요청이 지속될 경우 발생하는 상황을 파악하고 싶을 때
    Goad 부하 생성 클라이언트 구성을 포함한 부하 테스트 관련 인프라 구성을 피하고 싶을 때
    RedLine13 JMeter 로 테스트 플랜을 작성하여 활용을 원하지만, 비용을 최소화 하고 싶고 사용한 만큼만 비용이 발생하길 원할 때
    Blazemeter 높은 동시성을 위해 JMeter 의 Remote Testing 기능을 활용하고 싶지만, 테스트 플랜 작성에 집중하고, 부하 테스트 관련 인프라 구성은 하고 싶지 않을 때
    Loader.io 부하 테스트 관련 인프라 구성을 하고 싶지 않고, Tsung 과 비슷한 목적으로 사용하고 싶을 때

부하 테스트에는 보통의 시나리오 기반의 가상의 워크로드에 대한 부하 테스트 뿐만 아니라, 실제 워크로드에 대한 부하 테스트를 위해 프로덕션에서 발생하는 트래픽을 활용하는 방법도 있습니다. 프로덕션 환경의 실제 트래픽을 활용하기 위해서는, 트래픽을 재사용 하기 위해 기록하거나 곧바로 테스트 환경으로 리플레이 해 주는 gor (https://goreplay.org/) 와 같은 툴을 사용할 수 있습니다. 프로덕션 환경의 실제 트래픽을 반복하여 활용할 수 있다는 이점 이외에도, 서비스 및 애플리케이션 업데이트 예정 버전에 실제 트래픽을 흘려 보내 사용성에 대한 테스트도 진행할 수 있는 장점도 있습니다.

추가로, 많은 경우 부하 테스트는 개발 주기 마지막에 진행되는 경우가 많습니다. 애자일 방법론과 지속적인 통합(CI/CD)을 활용하는 경우 조금 더 일찍, 자주 부하 테스트를 진행할 수 있으며, 이를 통해 추후 발생할 수 있는, 비용이 많이 드는 성능 문제를 미리 방지할 수 있습니다. 따라서, 가능한 개발 주기에 부하 테스트를 포함하여 자주 진행하는 것이 바람직하다고 볼 수 있습니다.

AWS 에서 제공하는 방대한 인프라와 이미 부하에 대해 고려되어 설계된 관리형 서비스, 그리고 다양한 규모 관련 기능들을 적극 활용하여 서비스를 구축한다면 가변적인 부하에도 유연한 서비스를 제공할 수 있을 것 입니다.

본 글은 아마존웹서비스 코리아의 솔루션즈 아키텍트가 국내 고객을 위해 전해 드리는 AWS 활용 기술 팁을 보내드리는 코너로서, 이번 글은 김필중 솔루션즈 아키텍트께서 작성해주셨습니다.
load-test-image005

AWS Application Load Balancer 서비스 공개

지난 2009년 Elastic Load Balancing (ELB) 서비스를 시작하였습니다.(New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatch 참고). ELB는 AWS 기반 애플리케이션의 가장 중요한 아키텍처의 구성으로서 자동 스케일링과 함께 고가용성을 유지하면서 손쉽게 확장 및 감소를 할 수 있도록 도와 주고 있습니다.

상위 레이어 로드 밸런싱 기능 지원
잘 알려진 OSI 모델에 따르면, 로드밸런싱은 일반적으로 Layer 4 (네트워크) 또는 Layer 7 (애플리케이션)에서 처리합니다.

Layer 4 로드밸런싱은 네트워크 프로토콜 레벨에서 제공 되며, 실제 패킷을 살펴 보지는 못하기 때문에 HTTP나 HTTPS 같은 특정 프로토콜을 인지하지 않고 부하를 분산합니다.

대신 Layer 7 로드밸런싱은 좀 더 정교하고 강력한 기능을 제공합니다. 패킷을 조사하고, HTTP 및 HTTPS 헤더에 접근해서 좀 더 지능적인 부하 분산 작업이 가능합니다.

AWS Application Load Balancing 서비스 제공
오늘 ELB의 새로운 옵션인 애플리케이션 로드밸런서(Application Load Balancer)를 공개합니다. 이 서비스는 Layer 7 로드밸런싱을 통해 많은 고급 기능을 제공합니다. 기존의 로드 밸런싱 기능은 앞으로 Classic Load Balancer라고 부르게 되며, 여전히 Layer 4 및 Layer 7 기능을 제공합니다.

애플리케이션 로드밸런싱은 콘텐트 기반 라우팅 및 콘테이너 상 애플리케이션을 지원합니다. 표준 프로토콜인 WebSocket 및 HTTP/2를 지원하며, 인스턴스 및 콘테이너의 추가 가시성을 제공하게 됩니다. 콘테이너 및 EC2 인스턴스에서 실행하는 웹 사이트 및 모바일 앱에 대해 부하 분산에 대한 효과가 매우 높을 것입니다.

이제 좀 더 자세하게 애플리케이션 로드밸런싱 기능을 살펴 보겠습니다.

콘텐츠 기반 라우팅
애플리케이션 로드밸런서는 HTTP 헤더에 접근해서 다른 백엔드 서비스에 따라 다른 요청을 처리할 수 있습니다. 예를 들어, URL에 /api라는 경로를 포함하고 있는 경우, 다른 서버 그룹(일명 target group)으로 요청을 보낼 수 있으며 /mobile은 또 다른 서버 그룹으로 보낼 수 있습니다. 이를 통해 여러 개의 마이크로서비스를 독립적으로 실행하고 확장할 수 있도록 할 수 있습니다.

각 애플리케이션 로드밸린서는 10개의 URL 규칙을 만들 수 있으며, 앞으로 더 많은 라우팅 방법을 제공할 계획입니다.

콘테이너 기반 애플리케이션 지원
많은 AWS 고객들이 자사의 마이크로서비스를 콘테이너 형식으로 만들어서 Amazon EC2 Container Service를 통해 배포하고 있습니다. Amazon ECS는 하나의 EC2 인스턴스에 한 개 이상의 서비스를 배포 및 운영할 수 있습니다. 그러나, 포트 맵핑 및 헬스 체크 등에 대해 전통적인 로드밸린서로는 어려운 문제가 있습니다.

애플리케이션 로드밸린서를 통해 콘테이너 기반의 애플리케이션 역시 같은 타겟 그룹 내에 다수의 포트를 사용할 수 있으며, 세부적인 포트 수준의 헬스 체크를 지원할 수 있게 되었습니다.

더 자세한 통계 수치 제공
애플리케이션 로드밸린서는 포트 기반의 헬스 체크에 대한 리포트를 실행할 수 있어, HTTP 응답에 대한 범위를 정의할 수 있고 자세한 오류 코드에 대한 부분도 확인할 수 있습니다.

콘텐츠 기반의 라우팅을 제공함으로서 각 마이크로서비스의 다양한 통계 수치도 얻어낼 수 있습니다. 이는 마이크로서비스 기반에서 운영하는 타겟 그룹 또는 특정 EC2 인스턴스 그룹에 대한 유효한 부수 효과입니다. 개별 서비스에 대한 부하에 대해 좀 더 자세히 살펴 볼 수 있음으로서 확장성에 대한 도움을 얻을 수 있습니다.

애플리케이션 로드밸린서는 CloudWatch에서 전체 트래픽 (overall traffic in GB), 액티브 연결 갯수, 시간당 연결 비율 등의 새로운 통계 수치를 제공합니다.

추가 프로토콜 지원
애플리케이션 로드밸린서는 WebSocketHTTP/2를 지원합니다.

WebSocket은 클라이언트와 서버간 긴 TCP 연결을 제공하는 프로토콜로서, 긴 연결이 필요할 경우 기존의 HTTP 연결을 통해 하던 고전적인 풀링 방식을 개선할 수 있습니다. 모바일 앱의 경우, 주식 가격이나 스포츠 경기 점수 등 다양한 동적 데이터를 서로 주고 받을 때 유용하며 ALB는 ws://wss:// 프로토콜을 지원합니다.

HTTP/2 역시 기존 HTTP 1.1에 비해 중요한 기능 향상을 가진 프로토콜로서 단일 연결에 멀티플렉스 요청을 처리할 수 있고, 바이너리 속성을 통한 네트웍 트래픽을 줄여줍니다.

애플리케이션 로드밸린서는 실시간 스트리밍 뿐만 아니라 WebSocket 로드를 최적으로 처리 가능합니다. 요청 및 응답에 대한 버퍼링 대신 스트리밍 방식으로 처리함으로서 지연 속도를 줄이고 애플리케이션의 성능을 눈에 띄게 높일 수 있습니다.

ALB 생성하기
이제 애플리케이션 로드밸린서를 만들어서 트래픽을 처리해 보겠습니다.

The Elastic Load Balancing Console에 두 가지 중 하나의 로드밸린서를 선택할 수 있습니다.

Application load balancer을 선택하고 이름(MyALB)을 넣고 internet-facing를 선택 후, HTTPS listener를 추가합니다.

같은 화면에서 VPC를 선택하고 (VPC만 지원함), 원하는 가용 영역과 서브넷을 선택합니다. 애플리케이션 로드밸린서를 태그하고 Configure Security Settings 설정으로 갑니다.

HTTPS listener를 선택했기 때문에 ALB는 인증서가 필요합니다. IAM에 있는 기존 인증서를 선택하거나, AWS Certificate Manager (ACM)에서 발급 받거나 또는 로컬 인증서를 업로드할 수 있습니다.

오른쪽에서 보안 그룹을 설정합니다. 새로운 보안 그룹을 만들었으나 기존 VPC나 EC2 보안 그룹을 사용하실 수도 있습니다.

다음 단계로 타겟 그룹(main)을 만들고, 헬스 체크를 기본으로 체크합니다.

이제 타겟그룹의 EC2 인스턴스 세트를 선택하여 애플리케이션 로드밸린서를 통해 분산할 80포트를 선택합니다.

마지막 단계로 모든 설정을 확인 한후 Create를 누르면 됩니다.

Create 누르고 나면, 애플리케이션 로드밸린서가 수 분 안에 만들어집니다.

추가 타겟 그룹을 만들 수도 있습니다.

각 타겟 그룹에 원하는 경로, 즉 /api 호출을 보낼 수 있습니다.

애플리케이션 로드밸린서는 Auto Scaling, Amazon ECS, AWS CloudFormation, AWS CodeDeployAWS Certificate Manager (ACM) 서비스와 연동해서 사용할 수 있습니다.

신규 로드밸런서로 이전하기
현재 기존 로드밸런서를 사용하고 있으시고, 애플리케이션 로드밸린서로 옮기고 싶으시다면, Load Balancer Copy Utility를 활욜하시기 바랍니다. 기존 설정을 그대로 애플리케이션 로드밸린서에 맞게 옮겨주는 Python 기반의 도그로서 기존 EC2 인스턴스를 신규 로드밸런서로 등록하는 기능도 있습니다.

가용성 및 가격
애플리케이션 로드밸린서는 모든 AWS 리전에서 오늘 부터 사용가능합니다. ALB의 시간당 사용 비용은 기존 로드밸런서 보다 10% 낮습니다.

ALB를 사용하시면 로드밸런서 용량 단위(LCU)를 기반으로 시간당 과금하게 되며, LCU는 초당 연결 갯수, 활성 연결수, 및 데이터 전송량 등을 측정하게 됩니다. 이 세 가지 측면의 데이터를 기반으로 비용이 결정됩니다. 하나의 LCU는 다음 중 하나를 선택합니다.

  • 25 초당 연결 수 (2 KB 인증서, 3,000 활성 연결 수, 2.22 Mbps 데이터 전송량) 혹은
  • 5 초당 연결 수 (4 KB 인증서, 3,000 활성 연결 수, 2.22 Mbps 데이터 전송량

시간당 1 LCU에 대해 0.008 달러가 과금되며, 저희의 계산에 따르면 모든 고객들이 기존 로드밸런서에서 ALB로 이전할 경우 기본적으로 총 비용이 감소할 것으로 생각합니다. 지금 부터 한번 활용해 보시기 바랍니다.

Jeff;

본 글은 New – AWS Application Load Balancer의 한국어 번역본으로 AWS Summit 뉴욕 행사의 신규 발표 소식입니다.