DevOps Day 31 (4.18) AWS_수평확장

수평확장

Auto Scaling Group
Auto Scaling은 미리 정해 놓은 규칙에 따라 워크로드(작업량)를 자동으로 확대 또는 축소할 수 있는 기술로 클라우드가 제공하는 탄력성에 의해 만들어지고, 사용자의 요구 수준을 반영할 수 있는 기술입니다.

프로비전(provision) 필요한 컴퓨팅 리소스들을 필요한 곳에 배치, 유휴 자원들을 다시 회수하는 일련의 작업들을 의미

 

Auto Scaling의 장점 :
- 동적 스케일링 : Auto Scaling의 가장 큰 장점은 사용자의 요구 수준에 따라 리소스를 동적으로 스케일링 할 수 있다는 점입니다. 서버의 수에는 제한이 없음
- 로드 밸런싱 : Auto Scaling은 리소스를 동적으로 스케일업 혹은 스케일다운 합니다. 로드밸런서와 함께 사용하면, 다수의 EC2 인스턴스에게 워크로드를 효과적으로 분배할 수 있습니다
- 타겟 트래킹 : 사용자는 특정 타겟에 대해서만 Auto Scaling을 할 수 있으며, 사용자가 설정한 타겟에 맞춰 EC2 인스턴스의 수를 조정합니다.
- 헬스 체크와 서버 플릿 관리 : Auto Scaling을 이용하면 EC2 인스턴스의 헬스 체크 상태를 모니터링 할 수 있습니다.

EC2 서버에서 애플리케이션을 많이 호스팅 할 경우 서버 플릿(fleet)이라 부릅니다.

 

EC2 Auto Scaling 활용
Auto Scaling은 EC2 인스턴스 뿐만 아니라 다른 인스턴스와도 결합 가능하지만, EC2 사용자에게 가장 인기가 많은 서비스 입니다.

 

시작 템플릿 (Launch configuration)
확장 또는 축소 결정은 템플릿을 통해서 가능하며, AMI 상세 정보, 인스턴스 타입, 키 페어, 시큐리티 그룹 등 인스턴스에 대한 모든 정보를 담고 있습니다.

 

Auto Scaling 그룹 생성
Auto Scaling 그룹은 스케일업 및 스케일 다운 규칙의 모음으로 EC2 인스턴스 시작부터 삭제까지의 모든 동작에 대한 규칙과 정책을 담고 있습니다.

 

Scaling 유형

인스턴스 레벨 유지 : 기본 스케일링 계획으로도 부르며, 항상 실행 상태를 유지하고자 하는 인스턴스의 수를 지정할 수 있습니다. 최소, 최대 및 원하는 용량은 동일한 값을 설정 가능합니다.

 

수동 스케일링 : Auto Scaling 그룹의 크기를 수동으로 변경할 수 있으며 수동 선택시 사용자가 직접 콘솔이나, API, CLI 등을 이용해 수동으로 인스턴스를 추가 또는 삭제 해야 합니다.

 

예측 스케일링 : 트래픽의 변화를 예측할 수 있고, 특정 시간대에 어느 정도의 트래픽이 증가하는지 패턴을 파악하고 있다면 일정별 스케일링을 사용하는 것이 좋습니다.

 

동적 스케일링 : 수요 변화에 대응하여 Auto Scaling 그룹의 용량을 조정하는 방법을 정의합니다. 이 방식은 CloudWatch가 모니터링 하는 지표를 추적하여 경보 상태일 때 수행할 스케일링 규칙을 정합니다.

 

스케일링 정책을 지원하는 EC2 Auto Scaling
- 타겟 트랙킹 스케일링 : 미리 정의된 성능 지표를 이용하거나, 커스텀 성능지표(custom metric)을 사용하여 타겟 값으로 설정할 수 있습니다.
- 단순 스케일링 : 단 하나의 스케일링 설정에 따라 그룹의 현재 용량을 늘리거나 줄입니다.
- 단계 스케일링 : 단순 스케일링은 특정 이벤트에 대해 매번 같은 액션을 한다면, 단계 스케일링은 좀 더 세분화 해서 단계를 나누어 규칙을 추가할 수 있습니다.

 

인스턴스 삭제 정책
스케일다운 정책이 적용되면, EC2 인스턴스가 삭제되며, 서버를 셧다운 하는 것은 리소스 관리 측면에서도 꼭 필요한 일입니다. 명확하게 몇 개의 인스턴스를 삭제할 것인지, 어떤 인스턴스를 먼저 셧다운 할 것인지 환경 설정을 통해 결정 할 수 있습니다.

 

대표적인 인스턴스 삭제 정책
- 사용자의 서버 플릿에서 가장 오랫동안 실행된 서버를 삭제합니다. 가장 오랫동안 실행된 서버일수록 패치 수준이 낮고 메모리 누수 등의 문제가 누적해 있을 가능성이 크기 때문에 이를 삭제함으로써 최신의 성능 기준을 유지할 수 있다는 장점이 있습니다.

- 시간 단위 과금이 임박한 서버를 삭제합니다. 이 서버를 삭제하면 Auto Scaling의 특유 장점을 최대한 살려, 과금 부담을 줄일 수 있습니다.

 

Elastic Load Balancing
서비스 규모가 커지면 물리/가상 서버 한 대로는 모든 서비스를 수용할 수 없게 됩니다. 서버 한 대로 서비스를 제공 가능하지만 서버의 애플리케이션, 운영체제, 하드웨어에 장애가 발생했을 때 정상적인 서비스를 제공할 수 없습니다. 서비스 가용성을 높이기 위해 하나의 서비스는 보통 두 대의 이상의 서버로 구성하고 각 서버는 IP 주소가 달라 서비스를 호출할 때 혼란이 있을 수 있어 로드 밸런서를 사용합니다. 로드 밸런서에는 동일한 서비스를 하는 다수의 서버가 등록되고 사용자로부터 서비스 요청이 오면 로드 밸런서가 받아 사용자별로 다수의 서버에 서비스 요청을 분산시켜 부하를 분산합니다.

 

ELB?
Elastic Load Balancing은 둘 이상의 가용 영역에서 EC2 인스턴스, 컨테이너, IP주소 등 여러 대상에 걸쳐 수신되는 트래픽을 자동으로 분산합니다.

 

ELB의 장점 :
- 고가용성 : ELB는 다수의 EC2 인스턴스, 컨테이너 등에 트래픽을 분산 시키며 다수의 AZ에 배포된 EC2 인스턴스에 애플리케이션을 배포해 트래픽을 여러 AZ로 분산 시킬 수 있습니다. AZ가 다운 돼도 애플리케이션은 문제 없이 실행 가능합니다.

- 탄력성 : ELB의 최대 장점은 자동적 확장성 입니다. 관리자는 인스턴스 추가 또는 삭제를 위한 어떤 수작업도 할 필요가 없으며, 수동으로 뭔가를 할 여지도 없습니다.

- 안전성 : 통합 인증관리, SSL 복호화, 포트 포워딩 등 다수의 보안 기능을 제공합니다. 현대 웹사이트 운영자는 웹 애플리케이션 레벨에도 암호화 기법을 적용하며, 다수의 보안 정책을 제공합니다.

- 높은 처리량 : ELB는 트래픽 증가를 처리할 수 있도록 설계되었으며 초당 수백만 개의 요청을 로드 밸런싱할 수 있습니다. 또한, 갑작스럽고 변동이 심한 트래픽 패턴도 처리할 수 있습니다.

 

작동 방식
로드 밸런서는 클라이언트에 대한 단일 접점으로, 클라이언트에서 오는 트래픽을 허용하고, 하나 이상의 가용 영역에서 등록된 대상(EC2 인스턴스)으로 요청을 라우팅합니다. 또한 로드 밸런서는 등록된 타겟의 상태를 모니터링하고 정상 타겟으로만 트래픽이 라우팅 되도록 합니다.

리스너는 구성한 프로토콜 및 포트를 사용하여 클라이언트의 연결 요청을 확인합니다. 각 규칙은 우선 순위, 하나 이상의 작업, 하나 이상의 조건으로 구성됩니다.

각 타겟 그룹은 지정한 프로토콜과 포트 번호를 사용하여 EC2 인스턴스 같은 하나 이상의 등록된 타겟으로 요청을 라우팅합니다.

ELB의 다양한 유형
Application Load Balancer : OSI 모델의 레이어 7에 해당하며, HTTP와 HTTPS를 지원합니다. 로드 밸런서는 요청을 받으면 우선 순위에 따라 리스너 규칙을 평가하여, 적용할 규칙을 결정한 다음 규칙 작업의 타겟 그룹에서 타겟을 선택합니다.

 

Network Load Balancer : Network Load Balancer는 TCP 로드 밸런서라고 부르며, OSI 모델의 레이어 4에서 작동합니다. 로드 밸런서가 연결 요청을 받으면 기본 규칙의 타겟 그룹에서 대상을 선택합니다.
TCP 트래픽의 경우, 로드 밸런서는 프로토콜, 원본 IP 주소, 원본 포트, 타겟 IP 주소, 타겟 포트, TCP 시퀀스 번호에 따라 흐름 해시 알고리즘을 사용하여 타겟을 선택합니다.
UDP 트래픽의 경우, 로드 밸런서는 프로토콜, 원본 IP 주소, 원본 포트, 타겟 IP 주소, 타겟 포트에 따라 흐름 해시 알고리즘을 사용하여 타겟을 선택합니다.

 

다중 AZ의 활용
Auto Scaling과 ELB를 활용해 애플리케이션을 구현할 때는 가능한 다중 AZ를 기반으로 할 것을 권장합니다. 왜냐하면 AZ가 고가용성을 구현하기 위한 기본 구조이기 때문입니다.
- 다중 AZ의 문제점은 무엇이고 어떻게 해결?
  - Cross Zone Load Balancing : 교차 영역 로드 밸런싱을 이용하면 각 로드 밸런서 인스턴스는 전체 가용 영역에 등록된 모든 인스턴스에 전반적으로 고르게 분산 된다.

  - Sticky Session : Sticky Session이란 특정 세션의 요청을 처음 처리한 서버로만 전송하는 것을 의미합니다. 요청 이후의 모든 요청을 특성 서버로 고정하는 방법으로 세션을 관리합니다. 일반적으로 Sticky Session을 유지하기 위해 Cookie를 사용하거나 클라이언트의 IP tracking하는 방식이 있습니다.