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 프로토콜을 사용할 수 있다.

  • 인스턴스 ID를 이용하여 대상을 명시하면, 인스턴스의 기본 네트워크 인터페이스에 명시된 기본 사설 IP 주소를 이용하여 트래픽을 라우팅한다.

  • IP 주소를 이용하여 대상을 명시하면 하나 이상의 네트워크 인터페이스에서 온 사설 IP 주소를 이용해서 인스턴스로 트래픽을 라우팅할 수 있다. 각 네트워크 인터페이스는 각자의 보안 그룹을 가질 수 있다. 로드 밸런서는 데이터 패킷의 출발지/목적지 IP 주소를 자신의 것으로 바꾼 후 타깃 인스턴스 혹은 사용자에게 전달한다.

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을 활용해 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 인스턴스를 사용할 준비가 될 때까지 대기 시간을 지정할 수 있다.

Last updated