4-4. ELB들의 보충 개념 (AWS Certified Developer Associate)
1. Sticky Sessions(Session Affinity)고정 세션 or 밀접성
1-1. 설명
LB에서 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것이다.
예를 들어 2개의 EC2와 3개의 클라이언트가 존재하고 이들은 ALB를 통해 통신을 한다고 가정하자. 만약 Client1이 EC2-1과 통신이 이뤄지면 Client1은 다음 요청 또한 동일한 EC2-1에게 요청하게 된다. Client2,3또한 처음 통신시 ALB에서 정해준 EC2와 고정적으로 통신하게 된다.
- 원리
그렇다면 어떻게 이게 가능할까??는 "쿠키"를 통해 클라이언트에서 ALB로 요청의 일부로 정송하기 때문이다. "쿠키"는 고정성과 만료 기간 또한 존재한다. 만약 쿠키가 만료가 된다며 다른 EC2로 리다이렉션 된다. 세션 만료를 사용시 로그인등 중요한 정보를 취하는 세션데이터를 잃지 않기 위해 고정성을 활용할 수 있는데 이는 EC2 부하에 불균형을 초례할 수 있으니 조심하자!
1-2. 쿠키
1-2-1. 애플리케이션 기반 쿠키
- target으로 생성된 사용자 정의 쿠키
애플리케이션에서 생성된다.
애플리케이션에 필요한 모든 사용자의 속성을 포함할 수 있다
쿠키 이름은 각 대상 그룹별로 개별적으로 지정하는데 "AWSALB","AWSALBAPP","AWSALBTG"라는 이름은 ELB에서 사용하기
떄문에 사용할 수 없다.
- Application 쿠키
LB 자체에서 생성된다.
"AWSALBAPP"이란 이름으로 생성된다.
1-2-2. 기간 기반 쿠기
- LB에서 생성되는 쿠키로 ALB = "AWSALB", ELB = "AWSELB"라는 이름을 가진다. 특정 기간을 기반으로 만로되면 기간은 LB 자체에서 생성되는 것
- 애플리케이션에서 기간을 지정할 수 있다.
1-2-3 실습
- ALB에 연결된 타겟그룹으로 이동해 Actions/Edit target group attribute 페이지에서 쿠키 생성 방식과 기간,쿠키명을 작성한다.
- 결과는 크롬이나 fireFox에서 개발자도구 -> 네트워크 -> 쿠키값 확인을 보면 알 수 있성
2. Cross-Zone LB
- Cross-zone이란 개념은 단순하게 설명하면 두개의 LB로 각각의 다른 인스턴스를 연결하고 있다 가정하자. 이떄 클라이언트는 두 LB로 애플리케이션을 접근하려하는데 Cross-zone이 활성화된 LB는 모든인스턴스를 동일한 확률로 연결시켜준다. 하지만 Cross-zone이 비활성화 된 LB는 클라이언트 요청/LB의 수의 확률로 나눈 A%라는 값을 LB에 연결된 인스턴스수만큼 확률을 나눈다. 이렇게 되면 Cross-zone이 비활성화돼있는 경우는 균일한 요청을 받을 수 없게된다.
2-1 ELB 종류에 따른 Cross-Zone 활성 유무 및 비용
3. SSL/TLS 인증서
- SSL 인증서 사용시 Client와 LB사이에 전송 중에 있는 트래픽을 암호화 할 수 있다. in-flight 암호화라고 불리는 과정으로 데이터가 네트워크를 통과하는 중에 암호화되고 발신자와 수진자만이 이를 해동할 수 있다.
- SSL은 Secure Socket Layer을 뜻하며 연결을 암호화하는데 사용한다.
- TLS는 SSL의 최신 버전으로 Transport Layer Security를 의미한다. (주로 TLS지만 SSL라 부르는게 전문가들 사이에선 편해 SSL이라고 주로 부름)
- 공용 SSL 인증서는 Comodo, Symantec, GoDaddy, GlobalSign ,Letsencrypt등의 인증 기관에서 발급한다.
- LB와 연결된 공용 SSL 인증서를 사용하면 Client와 LB사이 연결을 암호화할 수 있따.
- SSL 인증서는 개발자가 설정한 유효 기간이 있기때문에 인증을 위해 주기적으로 갱신돼야한다.
3-1 LB관점 SSL작동방법
유저가 HTTPS를 연결하게 된다. (이떄 S가 SSL 인증서를 사용하고 있다는 의미이며 암호화되어 안전한 상태를 의미한다,)
이때 LB는 내부적으로 SSL 인증서 종료라는 작업을 수행 후 EC2와 통신을 한다. 이때 HTTP통신을 하기때문에 암호화는 되어있지 않다,
(앞단에 안정성을 보장하는 VPC를 통한 트래픽이기 때문에 어느정도 안정성을 보정하기때문)
- 다음으로 LB는 SSL || TLS 서버 인증서인 X.509 인증서를 불러온다.
- SSL 인증서를 관리하는 ACM을 사용해 인증서를 관리한다.
- HTTPS 리스너
: 설정시 기본 인증서를 지정해야한다.
: 다수의 도메인을 지우너하는 인증서 선택 목록 추가 가능
: 클라이언트는 Server Name Indication(SNI)을 사용해 도달하는 호스트 이름을 지정할 수 있다.
: 레거시 클라이언트로 불리는 구형 TLS SLS를 지원하도록 할 수 있다.
3-2 Server Name Indication(SNI)
- 한 웹서버 상에 다수의 SSL 인증서를 발급해 단일 웹 서버가 여러개의 웹사이트를 제공하도록 해주는 녀석
- 클라이언트가 초기 SSL 핸드셰이크에서 대상 서버의 호스트 이름을 명시해한다.
- ALB,NLB와 같이 최신 버전의 ELB 또는 CloudFront에서만 작동한다.
- CLB경우 오직 한개의 SSL만 가능하다.
4.Connection Draining(연결 드레이닝)
- CLB에선 Connection Draining(연결 드레이닝) & ALB || ELB 에선 Deregistration Delay(등록 취소 지연)이라고 부름
- 인스턴스가 등록 취소, 비정상 상태일때 어느정도 시간을 주어 in-flight 요청, 즉 활성 요청을 완료 할 수 있도록 하는 기능
- 연결 드레이닝 혹은 등록 취소 지연인 인스턴스에게 새로운 요청을 보내지 않는 것을 뜻한다.
- 1~ 3,600초 사이의 값을 설정 할 수 있는데 기본적으로 300s이다. 이값을 0으로 설정하면 비활성화인셈이다.
- 짧은 요청일 경운 초를 낮추고(30초정도),업로드 또는 오래 지속되는 요청은 어느정도 높은 값으로 설정한다.
5.Auto Scaling Group(ASG)
5-1 개요
클라우드의 장점인 서버를 쉽게 생성 및 제거 할 수 있는 기능을 특화시킨 기능이 ASG이다. 즉 부하에 맞춰 인스턴스를 추가하는 Scale out, 서버를 제거하는 Scale in이 가능하다. 또한 ASG은 in/out을 인스턴스의 일정량만큼만 추가제거 할 수 도있다.
- ASG은 최소/최대 인스턴스 숫자를 설정할 수 있다.
- LB에 자동으로 새 인스턴스를 등록해줄 수 있다.
- 다음 그림을 통해 잘 알아두자!
- ASG를 생성할때 필요한 속성들을 알아두자!
참고로 수동으로 인스턴스를 생성하는 것과 비슷하다! 한가지 주의할점은 스케일링 정책을 정의 해야되는데 이것은 스케일 인/아웃의 정채을 정의하는 것이다.
- ASG Alarms
CloudWatch 알람을 기반으로 ASG을 스케일링 하는 방법이다.
몇가지 메트릭을 모니터링 하고 있으며 메트릭이 얼라가 알람이 울리면 스케일 아웃의 알람을 울리고 다시 내려가거나 너무 낮으면 스케일 인을 하는 알람을 받을 수 있다.
알람은 평군 CPU같은 메트릭을 모니터링하며 전방적인 평균으로 계산된다. "즉 평균만 보는것"
- ASG New Rules
- 평균 CPU사용량을원하는 것으로 지정해 CPU 사용량을 충족하는 부라릉 기반으로 스케일 인/아웃이 가능함
- 인스턴스당 ELB의 요청 개수를 기반으로도 가능
즉, ASG는 AWS의 노출된 메트릭에 결부되어 있지 않으며 어떤 메트릭스든 관계 없이 어떤 것도 커스텀 메트릭이 될 수 있다
-- 배운 내용정리는 너무 길어서.. PPT로 대체
