ELB - Elastic Load Balancer

Load Balancer

• 트래픽을 분산하는 서비스
• EC2 인스턴스, 컨테이너, IP 주소 등 여러 대상으로 자동 분산 가능
• 비정상 대상을 감지하면 해당 대상으로 트래픽 라우팅을 중단하고 대상이 다시 정상으로 감지되면 트래픽을 해당 대상으로 다시 라우팅

Application Load Balancer

• Layer 7
• HTTP, HTTPS
• HTTP Header Content를 사용해 라우팅 요청 처리
• 웹 애플리케이션, 마이크로서비스(포트 매핑)에 적합

Network Load Balancer

• Layer 4
• TCP, UDP, TLS
• Protocol, Port Number를 사용해 라우팅 요청 처리
• 수백만의 대용량 트래픽 처리에 적합

Gateway Load Balancer

• 단일 AZ
• Layer 3 - Gateway Load Balancer Endpoint
• Layer 4 - Gateway Load Balancer
• GENEVE protocol을 사용하여 encapsulation 트래픽 전송
• Transparency한 네트워크 게이트웨이를 제공하므로 방화벽, IPS, IDS 등의 원본 패킷의 데이터가 중요한 가상 어플라이언스에 적합

Gateway Load Balancer Deployments

• 게이트웨이 로드 밸런서는 AWS Auto Scaling 그룹과 함께 작동하므로 가상 어플라이언스를 확장할 수 있습니다.
• 트래픽을 정상 어플라이언스로 라우팅하여 고가용성 구현
• PrivateLink에서 제공하는 Gateway Load Balancer Endpoint를 사용할 수 있습니다.
• 타겟 그룹으로 GENEVE 프로토콜 생성 가능 (GENEVE: 6081)
• 타겟 타입에는 인스턴스 또는 IP 선택

다음과 같은 타사 가상 어플라이언스와 함께 사용할 수 있습니다.

• Next Generation Firewalls (NGFW)
• Web Application Firewalls (WAF)
• Intrusion Detection Systems (IDS) 침입 탐지 시스템
• Intrusion Prevention Systems (IPS) 침입 방지 시스템

Gateway Load Balancer Monitoring

• CloudWatch 지표 - AWS/GatewayELB 네임 스페이스는 여러 지표가 포함됩니다.
• VPC Flow Log - GLB의 각 네트워크 인터페이스에 대한 흐름 로그 생성 (서브넷당 하나)
• CloudTrail Log - GLB와 관련된 API 작업 캡처

Classic Load Balancer

• Layer 4, Layer 7
• HTTP, HTTPS, TCP, TLS
• Protocol, Port Number를 사용해 라우팅 요청 처리
• 이전 세대 EC2-Classic 네트워크에서 사용

• Gateway Load Balancer Endpoint: 서비스 공급자(Provider) VPC의 가상 어플라이언스와 서비스 소비자(Consumer) VPC의 애플리케이션 서버 간에 프라이빗 연결은 제공
• 인터넷 게이트웨이를 통해 서비스 소비자 VPC로 들어오는 모든 트래픽은 먼저 검사를 위해 Gateway Load Balancer Endpoint로 라우팅된 다음 Application Server로 라우팅
• Application Server에서 나가는 모든 트래픽은 다시 인터넷으로 라우팅되기 전에 검사를 위해 Gateway Load Balancer에서 엔드포인트로 라우팅
• Network In: Layer 3 -> Layer 4
• Network Out: Layer 4 -> Layer 3

Elastic Load Balancer 구성

Client -> Listener -> ELB -> Target Group

Listener

• 연결 요청을 확인하는 프로세스
• 클라이언트와 로드 밸런서 간의 연결을 위한 프로토콜 및 포트 번호로 구성
• 로드 밸런서와 대상 간의 연결을 위한 프로토콜 및 포트번호로 구성

Target Group

• 대상(Target)의 모임
• Target

• EC2 Instace
• EC2 Auto Scaling Group
• IP address
• Lambda

Health Check

• 등록된 Target (대상)에게 상태 확인 메시지를 보내서 대상의 상태를 확인

important

속성 (Attributes) - HTTP / HTTPS (Application Load Balancer)

등록 취소 지연 (Deregistration delay)

• Auto Scaling 축소 등으로 Deregistration 된 인스턴스에 접속한 유저가 진행중인 프로세스가 있을 경우 해당 프로세스가 종료될 때까지 기다려주는 것과 같은 것으로 해당 인스턴스에 더 이상의 요청을 보내지 않도록 하는 기능
• 해당 인스턴스에 진행중인 요청이 있을 경우 설정해 놓은 시간동안 연결이 유효상태가 되지 않으면 해당 인스턴스에 연결 요청을 하지 않음

느린 시작 기간 (Slow start duration)

기본적으로 대상은 대상 그룹으로 등록되자마자 전체 요청을 공유 받기 시작하고 초기 상태 확인을 전달 느린 시작 모드에서는 로드 밸런서가 대상으로 보낼 수 있는 요청의 수를 선형으로 증가

알고리즘

• 라운드 로빈(Round Robin): 일정 시간마다 라우팅을 변경
• 최소 미해결 요청(Least Outstanding Requests): 처리하고 있는 요청이 가장 적은 대상에게 라우팅

고정 (Stickness)

Client가 Session을 유지한 상태라면 모든 요청을 동일한 인스턴스로 유지하는 기능

important

속성 (Attributes) - TCP / UDP / TLS (Network Load Balancer)

등록 취소 지연 (Deregistration delay)

• Auto Scaling 축소 등으로 Deregistration된 인스턴스에 접속한 유저가 진행중인 프로세스가 있을 경우 해당 프로세스가 종료될 때까지 기다려주는 것과 같은 것으로 해당 인스턴스에 더 이상의 요청을 보내지 않도록 하는 기능
• 해당 인스턴스에 진행중인 요청이 있을 경우 설정해 놓은 시간동안 연결이 유효상태가 되지 않으면 해당 인스턴스에 연결 요청을 하지 않음

등록 해제 시 연결 종료

등록 해제 지연에 도달했을 때 NLB가 활성 연결 종료

고정 (Stickness)

Client가 Session을 유지한 상태라면 모든 요청을 동일한 인스턴스로 유지하는 기능

클라이언트 IP 주소 보존

들어오는 모든 트래픽의 Client IP를 애플리케이션으로 전달

Application Load Balancer

• 최소 2개 이상의 가용영역을 지정해야 함
• 서브넷당 사용가능한 IP 주소가 최소 8개 필요
• 권장하는 최소 CIDR 블록은 /27 넷마스크 (ex: 10.0.0.0/27)
• 리스너는 HTTP, HTTPS를 사용할 수 있음
• HTTPS 프로토콜 사용시 SSL/TLS 인증서를 배포해야 함
• 인증서는 ACM(AWS Certificate Manager) 사용 또는 클라이언트 인증서 사용 가능
• 소스 IP 전달 (Source IP Prevention) 사용을 위해서는 X-Forwarded-For 헤더를 사용
• WebSocket 기능 사용을 위해서는 Stickness를 활성화해야 함

Listener 규칙

• Host header: 각 요청의 호스트 이름을 기반으로 호스팅
• Path: 요청의 URL의 경로 패턴을 기반으로 라우팅
• HTTP Header: 각 요청의 HTTP 헤더를 기반으로 라우팅
• HTTP Request method: 각 요청의 HTTP 요청 메소드를 기반으로 라우팅
• Query String: 쿼리 문자열의 키/값 페어 또는 값을 기반으로 라우팅
• Source IP: 각 요청의 소스 IP 주소를 기반으로 라우팅

Network Load Balancer

• Millions of Concurrent Users / Requests Per Second의 경우에 적합한 로드밸런서
• 서브넷당 사용가능한 IP 주소가 최소 8개 필요
• 권장하는 최소 CIDR 블록은 /27 넷마스크 (ex: 10.0.0.0/27)
• 고정 IP 주소 할당 가능
• 클라이언트 IP 주소 전달 가능 (Source IP Prevention)
• WebSocket 지원
• ALB처럼 리스너 규칙 설정 없음
• 리스너 프로토콜은 TCP, TCP/UDP, UDP, TLS를 사용할 수 있음
• TLS 프로토콜 사용시 SSL/TLS 인증서를 배포해야 함
• 인증서는 ACM(AWS Certificate Manager) 사용 또는 클라이언트 인증서 사용 가능

important

ALB를 통한 접근시 로그 기록하기

같은 가용영역안에서 퍼블릭 서브넷에 위치하는 두 개의 EC2 인스턴스를 대상으로 하는 타겟그룹을 생성하여 ALB에 연결하고 나면 EC2의 각 퍼블릭 주소로 접속할 수도 있고 ALB DNS 이름으로 접속할 수도 있다. ALB DNS로 접속할 경우 부하 분산을 해주기 때문에 새로고침시마다 두 EC2로 번갈아 호스팅되었다.

여기서 생각해 볼 수 있는 것이 하나 있다. 각각 EC2 인스턴스의 퍼블릭 주소로 접속할 때에는 EC2 인스턴스에 접속하여 /etc/httpd/logs/access_log 파일에 클라이언트 아이피 주소를 확인할 수 있었지만 로드밸런서 DNS 이름을 통해 인스턴스에 접속한 클라이언트의 아이피 주소는 남겨지지 않았다. 따라서 공식문서에 나와있는 대로 /etc/httpd/conf/httpd.conf에서 %{X-Forwarded-For}i를 추가하여 웹 서버를 재부팅시켜주었더니 ALB DNS 이름을 통해 접속한 클라이언트의 아이피 주소가 남겨진 것을 확인할 수 있었다.

하지만 여기에는 사전작업이 하나 필요한데 ALB 속성에 X-Forwarded-For header을 Append 해줘야 한다. 그렇지 않으면 위의 설정을 한다고 하더라도 클라이언트의 아이피 주소를 확인할 수 없다. 또한 액세스 로그를 S3에 저장할 수도 있는데 버킷 정책을 통해 권한을 위임해주어야 한다.

X-Forwarded-For (XFF)란 ?

XFF는 HTTP Header중 하나로 HTTP Server에 요청한 Client IP를 식별하기 위한 표준입니다. 웹 서버나 WAS 앞에 L4 같은 Load Balancer나 Proxy Server, caching server 등의 장비가 있을 경우 웹 서버는 Proxy server이지만 장비 IP에서 접속한 것으로 인식합니다. 그렇기 때문에 실제 클라이언트 IP가 아닌 앞단에 있는 Proxy 서버 IP를 요청한 IP로 인식하고 Proxy 장비 IP로 웹 로그를 남기게 됩니다.

클라이언트 -> Proxy Server -> Web Server

이 때 웹프로그램에서는 X-Forwarded-For HTTP Header에 있는 클라이언트 IP를 찾아 실제 요청한 클라이언트 IP를 알 수 있고, 웹 로그에도 실제 요청한 클라이언트 IP를 남길 수 있습니다.

ALB Access Log to S3 (Bucket Policies)

**600734575887**은 서울(ap-northeast-2)리전의 Elastic Load Balancing 계정 ID이다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::600734575887:root"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::S3버킷이름/AWSLogs/12자리어카운트번호/*"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "logdelivery.elb.amazonaws.com"
      },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::S3버킷이름"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "logdelivery.elb.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::S3버킷이름/AWSLogs/12자리어카운트번호/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-acl": "bucket-owner-full-control"
        }
      }
    }
  ]
}

로드 밸런서 구성 옵션: 라우팅 알고리즘

important

Application Load Balancer

Application Load Balancer에서 요청을 수신하는 로드 밸런서 노드는 다음 프로세스를 사용합니다.

적용할 규칙을 결정하기 위해 우선 순위에 따라 리스너 규칙을 평가합니다. 대상 그룹에 대해 구성된 라우팅 알고리즘을 사용하여 규칙 조치에 대한 대상 그룹에서 대상을 선택합니다. 기본 라우팅 알고리즘은 라운드 로빈입니다. 대상이 여러 개의 대상 그룹에 등록이 된 경우에도 각 대상 그룹에 대해 독립적으로 라우팅이 수행됩니다.

Network Load Balancer

흐름 해시 알고리즘을 사용하여 기본 규칙에 대한 대상 그룹에서 대상을 선택합니다. 알고리즘은 다음을 기반으로 합니다.

• 프로토콜
• 소스 IP 주소 및 소스 포트
• 대상 IP 주소 및 대상 포트
• TCP 시퀀스 번호

각 개별 TCP 연결은 연결 수명 동안 하나의 대상에 라우팅됩니다. 클라이언트로부터 TCP 연결은 소스 포트와 시퀀스 번호가 서로 다르므로 다른 대상에 라우팅될 수 있습니다.

Classic Load Balancer

Classic Load Balancer에서 요청을 수신하는 로드 밸런서 노드는 다음과 같이 등록된 인스턴스를 선택합니다.

• TCP 리스너에 대한 라운드 로빈 라우팅 알고리즘 사용
• HTTP 및 HTTPS 리스너에 대한 최소 미해결 요청 라우팅 알고리즘 사용

ACM/SSL 인증서를 로드 밸런서에 연결

Application Load Balancer에 대한 액세스 로그

ELB를 기반으로 하는 웹 서버 로그에서 클라이언트 IP 주소 캡처