본문 바로가기

NCP

[NCP] 로드밸런서 및 Global DNS 소개

반응형

Load balancer

  • 사용자의 서비스 트래픽을 다수의 서버로 로드를 분산시키는 역할, 로드를 분산시키며 가용성을 높임
  • Target Group
    • 트래픽을 전달할 때 이 서버들의 집합을 명시적으로 논리적으로 그룹핑을 함으로써 로드밸런서와 서버 간의 좀더 논리적이고 관리적인 부분을 향상시키고자 만든 것
    • 요청을 처리할 대상에 대한 집합
    • 동일 VPC 내에 있는 서버들에 대해 타겟 그룹 생성 가능
    • 타겟 그룹 안에 있는 서버를 다른 타겟 그룹에 속하게 할 수 있지만 타겟 그룹을 다수의 로드밸런서에 연결할 수 는 없다.
    • 서비스를 수행하는 대상의 프로토콜에 따라 L4와 L7으로 구분
    • 헬스체크 주기 (5~300초) 및 임계값 설정
    • 기본은 Round Robin 설정
    • 아니면 Source IP Hash 방식
      • 알고리즘 및 Sticky, ProxyProtocol 설정 변경은 생성 이후에 진행
  • 프로토콜
    • 사용하고자 하는 어플리케이션의 통신 프로토콜이 어떤 것이냐에 따라서 사용할수있는 로드밸런서가 달라짐
    • TCP : Network Load Balancer
    • Proxy_TCP : Network Proxy Load Balancer
    • HTTP : Application Load Balancer
    • HTTPS : Application Load Balancer
  • 로드밸런서
    • 부하처리 성능에 따라 Small / Medium / Large 중 선택할 수 있으며 각각 초당 연결수 (CPS) 기준 최소 30,000 / 60,000 / 90,000 개의 분산처리를 보장합니다.
  • 로드 밸런싱 알고리즘
    • Round Robin : 클라이언트에서 요청이 오면 서버에 1개씩 분배하는 방식
    • Least Connection : 클라이언트 연결이 제일 적은 서버에게 새로운 커넥션을 분배하는 방식
    • Source IP Hash : 클라이언트 IP에 대한 해시테이블을 가지고 클라이언트 IP에 매핑되는 서버에 새로운 커넥션을 분배하는 방식

Load balancer

  • 애플리케이션 로드밸런서
    • HTTP, HTTPS를 사용하는 웹 애플리케이션에 보다 유연한 구성이 가능
    • 고정 IP 제공 (DNS에 A-pack 도메인을 구성할 수 있음)
    • URL 기반 분기 가능 (...naver.com/kim 타겟그룹을 분리 가능)
    • 알고리즘은 3가지 제공
  • 네트워크 로드밸런서
    • 고성능의 분산처리 가능
    • Client IP가 그대로 로깅 (장점이다, 다른 애플리케이션 로드밸런서와 네트워크 프록시 로드밸런서는 Apache로그에서 실제 Real Client Real IP를 뽑아내지는 못함 추가적으로 Export forward와 같은 설정을 해야만 뽑아낼 수 있음)
      • IP table과 서버에서 다양한 필터 설정이 가능함 (Client IP가 그대로 로깅 되기 때문)
    • 알고리즘은 Hash, RR만 제공
      • 프록시 방식은 중간에 모든 괄로를 이 로드밸런서가 붙잡고 있기때문에 모든 세션을 알 수 있다. 하지만 네트워크 로드워크 로드밸런서는 토스하는 개념 서버로 forwarding 하기 때문에 서버에 몇개의 세션이 물려있는지 알수없음
  • 네트워크 프록시 로드밸런서
    • Classic과 유사한 로드밸런서

Load balancer

  • TCP 레벨 고성능 분산처리 - 네트워크 로드밸런서
    • 네트워크 로드밸런서는 초당 연결 수 기준 최소 100,000개에서 최대 400,000개까지 성능을 보장하는 단계별 상품을 제공하여 고객 서비스 규모에 최적화된 분산처리 성능을 제공합니다. 또한 네트워크 로드밸런서는 트래픽 분배만 수행하고 고객 서버에서 직접 응답하는 기능 (DSR)을 구현하여 보다 빠르고 효율적인 서비스를 이용하실 수 있습니다.
  • TCP 세션 관리 - 네트워크 프록시 로드밸런서
    • 네트워크 프록시 로드밸런서는 프록시 방식의 통신을 제공하여 세션 유지가 필요한 TCP 기반 애플리케이션에 이용할 수 있습니다. 또한 애플리케이션 로드밸런서와 동일한 부하 분산 알고리즘을 적용할 수 있습니다.
  • SSL 인증 및 암호화 설정 - 애플리케이션 로드밸런서, 네트워크 프록시 로드밸런서
    • 웹 기반의 콘솔에서 SSL 인증서를 추가할 수 있습니다. TLSv1, TLSv1.1, TLSv1.2 등 SSL 프로토콜 중 가능한 버전을 선택해 사용할 수 있으며, 적용된 SSL Ciphers를 설정할 수 있습니다. SSL 인증서는 Certificate Manager와 연동하여 편리하게 관리됩니다.
  • 다양한 서버 부하 분산 방식 - 애플리케이션 로드밸런서, 네트워크 프록시 로드밸런서
    • 제공하는 서버 부하 분산 방식에는 Round Robin, Least Connection, Source IP Hash 방식이 있습니다.
  • L7 (Application Layer) 기능 제공 - 애플리케이션 로드밸런서
    • HTTP/HTTPS 트래픽에 대해서 패킷 헤더를 확인하여 Application 레벨에서의 분기처리를 제공합니다. 로드밸런서의 리스너에 Host Header기반 분기처리, URL Path Pattern 기반 분기처리, 가중치 기반 분기처리, Redirection 응답처리와 같은 규칙이 지원되어 보다 상세한 고급 서비스 구성이 가능합니다.
    • URL을 보고 실제로 어느 서버로 가야할지를 필터를 걸게되면 해당 필터에 따라서 분기를 하게 된다.
  • Load Balancer 모니터링
    • 로드밸런서에 대해서는 기본 모니터링 정보를 제공하며 서버 모니터링과 마찬가지로 기간 선택에 따라 모니터링 정보 수집 주기를 1분, 5분, 2시간, 1일 단위로 제공합니다. 네트워크 로드밸런서 모니터링은 Concurrent Connection, 초당 Connection, Traffic In, (Un)Available hosts 등 5가지 항목의 정보를 제공하며, 애플리케이션 로드밸런서는 Traffic Out을 포함하여 6가지 항목을 제공합니다.
  • Load Balancer 포트 설정
    • 여러 개의 로드밸런서 규칙을 동시에 설정할 수 있습니다. 로드밸런서 규칙을 설정할 때는 로드밸런서 포트를 다른 로드밸런서 규칙의 포트와 다르게 설정해야 합니다. 서버 포트는 다른 로드밸런서 규칙의 서버 포트와 동일하게 설정하셔도 됩니다.
  • 타입별 기능 비교
  • LB의 구성 방식
    • NAT
    • DR
    • Proxy
  • 스케줄링 방식
    • Round-Robin Scheduling
    • Least-Connection
    • Source Hash Scheduling
    • Weighted Round-Robin Scheduling (서버의 스펙이 달라서 가중치를 둬야할때 사용하는 것이 Weighted방식 Cloud는 스펙 조절이 가능하기 때문에 문제가 없음)
    • Weighted Least-Connections
    • Locality-Based Least-Connection Scheduling
    • Locality-Based Least-Connection Scheduling with Replication Scheduling
    • Destination Hash Scheduling
  • 네이버 클라우드 플랫폼 로드밸런서 헬스 체크
    • 6초마다 헬스 체크
    • 3회 연속으로 OK 혹은 error가 뜨면 바인딩 혹은 언바인딩
  • 접속 정보로 도메인 정보를 제공
    • 따라서 DNS에는 CNAME으로 등록하여야 함. (IP 정보를 제공하지 않고 Host 정보를 제공하고 있기 때문에)
    • 하지만 Zone apex에 대해서는 RFC1033과 같이 등록 불가 (그래서 VPC에서는 IP주소를 제공)
  • 기본적으로 로드밸런서 하나를 생성하면 HAProxy 2개가 생성됨. HAProxy 1개의 안정적인 동접 성능은 대략 3000 동접 수준, 만약 동접이 수만 동접인 경우 HAProxy를 여러 개 생성하여야 함.
  • 제약 사항
    • 한 서버가 여러 개의 LB에 바인딩이 될 수 있지만 포트별 멀티 바인딩은 지원하지 않음
    • 18080 ~ 18095, 65130, 65131, 64000, 3389, 22포트는 관리용 포트이기 때문에 사용 불가
    • 최대 50대 서버 바인딩
  • KeepAlive & Connection Idel Time
    • On이 필요한 경우
      • 메모리가 충분하고
      • 컨텐츠 서비스 형태여서
      • 사용자가 지속적으로 서버에 요청하는 경우
    • Off가 필요한 경우
      • 메모리가 충분하지 못하고
      • 사용자가 서버에 지속적으로 머물지 않는 경우
  • SSL 이용시 Redirect
    • SSL을 이용할 경우 LB는 TCP 443 포트로 받고 80포트 서버로 전달
    • 서버 입장에서는 HTTP로 접근하는지 HTTPS로 접근하는지 확인 필요
  • 서버에 추가로 포트 개방하고 LB 80포트를 해당 포트에 연결하여 Redirect
    • 서버에 8080포트도 웹서버에서 Listen 하도록 설정
    • LB에서는 80포트로 오는 패킷을 8080으로 전달
    • 서버에서 8080포트로 오는 접근은 443으로 Redirect
    • Target Group은 80포트이다. 그런데 로드밸런서에 인증서를 설치하면 로드밸런서에서는 443포트만 Listen할 것이다. 80으로 오면 443으로 Redirect를 해야함. 그런데 로드밸런서 자체적으로는 80으로 왔을때 Redirect를 하는 기능이 없음 그래서 SSL을 이용할 경우에는 LB는 TCP443포트를 받고 80포트로 서버를 전달하면 그래서 LB와 서버간에는 평문으로 통신하게 됨. 클라이언트오 LB까지는 443 (보안된문서)로 전달, 서버 입장에서는 HTTP인지 HTTPS로 접근하는지 확인 필요 그래서 서버에 추가로 포트를 개방하고 LB80포트로 오는 것에 대해서 서버에다가는 5000번을 열거나 443으로 Redirect하는 기능
  • X-Forwarded 헤더를 이용
    • X-Forwarded-Proto 헤더를 이용하여 연결에 사용한 프로토콜을 식별
    • HTTP로 온 경우 HTTPS로 Redirect

Global DNS

  • DNS 서비스
    • 다양한 레코드 타입 지원 (A, NS, PTR, AAAA, MX, CNAME, SPF, TXT, SRV, CAA)
      (A : 호스트를 IP로 응답해주는 레코드
      NS : 위임해주는 NS
      AAAA : IPv6에 해당
      MX : 메일서버를 찾아줌
      CNAME : 호스트로 Redirection
      SPF, TXT : 기타 메일과 관련된)
    • Alias 기능 제공 및 설정 반영 단계 추가
    • 등록 도메인으로 인입되는 트래픽을 분기 (Round Robin)
    • 모니터링 기능 제공