로드벨런싱 & ALB

관리형 로드 밸런서

• 종류
  • 클래식 로드밸런서(CLB) v1
  • 애플리케이션 로드밸런서(ALB) v2: 2016출시
    HTTP, HTTPS, WebSocket프로토콜 지원.
  • 네트워크 로드밸런서(NLB) v2: 2017년 출시
    TCP, TLS, UDP프로토콜 지원
  • 게이트웨이 로드밸런서(GWLB): 2020년 출시
    네트워크층에서 작동 - 3계층과 IP프로토콜에서 작동

일부 로드 밸런서들은 내부에 설정될 수 있어 네트워크에 개인적으로 접근이 가능하다.
웹사이트와 공공 애플리케이션등 모두 사용이 가능한 외부 공공 로드 밸런서도 있다.

• 로드 밸런서 보안그룹들
  • 로드 밸런서의 보안그룹
    유저는 HTTP,HTTPS를 사용해 접근하기위해 포트80,443, source 0.0.0.0/0등으로 설정
  • 인스턴스의 보안 그룹
    포트 80, 443등, source는 IP가 아닌 보안그룹으로 설정한다.
    인스턴스의 보안 그룹을 로드 밸런서의 보안그룹으로 연결 => 로드 밸런서에서 온 트래픽만 허용하게 됨.
    

Elastic Load Balancing(ELB)

로드벨런서: 부하분산

• 기능:
  • 상태 확인 메커니즘으로 트래픽 상태 확인
  • SSL(인증서) 종료를 제공해 HTTPS 웹 사이트 트래픽을 가질 수 있다.
    • SSL,TLS -> 보안 소켓 계층
      서버와 클라이언트 사이의 데이터를 암호화해 인터넷 연결을 보호
  • 쿠키로 고정도를 강화할 수 있다.
  • 영역에 걸친 고가용성을 가진다.
  • 클라우드 내에서 개인 트래픽과 공공 트래픽을 분리할 수 있다.

ELB?

• ELB: 관리형 로드벨런서 -> AWS가 관리
  • 자체 로드 밸런서를 구축하는것 보다 저렴하고 직접 관리하면 확장성에서 번거롭기때문에 ELB사용을 권장
  • ELB는 다수의 AWS서비스와 통합되어 있다.
    ex) 인스턴스, 스케일링 그룹, ECS, 인증서 관리(ACM), CloudWatch, Route 53, 등등

상태 체크(Health Checks)

• 인스턴스의 작동이 올바르게 되고 있는지 체크
  상태 체크는 포트와 라우트에서 이뤄진다.(ex: 포트: 80, 프로토콜: http, 앤드포인트: /health)
• HTTP 상태 코드로 200으로 반환하지 않으면, 상태에 이상이 있다고 기록.

Classic Load Balancer(CLB) => AWS에서 지원하지 않음.

Application Load Balancer(ALB)

• ALB: 7계층, HTTP 전용 로드밸런서
  • 머신 간 다수의 HTTP 라우팅에 사용(대상 그룹)
  • 컨테이너와 ECS를 사용해 로드 밸런싱.
  • HTTP/2와 WebSocket을 지원
  • 리다이렉트 지원(HTTP -> HTTPS 자동 리다이렉트)
  • 경로 라우팅 지원
    • URL 경로 기반 라우팅 지원(ex: example.com/users, example.com/post)
    • URL 호스트 이름에 기반한 라우팅 지원(ex: one.example.com, other.example.com)
    • 쿼리 문자열과 헤더 기반 라우팅 지원(ex: example.com/users?id=123&order=false)
  • 마이크로 서비스나 컨테이너기반 애플리케이션에 가장 좋은 로드 밸런서
    도커나 아마존ECS등에 적합한 로드 밸런서이다.
    -> 포트 매핑 기능이 있어 인스턴스의 동적 포트로 리다이렉션을 가능하게 함.
  • 하나의 ALB로 다수의 애플리케이션 처리 가능.
  • 로드밸런서 규칙
    로드 밸런서(ALB)생성 -> 리스너 -> 리스너 규칙
    • 리스너 규칙
      • 호스트헤더: ex) *.example.com
      • 경로: ex) /error 설정시 example.com/error로 들어갔을때 설정한 규칙을 실행해라
        /error로 들어가면 오류 메세지 표시
      • HTTP 응답 메소드: 요청 메소드를 get, post등으로 설정 가능
      • IP 소스: IP를 기준으로 필터링하고 조건을 지정 가능
      • HTTP 헤더
      • 쿼리 문자열
    • 조건
      조건에 일치하면 어떤 동작을 할지 설정
      • 특정 대상 그룹에 전달
        대상 그룹이 두 개 이상인 경우 하나 이상의 애플리케이션을 정의 가능
      • URL 리다이렉트: 특정 URL로 리디렉션
        URI부분이나 전체 URL선택.
        프로토콜 HTTP,HTTPS중 선택
        특정 상태 코드 선택 가능 -> 호스트, 경로, 쿼리등을 사용자 지정
      • 고정된 응답 반환
        ex) /error 접근 시 응답 코드: 404, 응답 바디: "404 찾을 수 없음"
    • 우선순위
      1~50000까지의 우선순위를 정할 수 있다.
      어떤 조건이 여러 규칙에 일치하는 경우 우선순위에 따라 실행된다.
• 대상 그룹
  • 인스턴스(오토 스케일링 그룹에 의해 관리 될 수 있다.) - HTTP
  • ECS 작업 - HTTP
  • 람다 함수(서버리스) - 람다 함수 앞에도 애플리케이션 로드 밸런서가 있을 수 있다.
  • IP 주소 - 사설 주소여야만 한다.
    
    ALB는 여러 대상 그룹으로 라우팅할수 있고
    상태 확인은 대상 그룹 레벨에서 이뤄진다.

ALV 알아주면 좋은점

• 1. ALB를 사용하면 고정 호스트이름이 부여된다.
• 2. 애플리케이션서버는 클라이언트의 IP를 직접 볼 수 없다.
     클라이언트의 실제 IP는 (X-Forwarded-For)라고 불리는 헤더에 삽입
     X-Forwarded-Port와 X-Forwarded-Proto에 의해 사용되는 포트와 프로토콜을 얻게 된다.
     
     클라이언트 에서 로드밸런서를 통해 인스턴스를 종료하는 작업을 수행할때
     로드밸런서는 인스턴스의 사설주소를 통해 연결
     인스턴스가 클라이언트의 IP를 알기 위해서는 HTTP 요청에 있는 추가 헤더인 X-Forwarded-Port와 X-Forwarded-Proto를 통해 확인.