Notice
Recent Posts
Recent Comments
Link
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Tags
more
Archives
Today
Total
관리 메뉴

클라우드 엔지니어 꿈나무

loadbalancer(gateway/+ 쿠키(stickness) 본문

AWS

loadbalancer(gateway/+ 쿠키(stickness)

새싹싹이 2024. 1. 22. 11:47

로드밸런서

 

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

모든 트래픽이 방화벽을 통과하게 되거나 침입 탐지 및 방지 시스템에 사용 -> IDPS나 심층 패킷 분석 시스템 또는 일부 페이로드 수정 가능 (네트워크 수준에서 가능)

네트워크 트래픽 분석

L3 (IP 패킷 네트워크 계층)

1. 투명 게이트웨이 : 단일 엔트리와 출구 통과 

2. 로드 밸런서

6081 포트 사용

 

쿠키 종류 (로드 밸런서 생성 시, 설정 가능)

1. 어플리케이션 쿠키

2. 기간 쿠키

ELB가 선점하고 있는 쿠키 이름 : AWSALB, AWSALBAPP, AWSALBTG (이 외에 것으로 쿠키 이름 지정 가능)

 

 

Cross-Zone Load Balancer (교차 영역 로드 밸런서) 

각각의 로드 밸런서가 모든 영역에 있는 로드 밸런서의 인스턴스에 접근 가능 

인스턴스 각각에 고르게 분포 (cf. 10프로씩 인스턴스에 분포 / 로드밸런스에 있는 인스턴스 개수가 달라도 그대로 10프로임)  AZ에 있는 등록된 EC2 인스턴스 전체에 동등하게 분배

교차 영역 로드밸런서가 아니라면 인스턴스 별로 트래픽 할당량이 다름

어플리케이션 로드 밸런서 :  기본적으로 교차 영역 로드 배런서 - 교차 영역 비용 X

네트워크 로드 밸런서, 게이트웨이 로드 밸런서 : 교차 영역 로드 밸런서 defualt X, 가용 영역 데이터 교차 하면 비용 부과 O

클래식 로드 밸런서 : 교차 영역 로드 밸런서 defualt X, 가용 영역 데이터 교차 하면 비용 부과 X

 

SSL/TLS 인증

SSL

SSL 클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화 해줌 - 전송 중 암호화 (in-flight 암호화)

보안 소켓 계층

TLS  새로운 형식의 SSL 전송계층보안 (요새 더 많이 사용) 

HTTP 리스너를 구성할 때 반드시 HTTPS 리스너로 해야함/ 기본 인증서 추가

SNI(Server Name Indication) : 여러 개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹 사이트에 지원할 수 있게 해줌( 하나의 리스너로 다수의 SSL 인증서를 가져올 수 있도록 해줌 )/ ALB, NLB, Cloudfront에만 사용 가능

Classic Load Balancer : SSL 지원, but SSL 인증서 하나만 둘 수 있음

ALB : 여러 개의 SSL 인증서를 두고 리스너를 여러개 지원할 수 O => 여기에 SNI 사용 / TCP 지원 X

NLB  : 여러 개의 SSL 인증서를 두고 리스너를 여러개 지원할 수 O => 여기에 SNI 사용 / 애플리케이션이 필요로 할 경우 가장 높은 성능과 가장 낮은 지연 시간을 제공

 

연결 드레이닝 (Connection Draining) = 등록 취소 지연 (요청 시간 조절 / 임계값)

인스턴스가 등록 취소 혹은 비정상적인 상태에 있을 대 인스턴스에 어느 정도 시간을 주어 인프라이트 요청 (=활성 요청을 완료할 수 있도록 하는 기능) / 인스턴스가 드레이닝 되면 ELB는 등록 취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않음 

 

Auto Scaling Group (ASG) - 주로 로드 밸런서에 연결하여 사용

무료 서비스 

ASG 내 최소 인스턴스 개수 설정 / 희망 인스턴스 개수 설정 / 최대 개수 설정 (+ 희망 용량 설정) => 스케일 인아웃

ASG 는 로드밸런서와도 작동

ELB는 상태 확인을 통해 인스턴스 상태 확인하여 ASG 에 전달 

인스턴스 속성을 기반으로 ASG 생성하려면 시작 템플릿을 생성해야 한다

오토 스케일링 활성화 하면 Activity history 에서 활동 내역 확인 가능

 

오토스케일링 정책

1. 동적 스케일링 (Dynamic scaling policies)

- 대상 추적 스케일링 : ex)오토 스케일링 그룹의 평균 CPU 사용률을 추적하여 이 수치가 40프로대에 머무를 수 있도로  함 / 기준선 세우고 상시 가용 (Target Tracking scaling)

- 단순과 단계 스케일링 : 클라우드 워치 알람이 울리면 전체 ASG에 대한 CPU 사용량이 70 초과 시 용량을 두 유닛 추가, 전체 ASG CPU 30프로 미만이면 유닛 하나 삭제 설정 가능 (Simple & Step Scaling)

- 예약된 작업 : 시간 예약 여러 사람들이 사용할 시간 대에 스케쥴링 늘림

- 예측 스케일링 : 로드를 보고 스케쥴링 예측, 사전 예측 완료됨

2. 지표 (Metric) 

- CPU 사용률 (CPU Utilization)

- 테스트 기반 대상별 요청 수 (RequestCountPerTarget)

- 어플리케이션이 네트워크에 연결된 경우 - 네트워크에서 병목 현상이 발생할 것으로 판단된다면 평균 네트워크 입출력량을 기반으로 스케일링을 수행하여 특정 임계값에 도달할 때 스케일링 할 수 있도록 (Cloudwatch 로도 가능)

<<참고>>

백엔드-데이터베이스 연결에는 ‘분당 요청'에 해당하는 CloudWatch 지표가 존재하지 않기 때문에 cloudwatch 경보를 생성하려면 cloudwatch 사용자 지정 지표를 먼저 생성해야 함

3. 스케일링 휴지 (Scaling Cooldowns)

스케일링 작업이 끝날 때마다 (인스턴스 추가, 삭제) 시 휴식 기간 갖는 거 : 이 때는 추가 인스턴스 실행 및 종류가 안돼

 

stress 줘보기

amazon-linux-extras install epel -y

yum install -y stress

stress -c 4