로드밸런싱을 통한 높은 CPU 점유율 해결하기

배경

  • 서버 응답 대기 문제 해결
  • 위의 과정을 수행하던중, 높은 트래픽이 올때면 nginx의 cpu점유율이 70%을 넘는 것을 알게되었습니다.
    image
  • (nginx는 https 연결을 위해 인스턴스에 설치해둔 것입니다)
  • nginx의 설정파일의 유효성을 확인해보고 nginx의 error 로그를 확인해서 cpu와 관련된 로그들이 없음을 확인하였습니다.
  • 이 문제를 해결하기 위해서 스케일업과 스케일아웃 방법중 다음과 같은 이유로 스케일 아웃을 적용해보려고합니다
    • scale up 방식은 장애 자동복구/다중화 방안을 제시를 못한다는 점
    • scale up 방식은 단순하다는 장점이 있지만 어쨌든 확장을 하는데 한계가 있다는 점

로드밸런싱이란?

  • 서버가 처리해야 할 업무를 여러 대의 서버로 나누어 처리하는 것을 의미합니다.
  1. 라운드 로빈
    • 로드 밸런싱의 가장 간단한 방법으로 클라이언트 요청을 순환하는 각 서버에 균등하게 분배합니다. 3개의 서버가 있는 경우 서버 1이 첫 번째 요청을 받고 서버 2가 두 번째 요청을 받는 식입니다.
      목록 끝에 도달하면 다시 시작합니다.
    • 장점: 가장 단순하고, 모든 서버에 균등하게 트래픽을 분배합니다. 설정이 쉽습니다.
      단점: 모든 서버의 성능과 부하가 동일하다고 가정하기 때문에, 특정 서버에 부하가 많을 경우 이를 고려하지 않고 트래픽을 분배합니다.
    • 가장 단순하지만 로드밸런싱의 장점을 활용하지 못한다는 단점이 커보입니다.
  2. 최소 연결
    • 이 방법은 활성 연결이 가장 적은 서버로 트래픽을 보냅니다. 이는 서버의 기능이 다양하거나 각 연결에서 생성되는 로드가 크게 다를 수 있는 경우 좋은 선택입니다.
    • 장점: 현재 연결 수가 가장 적은 서버에 트래픽을 분배하므로 서버 간의 부하 차이를 최소화할 수 있습니다.
      단점: 연결 수만을 기준으로 분배하기 때문에, 연결의 부하 크기에 따른 차이를 고려하지 않습니다.
    • 단점을 고려하더라도 로드밸런싱의 장점(트래픽 분배)를 잘 활용할 수 있다고 생각하여 "최소 연결"방식을 선택하였습니다
  3. IP 해시
    • 이 방법은 클라이언트의 IP 주소를 사용하여 요청을 보낼 서버를 결정합니다.
    • 이는 클라이언트가 동일한 서버에 일관되게 연결되도록 하는 데 유용할 수 있으며, 이는 일부 애플리케이션에서 상태를 유지하는 데 중요할 수 있습니다.
    • 장점: 클라이언트 IP 주소를 기반으로 항상 동일한 서버에 연결되므로, 사용자 세션 또는 사용자 관련 데이터의 일관성을 유지할 때 유용합니다.
      단점: 일부 IP 주소에서 발생하는 트래픽이 과도할 경우, 해당 서버에 부하가 집중될 수 있습니다.
    • 세션의 일관성을 유지하지 않아도 되니 장점이 무의미하고, 단점이 부각됩니다.
  4. 가중 분포
    • 이 방법을 사용하면 처리해야 하는 클라이언트 요청의 비율을 결정하는 가중치가 각 서버에 할당됩니다. 이는 일부 서버가 다른 서버보다 강력할 때 유용합니다.
    • 각 서버의 처리 능력, 트래픽, 성능 등을 고려하여 각 서버에 가중치를 부여하는 방법입니다. 가중치는 서버가 처리할 수 있는 트래픽의 양이나 요청 수를 나타냅니다.

      예를 들어, 두 대의 백엔드 서버가 있을 때 한 서버는 성능이 좋아서 2배의 트래픽을 처리할 수 있다고 가정해봅시다. 이 경우, 가중치를 다음과 같이 설정할 수 있습니다:

      서버 A (높은 성능): 가중치 2
      서버 B (보통 성능): 가중치 1

      이렇게 설정하면 로드 밸런서는 서버 A로 2/3의 트래픽을, 서버 B로 1/3의 트래픽을 보내게 됩니다.
    • 장점: 서버의 성능이나 용량에 따라 다른 가중치를 부여하여 트래픽을 분배할 수 있습니다.
      단점: 적절한 가중치를 설정하는 것이 중요하며, 설정이 복잡할 수 있습니다.
    • 비용 문제 때문에 가장 저렴한 (동일한 설정의) 인스턴스를 사용해야하기 때문에 각 서버의 처리능력이 차이가 크게 나지 않아 장점이 크게 부각되지 않습니다.
  5. 고정 세션
    • 이 방법은 클라이언트가 세션 데이터가 저장된 서버로 연결되도록 합니다.
    • 장점: 사용자의 세션 정보나 쿠키를 기반으로 항상 동일한 서버에 연결되므로, 세션 데이터가 서버 간에 공유되지 않는 경우에 유용합니다.
      단점: 일정 서버에 트래픽이 집중될 위험이 있습니다.
    • 세션의 일관성을 유지하지 않아도 돼서 장점이 무의미하고, 단점이 부각됩니다

ELB (Elastic Load Balancer) 란?

  • AWS를 사용하여 로드밸런싱을 할 때 ELB라는 개념이 등장합니다. (현재 프로젝트는 AWS를 사용합니다)
  • 트래픽을 여러 대상에 자동으로 분산시켜 안정적인 서버 환경을 운용하는데에 도움을 주는 서비스 ELB의 구성요소입니다.
  • ELB는 VPC에 탑재되며, 사용자의 요청을 받고 이를 VPC 내의 리소스(EC2 등)에 적절히 부하 분산합니다
  • ELB는 외부의 요청을 받아들이는 리스너(Listener)와 요청을 분산/전달할 리소스의 집합인 대상 그룹(Target Group)으로 구성돼서 ELB는 다수의 리스너와 대상 그룹을 거느릴 수 있습니다.

VPC란?

  • 가상 사설망을 의미합니다.
  • 보안규칙을 적용하여 인스턴스에 나만 접근할수있게 할 수 있지만 VPC를 사용하면 향상된 보안 규칙 적용이 가능해집니다.
  • 이러한 네트워크는 소프트웨어를 통해 생성되고 각 장치에 대한 물리적 연결이 필요하지 않기 때문에 "가상"입니다

리스너란?

  • 리스너는 프로토콜과 포트를 기반으로 요청을 받아 검사하고 이를 적절한 타겟으로 전달하는 기능을 수행합니다.
  • 모든 로드 밸런서는 최소 1개 이상의 리스너를 필요로 합니다

로드밸런서 종류

로드 밸런서는 여러 서버(대상)에 걸쳐 트래픽을 분산하는 역할을 합니다. AWS에서 제공하는 Elastic Load Balancing (ELB)는 다양한 유형의 로드 밸런서를 지원합니다.

  1. Application Load Balancer (ALB)
    1. 레이어 7 (HTTP/HTTPS)에서 동작합니다.
      URL 경로나 호스트 기반 라우팅 같은 고급 라우팅 기능을 제공합니다.
      웹 애플리케이션에 주로 사용됩니다.
    2. 장점:
      고급 라우팅: URL 경로나 호스트 기반 라우팅을 통해 복잡한 라우팅 규칙을 적용할 수 있습니다.
      탄력성: 동적으로 변경되는 환경에 잘 적응하며, 다양한 트래픽 유형에 효과적입니다.
      웹소켓 및 HTTP/2 지원: 현대 웹 애플리케이션에 필요한 프로토콜을 지원합니다.
      단점:
      비용: 다른 로드 밸런서에 비해 비용이 더 발생할 수 있습니다.
      복잡성: 고급 라우팅 기능이 초보자에게는 다소 복잡할 수 있습니다.
  2. Network Load Balancer (NLB)
    1. 레이어 4 (TCP/UDP)에서 동작합니다.
      초당 수백만 개의 요청을 처리할 수 있으며 초저지연성을 제공합니다.
      높은 네트워크 트래픽 throughput이 필요한 경우나 초저지연성이 필요한 애플리케이션에 적합합니다.
    2. 장점:
      성능: 초당 수백만 개의 요청을 처리할 수 있는 높은 처리능력을 제공합니다.
      초저지연: 실시간 애플리케이션에 적합한 초저지연성을 보여줍니다.
      정적 IP: 클라이언트 애플리케이션에 고정 IP 주소를 제공할 수 있습니다.
      단점:
      라우팅 옵션 제한: ALB보다는 라우팅 옵션이 제한적입니다
  3. Gateway Load Balancer (GLB)
    1. 가상 네트워킹과 트래픽 라우팅을 통합적으로 관리할 수 있는 로드 밸런서입니다.
      주로 트래픽 검사, 방화벽에 사용됩니다.
    2. GLB는 네트워크와 보안 어플라이언스의 트래픽 라우팅에 중점을 둔 설계로, 일반적인 웹 애플리케이션의 세세한 요구 사항에는 최적화되어 있지 않습니다. GLB의 목적은 보안 및 네트워크 관련 트래픽의 안정적인 라우팅에 중점을 두기 때문입니다.
    3. 트래픽을 검사, 분석, 필터링하여 네트워크 트래픽 내의 패킷들을 개별적으로 살펴보고, 그 내용에 따라 원하는 동작을 수행합니다. 예를 들면, 방화벽에 주로 GLB가 사용되는데, 방화벽은 넘어오는 트래픽의 출발지와 목적지 주소, 포트 번호, 프로토콜 유형 등의 정보를 검사하여 정해진 규칙에 따라 트래픽을 허용하거나 차단합니다. 그렇기때문에 방화벽과 같은 곳에 GLB가 사용됩니다.
    4. 장점:
      통합 관리: 네트워킹과 트래픽 라우팅 관리를 통합적으로 제공합니다.
      보안 통합: IDS/IPS, 방화벽과 통합이 용이합니다.
      단점:
      특정 시나리오 제한: 일반적인 웹 애플리케이션 로드 밸런싱에는 최적화되어 있지 않으며, 특정 네트워크 및 보안 시나리오에만 적합합니다.
  4. Classic Load Balancer (CLB)
    1. ELB의 초기 버전이며 레이어 4 (TCP/UDP)와 레이어 7 (HTTP/HTTPS) 모두에서 동작 가능합니다.
      기본적인 로드 밸런싱 기능을 제공합니다.
    2. 장점:
      다양한 프로토콜 지원: L4 및 L7에서 모두 동작합니다.
      간단한 사용: 기본 로드 밸런싱 기능이 단순하게 제공됩니다.
      단점:
      낮은 확장성: ALB나 NLB에 비해 확장성과 특성이 제한적입니다.

레이어 4 VS 레이어 7

  • 레이어 4 (Transport Layer): 여기서는 TCP와 UDP 같은 전송 프로토콜이 동작합니다. 로드 밸런서가 이 레벨에서 동작할 때, IP 주소와 포트 번호만을 기반으로 트래픽을 분산합니다.
  • 레이어 7 (Application Layer): 여기서는 HTTP, HTTPS, FTP 등의 응용 프로토콜이 동작합니다. 로드 밸런서가 이 레벨에서 동작할 때, URL 경로, 쿠키, 헤더 정보 등 트래픽의 내용을 기반으로 트래픽을 라우팅하거나 조작할 수 있습니다.

로드밸런싱 결과 분석

image

 

image

  1. Errors율 0.1% -> 0.0% 감소
    • 로드밸런싱을 적용한 결과, 대부분의 테스트에서 오류가 거의 발생하지 않았습니다. 이는 로드밸런싱을 적용함으로써 시스템의 안정성이나 내구성이 향상되었음을 나타낼 수 있습니다.
    • 실제로 작은 오류율의 감소도 큰 서비스에서는 중요한 차이를 만들어낼 수 있습니다.
  2. Mean Test Time(테스트의 평균 실행 시간) 6xx -> 1xx로 감소
    • 로드밸런싱 적용 후 테스트 시간이 대체로 줄어든 것으로 보입니다.
    • 특히 대량의 사용자 또는 데이터 처리 요구사항이 있는 시스템에서는 이러한 속도 개선이 중요할 수 있습니다.
  3. Test Time Standard Deviation(테스트 실행 시간의 표준 편차)
    • 이 값이 작을수록 시스템의 성능이 일관되다는 것을 의미합니다. 로드밸런싱 적용 후에는 이 값이 매우 변동적인데, 이는 서버간의 트래픽 분배가 다양하게 이루어지고 있음을 나타내는 지표로 볼 수 있습니다.
  4. Transactions Per Second(초당 트랜잭션 수) 413 -> 1969로 증가
    • 로드밸런싱을 적용하니, 대체로 이 값이 높아졌습니다.
      이는 시스템이 더 많은 트랜잭션을 더 빠르게 처리할 수 있게 되었음을 나타냅니다.
    • 이러한 증가는 사용자가 더 많은 작업을 동시에 시스템에 요청할 때 더 나은 성능을 제공할 수 있게 합니다.
  5. Mean time to Resolve Host / Establish Connection / First Byte:
    • 호스트를 확인하는데 걸리는 시간, 연결을 설정하는데 걸리는 시간, 첫 번째 바이트를 수신하는데 걸리는 시간입니다.
    • 대체로 이 값들은 감소하였는데, 이는 로드밸런싱이 이러한 지연 시간을 줄여 시스템의 반응 시간을 개선했음을 나타냅니다.
      image
      image
  • 인스턴스 각각의 cpu사용률도 70% -> 20% 로 감소하였였음을 확인하였습니다.
    image
    image

결론

로드밸런싱의 적용으로 인해 시스템 전체의 부하 분배가 균일해졌습니다. 이전에는 일부 서버에 트래픽이 집중되어 과부하가 발생했지만, 로드밸런싱의 도입으로 각 서버가 처리하는 트래픽의 양이 균등해졌습니다. 이로 인해 각 서버의 리소스 사용률, 특히 CPU 사용률이 안정적으로 유지되게 되었습니다.

다음으로, 로드밸런싱은 서버 간의 트래픽 분배를 최적화함으로써 응답 시간을 줄였습니다. 사용자 요청이 과부하 상태의 서버가 아닌, 상대적으로 여유로운 서버로 라우팅되기 때문에 더 빠른 처리와 응답이 가능해진 것입니다.

결론적으로, 로드밸런싱의 적용은 시스템의 성능과 안정성을 높이는 결정적인 요인이 되었습니다. 이를 통해 사용자의 경험도 크게 향상되었을 것입니다.