sol 개발 블로그 로고
Published on

AWS ELB 정리 (1)

Authors
  • avatar
    Name
    Chan Sol OH
    Twitter

목차

Elastic Load Balancer (ELB)

우리 애플리케이션 시스템이 문제가 발생해도 정상적으로 작동하기위해선 고가용성이 필요하다. 고가용성을 위해선 한 인스턴스에 모든 역할을 부여하지 않고 여러 인스턴스에 나눠서 일해야한다. 그렇다면 우리는 어떤 작업을 여러 인스턴스가 하도록 작업을 분산, 수평적 확장해서 처리할 수 있어야한다.

이를 위해 로드 밸런서를 이용할 수 있다. 기본적으로 외부 유저는 로드 밸런서에 연결되고 ELB는 인스턴스에 요청을 나눠서 보낸다. 만약 부하가 많아지면 각 인스턴스로 그 부하를 분산해서 보낼 수 있다. 그리고 유저는 ELB에 연결하기 때문에 어떤 인스턴스가 자신의 요청을 처리하는지 알 수 없다. 한 엔드 포인트에만 연결된다고 생각한다.

로드 밸런서를 사용하는 이유?

  • multiple downstream 인스턴스로 부하 분산
  • 애플리케이션에 단일 액세스 지점(DNS)를 노출
  • 로드 밸런서가 상태확인 매커니즘으로 인스턴스의 상태를 확인해서 문제가 있으면 유저들 모르게 문제를 고칠 수 있다.
  • 웹 사이트를 위해 SSL 연결을 할 수 있다.
  • 글로벌 영역에 걸친 고가용성을 가진다.
  • 퍼블릭 트래픽을 프라이빗 트래픽으로 분산할 수 있다. 외부 인터넷에서 온 트래픽을 VPC 내부의 퍼블릭 서브넷에 있는 인스턴스로 보낼 수 있다.

ELB를 사용하는 이유?

  • ELB는 관리형 로드 밸런서,
  • AWS가 업그레이드와 유지 관리 및 고가용성을 책임진다.
  • 몇가지 설정을 할 수 있도록 열려있다.
  • 다양한 AWS 서비스(EC2, ACM, ASG,...)과 함께 사용된다. 꼭 쓰자!!

자체 로드 밸런서를 마련하는 것보다 저렴하고 더 효율적이다. 확장성에 이점이 있다.

Health Checks

인스턴스가 잘 작동되고 있는지 ELB가 체크하는 작업. 아래 3가지를 기준으로 요청을 보내서 적절한 응답(200)이 들어오면 정상으로 간주한다. 비정상으로 간주하면 그쪽으로 트패픽을 발생시키지 않는다.

  • 프로토콜
  • 포트
  • 엔드포인트(/health)

AWS 로드 밸런서 종류

  • ALB - 7계층
    • application load balancer
    • HTTP, HTTPS, WebSocket 사용가능!
    • Port (X-Forwarded-Port), proto (X-Forwarded-Proto)
  • NLB - 4계층
    • Network Load Balancer
    • TCP, TLS, UDP 프로토콜을 지원
  • GWLB - 3계층
    • Gateway Load Balancer
    • IP 프로토콜

로드 밸런서 Security Groups

유저는 로드 밸런서에 HTTP, HTTPS 요청과 응답을 주고 받을 수 있어야한다. 이를 위해 로드밸런서는 80, 443 포트에 TCP로 0.0.0.0/0에대해서 허용해야한다. 그리고 EC2는 HTTP, 80포트로 들어오는 Security Groups (로드 밸런서)만 허가해서 오직 로드 밸런서로부터 오는 요청만 받아드리도록 설정할 수 있다.

application Load Balancer (ALB)

7계층에서 머신 간 다수 HTTP 애플리케이션의 라우팅에 사용된다. 이 머신들은 로드 밸런서의 대상 그룹(target group)이라는 그룹으로 묶인다. 일반적으로 대상 그룹에는 EC2 인스턴스 (ASG로 관리될 수 있음), ECS, Lambda functions 같은 컴퓨팅 머신을 사용하고 프라이빗 IP 주소가 될 수 있다. 또한 HTTP/2, WebSocket, 그리고 리다이렉트(from HTTP to HTTPS)를 지원한다.

위에선 머신 간 라우팅을 지원한다고 했지만, 또한 대상 그룹 간의 라우팅(nginx가 해주는 것처럼!)도 지원한다. 예를 들어 특정 URL 엔드 포인트로 시작하면 그에 맞는 대상 그룹으로 라우팅 할 수 있다. (example.com/users, example.com/posts) URL 엔드 포인트 뿐만 아니라 hostname (one.example.com & other.example.com), Query String, Header에 기반할 수 있다.

위와 같이 다양한 방법으로 대상 그룹이나 머신들의 라우팅을 지원하기 때문에 마이크로 서비스와 컨테이너 기반 애플리케이션(Docker & ECS)에 적합하다. 특히 포트 맵핑 기능은 ECS의 동적 포트에 리아이렉트할 수 있기에 더 좋다!

aws alb의 path 기반 라우팅 도안

대상그룹 (target group)

  1. ALB는 여러 대상 그룹에 라우팅 수행
  2. 대상 그룹 단위의 헬스 체크

ALB가 내부 머신을 숨기는 방법

기본적으로 외부 클라인트는 ALB의 IP와 HTTP(S) 통신을 하게된다. 클라이어트와 ALB가 통신할 때 ALB는 Connection termination하기 때문에 마치 ALB가 요청에 대한 응답을 수행하는 것처럼 보이는 것이다.

로드 밸런런서는 EC2의 프라이빗 IP를 통해서 HTTP 통신을하고, EC2가 클라이언트의 IP를 알아내는 방법은 요청 헤더에 있는 Port (X-Forwarded-Port), proto (X-Forwarded-Proto)를 통해 알 수 있다.

ALB 생성할 때 주의 할 점

  1. 외부 클라이언트와 통신할 수 있도록 Security Group 만들기. HTTP 통신에는 80 포트를, HTTPS 통신에는 443 포트를 열어야한다. 또한 모든 사용자가 접근할 수 있어야하므로 인,아웃 바운드 모두 CIDR 설정은 0.0.0.0/0으로 한다.
  2. 대상 그룹 만들기 ALB가 라우팅할 머신들을 모은 대상 그룹을 만들고 인스턴스들을 대상 그룹에 등록한다. 여기서 등록된 인스턴스들을 ALB가 라우팅해줄 것이다.
  3. Listeners and routing 설정에서 HTTP(S)의 트래픽을 위에서 만든 대상 그룹으로 라우팅하도록 설정할 수 있다.
  4. ALB를 생성하고, 대상 그룹을 보면 Health status가 healty라는 것을 알 수 있고, 이는 인스턴스가 정상 동작하는 것을 의미한다. 인스턴스에 문제가 생기면 unused라고 뜨고 그 인스턴스로는 라우팅하지 않는다. 마이크로 서비스나 가용성을 위해 사용할 수 있는 좋은 예시다.

ALB 네트워크 보안

  1. EC2의 보안 그룹(Security Group) 설정하기

    EC2에는 로드 밸런서와 EC2의 퍼블릭 IP 두가지 방법을 통해서 EC2에 접속할 수 있다. 그러나 보안을 위해선 EC2의 퍼블릭 IP를 통한 접속은 막는 것이 좋다. 이를 위해 EC2의 SG에서 HTTP 요청 소스를 로드 밸런서의 SG만 허용하도록 수정해야한다. 그러면 EC2의 퍼블릭 IP 접속은 불가능해진다.

  2. ALB의 리스너 규칙 설정하기

    ALB의 리스너에서 규칙 섹션은 ALB로 들어오는 특정 hostheader, path, http header 등등 조건을 설정하고 어떤 대상 그룹으로 보낼지 결정할 수 있다. 예를 들어 /error 엔드포인트가 URL로 들어오면, 고정된 에러 페이지를 응답하도록 설정할 수 있고, 특정 조건에 맞으면 http를 https로 리다이레 할 수 있다.

Discuss on Twitter • View on GitHub