AWS - Elastic Load Balancing (ELB)

1. Load Balancer란?

DevOps에서 핵심이라고 할 수 있는 서버 배포 관련 내용 중 가장 기본이라고 할 수 있는 로드 밸런서(Load Balancer)에 대해 알아보자. 스마트링크에서 개발 완료된 서비스를 배포할 때 기본적으로 사용하는 클라우드 인프라인 Amazon Web Service (AWS)에서 제공하는 Elastic Load Balancer를 기준으로 설정 방법을 설명하려고 한다. 

우선, 먼저 Amazon의 Elastic Load Balancer 설명을 보도록 하자.

Elastic Load Balancing이란 무엇입니까?

Elastic Load Balancing은 여러 가용 영역에서 수신되는 애플리케이션 트래픽을 여러 EC2 인스턴스에 자동으로 분산합니다. 이렇게 하면 애플리케이션의 내결함성이 향상됩니다.

로드 밸런서는 클라이언트에 대해 단일 접점의 역할을 하여 애플리케이션의 가용성을 높입니다. 애플리케이션에 대한 요청의 전체적인 흐름을 방해하지 않고 필요에 따라 로드 밸런서에서 인스턴스를 추가 및 제거할 수 있습니다. 애플리케이션에 대한 트래픽이 시간에 따라 변화하므로 Elastic Load Balancing이 로드 밸런서를 자동으로 확장하며 대다수의 워크로드를 자동으로 확장할 수 있습니다.

로드 밸런서가 정상적인 인스턴스에만 요청을 보낼 수 있도록 등록된 인스턴스의 상태를 모니터링하는 데 사용되는 상태 확인을 구성할 수 있습니다. 또한 인스턴스가 주요 작업에 집중할 수 있도록 암호화 및 복호화 작업을 로드 밸런서로 오프로드할 수 있습니다.

"가용 영역", "단일 접점", "워크로드, 암호화 및 복호화 작업을 로드 밸런서로 오프로드 할 수"...  혹시 이 설명을 읽고 Load Balancer가 무엇인지 바로 이해가 되시는 분은 주저하지 말고 우리 회사 채용공고에 지원하시라. 채용은 따놓은 당상이니!!! ㅎㅎ

그렇다. Amazon이 무수히 많은 인프라서비스를 제공하지만 그 어떤 서비스도 한글로 제대로 설명하는 서비스가 없다. 물론, 다국적 서비스답게 원어(영어)로 설명하는 경우는 설명이 제대로다. 이런 이유로, 아래의 세부 설정 방법에서 사용되는 모든 용어와 스크린샷은 원어(영어) 기준으로 설명을 진행할 것이다!

좀 더 인간적인 설명을 찾아보자. 

*로드밸런싱의 정의 : 
로드밸런싱이란(Load Balancing)이란 하나의 인터넷 서비스가 발생하는 트래픽이 많을 때 여러 대의 서버가 분산처리하여 서버의 로드율 증가, 부하량, 속도저하등을 고려하여 적절히 분산처리하여 해결해 주는 서비스입니다.

*로드밸런싱 서비스 방식 : 
네트워크 상단에 L4스위치 가상서버가 존재하여 서버로 들어오는 패킷을 리얼 서버로 균일하게 트래픽을 부하 분산시킵니다.
만약 리얼 서버 중 정상적으로 작동하지 않는 경우가 발생하면 이를 감지하여 정상적으로 작동하는 서버로 부하 분산시킵니다.

*로드밸런싱의 장점 : 
1. 고가의 서버로 확장하지 않고 저렴한 비용으로 다수의 서버를 증설하여 경제적으로 비용절감 할 수 있습니다.
2. 대량의 트래픽으로 1대의 서버로 집중적인 부하율이 높아지면 L4 스위치가 이를 감지하여 합리적으로 부하분산 처리 할 수 있습니다.
3. 1대의 서버 장애가 발생하여도 서비스 중단없이 다른 서버로 적절히 자동으로 분배하여 서비스가 계속 운용가능하게 할 수 있습니다.
4. 추후 사용량이 많아 서버 확장으로 서비스 중단없이 서버 증설이 가능 합니다.

한마디로 말해서 Load Balancer는 여러대의 서버로 로드(요청 또는 트래픽)를 "적절하게" 분산해주는 역활을 하는 서버 또는 서비스이다. 아래의 그림을 보자.

위에서 말한 "적절하게"의 방식에 따라 로드 밸런스는 아래와 같이 크게 2가지로 나뉜다. 

1. L4 Load Balancer: OSI 7 Layer 중 Layer 4를 지원하는 Load Balancer이다. TCP나 UDP등이 대표적인 Layer 4 프로토콜이며, IP 주소와 포트 번호를 기준으로 트래픽을 분배한다.
2. L7 Load Balancer: OSI 7 Layer 중 Layer 7를 지원하는 Load Balancer이다. HTTP가 대표적인 Layer 7 프로토콜이며, HTTP 헤더의 내용을 기준으로 트래픽을 분배한다. 사용자의 Session에 따라 부하 분산을 하기 위해서는 L7 Load Balancer가 필수이며, AWS Elastic Load Balancer에서는 Application Load Balancer라는 이름으로 L7 Load Balancer를 서비스하고 있다.

추가로, Elastic Load Balancer의 동작 알고리즘은 기본적으로 Round Robin 방식(요청이 들어올때 마다 다른 서버로 부하 분산)을 사용하는데, 옵션으로 Sticky Session을 설정하는 경우 Session이 연결된 이후에는 다른 서버로 분산하지 않고 HTTP 헤더에 기존 Session이 설정된 서버로 요청이 가도록 할 수 있다.

사실 예전에는 부하 분산과 고가용성을 지원 하려면 별도의 L4/L7 장비나 서버를 구입해야 했기 때문에, Load Balancer가 일반 개발자들의 영역은 아니었다. 네트워크 전문가 또는 System Administration 담당자가 서비스의 부하를 측정하여 장비를 늘리면서 설정하는 경우가 대부분이었으나 클라우드 서비스 시대가 오고 DevOps가 일반화 되면서 상황이 많이 바뀌었다. AWS와 같은 클라우드 서비스에서 가장 빛을 발하는 부분이 바로 고가의 하드웨어를 구매하지 않고 손쉽게 사용할 수 있는 Elastic Load Balancer나 Auto Scaling이 아닌가 싶다.

2. AWS Elastic Load Balancer의 특징 

AWS의 Elastic Load Balancer를 제대로 설정하기 위해서는 AZ(Availability Zone) 개념을 이해해야 한다. 또한 AZ 개념을 제대로 이해하기 위해서는 Region에 대한 개념을 이해하고 있어야 한다. 사실 Region과 AZ에 대해서는 개념도 단순하고 잘 설명한 글들이 워낙 많으니 쉽게 찾아 보고 이해할 수 있을 것이나, 간략히 설명하자면, Region은 AWS가 입점(?)한 나라 또는 대륙이라고 보면되고, AZ는 각 Region내의 물리적인 데이터센터라고 이해하면 된다. 참고로, 몇년전까지만 해도 우리나라에는 AWS Region이 존재하지 않았었기 때문에, AWS로 서비스를 배포할때 마다 일본 Region이 네트워크 부하나 속도가 괜찮을지, 싱가폴 Region이 괜찮을지를 쓸데없이 고민하곤 했었다. 

아무튼 Elastic Load Balancer를 제대로 설정/활용하기 위해서는 다음을 꼭 기억하자!

"최소 2개 이상의 인스턴스가 각기 다른 AZ에 존재해야 한다."

생각해보면 너무나도 당연한 말이지 않는가?! AZ는 물리적인 데이터센터 이기 때문에 하나의 데이터센터가 테러, 화재, 천재지변 등으로 인해 서비스 불능 상태가 되더라도 다른 데이터선터가 하나라도 살아 있고 Load Balancer가 그쪽으로 트래픽을 전달해주기만 한다면, 나의 서비스가 중단되는 일은 없을 것이기 때문이다. 사실 이런 이유 때문에 이후 Load Balancer설정에서 Target에 대한 Health check를 설정한다.

3. 설정방법

AWS에서 L7 Load Balancer를 지원하는 서비스 명은 Elastic Load Balancer, 줄여서 ELB라 부른다. ELB 또는 다음 블로그에서 설명할 Auto Scaling의 경우 Elastic Cloud Computing (EC2)에 속한 기능이므로 ELB와 Auto Scaling을 사용하기 위해서는 AWS의 많은 서비스들 중에서 EC2를 선택하여 EC2 Dashboard 화면으로 진입한다.

ELB세팅을 하기 위해서는 너무나도 당연하게 로드를 분산할 EC2 인스턴스가 최소 2개 이상이 있어야 한다. 또한 앞서 언급한 것과 같이 고가용성(High Availability)을 위해서는 두개의 AZ(Availability Zone)에 EC2 인스턴스를 분산해야 한다. 그래야 하나의 AZ가 죽더라도 다른 AZ에서 운영중인 EC2로 인해 서비스 전체가 죽어버리는 일이 없기 때문이다. 아래는 예제로 보기 위한 최근 런칭한 서비스의 대쉬보드이다. 보이는 바와 같이 현재는 ELB나 Auto Scaling이 적용되어 있지 않으며, 아래와 같이 기본적인 Web 서버와 DB 서버가 동작중이다. 

MongoDB의 경우 일반적인 Web Server와는 다른 방식으로 고가용성을 지원해야 하므로, 이 블로그에서는 Web Server의 고가용성을 위한 ELB 설명에만 집중하기로 한다. MongoDB의 고가용성에 대해서는 별도의 블로그 포스트를 통해 설명할 예정이다.

3.1. 사전작업 (EC2 인스턴스 2개 만들기)

앞서 설명한 것과 같이 서로 다른 AZ에 EC2 인스턴스를 만들어야 한다. 쉬운 방법은 기존에 만들어진 EC2 인스턴스 동일한 세팅을 그대로 적용하되, AZ 존만 다르게 설정하는 것이다. EC2를 선택한 다음 Actions 메뉴에서 "Image"를 선택하거나 "Launch More Like This" 이용하여 동일한 인스턴스를 생성하는 할 수 있는데, 여기서는  "Launch More Like This" 방법으로 진행해 보자.

아래와 같이 기존 EC2와 동일한 세팅으로 인스턴스가 생성될 수 있도록 모든 설정값이 자동으로 입력되고, 인스턴스를 실제로 런칭할 수 있는 마지막 단계인 Review 단계로 넘어가게 된다. 

잠깐, 여기서 바로 "Launch" 버튼을 누르지 말고 화면 상단의 "3. Configure Instance" 단계로 돌아가 AZ 설정을 변경한다. 앞서 설명한 대로 기존 EC2와는 다른 AZ를 선택한다. 

기존 EC2의 AZ는 "ap-northeast-2a" 였으므로, 이번에는 아래와 같이 "ap-northeast-2c"로 변경 후 화면 하단의 "Review and Launch" 버튼을 클릭한다.

다음 단계로, 새로운 EC2 인스턴스를 Launch 하기전에 Key Pair를 새로 생성할 것인지 기존 Key Pair를 재활용할 것인지 물어보는데, 기존 Key Pair를 사용하도록 설정하고 "Launch Instance"를 클릭한다.

이후 런칭 상태를 보여주는데, "View Instance" 를 누르면 EC2 인스턴스 목록화면으로 돌아간다.

결론적으로, 아래와 같이 기존 EC2인스턴스와 AZ 설정만 다른 새로운 인스턴스가 생성된 것을 볼 수 있다. 다시한번, 기존 EC2의 AZ는 ap-northeast-2a 이며, 새로 생성된 EC2 인스턴스의 AZ는 ap-northeast-2c 인것을 확인한다.

3.2. Load Balancer 생성하기

이제까지는 Load Balancer를 적용하기 위한 사전 작업이었다면, 지금 부터는 본격적으로 ELB를 생성하고 다루는 본게임이다. 아래와 같이 EC2 인스턴스 목록 화면의 좌측 메뉴에서 "LOAD BALANCING" 섹션의 "Load Balancers"를 선택한다.

"Create Load Balancer"를 클릭해서 다음 화면으로 넘어간다.

ELB에서 지원하는 Load Balancer는 총 3가지 이며 Application Load Balancer는 L7 Load Balancer로, Network Load Balancer는 L4 Load Balancer로 이해하면 되겠다. 우리는 향후 Sticky Session 지원을 위해 HTTP head를 통한 트래픽 분산이 필요하니 당연 L7 Load Balancer인 Application Load Balancer를 선택한다.

Load Balancer의 이름을 입력한다.

다음으로 Load Balancer가 트래픽을 분배할 AZ를 선택한다. 

다음은 SSL(HTTPS)에 대한 설정을 하지 않는 경우 나오는 Warning이므로, 지금은 패스~

Security Group을 새로 만드는것을 추천한다. 기본적으로 일반 80 포트로 서비스하는 경우에는 80포트만 inbound 접속 가능하도록 설정해준다.

3.3. Target Group 생성

여기서 부터가 기존 Load Balancer와 비교시 조금 달라진 부분이다. 기존에는 Load Balancer내에 Target Group이 포함되어 있었으나, 지금은 두개가 분리되었다. 일반적으로 DNS에 세팅된 Load Balanacer의 DNS를 변경하지 않고 Target Group을 여러개로 구성할 수 있으니 편의성이 더 올라갔다고 볼 수 있다.

Target Group의 이름을 쓴 후 Target Group의 Health Check 옵션을 변경할 수 있는데, 보통 기본값을 쓰면 무난한다. 

Target Group 설정에서 가능 중요한 부분이다. 앞서 설정한 Load Balancer의 설정에서 선택된 AZ에 포함된 모든 EC2 인스턴스가 Instances 목록으로 나타나고 선택한 EC2 인스턴스를 Load Balancer의 Target으로 등록할 수 있다.

MongoDB 서버를 제외한 Web Application 서버가 동작중인 10X Web1과 10X Web2를 선택하고 "Add to registered"를 클릭한다.

아래와 같이 선택된 EC2 인스턴스가 "Registered targets"로 등록된 것을 확인 할 수 있다. 하단의 "Next: Review" 버튼을 클릭하여 다음 단계로 넘어간다.

마지막 단계 리뷰 단계이다. 앞서 설정된 값들이 모두 제대로인지 확인 후 "Create" 버튼을 누르자.

기분좋은 초록색 성공화면!

3.4. Sticky Session

자, 이제 거의 마지막! 로그인 서비스가 있는 경우 단순 Round Robin 방식의 트래픽 분산인 경우 브라우저에서 예상했던 대로 동작하지 않고 여러 이상 증상을 경험할 수도 있다. 특히 Meteor와 같이 기본 Web Socket 기반의 기술인 경우는 무조건, Sticky Session을 설정해야 한다. 우선, 왼쪽 메뉴에서 LOAD BALANCING > Target Groups를 선택한다.

Target Group 화면에서 앞서 생성한 "10xELB"를 선택하면 아래 화면과 같이 Stickiness를 선택할 수 있다.

화면에서 원하는 세션을 길이 설정할 수 있다. 기본값인 하루로 둬도 무방하다.

설정 후 아래와 같이 변경된 적용 값을 확인 할 수 있다.

4. 맺음말

이렇게 해서 AWS의 ELB를 세팅하는 방법에 대해 알아 보았다. 기존 L4/L7 장비 구입부터 까다로운 네트워크 세팅 들을 잘 추상화해서 몇번의 클릭 만으로 Load Balancer를 뚝딱 세팅할 수 있으니 Production 환경에서 매우 유용한 서비스이다. 사실 각 Region 별로 Target Group을 추가하는 등, 본격적인 Production 환경에서는 더 세분화된 세팅이 필요하나 기본적인 Load Balancer의 개념과 ELB 사용법은 충분히 설명이 되지 않았나 생각한다. 

다음 블로그에서는 한발 더 앞선 기술이자 AWS와 같은 클라우드 인프라에서만 가능한 Auto Scaling에 대해 알아보도록 하겠다.