Section 7. ELB+ASG

고가용성과 확장성

확장성은 애플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있다는 의미이다.
확장성의 두 종류
1. 수직 확장성
  - 인스턴스의 크기를 확장하는 것을 의미한다.
  - 분산되지 않은 시스템에서 흔히 사용된다.(데이터 베이스 같은 서비스들을 의미)
  - 하드웨어 제한으로 확장할 수 있는데에는 한계가 있다.
2. 수평 확장성(=탄련성)
  - 인스턴스나 시스템의 수를 늘리는 것을 의미한다.
  - 수평 확장을 한다는 것은 분배 시스템이 있다는 것을 의미한다.(대부분의 시스템이 현재 분배 시스템임.)

고가용성은 적어도 둘 이상의 AWS의 AZ나 데이터 센터에서 가용 중이라는 것을 의미한다.(수평 확장)
데이터 손실에서 살아남는 것이 주요 목표이다.

EC2에서는
1. 수직 확장을 통해 인스턴스의 크기를 늘린다!!
2. 수평 확장을 통해 인스턴스의 수를 늘린다.(=스케일 아웃/인)

고가용성은 같은 애플리케이션의 인스턴스를 multi-AZ를 통해 실행시키는 것을 의미한다.

 

Load Balancer

• 로드 밸런서는 서버 혹은 서버셋으로 트래픽을 전달하는 역할이다.

1. 로드 밸런서를 사용하는 이유?

1. 부하를 다수의 다운스트림 인스턴스로 분산하기 위해서
2. 애플리케이션에 단일 액세스 지점(DNS)를 노출하게 되고 다운스트림 인스턴스의 장애를 원활히 처리할 수 있다.
3. 인스턴스에서 규칙적으로 상태 확인을 할 수 있다.
4. SSL 종료도 가능하여 웹 사이트에 암호화된 HTTPS 트래픽을 가질 수 있다.
5. 쿠키로 고정도를 강화할 수 있다.
6. 영역에 걸친 고가용성을 가진다.
7. 프라이빗한 트래픽으로부터 공용 트래픽을 분리할 수 있다.

• Elastic Load Balancer는 관리형 로드 밸런서로, AWS가 관리하며, 작동할 것에 대해 보장한다.
• 로드 밸런서의 작동 방식을 수정할 수 있게끔 AWS는 일부 구성 놉을 제공한다.
• Elastic Load Balacer는 거의 무조건 쓰는 편이 좋은데 그 이유는 자체 로드 밸런서보다 저렴하고 자체 로드 밸런서를 관리하려면 확장성 측면에서 굉장히 번거롭기 때문이다.
• Load Balancer는 많은 AWS 서비스들과 사용할 수 있다.
  • EC2나 EC2 Auto Scaling Groups, ECS, ACM, Route 53 등등이 있다.

2. Health Checks

상태 확인은 Elastic Load Balancer가 EC2 인스턴스의 작동이 올바르게 작동하는지 확인하는 여부이다.
만일 제대로 작동하는 중이 아니라면 해당 인스턴스로는 트래픽을 보낼 수 없기 때문에 Load Balancer에겐 인스턴스의 상태가 아주 중요하다!!
또한 상태 확인은 포트와 라우트에서 이루어진다.(엔드 포인트는 "/health", 프로토콜은 HTTP, 포트는 4567이다.)

 

3. Types of Load Balancer on AWS

1. Classical Load Balancer | 구세대로 HTTP, HTTPS, TCP, SSL, secure TCP를 지원한다.
   • 더이상 사용을 권장하지 않음.
2. Application Load Balancer | HTTP, HTTPS, WebSocket 프로토콜을 지원한다.
3. Network Load Balancer | TCP, TLS, UDP 프로토콜 지원
4. Gateway Load Balancer | Network Layer에서 작동하므로 IP 프로토콜을 지원한다.

• 일부 로드밸런서들은 내부에 설정될 수 있어 네트워크에 개인적 접근이 가능하고, 모든 곳에 사용 가능한 외부 공공 로드 밸런서도 있다.

4. Load Balancer Security Groups

• Load Balancer Security Group:
  • 로드 밸런서의 보안 그룹은 외부에서 들어오는 트래픽을 허용하기 위해 모든 소스를 허용한다.
• Application Security Group:
  • EC2 인스턴스의 보안 그룹 규칙은 조금 달라야 한다.
  • 포트 80에서 HTTP 트래픽을 허용하며 소스는 IP 범위가 아니라 보안 그룹이 된다.

---

Application Load Balancer

Application Layer의 HTTP 전용 로드 밸런서로 HTTP 애플리케이션의 라우팅으로 사용된다.

1. ALB는 동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를 분산하므로 container와 ECS를 사용한다.
또한 HTTP/2와 WebSocket을 지원하며 리다이렉트도 지원하므로 HTTP에서 HTTPS로 트래픽을 자동 리다이렉트하려는 경우 로드 밸런서 레벨에서 가능케 한다.
2. ALB는 경로 라우팅도 지원한다. 대상 그룹에 따른 라우팅으로는 URL 대상 경로에 기반한 라우팅이 가능하며, URL의 호스트 이름에 기반한 라우팅도 가능하다. 또한 쿼리 문자열과 헤더에 기반한 라우팅도 가능하다.
3. 포트 기능이 있어 ECS 인스턴스의 동적 포트로의 리다이렉션을 가능하게 해준다.

ALB의 대상 그룹은 EC2 Instance, ECS task, Lambda 함수, private IP 주소 등이 될 수 있다.
상태 확인은 대상 그룹 내에서 이루어진다.

• 트래픽에 기반한 HTTP
  • 아래와 같은 그림을 보면 두 개의 독립된 마이크로서비스가 서로 다른 작업을 처리하는 것을 볼 수 있다.
    • 첫 번째 대상 그룹은 /user로 라우팅되고, 두 번째 대상 그룹은 /search로 라우팅된다.

• 쿼리 문자열/파라미터 라우팅
  • 아래 그림을 보면 클라이언트가 사용하려는 URL에 ?Platform=Mobile이 있다면 첫 번째 대상 그룹으로 리다이렉팅되도록 ALB에서 리다이렉션 라우팅 규칙을 만들 수 있다. 온프레미스의 경우도 마찬가지이다. 

• 알아두면 좋은 ALB 관련 사항들
  • ALB를 사용하는 경우에도 고정 호스트네임이 존재한다.
  • 애플리케이션 서버는 클라이언트의 IP를 직접 보지 못한다.
    • 클라이언트의 실제 IP는 X-Forwared-For라고 불리는 헤더에 삽입된다.
    • X-Forwared-Port와 X-Forwared-Proto에 의해 사용되는 포트와 프로토콜도 얻을 수 있다!
  • 아래 그림을 보면 EC2 인스턴스가 클라이언트의 IP 정보를 얻기 위해서는 HTTP 요청에 있는 X-Forwared-Port와 X-Forwared-Proto를 확인해야 한다.

---

Network Load Balancer

Network Layer(4계층)에서 작동하며 하는 일은 다음과 같다.
1. 인스턴스에서 TCP와 UDP 트래픽을 처리한다.
2. 초당 수백만 개 요청을 처리할 수 있다(ALB - 400 ms, NLB - 100 ms)
3. 가용 영역 당 하나의 고정 IP만 있다. 그리고 각 가용 영역에 Elastic IP를 배정할 수 있다.
(만일 시험에 애플리케이션이 1개, 혹은 서로 다른 2개, 3개의 IP로만 액세스가 가능하다고 나오면  NLB를 옵션으로 떠올려야 한다.)

• 트래픽에 기반한 TCP

• Target Group
  • NLB는 EC2 인스턴스로 리디렉션할 수 있고, TCP와 UDP 트래픽을 그쪽으로 보낼 수 있다.
  • 또한 IP 주소도 등록할 수 있다. 다만 이 주소는 하드 코딩이 되어야 하고, 프라이빗 IP 주소여야 한다.
  • NLB는 ALB와도 함께 사용할 수 있다.
    • NLB 덕분에 고정 IP 주소를 얻고 ALB 덕분에 HTTP 트래픽을 처리하는 것과 관련한 모든 규칙을 얻을 수 있다!
  • 시험에서 기억해야 할 것은, NLB의 대상 그룹이 하는 상태 확인은 위의 세 가지 프로토콜을 지원한다는 것이다!

---

Gateway Load Balancer

GWLB는 배포 및 확장과 AWS 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용된다.
GWLB는 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용한다.

 

작동 원리

• GWLB는 모든 로드 밸런서보다 낮은 수준에서 실행된다.(Layer 3, IP 패킷)
• GWLB는 2가지 기능을 갖게 되는데 이는 다음과 같다.
  1. 투명 네트워크 게이트 웨이
     • VPC의 모든 트래픽이 GWLB가 되는 단일 엔트리와 출구를 통과하기 때문이다.
  2. Load Balancer
     • 대상 그룹의 가상 어플라이언스 집합에 트래픽을 분산하여 로드 밸런서가 된다.
• 시험 볼 때는 6081번 포트의 GENEVE 프로토콜을 사용해라!

• Target Group
  • EC2 인스턴스
  • IP Address, 이 경우에는 개인 TCP이어야 한다.

---

Sticky Sessions(Session Affinity)

고정성 혹은 고정 세션을 실행하는 것으로 로드 밸런서에 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해
백엔드에 동일한 인스턴스를 갖는 것이다.

고정성을 이용하려면 'cookie' 개념이 필요한데 이는 클라이언트에서 로드 밸런서로 요청의 일부로서 전송되는 것이다.
쿠키가 만료되면 클라이언트가 다른 EC2 인스턴스로 리디렉션 된다.

세션 만료를 사용할 때는 사용자의 로그인과 같이 중요한 정보를 취하는
세션 데이터를 잃지 않기 위해 사용자가 동일한 백엔드 인스턴스에 연결된다.

고정성을 활성화한다면 EC2 인스턴스 부하에 불균형을 초래할 수 있다!(유의)

고정성의 원리

• 쿠키란?
  1. Application-based Cookies
     1. Custom cookie 
        • 대상으로 생성된 쿠키
        • 애플리케이션에 필요한 모든 사용자 정의 속성을 포함할 수 있다.
        • 쿠키 이름은 각 대상 그룹별로 개별적으로 정해져야 한다.(AWSALB, AWSALBAPP 같은 이름 금지)
     2. Application cookie
        • 로드 밸런서로 생성된 쿠키
        • 쿠키 이름은 AWSALBAPP이다.
  2. Duration-based Cookies
     
     • 로드 밸런서에서 생성되는 쿠키
     • 쿠키 이름은 ALB에서 AWSALB, CLB에서는 AWSELB이다.
     • 특정 기간을 기반으로 만료되며 그 기간이 로드 밸런서 자체에서 생성된다.

Cross-Zone Load Balancing

• 상황 제시
  • 가용 영역이 2개 있고, 1번에는 EC2 인스턴스가 2개 존재한다. 2번에는 EC2 인스턴스가 8개 존재한다.
  • 교차 영역 로드 밸런싱이 적용되면 각 로드 밸런서 인스턴스는 모든 가용 영역에 등록된 모든 인스턴스에 고르게 분포된다.
  • 클라이언트가 1번 ALB 인스턴스에 트래픽 50%, 2번 ALB 인스턴스에 나머지 50%를 보내면 각 ALB는 이 트래픽을 10개의 EC2 인스턴스에 리디렉션한다. 이것이 교차 영역 로드 밸런싱이다.
  • 각 가용 영역에 있는 EC2 인스턴스의 개수가 불균형하면, 특정 가용 영역에 있는 EC2 인스턴스는 더 많은 트래픽을 받게 된다.

Cross-zone Load Balancing

• 기본적으로 ALB에는 교차 영역 로드 밸런싱이 활성화되어 있다. 비활성화는 대상 그룹 레벨에서 가능하고, 데이터가 가용 영역으로 넘어가도 요금이 부과되지 않는다.
• 하지만 NLB와 GWLB는 비활성화되어 있다. 이 경우에는 활성화를 하면 요금이 부과된다.
• CLB는 비활성화가 기본값이고 활성화를 해도 요금이 부과되지 않는다.

SSL 인증서

1. SSL/TLS - 기초

• SSL 인증서는 클라이언트와 로드 밸런서 사이에서 트래픽이 전송되는 동안 암호화되도록 해준다.
  • 데이터가 네트워크를 통과하는 중에는 암호화되어 있고 발신자와 수신자만 해독이 가능하다.
• SSL은 '보안 소켓 계층'이라는 뜻이고 연결을 암호화할 때 사용한다.
• TLS는 SSL의 새 버전이고, '전송 계층 보안'을 의미한다.
• 퍼블릭 SSL 인증서는 인증 기관에서 발행하고, 이 기관에는 Comodo, GoDaddy 등이 있다.
• SSL 인증서에는 만료 날짜가 있고, 인증서의 진위를 확인하기 위해 주기적으로 갱신하여야 한다.

2. Load Balancer - SSL Certificates

• 로드 밸런서는 X.509 인증서를 로딩하는데, SSL 혹인 TLS 서버 인증서라 불린다.
• AWS에서는 ACM을 활용해 이 SSL 인증서를 관리할 수 있다.
• HTTPS listener
  • HTTPS 리스너를 설정할 때는 기본 인증서를 지정해줘야 한다.
  • 원하는 경우에는 HTTPS에 특정 보안 정책을 설정해서 구버전의 SSL/TLS를 지원할 수 있다.

3. SSL - Server Name Indication

• SNI는 하나의 웹 서버에 여러 SSL 인증서를 로드해 웹 서버가 여러 웹사이트를 지원하게 만드는 방법이다.
• 클라이언트가 초기 SSL 핸드쉐이크에서 대상 서버의 호스트 이름을 표시해야 하는 새 프로토콜이다.
• 오로지 ALB와 NLB를 활용할 때만 적용된다.
• 그렇다면 SSL 인증서에는 무엇이 지원될까?
  • CLB에는 하나의 SSL 인증서만 지원된다.
    • 여러 SSL 인증서로 여러 호스트 이름을 사용하고 싶으면 CLB를 여러개 사용하면 된다.
  • ALB는 여러 SSL 인증서로 여러 리스너를 지원할 수 있다.(Good!)
    • 여기에 SNI를 사용하면 된다.
  • NLB도 ALB와 같다.

연결 드레이닝

• 로드 밸런서에 따라 다르게 이름이 불리는데 이는 다음과 같다.
  • CLB | Connection Draining
  • ALB & NLB | Deregistration Delay
• 인스턴스가 등록 취소나 비정상인 상태에 있을 때는 활성 요청을 완료할 수 있도록 하는 "in-flight reqeusts"를 보낸다.
  • 즉 인스턴스가 정상이 아닐 때 들어오는 요청을 완료하는데 약간의 시간을 주는 개념이다.
• 인스턴스가 드레이닝되면 ELB는 등록 취소중인 EC2 인스턴스로 새로운 요청을 보내지 않는다.
• 연결 드레이닝 파라미터는 매개변수로 표시할 수 있는데 1~3600초 사이를 범위로 한다.(300초가 기본값)
  • 이 값을 0으로 한다면 드레이닝을 멈출 수 있다.
  • 짧은 요청이면 낮은 값으로 설정하면 된다.

---

오토 스케일링 그룹(ASG)

1. ASG

웹사이트나 애플리케이션을 배포하면 시간이 지나면서 로드가 변할 수 있다.
AWS에서는 EC2 인스턴스 생성 API 호출로 아주 빠르게 서버를 생성하고 제거할 수 있다.

이를 자동화하고 싶을 때 ASG를 사용한다.
ASG의 목표는 늘어난 로드에 맞추기 위해 스케일 아웃을 시도한다.(EC2 인스턴스 확장)
또한 줄어든 로드에 맞추기 위해 스케일 인을 시도한다.(EC2 인스턴스 제거)
다른 기능으로는 로드 밸런서와 연결 시,  ASG에 포함된 EC2 인스턴스가 로드 밸런스에 연결된다는 것이다.
다른 기능으로는 어떤 인스턴스가 비정상이라고 여겨지면 이것을 종료하고 새 EC2 인스턴스를 재생성하여 대체한다.
ASG는 무료이다.

 

1. 작동 원리

• minimum & maximum 용량을 설정하고 원하는 용량을 맞춘다.
• 필요 시 스케일 아웃을 통해 용량을 늘려준다.

용량 설정하기

ASG의 동작 방식

2. Lauch Template

• 시작 템플릿에는 ASG에서 EC2 인스턴스를 시작하는 방법에 관한 정보가 들어있다.
  • AMI
  • EC2 User Data
  • EBS
  • Security Groups
  • SSH Key pair
  • IAM ROles
  • Network + Subnets Information
  • Load Balancer
• 또한 최소 크기, 최대 크기, 초기 용량과 스케일링 정책을 정의해야 한다.

3. CloudWatch Alarms & Scaling

• CloudWatch 알람을 기반으로 하여 ASG를 스케일 하는 것이 가능하다!

알람이 울리면 그에 맞게 ASG가 조정된다.

2. 스케일링 정책

1. 동적 스케일링
   1. 목표 추적 스케일링
      • CPU 사용률과 같은 ASG에 대한 매트릭을 정의하고, 40%와 같은 목표를 설정한다.
      • 자동으로 ASG가 확장이나 축소되어 이 메트릭을 40%로 유지할 수 있다.
   2. 단순/단계 스케일링
      • CloudWatch 알람을 정의하여 ASG에 용량 단위를 추가하거나 삭제할 때 알람이 발생하도록 한다.
2. 예약 스케일링
   1. 알려진 사용 패턴을 기반으로 스케일링을 예상할 수 있다.
3. 예측 스케일링
   1. 지속적으로 부하를 예측한 다음 미리 예약을 시작하는 경우이다.
   2. 반복되는 패턴이 있을 때 유용하다.
   3. ASG는 자동으로 과거 부하를 분석한 다음 예측치를 생성하여 예측치를 기반으로 스케일링 작업을 진행한다.

---

1. 메트릭

메트릭은 애플리케이션이 수행하는 작업과 작동 방식에 따라 달라진다.

1. CPU 활용도
   • 인스턴스가 요청을 받을 때마다 일반적으로 일종의 계산을 수행하기 때문이다.
   • 모든 인스턴스의 평균 CPU 사용률을 살펴본 후 이 비율이 높아지면 인스턴스의 활용도가 높아진다는 것이다.
2. 테스트를 기반으로 하는 타겟 당 요청 수
   • EC2 인스턴스당 요청 수가 꾸준한 상태가 되도록 하기 위함이다.
3. 평균 네트워크의 In/Out
   • 네트워크가 EC2 인스턴스의 병목 현상이 될 것이라고 예상된다면, 평균 네트워크 사용량을 기준으로 스케일링을 설정하는 것이 좋다.
   • 이렇게 하면 특정 임계값에 도달했을 때 자동으로 스케일링이 이루어지거나 CloudWatch에 설정한 사용자 정의 메트릭을 기반으로 스케일링을 조정할 수 있다.

2. 스케일링 쿨다운

• 스케일링 작업이 있은 후에, 인스턴스를 추가하거나 제거할 때마다 기본적으로 5분 쿨다운 시간이 지나간다.
• 쿨다운 시간 동안에는 ASG는 추가 인스턴스를 개시하거나 종료하지 않는다.
  • 메트릭의 안정화와 새로운 인스턴스가 적용되어 새로운 메트릭이 어떻게 변할지를 지켜보는 시간을 갖기 위해서이다.
• 쿨다운을 잘 이용하기 위해 준비된 도구를 사용하여 EC2 인스턴스의 설정 시간을 줄여 요청을 더 빠르게 처리할 수 있도록 하는 것이 좋다!

3. 인스턴스 새로고침

목표 | 시작 템플릿을 업데이트하고 모든 EC2 인스턴스를 재생성한다.
인스턴스를 종료한 다음 다시 나타날 때까지 기다리는 대신, 오토 스케일링 그룹의 고유 기능인 인스턴스 새로 고침을 사용할 수 있다.

• 새로운 시작 템플링을 만들고 AMI를 업데이트하고, 최소 정상 백분율을 60%로 설정하였을 때, 시간이 지나면서 삭제되는 인스턴스 개수를 오토 스케일링 그룹에 알려 준다.
• 인스턴스가 종료되면 새 인스턴스가 새 시작 템플릿으로 나타나게 되는데 이러한 이유로 EC2 인스턴스 새로고침이라고 한다.
• 뿐만 아니라, EC2 인스턴스가 준비되고 트래픽을 처리할 수 있는 시간이 있는지 확인하려면 워밍업 시간을 지정할 수도 있다!