고가용성과 스케일링

고가용성

• 고가용성은 애플리케이션 또는 시스템을 적어도 둘 이상의 AZ나 데이터센터에서 가동하는 것이다.
• 고가용성은 데이터센터에서의 손실에서 살아남아야 한다.
  즉, 가동중인 데이터센터에 문제가 생겨도 다른 데이터센터에서 정상적으로 돌아가야 한다.
• 동일한 애플리케이션의 동일한 인스턴스를 멀티AZ에서 가동해야 한다.
• 멀티AZ가 활성화된 오토 스케일링 그룹이나 로드밸런서에서도 사용한다.
• 고가용성은 수동적일 수도 있다(ex. RDS Multi AZ)
• 활성형도 존재한다.(수평 확장의 경우)

확장성

수직 확장성

• 수직 확장성은 인스턴스의 스펙을 확장한다. 시스템의 스펙을 향상시키는 것이다.
• 데이터베이스와 같이 분산되지 않은 시스템에서 주로 사용한다.
• 하드웨어 제한이 걸려있기 때문에 한계가 존재한다.

수평 확장성

• 수평 확장성은 애플리케이션에서 인스턴스의 수를 늘리는 방법이다.
• 현대 애플리케이션은 대부분 분배 시스템이므로 해당 방식이 적절하다.
• 요즘은 클라우드 제공 업체 덕분에 수평적으로 확장이 수월하다.

ELB(Elastic Load Balanceer)

Load Balancing

• 로드밸런서는 다수의 서버에게 트래픽을 전달하는 서버이다.
• 사용자는 로드밸런서를 사용하므로 어떤 서버를 사용하고 있는지 구체적인 동작은 모른다.

Load Balaner

• 로드밸런서는 부하를 다수의 다운 스트림 인스턴스로 분산하기 위해서 사용한다.
• 애플리케이션에 단일 액세스 지점(DNS)를 노출하고 다운 스트림 인스턴스의 장애를 원활하게 처리할 수 있다.
• 헬스 체크 메커니즘을 사용해 인스턴스의 상태를 확인하고 요청을 보낸다.
• SSL 종료도 가능하므로 HTTPS 트래픽을 받을 수 있다.
• 쿠키로 고정도를 강화할 수 있고 영역에 걸친 고가용성을 가지며 클라우드 내에서 개인 트래픽과 공공 트래픽을 분리할 수 있다.

ELB 소개

• ELB는 관리형 로드 밸런서다. AWS가 관리하는 서비스이며 어떤 경우에도 작동할 것을 보장한다.
• AWS가 업그레이드와 유지 관리 및 고가용성을 책임지며 로드 밸런서의 작동 방식을 수정할 수 있게 일부 구성 knobs도 제공한다.
• 자체 로드밸런서를 만드는 것보다 저렴하고 확장성 측면에서 유리하다.
• 로드밸런서는 다수의 aws 서비스랑 묶이는 EC2인스턴스, 스케일링 그룹, 아마존 EC2와 인증서 관리(ACM), 클라우드 워치, Rout53, AWS WAF, AWS Global Accelerator 등
• 헬스 체크는 ELB가 EC2에 동작이 올바르게 작동하고 있는지를 확인한다.

관리형 로드 밸런서 종류

로드밸런서 보안

• 유저는 http, https를 사용해 어디서든 로드밸런서에 접근이 가능하다.
• 로드밸런서도 보안그룹 규칙 적용 가능하다.
• 로드밸런서를 사용하는 이상적인 EC2의 인스턴스 보안은 오직 로드밸런서와 연결하는 것이다.
• 즉 EC2 인스턴스의 보안 그룹을 로드밸런서의 보안 그룹으로 연결하면 된다.
• 그러면 EC2 인스턴스는 로드밸런서에서 온 트래픽만을 허용한다.
• 로드밸런서의 다양한 리스너 규칙을 정의할 수 있다.
  • 리다이렉트, path에 따른 응답 코드 정의

1. CLB(클래식 로드밸런서)

• CLB는 현재 거의 사용하지 않기에 생략한다.

2. ALB(애플리케이션 로드밸런서)

• HTTP, HTTPS, WEBSOCKET에 특화되어있다.
• OSI 7계층(응용)에서 동작한다. 즉 HTTP 전용 로드밸런서다.
• 로드밸런서의 라우팅 타겟 머신들은 타겟 그룹이라는 그룹으로 묶인다.
• 리스너 규칙을 정할 수 있다.
  • PATH를 지정하면 라우팅을 지원한다.
  • URL의 호스트 이름에 기반한 라우팅을 지원한다.
  • 쿼리 문자열과 헤더에 기반한 라우팅을 지원한다.
• 컨테이너 기반 애플리케이션에 가장 좋은 로드밸런서이다.
• 포트 매핑 기능이 있어 ECS 인스턴스의 동적 포트로의 리다이렉션을 가능하게 해준다.

2-1 ALB의 Target Group

• EC2 인스턴스, ECS, 람다가 타겟 그룹이 될 수 있다.
• 타겟 그룹들은 오토스케일링 그룹에 의해 관리될 수 있다.
• ALB는 IP주소들의 앞에도 위치할 수 있다. 하지만 이때 꼭 사설IP주소여야 한다.
• ALB는 여러 타겟 그룹으로 라우팅할 수 있으며 상태 확인은 타겟 그룹 레벨에서 이뤄진다.
• 온프레미스 환경과 클라우드를 섞어서도 ALB를 사용할 수 있다. 해당 경우에어 쿼리 문자열이나 매개변수 라우팅을 사용하면 된다.
• ALB를 사용하는 경우에도 CLB와 마찬가지로 고정 호스트 네임이 부여된다.
• 애플리케이션 서버는 클라이언트의 IP를 직접 보지 못하며 클라이언트의 실제 IP는 X-Forwarded-For라고 불리는 헤더에 삽입된다. X-Forwarded-Port를 사용하는 포트와 X-Forwarded-Proto에 의해 사용되는 프로토콜도 얻게된다.

3. NLB(네트워크 로드밸런서)

• TCP, TLS, Secure TCP, UDP에 특화되어있다.
• L4 로드 밸런서이기에 TCP, UDP 트래픽을 다룰 수 있다.
• 성능이 매우 뛰어나며 초당 수백만건의 요청을 처리 할 수 있다.
• ALB보다 지연시간도 짧다. ALB는 400ms, NLB는 100ms
• NLB의 특징은 가용 영역별로 하나의 고정 IP를 갖게 된다.
• 탄력적 IP 주소를 각 AZ에 할당 할 수 있다.
• 여러개의 고정 IP를 가진 애플리케이션을 노출할 때 유용하다. 탄력적 IP 사용 가능하다.
• 1~3개의 IP로만 액세스할 수 있는 애플리케이션을 설계하라는 문제는 NLB 고려!, TCP, UDP, 정적IP가 있어도 NLB 고려

3-1 NLB의 Target Group

• EC2 인스턴스들이 타겟 그룹이 될 수 있다.
• NLB가 TCP, UDP 트래픽을 EC2 인스턴스로 리다이렉트할 수 있다.
• IP 주소를 등록할 수 있는데 IP주소는 반드시 하드코딩 되어야하며 private IP만 가능하다.
  • 자체 데이터 센터의 private IP도 사용할 수 있다.
• 온프레미스, 클라우드 둘 다 같은 네트워크 밸런서를 앞단에 두고 사용할 수 있다.
• ALB 앞에 NLB를 사용할 수 있다.
• NLB 덕분에 고정 IP 주소를 얻을 수 있고 ALB를 이용해 HTTP 유형의 트래픽을 처리하는 규칙을 정의할 수 있다
• 네트워크 로드 밸런서 타겟 그룹이 수행하는 상태 확인이 중요하다.

4. GWLB(게이트웨이 로드밸런서)

• 6081 포트의 GENEVE 프로토콜을 사용한다.
• 다른 로드밸런서보다 낮은 수준에서 실행된다. 3계층에서 실행된다.
• IP 패킷의 네트워크 계층의 L3에서 동작한다.
• GWLB는 배포 및 확장과 AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용된다.
• GWLB는 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용한다.
  • 그래서 IDPS나 심층 패킷 분석 시스템 또는 일부 페이로드를 수정할 수 있지만 네트워크 수준에서 가능하다.
• GWLB의 동작과정
  1. GWLB를 생성하면 VPC 내부에서 라우팅 테이블이 업데이트 된다.
  2. 라우팅 테이블이 수정되면, 먼저 모든 사용자 트래픽은 GWLB를 통과한다.
     그리고 GWLB는 가상 어플라이언스의 대상 그룹 전반으로 트래픽을 확산한다.
     그래서 모든 트래픽은 어플라이언스에 도달하고 어플라이언스는 트래픽을 분석하고 처리한다(방화벽, 침입탐지)
  3. 이상이 없으면 다시 GWLB로 보내고 이상이 있으면 트래픽을 드롭한다.
  4. GWLB를 통과하면 GWLB에서는 트래픽을 애플리케이션으로 보낸다.
     모든 트래픽이 GWLB를 통과해 타사 가상 어플라이언스를 통과해 애플리케이션으로 보내진다.
• GWLB 기능은 네트워크 트래픽을 분석하여 애플리케이션으로 진입시킬지 확인한다.

4-1 GWLB의 Target Group

• 타사 어플라이언스가 있다.
• EC2 인스턴스일 수도 있고 인스턴스 id로 등록하거나 ip 주소일 수도 있다. 이 경우는 private IP여야 한다
  • 자체 네트워크나 자체 데이터 센터에서 이런 가상 어플라이언스를 실행하면 IP로 수동 등록할 수 있다.

ELB Sticky Session

• 고정 세션을 실행하는 것으로 로드 밸런서에 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것이다.
• 첫번째 클라이언트가 특정 인스턴스에 첫 요청을 보내면 두 번째 요청도 동일한 인스턴스로 이동해야 한다.
• 타겟 그룹에서 설정이 가능하다.
• 보통 고정 세션은 사용자의 로그인과 같은 중요한 정보를 취하는 세션 데이터를 잃지 않기 위해 사용자가 동일한 백엔드 인스턴스에 연결하기 위해 사용한다.
  • 그러나 고정성을 활용하면 백엔드 ec2 인스턴스 부하에 불균형을 초래할 수 있다. 일부 인스턴스가 고정 사용자를 갖게 되기 때문이다.
• 고정 세션에는 애플리케이션 기반의 쿠키와, 기간 기반의 쿠키 2가지 유형이 있다.

애플리케이션 기반 쿠키

애플리케이션 기반의 쿠키는 애플리케이션에서 기간을 지정.

• 커스텀 쿠키
  • 애플리케이션 기반의 쿠키는 대상으로 생성된 사용자 정의 쿠키로 애플리케이션에서 생성된다.
  • 애플리케이션에 필요한 모든 사용자 정의 속상을 포함할 수 있다
  • 쿠키 이름은 각 대상 그룹별로 개별적으로 지정하는데, 다음과 같은 이름은 사용하면 안된다.
  • AWSALB, AWSALBAPP, AWSALBTG는 ELB에서 사용하기 때문이다.
• 애플리케이션 쿠키
  • 애플리케이션 쿠키가 될 수도 있는데 지금은 로드밸런서 자체에서 생성된다.
  • ALB의 쿠키 이름은 AWSALBAPP.

기간 기반 쿠키

• 로드 밸런서에서 생성되는 쿠키로 ALB에서는 AWSALB이다 CLB는 AWELB
• 특정 기간을 기반으로 만료되며 그 기간이 로드 밸런서 자체에서 생성된다.

ELB Cross Zone 로드밸런싱

• 교차 영역 로드밸런싱을 쓰면, 각각 로드 밸런서 인스턴스가 모든 가용 영역에 등록된 모든 인스턴스에 부하를 고르게 분배한다.
• ALB는 교차 영역 로드밸런성이 기본으로 활성화되어 있다. 데이터를 다른 가용 영역으로 옮기는데 비용이 들지 않는다.
• NLB와 GWLB는 기본으로 교차 영역 로드 밸런싱이 비활성화되어 있다. 따라서 활성화하면 비용을 내야한다.

ELB SSL TLS

• SSL 인증서는 클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화 해준다. 이를 전송중(in-flight) 암호화라고 한다.
• 데이터는 네트워크를 이동하는 동안 암호화되고, 송신자와 수신자측에서만 이를 복호화할 수 있다.
• 퍼블릭 SSL 인증서를 로드밸런서에 추가하면, 클라이언트와 로드 밸런서 사이의 연결을 암호화할 수 있다.
  • 로드 밸런서는 X.509 인증서를 사용하는데, 이걸 SSL 또는 TLS 서버 인증서라고 부른다
  • AWS에는 이 인증서들을 관리할 수 있는 ACM이란게 있다. AWS 인증서 관리자의 역할이다.
  • 우리가 가진 인증서를 ACM에 업로드하여 사용할 수도 있다.
• HTTP 리스너를 구성할 때 반드시 HTTPS 리스너로 해야 한다.
• 기본 인증서를 지정해줘야 한다.
• 다중 도메인을 지원하기 위해 다른 인증서를 추가할 수 있다. 도메인별로 인증서를 사용할 수 있기 때문이다.
• 클라이언트는 SNI(서버 이름 지정)라는 걸 써서 접속할 호스트의 이름을 알릴 수 있다.
  • 이렇게 SNI, 즉 서버 이름 지정을 써서 여러 개의 대상 그룹과 웹사이트를 지원할 수 있습니다, 다중 SSL 인증서를 사용해서요
• 우리가 원하는 대로 보안 정책을 지정할 수 있다. 구 버전의 SSL과 TLS, 즉 레거시 클라이언트를 지원할 수도 있다.
  

SNI

• Server Name Indication의 약어다.
• 여러개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹사이트를 지원할 수 있게 해준다.
• 이것은 확장된 프로토콜로 최초 SSL 핸드세이크 단계에서 클라이언트가 대상 서버의 호스트 이름을 지정하도록 한다.
• 그러면 클라이언트가 접속할 웹사이트를 말했을 때, ALB는 어떤 인증서를 로드해야 하는지 알 수 있다.
• 이건 새롭게 확장된 프로토콜로 모든 클라이언트가 지원하지 않는다.
• 이 프로토콜은 ALB와 NLB 그리고 cloudFront에서만 동작한다.
• 어떤 로드밸런서에 SSL 인증서가 여러개 있다면 ALB나 NLB 둘중 하나다.

연결 드레이닝 (Connection Draining)

• CLB를 사용하면 연결 드레이닝이라고 부르고 ALB, NLB를 쓰면 등록 취소 지연이라고 부른다.
• 인스턴스가 등록 취소, 혹은 비정상인 상태에 있을 때 인스턴스에 어느 정도의 시간을 준다. 이를 드레이닝이라고 부른다.
• 즉 인스턴스가 드레이닝 되면 ELB는 등록 취소 중인 Ec2 인스턴스로 새로운 요청을 보내지 않는다.
• 연결 드레이닝 파라미터는 매개변수로 표시할 수 있다. 1부터 36000초 사이의 값을 설정 가능하다. 기본은 5분이다.
  • 이 값을 0으로 설정하면 전부 다 비활성화한다는 값이 0 이면 드레이닝도 일어나지 않는다
  • 짧은 요청의 경우에는 낮은 값으로 설정하면 좋다.
  • 예를 들어 1초보다 적은 아주 짧은 요청인 경우에는 연결드레이닝 파라미터를 30초 정도로 설정하면 된다.
  • 그래야 EC2 인스턴스가 빠르게 드레이닝될 테고 그 후의 오프라인 상태가 되어 교체 등의 작업을 할 수 있다.
  • 요청 시간이 매우 긴 업로드 또는 오래 지속되는 요청 등의 경우에는 어느 정도 높은 값으로 설정하면 된다.
  • 그러면 EC2 인스턴스가 바로 사라지지 않음
  • 연결 드레이닝 과정이 완료되기를 기다려야 한다.

ASG(오토 스케일링 그룹)

• ASG의 목표는 스케일 아웃, 즉 증가한 로드에 맞춰 EC2 인스턴스를 추가하거나 감소한 로드에 맞춰 EC2 인스턴스를 제거한다.
• ASG에서 실행되는 EC2 인스턴스의 최소 및 최대 개수를 보장하기 위해 매개변수를 전반적으로 정의할 수 있다.
• 로드밸런서와 페어링하는 경우 ASG에 속한 모든 EC2 인스턴스가 로드 밸런서에 연결된다.
• 한 인스턴스가 비정상이면 종료하고 이를 대체할 새 EC2 인스턴스르 생성할 수 있다.
• ASG는 무료이며 EC2 인스턴스와 같은, 생성된 하위 리소스에 대한 비용만 내면 된다.
• cloudwatch 경보를 기반으로 ASG를 스케일인, 스케일 아웃할 수 있다.
• 클라우드 워치에서 경보가 울리면 스케일 아웃이 발생한다. 경보에 의해 내부에서 자동으로 스케일링이 이루어질 수 있다.
• 경보를 기반으로 정책을 만들면 좋다.
  

오토 스케일링 그룹 조정 정책

동적 스케일링 정책

대상 추적 스케일링

• 가장 단순하고 쉽다.
• 모든 Ec2 인스턴스에서 오토 스케일링 그룹의 평균 cpu 사용률을 추적해 이 수치가 40%대에 머무를 수 있도록 할 때에 사용한다.
• 이처럼 기본 기준선을 세우고 상시 가용이 가능하도록 한다.

단순/단계 스케일링

• cloud watch 경보를 설정하고 전체 ASG에 대한 CPU 사용률이 70%를 초과하는 경우 용량을 두 유닛 추가하도록 설정할 수 있다.
• 그리고 ASG의 CPU 사용률이 30% 이하로 떨어지면 유닛 하나를 제거한다는 설정도 추가할 수 있다.
• 대신 클라우드 워치 경보를 설정할 때 제거하고 추가할 유닛의 수를 단계별로 정의해야 한다.

예약된 작업

• 나와 있는 사용 패턴을 바탕으로 스케일링을 예상한다.
• 예시로 금요일 오후 5시에 큰 이벤트가 있으니 대비해서 ASG 최소 용량을 매주 금요일 오후 5시마다 자동으로 10개로 늘리는 것이다.

예측 스케일링 정책

• 예측 스케일링을 통해서 aws 내 오토 스케일링 서비스를 활용하여 지속적으로 예측을 생성할 수 있다
• 기존 로드를 보고서 다음 스케일링을 예측하는 것이다.
• 시간에 걸쳐 과거를 분석하고 예측을 생성한다.
• 그리고 이 예측을 기반으로 스케일링 작업을 예방한다.
• 머신러닝 기반

스케일링 기반이 되는 지표

• CPU 사용률
• 대상별 요청의 수 (참고로 EC2 인스턴스는 한번에 대상별로 1000개의 요청을 최적으로 작동)
• 평균 네트워크 I/O: 평균 네트워크 입출력량을 기반으로 스케일링을 수행
  커스텀 메트릭

Scaling Cooldowns (스케일링 휴지)

• 스케일링 작업이 끝날 때마다 인스턴스의 추가 또는 삭제를 막론하고 기본적으로 5분 혹은 300초의 휴지 기간을 갖는 것이 스케일링 휴지다.
• 휴지 기간에는 ASG가 추가 인스턴스를 실행 또는 종료할 수 없다.
  이는 지표를 이용해 새로운 인스턴스가 안정화될 수 있도록 하며 어떤 새로운 지표의 양상을 살펴보기 위함이다.
• 따라서 스케일링 작업이 발생할 때에 기본으로 설정된 휴지가 있는지 확인해야 한다.
• 그럴 경우는 작업을 무시하고 아닐 경우에는 인스턴스를 실행 또는 종료하는 스케일링 작업을 수행한다.
• 즉시 사용이 가능한 AMI를 이용해 EC2 인스턴스 구성 시간을 단축하고 이를 통해 요청을 좀 더 신속히 처리하는 것이 좋다.
  • EC2 인스턴스 구성에 할애되는 시간이 적으면 즉시 적용이 가능할테니 말이다
  • 이렇게 활성화 시간이 빨라지면 휴지 기간이 짧아지므로 ASG에서 더 많은 동적 스케일링이 가능해진다.
• 또한 ASG가 일 분마다 지표에 접근할 수 있도록 세부 모니터링 기능등을 사용하도록 설정하고 이와 같은 지표를 신속히 업데이트할 필요가 있다.

참고 자료
https://adityagoel123.medium.com/deep-dive-into-aws-for-developers-part2-2b9e8baf3373