AWS_SAA_준비(22)

Tyun_Record·2023년 7월 29일
ALBLoad balancingNLBSAAawselb클라우드
0

AWS SAA 준비

목록 보기
26/48

Scalability(확장성) & High Availability(고가용성)

  • Scalability
    • 애플리케이션 시스템이 조정을 통해 더 많은 양의 데이터를 처리할 수 있는 것
    • 수직 확장성
      • 인스턴스의 크기를 확장하는 것
      • 데이터베이스와 같이 분산되지 않은 시스템에 사용
      • RDS나 ElastiCache 등의 하위 인스턴스의 유형을 업그레이드해 수직적으로 확장할 수 있는 시스템들에 사용
      • 확장의 한계가 있고 하드웨어 제한이 있음
    • 수평 확장성
      • 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 것
      • 스케일 아웃 ( 인스턴스의 수가 늘어나는 것 )
      • 스케일 인 ( 인스턴스의 수가 줄어드는 것 )
  • High Availabilty
    • 시스템을 둘 이상의 AWS의 AZ나 데이터센터에서 가동하는 것
    • 다중 AZ가 활성화된 자동 스케일러 그룹이나 로드 밸런서에도 사용

Load Balancing

  • 로드 밸런서
    • 서버 혹은 서브넷으로 트래픽을 백엔드나 다운스트림 EC2 인스턴스 또는 서버들로 전달하는 역할
    • 로드 밸런싱을 통해 유저들이 각각 다른 EC2 인스턴스에 연결되도록 트래픽을 분산시켜줌
    • 유저들은 자신이 어떤 인스턴스에 연결되어 있는지 알 수 없음
    • 상태 확인(Health Checks) 매커니즘으로 어떤 인스턴스로 트래픽을 보낼 수 없는지 확인가능
    • SSL 종료 가능, 웹 사이트에 암호화된 HTTPS 트래픽 가질 수 있음
    • 쿠키로 고정도 강화 가능
    • 영역에 걸친 고가용성을 가짐
    • 클라우드 내 개인 트래픽과 공공 트래픽 분리 가능

Elastic Load Balancer

  • 관리형 로드 밸런서

  • AWS가 관리, 업그레이드, 유지 관리 및 고가용성 책임

  • 로드 밸런서 작동 방식 수정할 수 있도록 일부 구성 놉 제공

  • 자체 로드 밸런서 마련하는 것보다 저렴

  • 다수의 AWS 서비스들과 통합 되어 있음

  • 로드 밸런서 보안

    • 유저는 HTTP나 HTTPS를 사용해 어디서든 로드 밸런서에 접근 가능

    • 따라서 로드 밸런서 보안 그룹의 규칙은 아래와 같은 형태가 됨

      • 포트 범위 80, 혹은 443
      • 소스 0.0.0.0 / 0 (어디서든 접속 가능하다는 듯)

    • EC2 인스턴스 보안 규칙은 조금 다름, 로드 밸런서를 통해 들어오는 트래픽만 허용해야 하므로

      • 포트 범위 80, HTTP 트래픽 허용
      • 소스는 로드 밸런서의 보안 그룹으로 연결

  • Health Checks

    • Elastic Load Balancer 작동 상태 확인
    • 포트와 라우트에서 이루어짐
    • EC2 인스턴스가 괜찮다는 신호, HTTP 상태 코드로 200으로 응답하지 않으면 인스턴스 상태가 좋지 않다고 기록
      • Elastic Load Balancer는 해당 인스턴스로 트래픽을 보내지 않음

Application Load Balancer

  • 7계층, HTTP 전용 로드 밸런서
  • 머신 간 다수 HTTP 애플리케이션의 라우팅에 사용 됨
    • 머신들은 target groups로 묶이게 됨
    • redirects 지원 ( HTTP에서 HTTPS로 트래픽을 자동 redirects 하려는 경우 )
    • URL 대상 경로에 기반한 라우팅도 가능
      • ex) example.com/users & example.com/posts
      • users와 posts는 URL 상의 서로 다른 경로, 이들을 target groups 그룹에 redirets 가능
    • URL의 호스트 이름에 기반한 라우팅 가능
      • ex) 로드 밸런서가 one.example.com & other.example.comd에 접근 가능하다면
      • 두 개의 다른 target groups에 라우팅 됨
    • 쿼리 문자열과 헤더에 기반한 라우팅 가능
      • ex) example.com/users?id=123&order-=false가 다른 target groups에 라우팅 될 수 있는 것
  • 동일 EC2 인스턴스 상의 여러 애플리케이션에 트래픽을 분산
    • ex) containers, ECS
  • HTTP/2와 Websocket 지원
  • 약자로 ALB
  • 마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 로드 밸런서
    • 도커와 Amazon ECS에 적합
  • 포트 매핑 기능이 있어 ECS 인스턴스의 동적 포트로의 리다이렉션을 가능하게 해줌
  • 하나의 로드 밸런서로 다수의 애플리케이션 처리 가능

ALB Target Groups Types

  • EC2 인스턴스 (오토 스케일링 그룹에 의해 관리 ) - HTTP
  • ECS 작업 - HTTP
  • 람다 함수
  • IP Address - 사설 IP 주소여야만 함
  • 즉, ALB는 여러 Target Groups으로 라우팅 가능
  • Health Checks는 Target Groups 레벨에서 이루어짐

ALB 실습

  1. EC2 > Load Balacners > Creat > Select Load Balancer Type
  2. 각 선택사항 입력 ( 타겟 그룹 생성 등.. )

  3. 생성 된 DNS 이름을 복사해 새 탭에 넣으면, 애플리케이션 로드 밸런서를 통해 Hello World 출력
  4. 새로고침하면 인스턴스 대상이 바뀌는 것을 알 수 있음 (IP 바뀜)
  5. 이를 통해 트래팩 분산이 일어나고 있음을 알 수 있다

로드 밸런서 심화 개념

  • 네트워크 보안
    • 인스턴스에서 직접 접근할 수 있게 하는 것 보다는 로드 밸런스를 통해서만 접근하게 설정하는 것이 좋음
    • 네트워크 보안 강화를 위해
  • 애플리케이션 로드 밸런서 규칙
    • 규칙 추가 가능
    • 경로가 '/error'면 고정 응답으로 404 코드와 'Not found, custom error' 응답 보내는 규칙 생성
    • 결과

Network Load Balancer

  • L4 로드 밸런서
    • TCP와 UDP 트래픽을 다룰 수 있음
    • HTTP를 다루는 L7보다 하위 계층
    • 초당 수백만 건의 요청 처리 가능
    • ALB에 비해 지연 시간 짧음, ALM = 400ms, NLB = 100ms
    • 가용 영역별로 하나의 고정 IP를 가짐
    • 탄력적 IP주소를 각 AZ에 할당 가능
    • 여러 개의 고정 IP를 가진 애플리케이션을 노출할 때 유용
    • ex) 1~3개의 IP로만 액세스할 수 있는 애플리케이션을 만들라는 문제가 나오면 NLB를 선택!! ( TCP, UDP, 정적 IP )
    • 프리 티어 아님.. ㅜㅜ

NLB Target Groups Types

  • EC2 인스턴스
  • IP 주소 - 반드시 하드코딩, 프라이빗 IP
  • ALB 앞에 사용 가능
    • NLB를 통해 고정 IP 얻을 수 있고 ALB 덕분에 HTTP 유형의 트래픽 처리하는 규칙 얻을 수 있음
  • Health Check
    • TCP, HTTP, HTTPS Protocols 지원

NLB 실습

  1. EC2 > Load Balacners > Creat > Select Load Balancer Type
  2. 각 선택사항 입력 ( 타겟 그룹 생성 등.. )
  3. ALB와 다르게 AWS의 고정 IP 혹은 탄력적 IP로 IPv4 설정 가능
  4. nlb의 target group 생성..
  5. target groups 인스턴스들의 보안 그룹에 NLB 트래픽 허용 가능하도록 규칙 설정 해야함

Gateway Load Balancer

  • 가장 최근 로드 밸런서
  • 네트워크 트래픽 분석
  • L3 계층
  • GWLB 2가지 기능
    • Trasparent Network Gateway
      • VCP 모든 트래픽이 GWLB의 sing entry/exit을 통과하기 때문
    • 로드 밸런서
      • 가상 어플라이언스 집합에 트래픽을 분산해줌
  • 6081번 포트의 GENEVE 프로토콜을 사용함!!!
  • GWLB는 배포 및 확장, AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용
  • 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템 ( IDPS ) 에 사용
  • IDPS나 심층 패킷 분석 시스템 또는 일부 페이로드 수정 가능
    • 단, 네트워크 수준에서 가능

GWLB Target Groups Types

  • 타사 어플라이언스임
    • EC2 인스턴스
    • IP 주소 - 프라이빗 IP

Elastic Load Balancer Sticky Session ( Session Affinity )

  • 고정성 혹은 고정 세션을 실행하는 것
  • 로드 밸런서에 2가지 요청을 하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것
  • 2개의 EC2 인스턴스와 3개의 클라이언트가 있는 ALB와 같은 것
  • 1번 클라이언트가 요청을 생성해 첫 번째 EC2 인스턴스로 가면 두 번째 요청시에도 로드밸런서를 통해 동일한 인스턴스로 이동
  • 2번 클라이언트, 3번 클라이언트도 동일하게 로드 밸런서가 두 번째 인스턴스와 통신하면 해당 인스턴스로 이동
  • CLB와 ALB에서 설정 가능
  • '쿠키'라는 원리를 통해 가능
    • 클라이언트에서 로드 밸런서로의 요청이 일부 전송되는 것
    • 고정성과 만료 기간이 있음
    • '쿠키'가 만료 되면 클라이언트가 다른 EC2 인스턴스로 리디렉션 됨
  • 세션 만료시에는 사용자 로그인과 같은 중요한 정보를 취하는 세션 데이터를 잃지 않기 위해 사용자가 동일한 백엔드 인스턴스에 연결됨
  • 고정성을 활성화하면 백엔드 EC2 인스턴스 부하에 불균형을 초래할 수 있음, 일부 인스턴스는 고정 사용자를 갖게 됨
  • '쿠키'
    • Application-based Cookies ( 애플리케이션 기반 )
      • custom cookie
        • Generated by the target
        • 애플리케이션에 필요한 모든 사용자 정의 속성을 포함 가능
        • 애플리케이션에서 기간 지정
        • 쿠키 이름은 각 Target group 별로 개별 지정
        • Don't use AWSALB, AWSALBAPP, or AWSALBTG ( ELB에서 사용하기 때문 )
    • Application cookie
      • Generated by the load balancer
      • Cookie name is AWSALBAPP
  • Duration-based Cookies ( 기간 기반 )
    • Cookie generated by the load balancer
    • Cookie name is AWSALB for ALB, AWSELB for CLB
    • 특정 기간을 기반으로 만료, 로드 밸런서 자체에서 생상

고정 세션 활성화 방법

  1. EC2 > Target groups > Actions > Edit target group attributes

  2. 이후 DNS ID로 새탭 열고 새로고침하면 고정 IP로만 접속 되는 것을 확인 할 수 있음

... 다음 게시글에서 계속

profile
Tyun_Record
이전 포스트

AWS_SAA_준비(EC2 데이터 관리 퀴즈)

다음 포스트

AWS_SAA_준비(23)

0개의 댓글