Computing service
Elastic Load Balancer(ELB)
: 클라이언트의 서비스 요청 트래픽을 여러 서버로 분산시켜주는 AWS 서비스
- 처리방식 : EC2를 Target Group( EC2 인스턴스 묶음 )에 할당 → ELB를 구축하여 Target Group에 연동 → Target Group에서 상태검사( health check )로 정상적인 서버에만 요청전달( 단일 Web Service Endpoint로만 접근 )
- 완전 관리형 서비스(Managed Service) : 트래픽 증가시 EC2를 복사하여 추가적으로 인스턴스 생성( 자동확장 : auto-scaling ) 시스템 업그레이드, 가용성 관리등 수행 ⇒ 운영관리의 부담을 크게 줄여줌( 사용자가 외부적으로 수동으로 LB를 추가하지 않아도 내부에서 더 많은 처리능력 = 노드를 할당하여 동작 )
- 이중화가 자동으로 처리 이중화 : 시스템의 가용성과 신뢰성을 높이기 위해 동일한 기능을 하는 장비나 시스템을 여러 개 준비 → 하나의 서버가 고장나도 다른 하나가 즉시 작동하여 서비스 중단을 방지
// LB가 하나만 있을 경우, 그 LB가 고장나면 전체 서비스 중단
// 이중화된 LB는 하나가 실패해도 다른 LB가 즉시 작동
[사용자]
↓
[LB-1] [LB-2] (Active-Standby 또는 Active-Active)
↓
[서버1] [서버2] [서버3]
[ ELB의 구성요소 ]
- Listener : 클라이언트의 요청을 수신( IP가 부여됨 ) → 요청 검사 및 분배( 적절한 Target Group )
- 하나의 리스너에는 포트와 프로토콜이 정해져있음 = 하나의 포트 + 프로토콜 조합만 처리가능
- 최소 1개 ~ 최대 10개의 리스너를 설정가능
- SSL 인증서지원 → 쉽게 HTTPS 통신연동 가능
- Rule : 우선순위, 조건, 동작 등 요청 검사 및 라우팅 : 특정조건(규칙)에 따라 요청을 적절한 대상으로 라우팅( 서버로의 라우팅은 부하분산 규칙에 의해 결정 )하거나 지정된 동작( action )을 수행
- Target Group : 부하분산 대상 서버의 모임 ( EC2, Lamdba, IP address 등으로 구성 )
- Health Check(상태검사) : 서버 상태 모니터링
[ ELB의 종류 ]
- Application LB : L7에서 동작하는 LB로 HTTP, HTTPS요청을 지원( WebSocket까지 지원 ) ( ↔ TCP, UDP )
- Contents-Based Routing : 내용값( host, URL, header, method, query string 등.. )을 읽어서 내용기반으로 다르게 라우팅 → 서로다른 타켓그룹으로 라우팅 ( ex. /user/*이면 타겟그룹A로 라우팅, /shop/*이면 타켓그룹B로 라우팅 )
- SSL Offload 기능 : 클라이언트로부터의 HTTPS 연결에 사용되는 SSL/TLS 암호화를 LB가 복호화(offload)하여 서버에 평문으로 트래픽을 전달( HTTP로 전달 ) & 응답을 다시 SSL/TLS로 암호화하여 클라이언트로 전달 ⇒ CPU리소스를 많이 사용하는 암복호화를 LB가 처리
- Public IP를 사용(인터넷에서 들어오는 클라이언트의 요청을 처리), 가변적인 IP → DNS Name을 제공 / Elastic IP 사용불가
- Network LB : L4에서 동작하는 LB로 TCP, UDP, TLS 요청을 지원 ( 대용량 트래픽 처리용, 초당 수백만건 ) → ALB보다 좋은 성능
- 리스너당 하나의 타겟그룹에만 라우팅, 서로다른 타켓그룹에게 요청불가 방화벽에 NLB의 고정IP를 등록 → 매칭되는 하나의 타켓그룹을 ALB로 구성하여 세부적인 라우팅을 수행하도록 함
- Elastic IP적용가능 = 고정된 IP주소
- SSL Offload 기능
- Gateway LB : 네트워크 트래픽에 특화된 LB → 심화된 내용( advanced )
- Classic LB : 초기 LB모델 → 단종된 서비스로 사용을 권장하지 않음
Application LB | Network LB | |
리스닝 프로토콜 | HTTP, HTTPS ( L7 ) | TCP, UDP ( L4 ) |
라우팅 방식 | content-based routing : 내용기반으로 서로다른 TG로 라우팅 |
리스너당 매칭된 하나의 TG에 라우팅 |
주요기능 | SSL Offload기능으로 암복호화 | 대용량 트래픽 처리, 타켓그룹에 ALB를 설정 |
고정IP 여부 | 고정 IP( Elastic IP ) 설정 불가 | 고정 IP( Elastic IP ) 설정 가능 |
[ ELB Health check ]
정상응답( status code 200 )을 받은 서버에만 트래픽을 라우팅
ELB 서비스 구성 실습
(1) 보안그룹 생성( lab-edu-sg-alb ) → LB에 적용할 것임
(2) LB Target Group 생성 ( lab-edu-tg-web )
EC2 메인콘솔 → 로드밸런싱-대상그룹 → 대상그룹 생성
- 그룹세부 정보 지정 : 대상유형을 인스턴스(EC2)로 설정, 주소유형 IPv4, 인스턴스가 위치한 VPC를 선택
- 대상등록 : web서버 → 80포트를 이용 → 보류
(3) LB 생성 ( lab-edu-alb-web )
EC2 메인콘솔 → 로드밸런서 → 로드밸런서 생성 → Application LB 유형 선택
- 인터넷 경계, IPv4
- 네트워크 매핑 : VPC설정, 가용영역 설정 로드 밸런서는 두 가용 영역에 Elastic Network Interface(ENI)를 생성 → LB는 두 가용 영역에서 들어오는 트래픽을 처리 ( 다중 가용 영역을 지원 )
보안그룹 : lab-edu-sg-web ( 외부 트래픽 허용 )
bastion에서의 HTTP요청 뿐아니라 VPC의 HTTP요청(80)을 허용
리스너 : http 80 포트로의 요청을 대상 그룹으로 보내도록 함
(4) 접속확인 EC2 메인콘솔 → 로드밸런서 → lab-edu-alb-web DNS 이름 주소 복사
ALB가 퍼블릭 서브넷에 배포, 외부 트래픽을 받아들임(보안그룹지정) → private subnet내 인스턴스에 접근가능
Auto Scaling
: 증가하는 서비스 트래픽에 맞추어 자동으로 서버의 수량 및 스펙을 조절하는 기능
- Scale In & out : 트래픽에 맞추어 서버의 수량을 늘리거나 줄이는 방식
- Scale Up & Down : 트래픽에 맞추어 서버의 스펙( vCPU, Memory )를 향상시키거나 낮추는 방식
[ auto scaling 구성요소 ]
- Auto Scaling group(ASG) : 관리대상 EC2 인스턴스를 논리적으로 모아놓은 집합( TG과 유사함 )
- 최소크기, 최대크기, 희망용량을 설정 → 범위내에서 인스턴스 생성 및 제거
- LB의 특정 Target Group을 ASG에 저장가능
- Launch Template : 새로 생성할 EC2인스턴스의 정보를 설정한 값 모음 → 운영체제( AMI ), instance type( cpu, memory ), storage, SG( 보안그룹 ), key-pair, user data 등
- 수정불가능, 새로운 버전을 생성한뒤에 ASG 설정에서 버전 업데이트로만 변경가능
- Scaling Policies( 스케일링 정책 ) : 인스턴스를 조정하는 기준, 조건을 설정 = auto-scaling이 적용되는 기준 ( Scheduled, Dynamic, Predictive Scaling 방식 )
ex) CPU사용률이 50%가 넘으면 서버를 추가
[ ELB와 auto scaling 연동 ]
- LB에서 상태검사로 수행
ELB에서 이상을 탐지 ( health check를 통해 unhealty 상태를 판단 ) → auto-scaling 트리거 → Template에 맞는 EC2가 생성되어( create ) ASG, Target Group에 등록
** Health Check로 인해 발생하는 EC2 인스턴스 교체는 Scaling Policy 조건과는 무관하게 트리거 - 연동된 CloudWatch로 수행
인스턴스 모니터링 → scaling policy조건 만족하여 CloudWatch알람, auto-scaling 트리거 → Template에 맞는 EC2가 생성되어( create ) ASG, Target Group에 등록
Auto Scaling 서비스 구성 실습
web 서버가 부팅할 때 자동으로 Streamlit 애플리케이션을 80번 포트에서 실행하도록 설정
(1) AMI 생성
데이터 일관성을 위한 인스턴스 재부팅 설정X
(2) 시작템플릿 생성
EC2 메인 콘솔 화면 → 시작 템플릿 리소스 탭 → 시작 템플릿 생성 버튼 클릭
이름 : lab-edu-template-autoscaling-web
저장했던 AMI를 적용
인스턴스 유형: t3.micro, 키 페어: lab-edu-key-ec2, 서브넷: 시작 템플릿에 포함하지 않음, 보안 그룹: 기존보안그룹 lab-edu-sg-web 선택
리소스 태그
IAM 인스턴스 프로파일 부여
호스트는 IP이름 & DNS 요청을 활성화
(3) ASG 생성
이름(lab-edu-asg-web)과 시작템플릿을 지정
인스턴스 시작 옵션 선택 : VPC 및 서브넷 네트워크를 지정
다른서비스와 통합 : 로드 밸런싱 → 기존 로드밸런서와 연결, 기존 로드밸런서의 대상그룹 ( lab-edu-tg-web )에 연결
1 ~ 4개의 사이에서 생성
조정정책( 조건 )
시작템플릿의 태그값 Name : lab-edu-asg-web을 동일하게 추가 → ASG에서 생성되는 모든 인스턴스에 태그가 적용되도록 함
로드밸런스 DNS로 접속시 → ASG의 EC2로 접속
push button으로 pu 사용량이 나오는데 100%로 맞춘 후 → stress tool로 부하발생
부하에 따라 Launching a new EC2
인스턴스 관리에서 신규로 생성된 EC2 확인 가능
부하에 따라 새로 생성하거나 → 부하율이 낮아지면 다시 삭제됨