Elastic Load Balancer: 이점 극대화 및 비용 절감

이 글은 Networking & Content Delivery 블로그의 Elastic Load Balancer: Maximizing Benefits and Keeping Costs Low 의 한국어 번역입니다.

이 글에서는 워크로드의 ELB (Elastic Load Balancer) 비용 및 성능을 최적화하는 방법에 대한 지침을 제공합니다. 최적의 처리량 성능과 짧은 지연 시간을 달성하고, 효율적인 연결 관리를 구현하고, 수요가 많은 기간 동안의 성능 및 안정성을 보장하기 위한 권장 사항을 찾을 수 있습니다.

AWS에서 기술 솔루션을 구축하는 조직은 Well‑Architected Framework의 여섯 가지 핵심 요소인 운영 우수성, 보안, 안정성, 성능 효율성, 비용 최적화, 지속 가능성에 대해 잘 알고 있어야 합니다. 이러한 두 가지 핵심 요소, 즉 성능 효율성과 비용 최적화는 서비스 소유자 및 기술 전문가와의 대화에서 자주 사용되는 주제입니다. 고객과의 일대일 대화에서 고객은 우리에게 더 적은 자원으로 더 많은 성과를 낼 수 있는 도구와 전략을 요구합니다. AWS는 일반적인 지침으로 Cost Management 및 AWS Compute Optimizer를 제공하고 있지만, ELB 인프라 비용 최적화에 대해 고객에게 제공한 구체적인 조언을 일부 취합하여 더 폭넓게 공유하고자 이 게시물을 작성하게 되었습니다.

ELB 기능 및 비용

ELB는 고객이 고가용성과 확장성으로 애플리케이션 트래픽을 안전하게 전송하는 데 사용하는 기본 AWS 네트워킹 서비스 포트폴리오이며, AWS 또는 온프레미스 로케이션에서 호스팅되는 서비스를 확장하는 고객을 위한 일반적인 구성 요소입니다. ELB는 조직이 애플리케이션 및 인프라 복원력을 달성하는 동시에 구현 및 운영 비용을 절감할 수 있도록 지원합니다.ELB를 통해 조직은 수요에 따라 인프라 (및 발생하는 비용) 를 동적으로 조정할 수 있으므로 들어오는 부하에 따라 목표를 조정할 수 있습니다.

애플리케이션 로드 밸런서 (ALB) 와 네트워크 로드 밸런서 (NLB) 는 가장 일반적으로 사용되는 ELB 서비스이며 이 글의 핵심입니다. ALB와 NLB의 기능 및 가격, 그리고 이러한 기능이 특정 사용 사례에 어떻게 적용될 수 있는지 숙지하는 것이 중요합니다. 또한 변화하는 조건, 트래픽 패턴 또는 새로운 기능은 ELB 설정과 기본 고객에게 최상의 경험과 성능을 제공하는 방법을 다시 검토할 수 있는 근거가 될 수 있습니다.

성능 극대화 및 비용 최적화

다음 권장 사항은 AWS 고객이 성능을 극대화하고 워크로드의 ELB 비용을 최적화하기 위해 성공적으로 사용한 실제 시나리오에 중점을 둡니다. 다음 모범 사례를 최대한 활용하려면 통신에 사용하는 프로토콜, API 및 특정 트래픽 패턴 등 워크로드를 잘 이해하고 LCU/NLCU의 특성을 파악하는 것이 모두 중요합니다.

1. 클라이언트 연결 최적화

ELB는 클라이언트와 엔드포인트 (예: 애플리케이션 인스턴스) 간의 연결을 중개합니다. 클라이언트는 특정 ELB 엔드포인트에 자주 액세스할 수 있으며 최적의 성능을 위해서는 클라이언트의 연결 메커니즘을 최적화하는 것이 중요합니다. 또한 클라이언트 연결 최적화 작업은 서비스 상태에 중요한 영향을 미칠 수 있습니다.

클라이언트는 연결 풀링을 사용하여 연결을 효율적으로 사용해야 합니다. 연결 풀링은 클라이언트가 서비스를 여러 번 호출할 때 연결을 재사용할 수 있도록 합니다. 이는 클라이언트 리소스와 지연 시간에도 긍정적인 영향을 미칠 수 있습니다. 연결 풀은 서비스 플릿에서 제어할 수 없는 연결 고갈을 (Connection exhaustion) 방지하는 데 필요한 요소입니다. Exponential backoff and injecting jitter와 같은 연결 재시도 전략은 갑작스러운 수요에 서비스가 중단되지 않도록 서비스를 보호하는 일반적인 방법입니다.

구성 가능한 ALB 및 NLB 연결 유휴 제한시간 (Idle timeout)기능을 숙지하여 클라이언트, 서버 및 해당하는 경우 ELB 설정 자체를 조정하여 연결 수명 주기가 최적인지 확인하십시오. ALB에 대한 연결 유휴 제한 시간 제한 문서와 NLB 설명서는 여기를 참조하십시오.

ELB에서 많이 사용되고 있는 기능은 TLS 프로토콜 지원입니다. AWS는 NLB에서만 지원 되었던 TLS 1.3을 2023년 3월, ALB가 TLS 1.3을 지원한다고 발표했습니다. ELB는 TLS 핸드셰이크를 단일 왕복 교환으로 최적화하여 보안을 강화할 뿐만 아니라 클라이언트의 지연 시간을 줄여줍니다. TLS 1.3 버전을 통해 짧은 지연 시간을 도모 할 수 있습니다.TLS 1.3을 지원하는 클라이언트의 경우 이 기능을 사용하면 전체 왕복 시간만큼 연결 핸드셰이크가 줄어들어 지연 시간이 절반으로 줄어듭니다.

ALB와 NLB는 TLS 세션 재사용도 지원합니다. 올바른 사용 사례를 위해 이전에 설정된 TLS 세션을 사용하도록 이 기능을 지원하는 클라이언트를 구성할 수 있습니다. 이렇게 하면 많은 바이트를 전송하지 않고도 동일한 TLS 엔드포인트에 훨씬 빠르게 다시 연결할 수 있습니다. 이는 연결 및 연결 해제가 더 빈번할 수 있는 모바일 클라이언트에 특히 중요합니다.또한 이를 통해 상당한 지연 시간과 비용 절감 효과를 얻을 수 있습니다.

2. 인바운드 및 아웃바운드 트래픽 최적화

ELB를 통과하는 트래픽의 유형을 면밀하게 검토하는 것이 좋습니다.

데이터 전송 속도 향상을 위한 표준 권장 사항은 페이로드를 압축하는 것입니다. 이렇게 하면 전송되는 총 바이트를 크게 절약하고 데이터 전송에 필요한 총 시간을 줄일 수 있습니다. 대부분의 사용 사례에서, 다수의 호출 대신 더 많은 양의 데이터를 전송하도록 요청을 결합하면 단일 호출만 필요하므로 데이터 전송 계층의 오버헤드가 줄어들고 지연 시간도 줄어듭니다.

사용되는 데이터 전송 계층 프로토콜도 데이터 전송의 효율성을 높이는 데 큰 역할을 합니다. 효율적인 프로토콜로 전송하는 데이터를 직렬화하는 것은 특히 대용량 페이로드의 경우 매우 중요합니다. AWS 서비스 프레임워크 팀은 기존 유선 프로토콜의 효율성 및 확장성 문제를 해결하기 위해 Smithy를 일부 개발했습니다. 일부 클라이언트의 경우 전환이 더 오래 걸릴 수 있지만 사용량이 가장 많은 클라이언트와 API를 대상으로 하는 것이 비용 절감을 위한 좋은 전략일 수 있습니다.

다음은 기존 REST API 데이터 전송 계층과 달리 프로토콜 버퍼 (Smithy와 함께 사용할 수 있는 프로토콜) 를 사용하여 트래픽 비용을 절감할 수 있는 잠재적 사례입니다.

다음과 같은 REST JSON 객체의 크기는 50바이트입니다.

{ "cid": 12345, "ctype": "elb", "country": "CA" }

프로토콜 버퍼로 동일한 JSON 문자열을 인코딩하면 다음과 같은 바이트 배열이 생성되며 크기는 12바이트에 불과합니다.

08 b9 60 12 03 65 6c 62 1a 02 43 41

이 예시에서는 데이터 크기만으로도 페이로드 크기가 76% 감소했음을 나타냅니다. 상위 LCU / NLCU가 데이터 전송인 경우, 프로토콜 버퍼와 같은 방법으로 통신에 사용되는 데이터 전송 계층 프로토콜 변경을 통해 효과적으로 ELB의 데이터 전송 요금을 줄일 수 있습니다.

또한 위의 예에서는 RPC (Remote Procedural Call) 메커니즘을 사용할 때 얻을 수 있는 다른 이점을 고려하지 않았습니다. 여기에는 HTTP 헤더와 같은 관련 페이로드 메타데이터를 크게 줄이고 데이터 직렬화/역직렬화를 위한 오버헤드를 줄이는 것이 포함됩니다. 일부 사용 사례에는 바이너리 프로토콜을 사용하는 것이 적절하지 않을 수 있으므로 이중 RPC, REST 인터페이스를 제공하는 것도 좋은 방법입니다.

서비스 소유자는 클라이언트를 위한 명확한 가이드라인을 수립하고 클라이언트가 데이터를 로컬로 캐시하는 방법과 1 밀리초 미만의 지연 시간을 허용하는 사용 사례를 포함하여 서비스 액세스를 위한 예시를 제공해야 합니다.

신뢰할 수 있는 데이터 공급자로부터 직접 액세스할 수 있는 데이터를 얻는 API 서비스를 ELB를 통해 서비스 하고 있다면, 필요 이상으로 많은 비용을 지출 하게 될 수 있습니다. 예를 들어 API서비스가 호출자에게 Amazon Simple Storage Service (Amazon S3) 객체 데이터를 반환할 때, 객체 데이터 크기만큼의 ELB 데이터 전송요금이 부가적으로 발생하게 됩니다. 이러한 경우 API 서비스가 객체를 직접 반환하는것이 아닌 호출자에게 객체 참조를 반환하여 호출자가 Amazon S3 서비스에 직접 요청할 수 있도록 하는 옵션을 고려해 보십시오. 이렇게 하면 Amazon S3 전송 요금과 관련된 잠재적 비용도 피할 수 있습니다. 다만 부가적인 관리가 발생할 수 있다는 점을 감안해야 합니다.

서비스 종단점에서 요청을 차단/필터링/캐시하여 불법적이거나 형식이 잘못된 요청과 관련된 요금을 피할 수 있습니다. 인터넷에 액세스할 수 있는 대상의 경우 AWS WAF를 사용하면 가용성에 영향을 미치거나, 보안을 손상시키거나, 리소스를 과도하게 소비할 수 있는 일반적인 웹 익스플로잇 및 봇으로부터 보호할 수 있습니다. AWS WAF는 Amazon CloudFront와 통합되어 사용 될 수 있습니다. Amazon CloudFront를 사용하면 콘텐츠를 캐싱하고 엣지에서 TLS 연결을 종료하고 엣지 로케이션을 통해 전송함으로써 전 세계 고객에게 더 빠르게 트래픽을 전송할 수 있습니다.

3. 교차 영역 로드 밸런싱: 알아야 할 사항

안정성을 위한 모범 사례는 서비스를 배포하고 트래픽을 여러 AWS Availability Zone (AZ) 에 분산하는 것입니다.

• 기본적으로 NLB는 교차 영역 로드 밸런싱을 활성화하지 않습니다.
• NLB 교차 영역 밸런싱을 활성화한 상태에서 하나의 가용 영역에서 문제가 발견되면 클라이언트 연결이 중단되고 이후 요청은 다른 영역으로 요청 됩니다. 하지만 클라이언트가 long-lived connection 을 사용할 경우, 문제가 발생한 교차 영역이 정상 상태로 돌아오더라도 설정된 클라이언트에 대해 로드 밸런싱이 균등하게 분산되지 않을 수 있습니다. 따라서 교차 영역을 활성화 할 경우 점진적이고 안전하게 연결을 종료 할 수 있는 방안을 마련 해야 합니다.
• NLB 교차 영역 밸런싱을 활성화하는 경우 클라이언트 IP 보존과 관련된 몇 가지 고려 사항을 숙지하십시오.
• NLB 교차 영역 밸런싱을 사용한다면 가용 영역간 데이터 전송 요금이 부과 됩니다. 단, ALB는 해당 되지 않으며 ALB는 교차 영역 로드밸런싱을 활성화 하더라도 대상 그룹 별로 교차 영역 로드 밸런싱을 비활성화 할 수 있습니다.

4. 적합한 ELB 통합

ELB를 통합하여 사용하는 일부 AWS 서비스에는 사용되는 ELB 수를 최소화하는 기능이 제공되어 있습니다. 예를 들어, Amazon Elastic Kubernetes Service(Amazon EKS) 는 IngressGroups를 사용하여 단일 ALB를 여러 서비스와 공유할 수 있습니다. 그러나 각 서비스에는 리스너 규칙이 추가되므로 이러한 구성 방법을 숙지해야 합니다.

기본 서비스 동작을 추적하는 지표를 설정하여 요청에서 잘못된 응답을 반환하거나, 대상이 비정상 상태로 보고 되었을 때 이를 검토하고 자동으로 알림을 받을 수 있도록 하는 것이 좋습니다. Amazon CloudWatch 이상 탐지를 사용하여 서비스에 영향을 미치는 문제를 발견하고 알릴 수 있습니다.

사용하지 않는 ALB와 NLB를 찾아 계정에서 제거해야 월별 AWS 청구서 비용을 줄일 수 있습니다. 예를 들어 Amazon Elastic Compute Cloud (Amazon EC2) 인스턴스와 같은 리소스가 연결되지 않은 대상 그룹이 포함된 ALB는 더 이상 사용되지 않는 것으로 볼 수 있습니다. AWS 인프라를 자동으로 배포 할 경우, 이러한 미사용 리소스가 빈번하게 발생 할 수있습니다. ELBv2 로드 밸런서는 관련 대상 그룹에 등록된 Amazon EC2 대상 인스턴스가 없거나 등록된 대상 인스턴스가 더 이상 정상으로 보고되지 않는 경우 “미사용” 상태로 간주 됩니다.

마치며

이 지침은 사용하고 계시는 워크로드가 변경 혹은 확장 될 때 다시 검토 하시는 걸 권장 드립니다. ELB를 통해 흐르는 트래픽의 유형과 이러한 엔드포인트에 액세스하는 클라이언트 유형을 이해해야 트래픽 흐름을 최적화할 수 있습니다.대부분의 경우 ELB 관점에서 성능과 효율성을 최적화하면 ELB 비용이 절감될 뿐만 아니라 다른 AWS 리소스와 클라이언트의 성능 상승 도모 할 수 있습니다. 이 블로그의 지침이 도움이 되었기를 바랍니다!

이제 ELB 설정과 클라이언트 유형을 살펴보고 비용, 성능 및 지연 시간을 최적화할 수 있는 변경 사항을 식별하고 우선 순위를 정해 보시길 바랍니다. 추가적으로 AWS의 비용 최적화 문서를 살펴 보시는 것을 권장드립니다.