1. AWS Elastic Load Balancing

 Auto Scaling Group 구성이 끝났으니 Elastic Load Balancing(AWS의 로드 밸런서 역활을 하는 서비스, 이하 ELB)를 구성하여 로드 밸런싱을 해보겠습니다.

보통 로드 밸런서도 일종의 서버지만 AWS에서는 로드 밸러서의 기능을 하는 서버를 내부적으로 관리하기 때문에 직접 들어가 볼 수는 없습니다..

ELB로 들어온 요청들은 특성 인스턴스나 설정한 Auto Scaling Group으로 전달이 가능한데, 너무 많은 요청을 처리하고 있거나 정상적으로 동작하고 있지 않은 서버에는 요청을 보내지 않습니다.

* ELB에 대한 요금은 https://aws.amazon.com/ko/elasticloadbalancing/pricing/ 에서 확인하실 수 있습니다.

 

 

 

* Target Group(대상 그룹)

대상 그룹은 ELB가 요청을 전해줄 서버들을 묶은 개념적인 그룹으로 생각하시면 됩니다.

그림에서 처럼 그룹에는 특정 인스턴스가 들어갈 수도 있고, Auto Scaling Group(ASG)이 들어갈 수도 있습니다.

ELB에 직접 인스턴스나 ASG를 등록하지 않고 왜 대상 그룹이라는 개념을 만들어서 중간에 두는 이유는 하나의 ELB에 여러 대상 그룹을 연결할 수 있고, 요청한 포트에 따라서 각기 다른 대상그룹으로 요청을 전달 할 수 있기 때문입니다.

예를 들어, 80/443 port로 들어오는 요청은 대상 그룹 A에, 8000 port로 들어오는 요청은 대상 그룹 B로 가도록 설정할 수 있습니다.

 

# ELB는 서버가 요청을 받을 수 있을때만 요청을 전해준다!

ELB에서는 서버가 정상적으로 활동 중인지 확인을 위해서 Health Check 과정을 거치게 됩니다. 예를 들어 서버에서 GET/health라는 요청에 대해서 상태코드 200반응을 응답하도록 설정해 두고, ELB에 Health Check 경로를 GET/health로 등록해두면 ELB는 주기적으로 서버들에게 GET/health 요청을 보내게 됩니다. 이때 예상과 다른 응답이 오면 해당 서버가 정상적인 반응이 올 때까지 요청을 전달하지 않습니다.

물론, 검사 주기 및 몇 번이나 연속으로 비정상 코드 응답을 받을 때 비정상 상태로 판단할지 등을 설정할 수 있습니다.(정상에 대한 설정도 가능합니다)

 

2. 실습

2-1. 인스턴스 중지(stopped) 확인

생성은 대시보드에서 [로드 밸런싱] -> [로드밸런서] -> [로드 밸런서 생성] 을 클릭하면 됩니다.

Application Load Balancer, Network Load Balancer(신규), Classic Load Balancer

이렇게 세가지 항목을 확인 할 수 있는데 설명이 아래 잘 나와 있습니다. 저희는 HTTP, HTTPS 요청을 받을 것이기 때문에 ALB를 생성하겠습니다.

HTTPS 리스너를 구성하지 않아서 경고문이 뜨지만 우선 다음 : 보안 설정 구성 으로 넘어갑니다.(지금은 HTTPS 요청을 받지 않습니다.. 추후에 인증서 작업이 있으니 기다려주세요!)

보안그룹은 아래와 같이 미리 만들어둔 WEB만 선택하겠습니다.

여기서 ssh 그룹을 선택하지 않는 이유는 ssh를 이용해 로드 밸런서 서버에 접속할 일이 없기 때문입니다.

 

 

Health Check 경로를 /health로 해주는 이유는 샘플 프로젝트의 코드를 보시면 /health의 경로로 요청이 들어온 경우 상태코드 200을 반환하도록 구현이 되어있기 때문입니다.

간단하고 명료하게 구현이 되어있습니다. 약 3줄 뿐이기 때문에 직접 확인해 보셔도 좋습니다.

 

대상 등록화면을 보시면 실행 중인 인스턴스가 보입니다. 인스턴스를 직접 추가할 수도 있지만 저희는 Auto Scaling Group 자체를 대상 그룹에 등록할 것이기 때문에 그냥 넘어가겠습니다.

검토 후 생성을 마치시면 [로드 밸런싱] -> [로드 밸런서] 메뉴에서 생성된 ELB를 확인 할 수 있습니다.

 

2-2 Auto Scaling Group 을 대상 그룹으로 등록하기

대시보드에서 [AUTO SCALING] -> [Auto Scaling 그룹] 에서 생성했었던 ASG의 [세부 정보] -> [편집]으로 들어갑니다.

위와 같이 대상 그룹을 추가하고, [로드 밸런싱] -> [대상 그룹] 메뉴로 들어가면 아래와 같이 인스턴스가 제대로 등록 된 것을 볼 수 있습니다.

 

 

* 여기서 가용영역에 정상인 인스턴스가 없다! 라는 문구가 뜨시는 분들은 인스턴스에 들어가셔서 nginx가 기동이 되어있는지 확인하시기 바랍니다!

 

이제 구성한 다중 서버 환경이 제대로 동작하는지 확인하는 일만 남았습니다.

[로드 밸런싱] -> [로드 밸런서] 로 가서 생성한  ALB를 클릭합니다. 그리고 DNS 주소를 브라우저에 입력하면 아래와 같은 창이 뜹니다.

 

*여기서 nginx에 server_name 등록을 하지 않았는데? 라는 의문이 드실 수 있는데, nginx에서 요청을 받았을 때 정확히 일치하는 서버가 없더라도 요청에 가장 근접합 서버를 찾아서 실행을 해주기 때문에 어플리케이션이 올바르게 실행 된 것입니다.

 

3. Auto Scaling Group과 ELB를 사용한 장애 조치

저희는 일부 서버에 장애가 생기더라도 전체 시스템이 죽는 것이 아닌, 예비 시스템이 즉시 요청을 대신 처리해서 down time을 최소하 하는 것이 중요합니다.

이러한 장애 조치를 지금 까지 만들어온 Auto Scaling Group과 ELB를 사용하여 구현할 수 있습니다!

ELB의 기능중에 정상적인 반응을 주지 않은 인스턴스에는 요청을 전달하지 않는 기능이 있었습니다. 이 기능 덕분에 클라이언트에서 잠시 에러 응답을 받을 수는 있지만, 곧 바로 정상적인 응답만을 받을 수 있도록 조치 할 수 있습니다.

 

4.실습

바로 구현해보고 테스트까지 진행해 보도록 하겠습니다.

[로드 밸런싱] -> [대상 그룹] 에서 만든 대상그룹을 클릭하고 상태 검사를 아래와 같이 수정합니다.

아래는 항목에 대한 설명입니다.

* 경로 : 인스턴스가 정상인지 확인하기 위해 호출할 URL 주소. 인스턴스 내에서 해당 주소로 응답을 주도록 구성되어있어야함

* 정상 임계 값 : 연속으로 몇 번 정상 응답을 해야 정상 상태로 볼 것인가

* 비정상 임계 값 : 연속으로 몇 번 비정상 응답을 해야 비정상 상태로 볼 것인가

* 제한 시간 : timeout 시간으로 응답이 몇 초 이내로 오지 않을 때 비정상으로 판단할 것인가

* 간격 : 체크 주기

* 성공 코드 : 어떤 응답 코드를 성공으로 볼 것인가

 

[AUTO SCALING] -> [Auto Scaling 그룹] 에서 생성한 그룹의 [세부정보] 에서 목표용량 -> 2 / 최소 -> 2 로 편집한 뒤 저장합니다.

[인스턴스] 탭으로 가시면 인스턴스 2개가 기동중인 것을 확인 할 수 있습니다.

 

ALB의 DNS주소를 새로고침하면서 실시간으로 로그를 확인해 보겠습니다.

번갈아 가면서 요청이 잘 들어가는 모습입니다.

 

다음으로 장애 상황을 재현해보겠습니다. 마음에 안드는 서버의 nginx 서비스를 종료하고 똑같이 새로고침을 여러번 진행해 줍니다.

* 정말 빠르게 멈추시고 바로 진행해 주세요.. 성능이 좋아서 느릿느릿하시면 결과를 볼 수 없습니다... ㅜㅜ

위와 같이 Health Check를 통해 하나의 인스턴스를 비정상 상태로 판단하기까지는 요청 중 절반은 에러가 발생합니다.

하지만 곧 바로 새로고침을 눌러보시면 정상적인 서버로만 요청을 전달하기 때문에 모든 요청이 성공하는 모습을 확인하실 수 있습니다.

 

사용하신 인스턴스는 목표수량,최소,최대를 0으로 설정해서 종료해 주시기 바랍니다!

 

5. 마치며 

이제 다중 서버 구성을 마쳤으니 실제 운영 환경에 적용할 수 있느냐..라고 하면 아닙니다.

서비스를 외부에 오픈하려면 몇가지 추가 작업이 필요한데, 실제 사용자들이 접속할 수 있는 도메인을 지정하는것과, 안전한 통신이 가능하도록 HTTPS 프로토콜을 설정해 주는 일이 남아있습니다.

다음 실습에서는 위 내용들을 시작으로 진행해 가겠습니다. 감사합니다