Monitoring_AWS_ELB_Costs

개요

그동안 ELB를 활용하여 무중단 배포를 구상하였다. Jenkins와 AMI,Blue/Green배포를 활용하여 무중단 배포에 대한 고민을 많이 하였다. 하지만 비용적으로 ELB 뒤에 서버가 한대만 바라보고 있었으며, ELB는 부하분산에 대한 역할보다 HTTPS리다이렉션 역할만 하는 중이었다.

AWS의 비용을 살펴보면 월 9만원 가량의 비용을 지출하고 있었다.
월 9만원이면 적은 돈이라고 생각할수도 있지만 연간 지출비용은 100만원 이상이기에 바꿔야 할 필요가 있다고 느꼈다.

ELB란?

ELB는 AWS의 부하분산 서비스이다.
(필자가 좋아하는)On-premise의 L4스위치와 다르게 부하분산뿐 아니라 부하분산 대상에 대한 헬스체크, 고정세션,SSL Offload,헬스체크를 통한 다운서버 제외 등이 가능하다.
또한 ELB는 단순 부하분산을 넘어 HTTP Header를 조작하여 전달 대상을 정하거나 고정 페이지를 반환하며, Amazon Certificate Manager(ACM)의 SSl인증서를 탑재하여 EC2의 부하를 줄이고,WAF를 앞에 내세워 보안 기능을 강화하거나 Cloudfront를 연결하여 반응 속도를 향상시키는등 다양한 기능을 한다.
또한 AutoScaling을 할 경우 ELB에 연동하여 EC2를 일정조건에 맞게 스케일링 할 수도 있다.

ELB의 구성

ELB는 AWS의 사용자 정의 네트워크인 Virtual Private Network에 탑재되며, 사용자의 요청을 받고 이를 VPC 내의 리소스에 적절히 부하분산 한다. 그렇기에 ELB는 외부의 요청을 받아들이는 리스너와 요청을 분산/전달할 리소스의 집합인 대상그룹으로 구성되며 ELB는 다수의 리스너와 대상그룹을 거느릴수 있다. 그리고 부하분산 대상인 대상 그룹 내 리소스들을 헬스체크를 활용해 끊임없이 상태를 확인받는다.

L4스위치의 구조

ELB,ALB(L7스위치)의 구조

ELB의 종류

ELB에는 크게 3가지 종류의 로드밸런서가 있다.

현재 코인/쩝쩝박사는 모두 ALB를 활용하고 있다

• Application Load Balancer
  HTTP,HTTPS의 특성을 주로 다루는 로드밸런서이다. 단순 부하분산 뿐 아니라 HTTP의 헤더 정보를 이용해 부하분산을 실시하는 것이 ALB의 가장 큰 특징이다.
• Network Load Balancer
  HTTP가 아닌 TCP/UDP에서 부하분산을 처리한다.
• Classic Load Balancer

nginx 로드밸런서 vs AWS ELB

aws에서 로드밸런싱 서비스를 제공하지만 nginx자체 설정으로도 로드밸런싱을 진행할 수 있다. AWS EBS의 단점은 여러 애플리케이션 또는 서비스를 지원하는데 필요한 별도의 Load Balancer 인스턴스를 생성해야 한다는 것이다. 반면 nginx는 별도로 인스턴스를 구성할 필요가 없이 리버스 프록시 형태로 운용이 가능하다. 다만 ELB는 공용IP및 https통신의 SSL종료를 처리하고 가용성 영역에서는 여러 웹서버의 NGINX간의 트래픽 균형을 조정하는 반면 NGINX서버는 실제 애플리케이션/서비스 계층에 대한 캐싱 및 전달 트래픽을 처리한다. 물론 둘다 사용하는 것이 이상적이지만 현 규모에서는 nginx만으로도 충분하다고 생각되었다.

인프라 살펴보기

ELB요금표를 확인해보면 시간당 0.0225달러이다. 온보딩을 받을때와 온보딩을 할때도 ELB를 활용해 HTTP -> HTTPS리다이렉트를 위해 사용하였다.
아무래도 이전에는 구글링을 통해서 ELB에 대한 이해보단 서비스구현을 위해 사용하였다는 느낌이 강하였다. 이전 WAF나 Cloudfront등을 활용하는 방안도 생각해 보았으나, 규모에 비해 불필요하다고 생각이 들어 도입하지 않았고 현재 도커스웜에서 클러스터링을 통한 부하분산, Datadog healthCheck를 진행중이었기에 더욱 활용성이 떨어진다는 느낌이 강했다. 이에 백엔드 트랙장과함께 Nginx를 활용한 Https리다이렉션을 하게 되었다.

진행과정

현재 ELB를 사용하는 도메인은 크게 쩝쩝박사와 코인 두가지가 있으며, 예시는 쩝쩝박사로 예시를 들도록 하겠다.

1. 도메인을 ELB에서 EC2에 연결하기
   
   
   
   도메인의 A레코드를 생성한다. 이때 대상값을 Ec2의 퍼블릭IP(탄력적IP)로 향하게 구성하면 된다.

2. Nginx설정

server { 
		# 서브도메인을 구성하면 이렇게 구성할 수 있다.
        server_name api.도메인.com;
        location / {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $http_host;
                proxy_pass http://127.0.0.1:8080;
        }
}

스프링을 사용한다면 다음과 같이 설정을 할 수 있다.

3. SSL인증서 발급 및 Https설정
   
   Let's Encrypt라는 기관(CA)을 통해 인증서를 발급받고 cerbot을 활용해 도메인에 적용하는 과정을 살펴보자.

cerbot을 설치하기 위한 snap을 설치하기

sudo apt update
sudo apt install snapd

cerbot설치

sudo snap install --classic certbot

설치를 완료했다면 인증서를 발급받자.

cerbot을 nginx에 연결

sudo certbot --nginx

이메일 입력 및 약관 동의를 하면 위와 같은 화면이 나온다.
우리가 nginx에 선언해둔 server_name에 대한 인증서 발급을 수행한다고 설명하고 있다.
현재는 한개의 도메인만 입력하였지만 여러개의 도메인도 연결이 가능하다.

발급이 완료되면 작성했던 파일에 cerbot이 SSl인증서를 적용하는 코드와 http->https리다이렉트 하는 코드를 적용한 모습을 볼 수 있다.(만약 처음 nginx를 작업한다면 aws보안그룹에서 443포트도 개방을 해줘야 한다.)

4. 인증서 갱신 자동화
   Let's Encrypt에서 발급해주는 인증서는 무료 인증서로 3개월의 유효기간을 가지고 있다.
   
   3개월 마다 직접 갱신을 하는것은 불편하기 때문에 cron을 활용하여 자동갱신을 해줄수 있다.

Crontab 열기

sudo crontab -e 

0 3 1 * * /usr/bin/certbot renew --renew-hook="sudo systemctl restart nginx"

위와 같이 매월 1일 오전 3시에 인증서가 갱신이 된다.

후기

기존에는 AMI/ELB가 무중단 배포에 필수적이라는 생각에 사용중이었지만 인프라 규모에 비해 비효율적으로 가동하고 있었기에 제거를 하였다. 비용적인 측면에서는 35퍼센트의 비용을 절감한 셈이기에 충분히 납득할만하다.물론 추후에 다시 필요하다면 연결하는 방식으로 운용을 할 것 같다.

출처
https://velog.io/@mingtorr/AWS-ELB-%EB%9E%80
https://aws-hyoh.tistory.com/128