📒목표

로드 밸런서가 하는 일과 고가용성, 확장성에 대해 알아보기

📒확장성

애플리케이션이 더 많은 양의 트래픽을 처리할 수 있도록 하는 것을 의미합니다.

두 가지 종류의 확장성이 있습니다.

✔️수직 확장성

서버의 크기를 확장시키는 것을 수직 확작성이라고 합니다.

예를 들면,

aws에서 인스턴스의 크기를 확장하는 것을 의미하고, 온 프레미스 환경이라면 말 그대로 더 좋은 성능의 서버로 바꾸는 것을 의미합니다.

물론 DB도 마찬가지로 더 좋은 인스턴스로 교체하거나, 온 프레미스 환경에서 더 좋은 성능의 DB 서버로 교체하는 것의 의미합니다.

✔️수평 확장성

서버의 갯수를 늘리는 거라고 생각하면 편합니다.

우리의 앱이 동작하는 ec2 인스턴스의 갯수를 늘리는 경우입니다.

온 프레미스 환경이라면, 새로운 컴퓨터를 사서 네트워크 연결을 하고 우리 서버 앱을 배포해야 합니다.

클라우드 환경에서는 수평 확장성이 이점이 도드라지는 것 같습니다.

📒고가용성

고가용성은 수평 확장과 연관된 개념입니다.

고가용성을 쉽게 이야기해서 둘 이상의 애플리케이션 서버를 두고, 하나의 서버가 멈춰도 계속 작동이 가능하게끔 하는 것을 의미합니다.

📒로드 밸런서

로드 밸런서가 서버로 들어오는 트래픽을 여러 서버로 분산시켜주는 것을 의미합니다. 즉, 부하를 다수의 다운스트림 인스턴스로 분산해줍니다.

사용자가 서버로 액세스 하는 지점은 하나(로드 밸런서)로 노출하고 로드 밸런서를 통해 로드 밸런싱을 진행합니다. 이를 통해, 다운스트림 인스턴스의 장애를 원할하게 처리할 수 있습니다.(하나의 인스턴스가 죽어도 상관없음)

이는 로드 밸런서가 헬스체크를 통해 어떤 인스턴스가 트래픽을 받을 수 없는지 매번 확인(인스턴스의 상태 확인)하고 있기 때문에 가능합니다.

✔️관리형 서비스

엘라스틱 로드밸런서는 관리형 로드 밸런서로서, aws에서 이를 관리하며 어떤 상황에서도 작동할 것을 보장합니다.

aws에서 업그레이드, 유지관리, 고가용성을 관리합니다. 관리형 서비스이지만 로드 밸런서의 동작을 조정할 수 있는 몇 가지 구성 옵션 또한 제공합니다.

로드밸런서를 사용하는 것이 좋은 이유는, 자체 로드밸런서를 구축하여 관리하는 것보다 편리하기 때문입니다.

로드밸런서는 EC2, EC2 오토 스케일링 그룹, Amazon ECS, AWS Certificate Manager(ACM), CloudWatch, Route 53, Global Accelerator 등등 많은 aws 서비스와 통합할 수 있습니다.

✔️헬스 체크

헬스 체크는 로드밸런서가 ec2의 인스턴스 살아있는지 확인하기 위해 사용됩니다. 트래픽을 보낼 수 있는지 없는지 확인해야 하기 때문입니다.

로드밸런서는 보통 특정 포트와 /health 엔드포인트를 사용해서 헬스 체크를 진행하며, 200 응답을 받지 못하면, 해당 인스턴스가 트래픽을 처리할 수 없다고 기록하며, 트래픽을 보내지 않게 됩니다.

✔️로드밸런서 종류

전체적으로는 더 많은 기능을 제공하는 신세대 로드 밸런서를 사용하는 것이 좋습니다.

일부 로드 밸런서는 내부적으로 설정할 수 있습니다. 따라서 네트워크에 대한 내부 및 사설 접근용 또는 외부 공용 로드 밸런서, 예를 들어 웹사이트 및 공용 애플리케이션에 사용할 수 있습니다.

📌ALB

2016년에 출시된 새로운 세대의 애플리케이션 로드 밸런서(ALB)가 있으며, 이는 HTTP, HTTPS 및 WebSocket 프로토콜을 지원합니다.

📌NLB

2017년에 출시된 네트워크 로드 밸런서(NLB)가 있으며, 이는 TCP, TLS, 보안 TCP 및 UDP 프로토콜을 지원합니다.

📌GWLB

2020년에 출시된 게이트웨이 로드 밸런서(GW ELB)가 있으며, 이는 네트워크 계층(IP 프로토콜)에서 작동합니다.

📒ALB

HTTP 전용 로드밸런서, 마이크로 서비스나, 컨티에너 기반 애플리케이션에 가장 좋은 로드밸런서다.(도커, ecw에 가장 적합함, ALB는 인스턴스의 동적 포트로 리디렉션할 수 있는 포트 매핑 기능을 가지고 있기 때문)

✔️ALB에서 하는 일

1. 여러 인스턴스(target groups으로 묶인)간 다수 HTTP 애플리메이션 라우팅에 사용.

2. 하나의 인스턴스 상의 여러 애플리케이션에 부하를 분산.(ECS, 컨테이너 등에 사용됨)

3. HTTP/2, WebSocket을 지원함.

4. redirect 지원함(HTTP에서 HTTPS로 트래픽 자동 리다이렉트도 지원함)

5. 경로 기반(URL 경로 기반)으로 서로 다른 타겟 그룹에 라우팅 가능, URL의 hostname 기반으로 라우팅 가능, 쿼리 스트링과 헤더 기반 라우팅 가능

✔️target group(대상 그룹)

ALB는 여러 대상 그룹으로 라우팅 할 수 있고, 헬스 체크는 대상 그룹 레벨에서 이루어진다.

ec2 인스턴스들이 target group이 될 수 있으며, 이 ec2 인스턴스들은 오토 스케일링 그룹에 의해 관리될 수 있음. - HTTP

ecs task가 target grup이 될 수 있으며, ECS에 의해 관리됨. - HTTP

Lambda 함수가 target group이 될 수 있음. - HTTP 요청을 JSON으로 변형

IP 주소가 tagret group이 될 수 있음. - 반드시 사설 IP 주소여야 함.

✔️알아두면 좋은 점

1. ALB에 고정 hostname이 부여된다.

2. 서버 애플리케이션은 클라이언트의 IP를 직접적으로 확인할 수 없고, 클라이언트의 IP는 X-Forwarded_for라고 불리는 헤더값으로 사용된다.
   port와 protocol 또한 X-Forwarded-Port/Proto로 사용되는 포트와 프로토콜 정보를 얻을 수 있음.

클라이언트가 직접 ALB와 통신하고, ALB는 연결 종료 작업을 수행하며, 로드 밸런서가 EC2 인스턴스오 통신할 때는 로드 밸런서 IP(사설 IP)룰 사용해서 EC2 인스턴스와 통신하게 된다.

✔️ALB 생성

ALB를 생성할 때 VPC와 ALB를 생성할 가용 영역을 선택해야 한다. 가용 영역은 두 개 이상 선택해야 하며, 가용 영역 당 하나의 서브넷을 선택한다.

ALB를 생성하면 하나의 퍼블릭 DNS를 가진다. AWS Application Load Balancer (ALB)를 생성할 때 여러 가용 영역(AZ)을 선택하면, 실제로 각 가용 영역에 ALB가 개별적으로 생성되는 것은 아님.

대신, ALB는 하나의 논리적 엔티티로 동작하며, 선택한 각 가용 영역에 걸쳐 트래픽을 분산시킬 수 있도록 내부적으로 구성된다.

ALB는 선택한 각 가용 영역에 하나 이상의 ENI(Elastic Network Interface)를 생성하고, 이러한 ENI는 각 가용 영역에 트래픽을 분산시키기 위해 사용된다.

📌Listeners and routing

들어온 트래픽을 대상 그룹으로 라우팅한다.

대상 그룹을 생성하여야 하고, ALB는 특정 프로토콜 및 포트를 통해 들어온 트래픽을 매핑한 대상그룹으로 라우팅한다.

대상 그룹에는 헬스 체크 경로를 지정해야 하고, 실제로 이 헬스 체크 경로로 ALB가 헬스 체크를 진행하기 때문에 해당 경로에 200 요청을 응답할 수 있도록 해야한다.

대상 그룹에 할당할 인스턴스들을 고르고, 이 인스턴스에서 사용하는 포트 또한 대상 그룹을 생성할 때 지정한다.

✔️ALB Listener rule

ALB 리스너에서는 listener rule을 추가할 수 있다.

기본 규칙으로 ALB를 생성할 때 Listeners and routing에서 지정했던 라우팅으로, 특정 프로토콜 및 포트로 들어온 트래픽을 매핑된 대상그룹으로 라우팅 하는 규칙이 생성되어있다.

그 외에 다른 규칙들을 추가할 수 있다.

추가하는 규칙에는 여러 종류가 있다.

📌규칙 추가

규칙 이름을 정하고, 컨디션 및 액션, 우선순위 등을 정하여 생성한다.

👉conditions

condition을 추가해야 하는데, 이 규칙에서 어떤 조건으로 트래픽을 필터링 할 것인지 고르는 것이다.

condition type으로는 Host header, Path, HTTP Request Method, Source IP, HTTP header, Query string 등으로 존재한다.

rule을 추가할 때 rule limit 또한 확인할 수 있다.

👉actions

이 규칙에서 수행할 actions을 정의한다. 특정 condition에 해당하는 트래픽을 어떻게 처리할 것인지 정해주는 부분이다.

📒elb with ssl/tls

✔️ssl/tls

원래는 tls라고 해야 맞지만, 대부분의 사람들이 ssl이라고 이야기하고, 다들 그냥 알아서 이해하는 듯하다.

ssl(tls) 인증서는 클라이언트와 로드밸런서 사이에서 트래픽이 이동하는 동안 통신하는 데이터를 암호화 해준다(in-flight encryption, 전송 중 암호화)

Public SSL 인증서는 CA(Certificate Authorities)에서 발급해주는데 인증 기관에는 Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Letsencrypt 등등 여러 기관이 있다.

Public ssl 인증서를 로드 밸런서에 추가하면, 클라이언트와 로드밸런서 사이의 연결을 암호화 할 수 있다.

ssl 인증서는 만료 날짜가 존재하기 때문에 주기적으로 갱신해줘야 한다.

✔️로드밸런서 - ssl certificate

client와 로드밸런서 사이에서는 암호화된 통신이 오고가고 ALB에서 ssl terminate 작업이 이루어진다.

로드밸런서와 EC2 인스턴스 사이에는 HTTP를 사용해서 통신하는데 VPC로 프라이빗 네트워크를 사용하기 때문에 안전하다.

로드밸런서는 X.509 인증서를 사용하는데 이를 ssl/tls 서버 인증서라고 부르고, aws에도 인증서들을 관리할 수 있는 ACM이 존재한다.

클라이언트는 SNI(Server Name Indication)을 사용해서 접속할 호스트의 이름을 알릴 수 있다.

📌SNI(Server Name Indication)

SNI는 하나의 웹 서버에서 여러 개의 SSL 인증서를 로드하여 하나의 웹 서버가 여러 개의 웹 사이트(서버)를 지원할 수 있도록 해줍니다.

SNI는 확장된 프로토콜로, SSL 핸드쉐이크 초기화 과정에서 클라이언트가 대상 서버의 호스트 이름을 지정하도록 한다.

따라서 클라이언트가 어떤 웹 사이트(서버)에 접속할 것인지 지정하기 때문에 서버는 어떤 인증서를 로드해야하는지 알 수 있게 된다.

이는 새로운 프로토콜이기 때문에 ALB와 NLB, CloudFront에서만 동작한다.

클라이언트가 특정 도메인을 사용하는 웹 사이트(서버)에 접속하고 싶다고 요청을 보내면 로드밸런서는 그 도메인에 해당하는 SSL 인증서를 가져와 SSL 핸드쉐이크 초기화 과정에서 트래픽을 암호화한 다음, 리스너 규칙에 따라 대상 그룹에게 트래픽을 라우팅한다.