AWS 로드밸런싱

로드 밸런싱

• 트래픽을 EC2 등 서버들로 전달하는 역할을 한다
  • 유저들은 로드밸런서를 통해 접속하기 때문에 어떤 인스턴스에 연결된 것인지 알 수 없다
    

필요한 이유

• 부하를 다수의 다운스트림 인스턴스로 분산하기 위해서이다
• 애플리케이션의 단일 액세스 지점(DNS)를 노출하고 인스턴스 장애를 원활히 처리할 수 있다
  • 상태체크 매커니즘으로 트래픽을 보낼 수 있는지 확인한다
• SSL 기술을 적용해 웹사이트에 암호화된 HTTPS 트래픽을 가질 수 있다
• 쿠키를 활용하여 클라이언트 요청을 특정 서버(인스턴스)로 지속적으로 라우팅(Stickiness)하도록 강제할 수 있다
• 다중 가용영역으로 고가용성을 지킬 수 있다
• 클라우드 내에서 개인 트래픽과 공공 트래픽을 분리할 수 있다

1. Elastic Load Balancer

• 관리형 로드 밸런서이다
• AWS가 관리하며 어떤 경우에도 작동할 것을 보장한다
  • AWS가 업그레이드와 유지 관리 및 고가용성을 책임진다
• 자체 로드 밸런서를 마련하는 것보다 저렴하고 확장성 측면에서도 쉽다
• 로드 밸런서는 다양한 AWS 서비스와 통합할 수 있다(Route 53, CloudWatch 등)
  

1). Classic Load Banalcer(v1)

• 2009년에 만들어진 예전 버전이다. CLB라고도 불린다
  • HTTP, HTTPS, TCP, SSL, Secure Tcp를 지원한다
• 하지만 AWS에서 로드밸런서의 사용을 권장하지는 않는다

2). Application Load Balancer(v2)

• 2016년에 출시된 로드밸런서 ALB이다
  • HTTP, HTTPS, WebSocket을 지원한다
• L7 로드밸런스로 다수 HTTP 애플리케이션 라우팅에 사용된다
  • 여러 인스턴스들을 묶는 것을 대상 그룹으로 묶고 라우팅한다
• Http -> Https 리다이렉트와 URL기반, 메서드, 호스트, 쿼리 등 라우팅도 가능하다
• MSA나 컨테이너 기반 (Docker, ECS)등에 적합하다
  • 포트매핑으로 동적 포트로 리다이렉트를 도와주기 때문이다
    

Target Group

• EC2 인스턴스, ECS 작업들, 람다 함수, IP 주소들이 될 수 있다
• ALB는 여러 대상 그룹으로 라우팅할 수 있으며 헬스체크는 대상 그룹 레벨에서 이뤄진다
• EC2로 접근하는 걸 막기위해 보안그룹을 ALB의 보안그룹으로 바꾼다
  

3). Network Load Balancer(v2)

• 2017년에 출시된 로드밸런서 NLB이다
  • L4 로드밸런서로 TCP, TLS, UDP를 지원한다
  • 성능이 매우 높고 지연시간도 짧다
  • 가용 영역별로 하나의 고정 IP를 갖는다. 탄력적 IP 주소를 각 AZ에 할당할 수 있다
  • 여러개의 고정 IP를 가진 애플리케이션을 노출할 때 유용하다
    

Target Group

• TCP 또는 UDP 트래픽을 EC2 인스턴스로 리다이렉트 할 수 있다
• IP 주소는 하드코딩되어야 하고 private IP여야 한다
• ALB로 로드밸런서를 할 수 있다
  • ALB 덕분에 HTTP 유형의 트래픽을 처리하는 규칙을 얻을 수 있다
• 헬스체크는 TCP, HTTP, HTTPS를 지원한다

4). Gateway Load Banacer

• 게이트웨이 로드밸런서로 GWLB라고 불린다
• 네트워크층에서 작동한다 (IP 프로토콜)
• 모든 트래픽을 방화벽, 침입 탐지, 및 방지 시스템 걸칠 때 사용된다
• IDPS 심층 패킷 분석 시스템 일부 페이로드를 수정할 수 있지만 네트워크 수준에서 가능하다
• 특징
  • 투명 네트워크 게이트웨이: VCP의 모든 트래픽이 GWLB가 되는 단일 엔트리와 출구를 통과한다
  • 로드 밸런서: 가상 애플리케이션 집합에 전반적으로 트래픽을 분산한다

Target Group

• EC2 인스턴스 IP Address(수동 등록), 외부 애플리케이션

2. 보안그룹

• 유저는 HTTP나 HTTPS를 사용해 로드밸런서에 접근이 가능하다
• EC2는 로드밸런서를 통해서만 접근이 가능하도록 IP주소가 아닌 보안그룹으로 들어오도록 설정해야한다
  

3. 고정 세션

• 요청에 대해 동일한 인스턴스의 응답을 받기 위한 것이다
• CLB와 ALB에서 설정할 수 있고 쿠키와 함께 요청을 보내면 해당 쿠키로 동일한 인스턴스에 요청을 보내는 것이다

1). 쿠키이름

• 고정 세션에는 2가지 유형의 쿠키가 있다
• 애플리케이션 기반 쿠키
  • Custom: 쿠키 이름은 각 대상 그룹별로 개별적으로 지정한다
  • AWSAB, AWSALBAPP, AWAALBTG는 AWS에서 사용하고 있는 이름이기 때문에 사용하면 안된다
• 애플리케이션 쿠키
  • 로드밸런서 자체에서 생성되는 쿠키이다
  • ALB의 쿠키 이름은 AWSALBAPP이다
  • 애플리케이션에서 기간을 설정할 수 있다
• 기간 기반 쿠키
  • 로드밸런서에서 생성되는 쿠키로 ALB에서는 AWSALB이고 CLB에서는 AWSELB이다
  • 특정기간을 기반으로 만료되며 그 기간이 로드밸런서에서 생성된다

4. 교차 영역 로드밸런싱

• 교차영역 로드밸런싱을 하게되면 가용영역이 다르더라도 동일하게 트래픽을 분배해준다
  • 모든 영역에 있는 EC2 인스턴스에 트래픽이 고르게 분배된다
• ALB는 교차 영역 로드 밸런싱이 기본적으로 활성화되어 있다
  • 대상 그룹 설정에서 비활성화할 수 있고 데이터를 다른 가용 영역으로 옮길 때 비용이 들지 않는다
• NLB & GWLB는 기본적으로 비활성화되어 있다
  • 가용영역별로 나눠져 있기 때문에 활성화하게 되면 비용을 지불해야 한다
    

1). 영역을 교차하지 않는다면

• 영역을 교차하지 않고 부하를 분산하게 되면 탄력적 로드 밸런서 노드로 분산된다
• 모든 인스턴스에게 동일하게 요청을 보내지 않고 가용영역별로 트래픽을 나눠서 보내게 된다
  

5. SSL/TLS

• SSL인증서는 클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화해준다
  • 이를 전송 중(In-Flight)암호화라고 한다
• 송신자와 수신자 측에서만 복호화할 수 있다
• SSL은 보안 소켓 계층을 의미하고 연결을 암호화하는데 사용한다
  • TLS는 새로운 버전의 SSL이다 (전송 계층 보안)
• Public SSL 인증서는 CA에서 발급하고 이를 로드밸런서에 추가하면 암호화할 수 있다
  • AWS에서 이 인증서를 관리할 수 있는 ACM이 있다
  • AWS Certificate Manager(AWS 인증서 관리자)를 의미한다
  • 원한다면 내가 가진 인증서를 ACM에 업로드할 수도 있다
• SNI(서버 이름 지정)을 써서 접속할 호스트의 이름을 알릴 수 있다
  

1). SNI

• Server Name Indication(서버 이름 지정)
• 여러 개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹서버가 여러 개의 웹사이트를 지원할수 있게 해준다
• 확장된 프로토콜로, 클라이언트가 대상 서버의 호스트 이름을 지정하게 한다
  • 최초 SSL 핸드셰이크 단계이다
  • 클라이언트가 접속할 웹사이트를 입력했을 때 서버는 어떤 인증서를 로드해야 하는지 알 수 있다
• ALB & NLB, CloudFront에서만 동작한다
  

6. Connection Draining

• CLB의 경우 Connection Draining이라 부르고 ALB & NLB에서는 등록 취소 지연(Deregistration Delay)라고 부른다
• 인스턴스가 등록 취소, 혹은 비정상적인 상태에 있을 때 시간을 주어 활성 요청을 완료할 수 있도록 하는 기능이다
• 인스턴스가 드레이닝이 되면 ELB는 새로운 요청을 보내지 않는다
  

7. 오토 스케일링 그룹

• 웹사이트나 애플리케이션 방문자가 많아지면 자동으로 인스턴스를 생성하는 것이다
• ASG의 목표는 Scale Out, Sacle In이다
• 최소 및 최대 개수를 보장하기 위해 전반적으로 정의할 수 있다
• 로드밸런서와 페어링하면 ASG에 속한 모든 인스턴스가 로드 밸런스에 연결된다
• 한 인스턴스가 비정상이면 종료시키고 대체할 새 인스턴스를 생성한다
  

1). 실행

• Launch Template으로 ASG내에서 인스턴스를 시작하는 방법을 적어놓는다
• 최소, 최대, 시작 용량을 정의해야 한다
• CloudWatch 경보를 기반으로 ASG를 Scale Out, Scale In할 수 있다
  

2). 조정 정책

• 동적 스케일링
  • 간단한 스케일링으로 목표 추적이 있다
  • CPU 사용률 같은 메트릭을 정의하고 자동으로 ASG를 확장, 축소할 수 있다
• 단순 / 단계 스케일링
  • 클라우드 와치 알람을 정의하여 CPU 70% 이상이면 2개 추가등을 하는 것이다
• 예약 스케일링
  • 패턴을 기반으로 스케일링을 한다
  • 예를 들어 금요일 오후 5시에 매번 사용자가 늘어난다면 해당 날짜에만 스케일링을 한다
• 예측 스케일링
  • 지속적으로 부하를 예측한다음 예약을 하는 개념이다
  • ASG는 자동으로 분석하여 사용한다
• 스케일링 쿨다운
  • 쿨다운 시간동안 ASG는 인스턴스를 추가하거나 종료하지 않는다
  • 메트릭이 안정화되도록하고 새로운 인스턴스가 적용되어 새로운 메트릭이 어떻게 변할지 지켜보는 것이다
• CPU 사용량, 타겟당 요청 수, 평균 Network I/O를 기준으로 스케일링을 한다