nginx로 https 적용해서 서버비용 줄이기

Astin·2024년 10월 2일
solitour
0

문제상황

ec2 프리티어를 사용해서 spring서버를 구성했는데 위와 같이 비용이 발생했습니다.

그래서 청구서를 자세히보니 ipv4에 0.005달러식 과금이 부과되어 있는걸 확인했습니다.

구글링 결과 이는 ec2 인스턴스 이외의 ipv4 ip가 사용되어 발생하는 원인이었습니다. 그래서 어디서 ipv4를 사용하고 있는 지 파악하기 위해 AWS 콘솔 > VPC IP Address Manager (검색창에 address라고 치면 나옴) 를 사용했습니다

해당 기능을 사용하기 위해서 우선적으로 ipam을 설정해줘야 했습니다.

데이터 복제 허용을 체크하고 현재 프리티어를 사용하므로 프리티어를 체크하고 ipam을 생성합니다.

ipam을 생성하고 VPC IP Address Manager > 퍼블릭 IP 인사이트 > 퍼블릭 IP주소 섹션을 확인하면 됩니다. 다만 리전내 ipv4를 검색하는데 시간이 걸리니 잠시 기다릴 필요가 있습니다. 기다리면 위와 같이 현재 사용중잉 ipv4를 알 수 있습니다. 저의 경우 현재 퍼블릭 ip 주소를 3개나 사용해서 과금이 되었음을 여기서 알 수 있었습니다.

좀 더 자세히 보면 로드 밸런서에 ip가 2개 할당되어 있었습니다. 이는 저번에 https를 설정하면서 aws에 있는 elb를 이용했기에 생긴 ip였습니다. 따라서 aws elb가 아닌 ec2 인스턴스를 이용해서 로드 밸런서를 설정해줘야 해당 비용을 아낄 수 있다고 결론을 내렸습니다.

어떤 로드 밸런서를 사용할 것인가?

ec2 인스턴스를 통해 구축할 수 있는 것은 소프트웨어 기반 로드 밸런서이므로 해당 리스트를 우선 조사하고 각각이 가진 장단점을 비교해서 선택하기로 했습니다. 찾아보니 가능한 옵션으로 nginx, HAProxy,Traefik, Apache HTTP Server 정도가 있었습니다.

  1. NGINX
  • 특징
    • 정적 콘텐츠 처리와 리버스 프록싱에서 강점.
    • 비동기 이벤트 기반 아키텍처로 고성능 제공.
    • TCP/UDP와 HTTP/HTTPS 모두 로드 밸런싱 가능.
    • 캐싱 기능 내장.
  • 장점
    • 설정이 간단하고 성능 최적화 가능.
    • 다목적 사용 가능: 웹 서버, 리버스 프록시, 로드 밸런서.
    • 다중 알고리즘 지원(예: Round Robin, Least Connections).
  • 단점
    • 실시간 트래픽 모니터링 도구 부족.
    • 빌드 시 필요한 모듈을 선택적으로 컴파일해야 함.
  1. HAProxy
  • 특징
    • 고성능의 TCP/HTTP 로드 밸런싱.
    • Health Check, 세션 유지 및 상세 로드 밸런싱 정책 지원.
    • 실시간 상태 대시보드 제공.
  • 장점
    • 매우 높은 처리량과 낮은 지연 시간.
    • 가볍고 메모리 사용량이 적음.
    • 설정 파일이 직관적이며 효율적.
  • 단점
    • 설정 변경 시 서비스 재시작 필요.
    • HTTPS 처리(SSL 종료)는 설정이 복잡할 수 있음.
  1. Traefik
  • 특징
    • 컨테이너와 마이크로서비스 환경에 최적화.
    • Docker, Kubernetes, Consul 등과의 자동화된 통합.
    • Let’s Encrypt를 통한 SSL 인증서 자동 관리.
  • 장점
    • 설정이 간단하고 동적 서비스 디스커버리 가능.
    • 클라우드 네이티브 애플리케이션과의 호환성 우수.
    • 웹 UI 기반 상태 모니터링 및 관리.
  • 단점
    • 전통적인 워크로드에는 적합하지 않을 수 있음.
    • 대규모 환경에서 성능 튜닝 필요.
  1. Apache HTTP Server (mod_proxy_balancer)
  • 특징
    • Apache 모듈(mod_proxy_balancer)로 로드 밸런싱 기능 제공.
    • HTTP/HTTPS 기반의 기본 로드 밸런싱.
    • .htaccess 기반 디렉터리별 설정 가능.
  • 장점
    • 기존 Apache 기반 애플리케이션과 통합 용이.
    • 동적 콘텐츠와 정적 콘텐츠 혼합 환경에서 유리.
  • 단점
    • 고성능 로드 밸런싱 요구에는 적합하지 않을 수 있음.
    • 설정이 다소 복잡하고, 최신 대안 대비 비효율적.

HAProxy는 고성능 트래픽 처리에서 탁월하고 특히, 대규모 트래픽에 강점이 존재했습니다. 다만, 초기의 서비스의 경우 설정 변경이 잦을 것으로 예상되었고 htttps 처리 설정이 복잡하다는 단점이 있었습니다.

Traefik은 분산 컨테이너 환경에 최적화된 로드밸런서로 현재의 모놀리틱 서버 환경으로 구성된 상황에서는 적합하지 않다고 생각했습니다.

Apache mod_proxy_balancer는 기존 apache 기반 앱과 라이브러리를 사용한다면 가장 좋은 선택지겠지만 현재 서버에서는 apache 기반 앱과 라이브러리를 사용하지 않으므로 제외시켰습니다.

NGINX는 정적 콘텐츠, 리버스 프록싱, 로드 밸런싱 등 다목적 활용 가능하고 소규모 트래픽을 효율적으로 처리할 수 있어 현 상황에 가장 적합하다고 판단하였습니다. 또한, 기본적인 실시간 트래픽 모니터링이 부족하다는 단점은 추후에 Prometheus + Grafana, datadog 같은 모니터링 시각화 외부 라이브러리를 활용해서 보완할 수 있다고 판단하여 채택하였습니다.

ec2에서 nginx 설치(ubuntu)

따라서 우선 ec2에서 nginx 설치를 진행하였습니다.

패키지 목록 업데이트

sudo apt-get update

Nginx 설치

sudo apt-get install nginx -y

Nginx 시작

sudo systemctl start nginx

Nginx 상태 확인

sudo systemctl status nginx

여기까지 하면 nginx가 정상적으로 실행되는 것을 확인할 수 있습니다.

도메인 구매

HTTPS를 사용하면 데이터 전송이 암호화되므로, 쿠키 탈취(특히 세션 쿠키)와 같은 보안 문제를 방지할 수 있습니다. 저는 jwt 토큰을 쿠키에 저장하여 로그인을 처리했는데 보안을 높이기 위해 HTTPS를 사용했습니다.

다만, HTTPS 인증을 받기 위해서는 도메인이 필요했습니다. 도메인의 경우 도메인 구매 사이트에서 구하면 됩니다. 대표적으로 가비아, cafe24같은 국내 사이트, go daddy,네임칩 같은 해외 사이트가 있습니다. 저는 이용과 관리가 편하고 비용도 저렴한 가비아를 선택했습니다.

가비아에서 원하는 도메인을 선택해서 구매하고 나면 도메인 관리 사이트로 이동해야 합니다. my gabia > 서비스 관리> 해당 도메인 관리 버튼 을 누르면
아래와 같은 도메인 관리 페이지가 나오게 됩니다.

해당 도메인과 aws를 연결해주기 위해서는 네임서버를 넣어줘야 합니다. 이를 위해서는 Route53에서 호스팅 영역을 설정해 줄 필요가 있습니다.

Route53에서 호스팅 영역 설정

route53에서 오른쪽의 호스팅 영역 설정을 클릭합니다.

도메인 이름을 설정하고 호스팅 영역 생성을 클릭합니다.

그러면 호스팅 영역이 생성되고 호스팅이름을 클릭하면 위와 같이 레코드 목록이 나옵니다. 우리는 가비아에서 산 도메인과 aws route53을 연결하는 것이 목적이므로 새로운 레코드를 생성해야 합니다.

값에는 aws ec2의 퍼블릭 ip 주소를 입력하면 됩니다.

a 레코드를 생성하고 나서 ns 레코드 편집을 눌러 레코드 편집을 누르면 값을 압력할 수 있는데 여기에는

아까 가비아 도메인 페이지에서 본 1~4차까지의 네임서버 값을 넣어주면 됩니다. 이때 주소의 마지막 . 은 빼고 넣어야 합니다.

이제 여기까지 했으면 https 인증을 하고 이를 로드밸런서에 연결해줘야 합니다. 기존에 이 과정을 저는 aws elb를 이용하여 처리하였습니다. 그러나 이로인해 지속적인 과금이 발생하였습니다. 따라서, 다른 방법을 찾아야 했는데 저는 https인증을 대신해주는 오픈소스 라이브러리cerabot과 nginx를 사용했습니다.

https 인증을 위한 SSL인증서 발급

Let's Encrypt

우선 Certbot 설치을 설치해야 합니다. Certbot은 Let's Encrypt에서 인증서를 발급받고 자동으로 웹 서버에 설정하는 도구로 사용중인 웹서버와 운영체제에 맞게 설치해야 합니다.

Ubuntu/Debian에서 Certbot 설치

sudo apt update
sudo apt install certbot python3-certbot-nginx

이후 아래 명령어를 사용하면 Certbot을 사용하여 Let's Encrypt에서 SSL 인증서를 발급받을 수 있습니다.

sudo certbot --nginx

로드 밸런서 설정

nginx

이제 가지고 있는 도메인으로 ssl 설정까지 했으니 Nginx의 사이트 설정 파일을 열고, HTTPS 설정을 추가하면 됩니다. 보통 설정 파일은 /etc/nginx/sites-available/default 또는 /etc/nginx/sites-available/yourdomain에 위치하고 있습니다.

server {
    listen 80;
    server_name solitour.shop www.solitour.shop;

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl http2;
    server_name solitour.shop www.solitour.shop;

    ssl_certificate /etc/letsencrypt/live/solitour.shop/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/solitour.shop/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;                                
    ssl_ciphers HIGH:!aNULL:!MD5;                                                                                           
    client_max_body_size 10M;                     
    
    location / {                                             
        proxy_pass http://localhost:8080;                     
        proxy_set_header Host $host;                           
        proxy_set_header X-Real-IP $remote_addr;               
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;                                                     
        proxy_set_header X-Forwarded-Proto $scheme;             
    }
  • listen 80: HTTP 요청을 수신하고 HTTPS로 리디렉션합니다.
  • listen 443 ssl: HTTPS 요청을 수신하고 SSL 인증서를 사용합니다.
  • ssl_certificate: SSL 인증서 파일 경로를 지정합니다.
  • ssl_certificate_key: 개인 키 파일 경로를 지정합니다.
  • ssl_protocols: 허용된 TLS 버전을 지정합니다.
  • ssl_ciphers: 보안 암호화 알고리즘을 설정합니다.
  • client_max_body_size : Nginx에서 클라이언트가 서버로 전송할 수 있는 최대 요청 본문 크기를 설정합니다.

저의 경우 서버와 프론트가 분리되어 서버만 올려야 했으므로 프록시를 사용해서 https 요청을 연결해주었습니다.

sudo nginx -t  # 설정 파일 구문 오류 확인
sudo systemctl reload nginx # nginx 재시작

설정한 후에는 구문에 오류가 없는지 체크하고 설정 파일에 오류가 없다면 Nginx를 재시작하여 변경 사항을 적용하면 https 적용이 정상적으로 됨을 확인할 수 있습니다.

마치며

기존에 aws로 편리하게 로드밸런싱과 https 설정을 해온 것을 nginx와 cerabot으로 직접 설정하면서 https와 로드밸런서가 작동하는 방식에 대해 알아볼 수 있었습니다. 또한, 이를 통해 시간당 0.005달러가 과금되는 것도 해결할 수 있었습니다.

참고

https://shortcuts.tistory.com/53

profile
Astin
이전 포스트

docker-compose를 이용한 SonarQube 도입기

다음 포스트

스프링 프레임워크(Spring framework)의 탄생 배경 (초기웹, CGI, Servlet) - 1편

0개의 댓글

관련 채용 정보