로드벨런서(3)

고정 세션

• 고정성/고정 세션: 로드밸런서에 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것.
  즉, 클라이언트의 첫 번째 요청으로 1번 인스턴스를 통과하면 다음 요청에도 동일한 인스턴스로 이동
• 이는 쿠키의 원리로 동작한다.
  클라이언트에서 로드 밸런서로 가는 요청의 일부로 전송
  고정성과 만료 기간이 있다. -> 쿠키 기간이 만료되면 다른 인스턴스로 리디렉션
• 고정성을 활성화하면 백엔드 인스턴스 부하에 불균형을 초래할 수 있다.
  일부 인스턴스는 고정 사용자를 갖게 된다.

쿠키란?

• 종류

  • 1. 애플리케이션 기반 쿠키
    • 애플리케이션에서 쿠키 기간을 지정할 수 있다.
    • 1-1 사용자 정의 쿠키
      - 애플리케이션에서 생성
      - 애플리케이션에 필요한 모든 사용자 정의 속성을 포함할 수 있음.
      - 쿠키 이름은 각 대상 그룹별로 개별적으로 지정해야 한다.
      - AWSALB,AWSALBAPP,AWSALBTG같은 ELB에서 사용될법한 이름은 사용하지 말아야 한다.
    • 1-2 애플리케이션 쿠키
      - 로드 밸런서 자체에서 생성
      - ALB의 쿠키 이름은 AWSALBAPP이다.
  • 2. 기간 기반 쿠키
    • 로드 밸런서에서 생성되는 쿠키
    • 쿠키 이름은 AWSALB, AWSELB, ALB이다.
    • 특정 기간을 기반으로 만료디고 그 기간은 로드 밸런서 자체에서 생성되는 것이다.

• 정리
  대상그룹 -> 액션 -> 대상 그룹 속성 편집 -> 고정성 탭에서 [로드밸런서 생성 쿠키],[애플리케이션 기반 쿠키]중 선택
  기간 기반 쿠키인 [로드밸런서 생성쿠키]는 1초에서 7일이고 이름은 로드밸런서가 알아서 해준다
  애플리케이션 기반 쿠키도 1초에서 7일이고, 앱에서 로드밸런서로 보낼이름은 직접 지정한다.
  => 고정성을 지정후 브라우저가 로드밸런서에 요청을 보내면 쿠키를 보내 그 쿠키가 인스턴스를 통과하기 때문에 고정성이 실행 되는 것.

• 실습
  고정성을 지정하고 웹페이지에서 F12을눌러 네트워크 탭에 들어가면 같은 인스턴스에 접속하는것을 알 수 있다.

크로스존 로드밸런싱

교차 영역 밸런싱을 사용하면 모든 영역에 있는 인스턴스에 트래픽을 고르게 분배할 수 있다.
교차 영역 밸런싱을 사용하지 않으면 각 가용 영역 내에서 부하분산 실행.

• ALB는 교차 영역 밸런싱이 기본으로 활성화 되어 있다.

  • 데이터를 다른 AZ로 옮기는데 비용이 들지 않는다. -> 일반적으로는 비용 발생
  • 대상 그룹 설정에서 비활성화할 수 있다. -> 비활성화하면 비용 발생

• NLB,GWLB는 기본적으로 비활성화 되어 있다.

  • 활성화하려면 비용 지불 필수. -> 가용 영역 사이에서 데이터를 옮기려면 비용이 든다.

• CLB은 비활성화 상태, CLB는 활성화 시켜도 AZ간 데이터 이동에 비용이 들지 않는다.

• 교차 영역 밸런싱 활성화 방법

  • NLB, GWLB
    로드밸런서 -> 속성탭 -> 편집 -> 교차영역밸런싱 활성화
  • ALB
    로드밸런서 -> 속성 탭 -> 편집 -> 항상 활성화 되어있음
    -> 대상 그룹 -> 속성 탭 -> 편집 -> 교차 영역 밸런싱 비/활성화

SSL 인증서

SSL 인증서: 클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화 해준다.
-> 이를 전송 중 암호화(in-flight)라고 한다.
-> 데이터는 네트워크를 이동하는 중에는 암호화되고, 송수신자 측에서만 복호화할 수 있다.

• SSL
  • 보안 소켓 계층을 의미
  • 연결을 암호화하는데 사용
• TLS
  • SSL의 업그레이드 버전
  • 전송 계층 보안을 의미
• Public SSL
  • CA(인증 기관)에서 발급한다.
  • 인증 기관에는 코모도, Symantec, GoDaddy, GlobalSign, Digicert, Letsencrypt, etc..
  • public SSL를 도르 밸런서에 추가하면 클라이언트와 로드 밸런서 사이의 연결을 암호화 할 수 있다.
• 공통
  • SSL 인증서는 만료 날짜가 있어 주기적으로 갱신해 인증 상태를 유지 해야 한다.
• 동작 방식
  사용자가 SSL을 통해 HTTPS요청을 하면 로드밸런서내부에서 SSL 종료를 실행
  로드밸런서에서 인스턴스로는 HTTP로 통신하지만 VPC로 이동하는 트래픽은 프라이빗 네트워크를 사용하기 때문에 보호된다.
  • 로드밸런서는 X.509인증서를 사용하는데 이것이 SSL또는 TLS 서버 인증서라 부른다.
  • AWS에는 이 인증서를 관리하는 ACM이 있다.(ACM: AWS 인증서 관리자)
  • 내가 가지고 있는 인증서를 ACM에 업로드 가능
  • HTTP 리스너를 구성할때 반드시 HTTPS 리스너로 구성해야 한다.
    • 기본 인증서를 지정해줘야 함.
    • 다중 도메인을 지원하기 위해 다른 인증서를 추가할 수 있다.
    • 클라이언트는 SNI(Server Name Indication)를 써서 접속할 호스트의 이름을 알릴 수 있다.
    • 보안정책을 지정할 수 있다
      구 버전의 SSL과 TLS, 즉 레거시 클라이언트를 지원할 수도 있다
• SSL 인증서 지원 항목
  • CLB: 하나의 SSL 인증서만 사용 가능 -> 여러개 인증서로 여러 호스트를 지원하려면 CLB를 여러개 둬야 한다.
  • ALB: 여러개의 SSL 인증서를 두고 리스너를 여러 개 지원할 수 있다.(SNI)
  • NLB: 여러개의 SSL 인증서로 다중 리스너 지원(SNI)

SNI(Server Name Indication)

• SNI는 매우 중요하다.
  여러 개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹서버가 여러개의 웹 사이트 지원할 수 있게 해준다.
• 최초 SSL 핸드셰이크 단계에서 클라이언트가 대상 서버의 호스트 이름을 지정하도록 한다.
  그러면 클라이언트가 접속할 웹사이트를 말했을 때, 서버는 어떤 인증서를 로드할지 알 수 있다.
• SNI 프로토콜은 새로 확장된 프로토콜이기 때문에 ALB,NLB, CloudFront에서만 동작한다.
• 어떤 로드 밸런서에 SSL 인증서가 여러개 있으면 ALB,NLB중 하나이다.

SSL 인증서 사용 방법(실습)

• ALB
  ALB -> 리스너 추가 -> 프로토콜(HTTPS,443) -> 특정 대상그룹으로 전달(Forward: 대상그룹 선택) -> [리스너 보안설정]에서 SSL 보안 정책 설정(보안 정책 설정에서는 인증서가 어떤 협상 방식을 쓰게 할 건지 정하는 것) -> SSL/TLS 인증서의 위치를 지정(ex: ACM,IAM, Import(import에선 개인키, 인증서,인증서 체인을 붙여넣어 외부에서 가져올 수 있음.))
• NLB
  NLB -> 리스너 추가 -> 프로토콜(TLS,443) -> 대상 그룹 지정 -> 보안 정책 설정 -> 인증서 위치 설정 -> ALPN(응용 프로그램 계층 프로토콜 협상, 이는 고급 설정 항목)

연결 드레이닝

• 네이밍
  • CLB: 연결 드레이닝
  • ALB/NLB: 등록 취소 지연
• 연결 드레이닝
  인스턴스가 등록 취소 또는 비정상 상태에 있을 때 인스턴스에 시간을 주어 in-flight 요청 즉, 활성 요청을 완료할 수 있도록 하는 기능.
  인스턴스가 드레이닝되면 ELB는 등록 취소 중인 인스턴스로 새로운 요청을 보내지 않는다.
  
• 연결 드레이닝 파라미터는 매개 변수로 표시할 수 있다.
  1~ 3,600초 사이의 값으로 설정 가능(default: 300초
  값을 0으로 두면 비활성화할 수 있다.
  • 짧은 요청의 경우 낮은 값으로 설정 (ex: 1초정도의 요청 -> 드레이닝 파라미터 30초 설정)
  • 긴 요청(업로드 등)의 경우 높은 값으로 설정

ASG(Auto Scaling Group)

웹사이트나 애플리케이션을 배포할 때 웹사이트 방문자가 갈수록 많아지면서 로드가 바뀔 수 있다.
AWS에서 인스턴스 생성 API 호출을 통해 서버를 빠르게 생성하고 종료할 수 있다.
이를 자동화 하고 싶다면 ASG를 생성할 수 있다.

• ASG의 목표는 스케일 인/아웃 이다.
  즉 ASG 크기는 시간이 지나면서 변할 것이다.
  • ASG에서 실행되는 인스턴스의 최소 최대개수를 보장하기 위해 매개변수를 정의할 수 있다.
  • 로드 밸런서와 페어링하는 경우 ASG에 속한 모든 인스턴스가 로드밸런서에 연결된다.
  • 어떤 인스턴스가 비정상이면 종료하고, 대체할 새 인스턴스를 생성한다.
  • ASG는 무료이며 인스턴스같은 하위 리소스에 대한 비용만 내면 된다.
  • 최소용량, 희망 용량, 최대 용량을 설정한다.
    
    
• ASG 속성
  • 시작 템플릿 생성하기
    • 시작 템플릿은 ASG 내에서 인스턴스를 시작하는 방법에 대해 정의가 포함되어 있다.
      AMI, 인스턴스 유형, EC2 사용자 데이터, EBS 볼륨, 보안 그룹, SSH 키 페어, 인스턴스의 IAM 역할, 네트워크 및 서브넷 정보, 로드 밸런서 정보 등등등
    • ASG의 최소 크기, 최대 크기, 초기 용량을 정의
    • 스케일링 정책 정의
• 스케일링 정책 - CloudWatch Alarms & Scaling
  ASG는 CloudWatch Alarms를 기반으로 스케일 인/아웃할 수 있다.
  CloudWatch Alarms는 지표를 통해 트리거 발생 -> 모니터링할 수 있는 평균 CPU, 사용자 지정 지표등
  EX) ASG 전체의 평균 CPU가 너무 높으면 지표에 따라 트리거를 통해 ASG의 스케일링 활동 시작
  경보에 의해 내부에서 자동적으로 스케일링이 이루어짐.

ASG 조정 정책

• 동적 스케일링 정책

  • 1. 대상 추적 스케일링: 가장 단순하고 설정하기 쉽다. (수동?)
       이 정책을 통해 CloudWatch 경보를 생성 할 수 있다.
       ex) 모든 인스턴스에서 ASG의 평균 CPU 사용률을 추적해 수치가 40%대에 머무를 수 있도록 할때 사용 -> 기준선을 두고 상시 가용이 가능하도록 함.
  • 2. 단순/단계 스케일링(단순: 하나의 작업, 단계: 다수의 경보를 설정)
       CloudWatch경보 발생 시 스케일링 작업 시작
       -> 설정할때 한번에 추가할 유닛의 수, 한번에 제거할 유닛의 수를 단계별로 설정해야함.
       ex) CloudWatch 경보를 설정하고 전체 ASG에 대한 CPU 사용률ㄹ이 70%를 초과하면 용량을 두 유닛을 추가하도록 설정
       전체 ASG 내의 CPU 30% 이하로 떨어지면 유닛 하나를 제거

• 예약된 작업
  사용 패턴을 바탕으로 스케일링을 예상하는 것.
  스케일링이 필요함을 미리 알고 있을 때
  ex) 금요일 오후 5시가 되면 큰 이벤트가 있을 예정이면 많은 사람들이 사용할것을 대비해 ASG 최소 용량을 매주 금요일 오후 5시마다 자동으로 10까지 늘리는 등의 작업.

• 예측 스케일링
  AWS 내 오토 스케일링 서비스를 활용해 지속적으로 예측을 생성
  로드를 보고 다음 스케일링을 예측
  
  머신러닝을 기반으로 ASG 오토 스케일링 중 하나
  
  

  • 확장하기 좋은 지표
    • 1. CPU 사용률
    • 2. 테스트를 기반으로 하는 대상별 요청의 수
         인스턴스는 한번에 대상별로 1,000개의 요청까지만 최적으로 작동해 이 지표로 스케일링활용
    • 3. 애플리케이션이 네트워크에 연결된 경우
         ex) 업로드/다운로드가 많아 인스턴스에 대해 해당 네트워크에서 병목 현상이 발생할 것 같다 판단 시 평균 네트워크 입출력량을 기반으로 스케일링 수행해 특정 임계값에 도달하면 스케일링 수행
    • 4. 직접 CloudWatch에서 애플리케이션 별로 지표를 설정
         직접 지표를 설정해 이를 기반으로 스케일링 정책을 바꿀 수 있다.

• 스케일링 Cooldowns
  스케일링 작업이 끝날 때마다 인스턴스의 추가/삭제 상관없이 기본적으로 5분의 휴지 기간을 갖는 것.
  * 휴지 기간에는 ASG가 인스턴스를 실행/종료 할 수 없다.
  * 지표를 이용해 새로운 인스턴스가 안정화될 수 있게 하고, 어떤 새로운 지표의 양상을 보이는지 살피기 위함.
  * 즉시 사용 가능한 AMI를 이용해 인스턴스 구성 시간을 단축하고, 요청을 더 빠르게 처리하는것이 좋다.
  * 인스턴스 구성에 할애되는 시간이 적으면 즉시 적용이 가능해지기 때문
  * 활성화 시간이 빨라지면 휴지 기간도 단축되기 때문에 ASG상에서 더 많은 동적 스케일링이 가능해진다.
  * ASG가 1분마다 지표에 접근할 수 있도록 세부 모니터링 기능등을 사용하도록 설정하고 이 지표를 신속히 업데이트할 필요가 있다.