Elastic Load Balancer

글쓴이 상배 윤 날짜

AWS 서비스에서 가장 많이 다루게 될 서비스는 단연코 ELB(Elastic Load Balancer)일 것이다. ELB는 EC2로 구성된 IaaS 느낌의 서비스 뿐만 아니라, 컨테이너 기반인 ECS, Lambda를 이용한 Serverless 모델 그리고 PrivateLink를 이용한 SaaS 모델 까지 모든 영역에서 핵심적으로 사용한다.

로드밸런서가 클라우드의 모든 영역에서 핵심적으로 사용되는 이유는 클라우드의 스케일링 정책이 Scale-UP/Down이 아닌 Scae-In/Out을 기본으로 하기 때문이다. 유저 요청이 늘어나면, 인스턴스를 몇 개 더 실행해서 요청을 처리하고 요청이 줄어들면, 인스턴스 수를 줄여서 비용을 절감한다.

이를 이용 장애 내성(장애를 허용하되, 서비스는 지속되는)환경을 구성한다.

로드밸런서 개요

로드밸런서는 인터넷에 연결되는 단일 연결 지점이다. 인터넷에서의 모든 요청은 로드밸런서로 들어오게 되는데, 로드밸런서는 유저의 요청을 몇 개의 알고리즘에 따라서 로드밸런서 밑에 있는 (보통 두 개 이상으로 구성된)서버들로 분산 전송한다. 일반적으로 사용하는 스케줄링  알고리즘은 아래와 같다.

  • Round Robin : 새로운 요청을 최근 요청을 전송한 서버의 다음 서버로 보내는 방식이다. 모든 서버의 용량이 같을 때 효과적이다. 특정 서버에 부담이 걸릴 수 있다.
  • Least Connections : 좀 더 지능적인 접근 방식이다. 연결이 가장 적은 서버에 요청을 우선 분산한다. 로드밸런서는 각 서버의 연결 수를 알고 있어야 한다. 용량이 다른 서버들로 구성되더라도 효율적으로 요청을 분산 할 수 있다.
  • Ratio-based Round Robin : 특정 서버가 더 많은 요청을 받도록 수동으로 설정 할 수 있다. 예를 들어 A 서버가 B 서버보다 3배 더 많은 용량을 가지고 있다면, 3대 더 많은 요청을 처리하도록 할 수 있다.

아래는 www.joinc.co.kr 사이트의 구성이다.

www.joinc.co.kr는 3대의 서버로 이루어져 있다. 유저의 요청은 로드밸런서를 거쳐서 서버로 전달된다. 로드밸런서는 약 10초 간격으로 서버의 상태를 확인(Health Check) 한다. 유저의 요청이 연속으로 3번 이상 실패하면면, 서버가 요청을 처리 할 수 없다고 판단 해당 서버로는 요청을 보내지 않는다.  이론적으로  3개의 서버가 모두 실패하지 않는 이상 안정적으로 서비스 할 수 있다.

기타 로드밸런서들은 아래와 같은 기능들을 가진다.

  • TLS/SSL 오프로드와 가속
  • DDos(Distributed Denial of Service) 공격 방어
  • HTTP 압축
  • Direct Server Return : 요청과 응답이 다른 네트워크 경로를 가지는 비대칭로드 분산이다. 요청은 로드밸런서로 오는데, 응답은 로드밸런서를 거치지 않고 다른 네트워크를 타고 나간다.
  • Priority Queuing
  • Client authentication
  • Firewall
  • IPS(Intrusion prevention system)

L4 & L7 로드밸런스

Layer 4, Layer 7 로드밸런서의 줄임말이다. Layer는 OSI 7 Layer를 의미한다. 즉 L4 로드밸런서는 OSI 7 Layer의 4 Layer(전송계층 프로토콜)를 기준으로 요청을 분산한다. TCP, UDP 기반으로 분산한다고 보면 되겠다.

L7은 OSI 7 Layer의 & Layer 즉 애플리케이션 프로토콜로 요청을 분산 할 수 있다. HTTP가 대표적인 프로토콜이다. HTTP 프로토콜의 헤더, 혹은 본문에 있는 정보를 기준으로 요청을 분산 할 수 있다. 예를들어 /api/music 으로 향하는 요청은 음악 서버로 보내고, /api/photo 요청은 사진 서버로 보내는 일을 할 수 있다. 지능적인 로드밸런싱이 가능하다.

AWS의 ELB는 L4, L7 을 모두 지원한다.

ELB소개

ELB는 AWS에서 제공하는 완전 관리형 로드밸런서다. 사용자는 웹 콘솔이나 CLI를 이용해서 몇 분 안에 로드밸런서를 만들 수 있다. ELB는 고 가용성, 내결함성을 제공하며 요청에 따라서 자동으로 확장/축소된다.

ELB 종류

ELB는 3가지 종류의 로드 밸런서를 제공한다. 여기에서는 Application Load balancer만 설명한다. Network Load Balancer는 간단히 소개만 하고 기회가 되면 자세한 내용을 포스트하겠다.

Classic Load Balancer

밑에 설명할 Application Load Balancer이 나오기 전에 사용하던 이전 세대 로드밸런서다. 선택화면에서 회색으로 표시가 되서, 왠지 선택하면 안될 것 같은 느낌을 준다. 로드밸런서 설명서에도 아래와 같이 소개하고 있다.

Choose a Classic Load Balancer when you have an existing application running in the EC2-Classic network.

VPC에 전개하지 않은 특수한 경우를 제외하고는 Classic Load Balancer를 쓰지 말라는 이야기다. 새로 만들어야 한다면, Application Loa Balancer를 사용하자.

Classic Load Balancer는 Network Load Balancer의 하위 호환이다. 유일한 장점은 (단순해서)사용하기 쉽다는 점 정도겠다. 여기에서는 Classic Load Balancer는 다루지 않겠다. 쓸 일도 없을 테고, Application Load Balancer를 다룰 수 있게 되면, 껌으로 다룰 수 있을 테니까.

Application Load Balancer

L7 로드 밸런서다. L7인 만큼 HTTP의 컨텐츠(헤더정보)정보를 토대로 유저 요청을 분산 할 수 있다. 유저 요청은 VPC내에 있는 EC2 인스턴스, 컨테이너로 라우팅 할 수 있다. AWS에 제공하는 ACM(AWS Serfificate Manager)를 이용해서 SSL/TLS 인증서를 오프로드(offload)할 수 있다.

Application Load Balancer는 호스트 기반경로 기반으로 라우팅 할 수 있다. 호스트 기반 라우팅의 경우 music.api.com 도메인으로 향하는 요청은 음악 API를 제공하는 리소스로, map.api.com 도메인으로 향하는 요청은 지도 API를 제공하는 리소스로 각각 보낼 수 있다. 경로기반 라우팅의 경우 /api/music, /api/map 등 URL을 기반으로 각 리소스로 보낼 수 있다. 아래 그림을 보자.

이 서비스는 Music Api와 Photo Api를 제공한다. GET /music/* 요청은 Music API Server로 GET /photo/* 요청은 Photo API Server로 보낸다.

그밖에 아래의 기능을 제공한다.

  •  HTTP/2 지원
  • WebSocket 지원
  • IPv6 지원
  • Sticky Sessio
  • 상태 모니터링 : 주기적으로 상태를 학인해서, 정상상태의 리소스로만 요청을 보낸다.
  • 로깅 : 엑세스 로그를 S3로 저장할 수 있다.
  • 삭제보호 : 삭제보호를 활성화 해서 우발적인 삭제를 방지 할 수 있다.
  • 요청추적 : 로드밸런스에 수신되는 모든 요청에 대해서 “X-Amzn-Trace-id” HTTP 헤더를 추가한다. 이 값을 이용해서 요청을 추적 할 수 있는데, 특히 마이크로 서비스에서 요청을 추적/분석/디버깅/성능측정 할 때 유용하게 사용 할 수 있다.

Network Load Balancer

Network Load Balancer은 OSI 7계층에서 네번째 계층에서 작동하는 로드배런서다. 보통 L4 로드밸런서라고 부른다. Application Load Balancer 보다 더 낮은 계층에서 작동하는 만큼, 좀 더 범용적으로 사용 할 수 있다.

Network Load Balancer의 이점은 아래와 같다.

  •  일시적 워크로드를 처리하고 초당 수백만개의 요청으로 확장 할 수 있다.
  • 로드밸런서에 고정 IP 주소를 설정할 수 있다.
  • Classic / Application Load Balancer는 VPC 외부의 IP에 대해서 로드밸런싱을 할 수 없다.
  • 컨테이너화된 애플리케이션을 지원한다.
  • CloudWatch를 붙일 수 있다.

개인적으로 Network Load Balancer를 사용했던 이유는 “고정 IP” 때문이었다. 외부 서비스와 연동하기 위해서는 보안상의 문제로 ACL에 등록할 고정 IP를 제공해야 하는 경우가 있는데, Network Load Balancer가 이를 지원했기 때문이다. 다른 여러 기능들은 Application Load Balancer도 모두 지원하고 있는 것이라서 특별한 이점이라고 보기는 어렵다.

단점도 있는데 L4 계층에서 작동하기 때문에 HTTPS를 지원하지 않는다. 만약 HTTPS로 서비스하고 싶다면, 인스턴스 차원에서 사용자가 직접 SSL을 올려야 한다.

VPC 외부의 IP에 대한 로드밸런싱은 언젠가는 써먹을 곳이 있을 것 같다.

Application Load Balancer  설정

구성도

아래와 같은 인터넷 서비스 구조를 만들기로 했다.

Public subnet과 Private subnet을 구성한다. 그리고 가용 영역도 구성하기로 했다. 해서 총 4개의 subnet을 만들었다. EC2 인스턴스는 모두 Private subnet에 전개한다.

VPC 서브넷은 Virtual Private Cloud 포스트를 참고해서 만들도록 하자. ELB 기능만 테스트하려고 한다면, 굳이 위의 복잡한 구성을 따를 필요는 없다.

로드밸런서 설정

Select Loadbalancer Type 에서 Application Load Balancer 를 선택한다.

  • Name : 로드밸런서 이름
  • Schema : Intenet-facing와 internal이 있다. Internet-facing를 선택하면 인터넷에 노출된다. internal의 경우 vpc 내부에서만 사용 할 수 있다.
  • Listeners : 인터넷에 노출되는 Port 번호다. HTTP(80)을 선택 했다.

다음 가용 영역(Availability Zones)을 설정해야 한다. ELB를 전개할 VPC를 선택한다. ELB는 인터넷에서 접근해야 하기 때문에 반드시 Public subnet 영역에 위치해야 한다. 그래서 test-a.joinc.public 와 test-c.joinc.public 두 개를 선택했다.

configure security Group

시큐리티 그룹(Security Group)을 설정한다. my-alb-joinc-co-kr을 새로 만들었다. 인터넷(0.0.0.0/0)에서 80번으로 향하는 요청을 허가 한다.

Configure Routing

유저 요청을 어디로 보낼지(Routing)할지를 설정한다.

  • Target group : 요청을 보내는 타겟을 설정한다. EC2 인스턴스, ECS(컨테이너)를 타겟으로 설정 할 수 있다. 만들어 둔 타겟 그룹이 없으므로 “New target group”으로 하고 새로운 타겟 그룹을 만들기로 했다. 타겟 그룹의 이름은 “music-api-server”로 했다. music-api-server는 우리가 만든 ELB의 default target이 될 것이다.
  • Target type : Instance와 IP가 있다. EC2 인스턴스나 컨테이너는 IP가 변경될 수 있으므로 보통은 Instance를 선택한다. AWS Direct Connect나 VPN을 통해서 연결되는 리소스를 Target으로 설정 할 수 있는데, 이 경우 IP를 선택하면 된다. 인터넷에 공개된 IP 주소는 사용 할 수 없다.
  • Protocol & Port : 요청 프로토콜과 포트번호
  • Health Check : 헬스체크할 URL을 설정한다. ELB는 일정시간 간격(Interval)로 헬스체크를 수행해서, 그 결과로 라우팅 빼거나 넣는 등의 작업을 한다.

Register Targets

Target를 등록한다. 지금은 Target group이 없으므로 바로 Review 단계로 넘어간다. Target Group과 로드밸런서는 독립적인 자원이므로 나중에 붙여도 상관 없다.

Target Group

타겟그룹(Target group)는 로드밸런서에서 목표로 하는 동일한 설정을 가지는 논리적 리소스의 그룹을 말한다. 즉 EC2나 ECS로 구성된 웹 애플리케이션 서버들이 타겟 그룹이 된다.

타겟그룹은 로드밸런서와 독립적인 자원이기 때문에, 자유롭게 로드밸런서에 attach 혹은 detach 할 수 있다.

우리가 만들려고 하는 애플리케이션 서버의 요구사항은 아래와 같다.

  •  /music/api 는 Music 서버 군으로 향해야 한다.
  • /photo/api 는 photo 서버 군으로 향해야 한다.

요구 사항을 해결하기 위해서 각 서버군을 위한 Target Group를 만들기로 했다. Target Group에는 하나 이상의 EC2 인스턴스를 배치해야 한다. 가용성을 위해서는 최소한 2개의 인스턴스를 배치해야 할 것이다.

먼저 music-api-server target group을 위한 EC2 인스턴스를 배치해보자. EC2 인스턴스는 10.10.1.0/24 와 10.10.3.0/24 두 개의 private subnet에 배치하기로 했다. 이 서버에는 nginx를 설치하고 /musci/api 파일을 만들어서 /music/api 요청에 응답할 수 있도록 했다. EC2 인스턴스 실행 Nginx 설정은 여기에 기록하지 않는다.

동일한 방법으로 photo-api-server target group를 위한 인스턴스를 만들어서 private subnet에 배치했다. 역시 nginx를 설치하고 /photo/api 파일을 만들어서 /photo/api 요청에 응답할 수 있도록 했다.

Target Group Name
subnet
자원 타입
music-api-server10.10.1.0/24
10.10.3.0/24
EC2 Instance x 2
photo-api-server10.10.1.0/24
10.10.3.0/24
EC2 Instance x 2

인스턴스 상황은 아래와 같다.

Target Group 만들기

Target group name, type, protocol, port 그리고 Target Group에 넣을 자원(EC2 인스턴스)이 배치된 VPC를 설정하고 “Create” 버튼을 누르면 Target group이 만들어진다. photo-api-server Target group도 동일한 방법으로 만든다.

이제 Target Group에 자원을 등록하면 된다. music-api-server에 music-api-2a.joinc.co.kr, music-api-2c.joinc.co.kr 을 등록한다.

그냥 해당 VPC에 떠 있는 인스턴스를 선택하고 Add to registered 하면 된다. photo-api-server 도 동일한 방법으로 인스턴스를 등록한다.

ELB Listener 등록

이제 myalb-joinc-co-kr ELB에 위 Target Group을 Listener로 등록 하면 된다. Application Load balancer는 Host 기반 라우팅과 URL 기반 라우팅을 제공한다.

View/edit rules를 클릭해서 라우팅 룰을 설정 할 수 있다. 라우팅룰의 구성은 아래와 같이 설정했다.

룰은 1부터 last 까지 순서대로 적용된다. 즉 위의 경우

  1.  유저 요청이 /photo/api 일 경우 photo-api-server 타겟 그룹으로 요청을 전송.
  2. 유저 요청이 /music/api 인 경우 music-api-server 타겟 그룹으로 요청을 전송
  3. 일치하는 룰이 없을 경우 music-api-server 타겟 그룹으로 요청을 전송 한다.

실제 룰을 넣어보자. + 버튼을 클릭해서 룰을 추가 할 수 있다. 룰을 IF & THEN 형식으로 직관적으로 설정 할 수 있다.

/photo/* 요청을 photo-api-server 타겟 그룹으로 보내도록 설정했다. IF 에서는 “Host is…”와 “Path is…”를 선택해서 호스트 기반 라우팅과 경로 기반 라우팅을 설정 할 수 있다. THEN의 경우 5가지 유형의 Action을 선택 할 수 있다.

  1. Forward to… : 요청을 지정한 타겟 그룹으로 전달 한다. 가장 많이 사용하는 유형이다.
  2. Redirect to… : 요청을 다른 URL로 리다이렉션 한다.
  3. Return fixed response… : 사용자가 설정한 HTTP 응답을 반환한다.
  4. Authenticate-cognito : Amazon Cognito로 사용자를 인증 할 수 있다.
  5. Authenticate-oidc : OpenID Connect와 호환되는 자격 증명 공급자로 사용자를 인증 할 수 있다.

이제 ELB의 Endpoint DNS로 테스트를 하면 된다.

ELB의 몇 가지 제한

마지막으로 ELB의 몇 가지 제한을 살펴보고 포스트를 마치려고 한다.

  1. 로드밸런서는 가용 영역당 하나의 서브넷만 가질 수 있다.
  2. Target Group은 하나의 로드밸런서에만 연겨 할 수 있다. 이건 때때로 제약이 될 수 있는데, 웹 애플리케이션을 인터넷과 internal 모두로 서비스하기 위해서 internet facing 유형 ELB과 internal 유형 ELB를 만들어서 동시에 서비스하는 구성을 만들 수 없다. 뭐, 심각한 제약이라고 할 수는 없다.

정리

  • Classic, Application, Network 3 개 유형이 있다. 일반 적인 웹 애플리케이션은 Application 유형을 사용한다.
  • ELB와 Target Group는 서로 독립적이다.
  • 하나의 Target Group은 하나의 ELB에만 붙일 수 있다.
  • Application 유형 ELB는 호스트 및 경로 기반으로 라우팅 할 수 있다.
  • ELB는 Internet facing와 Internal 영역에서 작동 할 수 있다.
  • ELB는 SSL 인증서 offload 기능을 지원한다. ACM을 사용 할 경우, AWS에서 인증서 만료 기간 등을 자동으로 관리해 준다.

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다

Bitnami