[AWS] ALB (AWS의 관리형 로드 밸런서 中)

ALB(Application Load Balancer) (v2)

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

(출처 : 구글이미지)

• 위에 이미지 가운데에 외부 ALB가 있고 공공이 대상이다.
• 그 뒤에는 EC2 인스턴스로 구성된 첫 번째 대상 그룹이 있다. 이건 Route/user로 라우팅 될 것이다.
• EC2 인스턴스로 구성된 두 번째 대상 그룹은 검색 애플리케이션으로 사용이 될 거고, 여기선 상태 확인도 가능하게 된다. 그리고 이는 /search라는 규칙에 따라 라우팅 된다.
• 두 개의 독립된 마이크로 서비스가 서로 다른 작업을 처리하는 것이다.
   : 첫 번째는 유저 애플리케이션으로, 두 번째는 검색 애플리케이션으로 작동하는 것

 

Target Groups

• 머신 간 다수 HTTP 애플리케이션의 라우팅에 사용되는데 이러한 머신들은 대상그룹으로 묶이게 된다.
• 오토 스케일링 그룹에 의해 관리 될 수 있다.
• ECS 작업도 될 수 있다.(추후 올라오는 ECS 글을 참고해주시면 감사하겠습니다)
• 람다 함수가 될수도 있다고 하는데, 잘 알려진 내용은 아니다.
    : 람다 함수 앞에도 ALB가 있을 수 있다.
    : 람다 함수는 AWS에서 무서버로 불리는 모든 것들의 기반이 되는 함수이다.
• IP 주소들의 앞에도 위치할 수 있다.
    : 꼭 private(사설) IP 주소여야만 한다.
• ALB는 여러 대상 그룹으로 라우팅 할 수있다.
• Health check(상태 확인)은 대상 그룹 레벨에서 이루어진다.

(출처 : 구글이미지)

• 위의 이미지 처럼 ALB와 두 개의 대상 그룹이 있다.
• 첫 번째는 AWS 기반의 EC2 인스턴스이고, 두 번째 대상그룹은 데이터 센터 내부의 온프레미스 개인 서버이다.
• 대상 그룹이 존재하기 위해서는 등록을 위해 서버의 사설 IP가 대상 그룹에게 지정되어야 한다.
• 위에 이미지에서처럼 ALB를 통해 요청을 처리하는 애플리케이션이 있다고 생각해보자.
   : 첫 번째 대상 그룹으로는 모바일 기반 트래픽 전체를, 두 번째 대상 그룹에게는 데스크탑 기반 트래픽 전체를 보내는 상황이다. 이런 경우에는 쿼리 문자열이나 매개변수 라우팅을 사용하면 된다.
• 클라이언트가 사용하려는 URL에
   : ?Platform=Mobile이 있는 경우, 첫 번째 대상 그룹으로 리다이렉팅되도록 ALB에서 리다이렉션 라우팅 규칙을 만들 수 있다.
   : ?Platform=Desktop이 있는 경우, 두 번째 대상 그룹으로 리다이렉트하도록 만들 수 있다.

 

따로, 또 알아두면 좋은 내용

• 클래식에서와 마찬가지로 ALB를 사용하는 경우에도 고정 호스트 이름이 부여된다.
• 애플리케이션 서버는 클라이언트의 IP를 직접 보지 못한다.
   : 클라이언트의 실제 IP는 X-Forwarded-For라고 불리는 헤더에 삽입된다.
   : X-Forwarded-Port를 사용하는 포트와 X-Forwarded-Proto에 의해 사용되는 프로토콜도 얻게되는 것이다
• 즉, 클라이언트의 IP인 12.34.56.78가 로드 밸런서와 직접 통신해 연결 종료라는 기능을 수행한다.
   그리고 로드 밸런서가  EC2 인스턴스와 통신할 때에는 사설 IP인 로드 밸런서 IP를 사용해 EC2 인스턴스로 들어가게 된다. 그리고 EC2 인스턴스가 클라이언트의 IP를 알기 위해서는 HTTP 요청에 있는 추가 헤더인 X-Forwarded-Port와 Proto를 확인해야 한다.
• 예시
   - ALB를 사용해 EC2 인스턴스에서 호스팅된 웹사이트의 트래픽을 분배하고 있다. 그런데 여러분의 웹사이트가 ALB의 IP 주소인 사설 IPv4 주소에서 들어오는 트래픽만을 확인하고 있는 것으로 나타났다. 이런 경우, 웹사이트로 연결된 클라이언트들의 IP주소를 받으려면?
        : 웹사이트의 백엔드를 수정해 X-Forwarded-For 헤더로부터 클라이언트 IP 주소를 가져오도록 만들면 된다.