ELB / ASG

고가용성 및 확장성

• 수직적 확장 vs 수평적 확장

  • 수직적 확장은 EC2 인스턴스의 사양을 높이는 것으로, t2.nano(0.5G RAM + 1 vCPU) 부터 시작해 u-t12tb1.metal(12.3TB RAM + 448 vCPUs) 까지 올릴 수 있다.

  • 수평적 확장은 동일한 사양의 EC2 인스턴스의 개수를 늘리는 것이다.

• 고가용성

  • 두 개 이상의 AZ 혹은 데이터 센터에서 동일한 애플리케이션이 가동중이어야 고가용성이 보장된다.

  • 보통 수평적 확장으로 보장된다.

ELB

• Elastic Load Balancer

• AWS가 업그레이드와 유지보수 및 고가용성을 책임진다.

• 로드밸런서 동작 방식을 설정할 수 있는 knobs를 제공한다.

• EC2 인스턴스가 올바르게 동작하는지 여부를 헬스 체킹하여 정상 인스턴스로만 트래픽을 전달한다.

• 헬스 체크는 port와 route를 통해 이뤄진다.

• 내부 용도의 로드밸런서와 외부 공개 용도의 로드 밸런서를 각각 제공한다.

• EC2 인스턴스는 로드밸런서로부터 온 트래픽을 처리하기 위해 EC2의 보안 그룹을 로드밸런서의 보안 그룹으로 연결한다.

• 4가지 종류의 로드밸런서를 제공한다.

  • CLB

    • Classic Load Balancer

    • HTTP, HTTPS, TCP, SSL

  • ALB

    • Application Load Balancer

    • HTTP, HTTPS, WebSocket

  • NLB

    • Network Load Balancer

    • TCP, TLS, UDP

  • GWLB

    • Gateway Load Balancer

    • 3계층 IP 프로토콜

ALB

• 7계층 HTTP/HTTPS 애플리케이션을 위한 로드밸런싱을 제공한다.

• 머신 간 다수 HTTP 애플리케이션의 라우팅에 사용된다. 머신은 대상 그룹으로 묶인다.

대상(target) 그룹

---

• 다음과 같은 리소스들을 하나의 그룹으로 묶어 로드밸런서에 등록할 수 있다.

  • EC2 인스턴스 (ASG에 의해 관리될 수 있다.)

  • ECS 태스크

  • 람다 함수

  • 사설(내부) IP 주소

• 여러 대상 그룹으로 라우팅할 수 있으며 헬스 체크는 대상 그룹 단위로 이뤄진다.

• 고정 호스트 이름이 부여된다.

• 실제 요청을 보낸 클라이언트의 IP는 X-Forwarded-For 헤더에 삽입된다. Port는 X-Forwarded-Port, 프로토콜은 X-Forwarded-Proto에 삽입된다.

• 컨테이너와 ECS를 사용해 동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를 분산한다.

• HTTP/2와 WebSocket을 지원한다.

리스너 규칙

• URL 기반 리다이렉트를 지원한다. HTTP에서 HTTPS로 리다이렉트할 수도 있다.

• URL 경로, hostname, query string, header 등을 기준으로 하여 서로 다른 대상 그룹에 라우팅할 수 있다.

  • 마이크로서비스나 컨테이너 기반 애플리케이션을 사용할 경우 URL 경로를 기반으로 처리할 대상 그룹을 지정할 수 있다.

    
• 고정된 HTTP 응답을 반환할 수 있다.

• 리스너 규칙의 우선순위를 지정할 수 있다.

• 포트매핑 기능이 있어 ECS 인스턴스의 동적 포트로 리다이렉트할 수 있다.

보안 그룹

• EC2의 보안 그룹 설정을 로드밸런서의 트래픽만 허용하도록 수정해주어야 한다.

• 로드밸런서의 보안 그룹을 Source로 설정하면 된다.

NLB

• 4계층 TCP/UDP 로드밸런싱을 제공한다.

• 초당 수백만건의 요청을 처리한다.

• 지연이 매우 적다.

• 기본적으로 가용 영역 당 하나의 고정 IP를 AWS로부터 부여받는다. 혹은 각 가용 영역에 Elastic IP를 할당할 수 있다.

• 따라서 일부 IP로만 네트워크 로드밸런서에 접근 가능하게 된다.

대상(target) 그룹

---

• 다음과 같은 리소스들을 하나의 그룹으로 묶어 로드밸런서에 등록할 수 있다.

  • EC2 인스턴스

  • 사설(내부) IP 주소

  • 애플리케이션 로드 밸런서

• 헬스 체크 시 TCP, HTTP, HTTPS 프로토콜을 사용할 수 있다.

GWLB

• 배포 및 확장, AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용된다.

• 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용한다.

• IDPS나 심층 패킷 분석 시스템 또는 일부 페이로드를 네트워크 수준에서 수정하는 기능을 제공할 수 있다.

• 트래픽이 애플리케이션에 도달하기 전에 EC2 인스턴스와 같은 타사 가상 어플라이언스를 배포했고 트래픽의 애플리케이션에 도달 전에 트래픽을 통과하기 위해 사용된다.

• GWLB를 생성하면 VPC에서 라우팅 테이블이 업데이트된다.

• 라우팅 테이블을 기반으로 모든 사용자 트래픽은 GWLB를 통과한다.

• GWLB는 가상 어플라이언스의 대상 그룹 전반으로 트래픽을 확산한다.

• 모든 트래픽은 어플라이언스에 도달하고 어플라이언스는 트래픽을 분석하고 처리한다.

• 이상이 없으면 트래픽을 다시 GWLB로 보내고, 이상이 있으면 트래픽을 드롭한다.

• GWLB는 살펴봤었던 모든 로드 밸런서보다 낮은 수준인 네트워크 3계층에서 수행된다.

• 기능

  • 투명한 네트워크 게이트웨이

    • VCP의 모든 트래픽이 하나의 GWLB를 통과한다.

  • 로드밸런서

    • 대상 그룹의 가상 어플라이언스 집합에 트래픽을 분산한다.

• 6081번 포트의 GENEVE 프로토콜을 사용하면 된다.

대상(target) 그룹

---

• 다음과 같은 리소스들을 하나의 그룹으로 묶어 로드밸런서에 등록할 수 있다.

  • EC2 인스턴스

  • 자체 네트워크나 자체 데이터 센터에서 실행된 가상 어플라이언스의 사설(내부) IP 주소

세션 기능

Sticky Session

• 한 사용자가 여러 번 요청을 보냈을 때 늘 동일한 인스턴스에 요청을 보내도록 하는 기능을 제공한다.

• ALB, NLB에서 동작 가능하다.

• 쿠키에 매핑 정보와 만료 날짜를 담아 Sticky Session 용도로 사용한다.

• 쿠키가 만료되면 다른 인스턴스로 요청이 갈 수 있다.

• 쿠키 유형

  • 애플리케이션 기반 쿠키

    • 애플리케이션 자체에서 생성하는 사용자 정의 쿠키

    • 사용자 정의 속성들을 담을 수 있다.

    • 쿠키 이름을 각 타겟 그룹마다 개별적으로 지정해야 한다.

    • AWSALB, AWSALBAPPOR, AWSALBTG를 쿠키 이름으로 사용하면 안된다.

  • 지속 시간 기반 쿠키

    • 로드밸런서에서 생성하는 쿠키

    • 쿠키 이름은 ALB에서 생성할 경우 AWSALB, CLB에서 생성할 경우 AWSELB가 된다.

    • sticky session 만료 시간을 지정할 수 있다.

Cross-Zone Load Balancing

• 여러 AZ에 로드밸런싱할 경우 로드밸런서 인스턴스가 AZ마다 존재하고, 각 로드밸런서 인스턴스에는 요청이 고르게 들어온다.

• 하나의 로드밸런서 인스턴스가 동일 AZ에 있는 EC2 인스턴스에만 트래픽을 분배하고 각 AZ에 존재하는 인스턴스의 개수가 서로 다르다면, 하나의 EC2 인스턴스 당 받아들이는 요청이 특정 AZ에서 높아질 수 있다.

• 교차 영역 로드밸런싱은 이러한 불균형을 막기 위해 하나의 로드밸런서 인스턴스가 모든 EC2 인스턴스로 트래픽을 균등하게 분배한다.

• 일반적으로 AWS에서 데이터가 다른 AZ로 넘어가면 비용이 발생되는데, 로드밸런서가 다른 AZ로 트래픽을 보내기 때문에 비용이 발생될 수 있다.

• ALB의 경우 기본적으로 이 옵션이 활성화되어 있으며, managed service이기 때문에 데이터가 다른 AZ로 넘어가는 것에 대한 비용은 부과되지 않는다. 대상 그룹마다 활성화/비활성화할 수 있다.

• NLB, GWLB의 경우 이 옵션을 활성화하면 비용이 발생된다.

SSL

• 사용자가 HTTPS를 통해 로드밸런서에 연결하면 로드밸런서는 SSL 종료를 한다.

• 로드밸런서와 EC2 인스턴스가 통신 시에는 VPC(Virtual Private Network)를 통해 전송되므로 HTTP를 이용한다.

• 로드 밸런서는 SSL 혹은 TLS 서버 인증서라 불리는 X.509 인증서를 로딩한다. AWS에서는 ACM(AWS 인증서 매니저)을 활용해 이 SSL 인증서를 관리한다.

• HTTPS 리스너 설정

  • 기본 인증서를 지정해야 한다.

  • 인증서 목록을 추가해 여러 도메인을 지원할 수 있다

  • HTTPS에 특정 보안 정책을 설정해서 SSL과 TLS의 구버전(legacy clients)을 지원할 수도 있다.

• SNI(Server Name Indication)

  • TLS 초기 단계에 접근하려는 호스트 이름(도메인)을 지정하여 있다.

  • 하나의 웹 서버에 여러 SSL 인증서를 로드해 웹 서버가 여러 웹사이트를 지원하게 만든다.

  • 클라이언트가 초기 SSL 핸드셰이크에서 대상 서버의 호스트 이름을 표시해야 하는 새로운 프로토콜이다.

  • 서버는 사용자 요청에 담긴 호스트 이름에 매칭되는 인증서를 찾는다.

  • ALB, NLB, CloudFront 에서만 사용할 수 있다.

Connection Draining (Deregistration Delay)

• 인스턴스가 등록 취소, 혹은 비정상인 상태에 있을 때 인스턴스에 어느 정도의 시간을 주어 in-flight 요청을 완료할 수 있도록 한다.

• 인스턴스가 드레이닝되면 ELB는 등록 취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않는다.

• EC2 인스턴스에 이미 연결된 유저는 드레이닝 시간을 통해 기존 연결 및 기존 요청을 완료할 수 있다.

• 만약 새로운 유저가 ELB에 연결하려고 하면 ELB는 드레이닝 상태의 인스턴스를 제외한 나머지 인스턴스에 요청을 전달한다.

• 1부터 3,600초 사이의 값으로 설정할 수 있다. 기본적으로는 300초(5분)이다. 값을 0으로 설정하면 드레이닝 기능을 비활성화할 수 있다.

• 짧은 요청의 경우에는 낮은 값으로 설정하고, 요청 시간이 긴 경우 높은 값으로 설정한다.

ASG

• Auto Scaling Group

• 부하에 따라 EC2 인스턴스의 개수를 자동으로 늘리고 줄이는 기능을 제공한다. (Scale Out/In)

• ASG 생성 시 스케일링 할 때 변경될 최소 및 최대 EC2 인스턴스 수, 현재 생성할 EC2 인스턴스 수를 지정할 수 있다.

• ASG 단위로 로드 밸런서에 연결할 수 있어 편리하다.

• 특정 인스턴스가 비정상이면 종료하고 새 EC2 인스턴스를 만들어 대체할 수 있다.

• 오토 스케일링 그룹은 무료이며, 그 아래에 생성되는 EC2 인스턴스와 같은 리소스에 대해서만 비용을 내면 된다.

• ELB에서 상태 확인 기능으로 EC2 인스턴스의 상태도 점검하여 ASG에 전달할 수 있다.

• CloudWatch 알람을 기반을 ASG에서 스케일 인, 스케일 아웃을 할 수 있다. 평균 CPU 지표나 원하는 사용자 지정 지표를 기준으로 알람을 설정하면 해당 알람이 발동될 때 스케일링된다.

스케일링 정책

• 동적 스케일링

  • Target Tracking 스케일링

    • 설정이 매우 간단하다.

    • 예를 들면, CPU 사용률이 평균 40% 정도에 머물도록 조건을 정의해 ASG가 자동으로 스케일링되도록 할 수 있다.

  • Simple/Step 스케일링

    • CloudWatch 알람을 정의하여, 알람을 기반으로 오토 스케일링 그룹에 용량 단위를 추가하거나 제거하도록 한다.

• 예약 스케일링

  • 이미 잘 알고 있는 사용 패턴을 기반으로 스케일링을 예상할 수 있을 때 적합하다.

• 예측 스케일링

  • 과거 부하 패턴을 활용해 부하를 예측한 다음 스케일링을 예약하는 방식이다.

  • 주기적이고 반복되는 패턴이 있을 때 적합하다.

  • ASG는 자동으로 과거 부하를 분석한 다음 예측치를 생성하여 예측치를 기반으로 스케일링 작업을 예약한다.

• 스케일링을 위한 메트릭 종류

  • CPU 활용도

    • EC2 인스턴스의 평균 CPU 사용률

  • 타겟 당 요청 수

    • EC2 인스턴스 당 들어오는 요청의 개수

  • 평균 네트워크 In/Out

    • 평균 네트워크 사용량

• 스케일링 쿨다운

  • 스케일링 작업으로 인스턴스가 추가/제거되었을 때 기본적으로 5분동안 쿨다운 시간이 생긴다.

  • 쿨다운 시간 동안 ASG는 추가 인스턴스를 개시하거나 종료하지 않는다.

  • 메트릭이 안정화되도록 하고 새로운 인스턴스가 적용되어 새로운 메트릭이 어떻게 변할지를 지켜보는 시간을 가지는 것이 목적이다.

  • 쿨다운 이후에도 문제가 있는 상황이라면 스케일링 작업을 다시 진행한다.

  • AMI를 사용하여 EC2 인스턴스의 설정 시간을 줄여 인스턴스 추가/제거 작업을 빠르게 처리하면 즉시 스케일링 효과가 나타나므로 좋다.

  • ASG가 1분마다 하위 수준의 메트릭에 액세스할 수 있도록 상세한 모니터링과 같은 기능을 활성화하고, 메트릭이 충분히 빠르게 업데이트되도록 해야 한다.

Instance Refresh

• 인스턴스를 시작하기 위해 설정했던 템플릿이 변경되어 기존 인스턴스들을 이에 맞게 재실행해야 하는 경우, 이 기능을 이용하면 된다.

• 예를 들어 EC2 인스턴스의 기본 AMI를 업데이트 하고 난 후에는 StartInstanceRefresh라는 API를 호출하여 Instance Refresh를 수행할 수 있다.

• minimum healthy percentage를 설정하여 모든 인스턴스가 동시에 내려가는 일이 없도록 한다.

• 기존 인스턴스가 종료되면 새로운 템플릿을 기준으로 인스턴스가 생성된다.

• 점차 기존 시작 템플릿을 가진 인스턴스가 모두 사라지고, 새 인스턴스로 대체된다.

• 새 EC2 인스턴스를 사용할 준비가 될 때까지 대기 시간을 지정할 수 있다.