NGINX 리버스 프록시 서버 설정 트러블 슈팅

개요

앞선 프로젝트처럼, 이번 프로젝트에서도 프론트엔드 팀이 Vercel 에 배포를 하였습니다. 배포된 Vercel 페이지에서는 HTTPS 통신을 사용해야 하고, 요청을 보안 처리 해줘야 하기 때문에, HTTPS 통신으로 API 요청을 받을 수 있어야 했습니다.

백엔드 API 서버에 직접 HTTPS 통신에 관한 설정할 수 있지만, 그렇게 하지 않고 SSL Termination 이라는 방식을 사용했습니다. 오프로딩(Offloading)은 시스템의 특정 작업이나 처리를 다른 시스템, 장치 또는 프로세스로 이전하여 메인 시스템의 부하를 줄이고 성능을 향상시키는 기술입니다. 백엔드 서버의 공통된 앞단의 한 곳에서 SSL 관련 처리를  모두 진행하는 것입니다. SSL Termination은 SSL Offloading의 한 형태로, SSL/TLS 연결이 로드 밸런서나 리버스 프록시 서버와 같은 중간 장치에서 종료되는 것을 의미합니다. 

앞선 프로젝트에서는 로드밸런서를 활용하여 SSL Termination 처리하였습니다.

https://programmer-may.tistory.com/176

서버에 HTTPS 요청 보내기 1편 - (feat. Mixed Content 에러 해결)

(이전 프로젝트 트러블 슈팅 포스팅 -  ALB 를 이용하여 Mixed Contents 에러 해결)

 

ALB를 활용하면, AWS 모듈을 하나 더 사용하므로써 비용이 과다 청구될 수있기에, 비용 절감 측면에서 저번 프로젝트와는 방식으로 SSL Termination 처리할 것을 팀에 의견 어필했습니다. 팀 내에선 인프라 담당이 저 혼자이니 저의 의견을 따른다고 하였고, 비용도 절감할 수 있어서 좋다고 했습니다.

ALB를 활용하는 것이 아니라 오픈소스 웹서버를 리버스 프록시 서버로 구축하여 문제를 해결했습니다.

 

리버스 프록시 서버 활용 : 아파치 혹은 NGINX 를 구동시켜 리버스 프록시 서버를 만들어  백엔드 서버에 요청이 오면 먼저 리버스 프록시 서버에서 처리하게 됩니다. 리버스 프록시 서버에는 Let's Encrypt 같은TLS/SSL 인증서를 쉽게 가져오고 설치할 수 있는 CA(인증 기관)에서 제공하는 인증서를 설정하여 SSL Termination을 가능하게 합니다.

리버스 프록시 서버에서 HTTP 요청을 받으면 HTTPS 요청으로 리다이렉트 시키고, HTTPS 요청을 받으면 SSL Termination 한 후 평문 요청을 Path 맞는 백엔드 서버에 포워딩 해주게 됩니다.

 

Apache HTTP Server  VS NGINX

서칭 결과 리버스 프록시 서버나 웹서버로 사용하는 널리 쓰이는 오픈 소스는 크게 아파치 HTTP 서버와 엔진엑스가 있었습니다.

둘 중에 어느 것을 사용할지 고민했습니다. 요청 소스 서버와 커넥션을 맺어 SSL Termination 하고 요청을 라우팅 할 정도의 목적성과, 가벼운 아키텍처이기에 엔진엑스를 선택했습니다.

왜 엔진엑스가 아파치 서버보다 가볍다고 할까요?

 

Apache HTTP Server

아차피 서버는 프로세스를 여러개 미리 만들어두고, 새 커넥션이 생길 때마 프로세스를 할당하는 PREFORK 방식을 사용하기 때문입니다. 이런 방식은 여러 문제를 일으키게 됩니다.

1. 커넥션 수립시 keep-alive 헤더로 지속 연결을 하게 되면 무수히 많은 프로세스를 사용하게 되고 결국 C10K 문제를 발생시킵니다.

2. 요청 마다 프로세스를 할당해서 CPU가 여러 프로세스의 요청을 해결하면 자주 컨텍스트 스위칭이 일어나게 되고, 프로세스 컨텍스트 스위칭은 높은 오버헤드가 발생합니다.

3. 여러가지 기능을 제공해주는 모듈을 지원해주지만, 그렇기 때문에 프로그램이 무거워집니다.

 

NGINX 

NGINX는 아파치 서버를 대체하려고 나온 것은 아닙니다. 보완하기 위해 만들어졌습니다. 많은 커넥션을 유지를 할 수 있었는데, 이는 엔진엑스의 이벤트 기반 아키텍처 덕분입니다. 

1. 커넥션 형성, 커넥션 제거 그리고 새로운 요청을 처리하는 것을 이벤트라고 부르는데, 이벤트는 큐에 담긴 상태에서 워커 프로세스가 처리할 때까지 비동기 방식으로 대기하고 워커 프로세스는 하나의 스레드로 이벤트를 꺼내서 처리해 나갑니다.

2. 워커 프로세스는 보통 CPU의 코어 수 만큼 생성합니다. 이러면 프로세스 컨텍스트 스위칭이 일어나는 횟수가 대폭 줄어 CPU의 오버헤드를 줄일 수 있습니다.

 

 

 

	아파치 서버	엔진엑스
아키텍처	프로세스 기반 모델	이벤트 기반 모델
안정성	높다(각 요청은 독립된 프로세스에서 처리되므로 안정성이 높다. )	비교적 낮다(한 워커 프로세스에서 여러 요청을 처리하기 때문에 한 요청이 문제를 일으키면 다른 요청에도 영향을 끼칠 수 있다.)
성능	많은 동시 요청을 처리할 때 무수히 많은 컨텍스트 스위칭이 일어나므로 성능 저하가 발생할 수 있다.	이벤트 기반 모델 덕분에 많은 동시 요청을 효율적으로 처리할 수 있다.
메모리	요청마다 프로세스를 할당하는 구조라 많은 메모리를 사용한다.	적은 프로세스를 사용하여 메모리 사용량이 적다.
확장성	여러 모듈을 추가할수 있어서 확장성에 용이하다. 엔직엑스에 비해 제공되는 모듈이 많다.	런타임에 모듈을 동적으로 추가하거나 제거할 수 없다.(워커 프로세스가 여러 요청을 담당하기에 기능 추가를 하려고 하면 워커프로세스를 종료하게 되어 직접 모듈을 만들기 까다롭다.)
설정	Apache의 설정 파일(httpd.conf 등)은 복잡할 수 있으며, 고급 기능 설정을 위해 자세한 구성이 필요할 수 있다.	Nginx의 설정 파일(nginx.conf 등)은 비교적 간단하고 읽기 쉽다.
용도	동적 컨텐츠 처리가 가능하다(Apache는 PHP, Python, Perl 등 동적 콘텐츠를 처리하는 모듈과의 호환성이 뛰어나다.) 모듈을 통해 복잡한 설정 및 기능에 쓰인다.	주로 정적 컨텐츠 처리(Nginx는 정적 콘텐츠(이미지, CSS, JavaScript 등)를 매우 빠르게 제공할 수 있다.) 리버스 프록시 및 로드 밸런서: Nginx는 리버스 프록시 및 로드 밸런서로서 뛰어난 성능을 발휘한다.(동적 설정 변경)

 

자세한 비교 내용은 따로 블로그 포스팅했기에 아래 포스팅을 참고해주시면 감사하겠습니다.

https://programmer-may.tistory.com/200

아파치 vs 엔진엑스

 

결론

이렇게 복잡한 모듈 기능을 사용할 것도 아니고 요청의 SSL Termination 하기 위한 목적이므로 가볍고, 오버헤드가 적은 비동기 이벤트 기반 NGINX를 활용하여 리버스 프록시 서버 (Reverse Proxy Server)를 구축 하기로 했습니다.

구축 과정은 아래 블로그에 포스팅 하였습니다.

https://programmer-may.tistory.com/196

SSL Termination 을 위해 NginX 로 리버스 프록시 서버 구축하기

 

NGINX를 활용하여 리버스 프록시 서버 설정을 하면서 겪은 트러블슈팅 경험을 이제부터 공유하겠습니다.

🚀 트러블 슈팅 1

문제 상황

테스트 EC2 서버의 8081 포트에 스프링 부트 서버를 배포하였는데, 요청이 서버까지 닿질 않고 있었습니다.

sudo ufw allow 8081

방화벽 문제인줄 알고, 8081 포트에 대한 방화벽도 열어보고 방화벽을 disable 했지만, 작동하질 않았습니다.

 

작업

nginx -t

명령어를 쳐서 EC2 서버에서 실행 중인 Nginx 웹 서버의 로그를 살펴보았습니다.

 

원인

nginx: [warn] conflicting server name "api.yanabada.com" on 0.0.0.0:80, ignored
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

테스트 결과 다음과 같이 나타났습니다.

Nginx 설정 파일(/etc/nginx/nginx.conf)의 구문이 올바르고, Nginx 설정 파일의 구문 검사와 테스트가 성공적이라고 하지만 맨위에 80포트에 대한 서버 네임이 충돌을 일으키고 있다고 경고하고 있습니다.

 

해결

server {
    listen 80;
    server_name api.yanabada.com;
    return 301 https://$server_name$request_uri;
}

server {
    index index.html index.htm index.nginx-debian.html;
    server_name api.yanabada.com;

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/api.yanabada.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/api.yanabada.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    location / {
        proxy_pass http://127.0.0.1:8081;
        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;
    }

    location /ws-stomp {
        proxy_pass http://127.0.0.1:8081/ws-stomp;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    if ($host = api.yanabada.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    listen 80;
    listen [::]:80;
    server_name api.yanabada.com;
    return 404; # managed by Certbot
}

 

맨 위와 맨 아래에 listen 80 에 대하여 같은 서버 네임을 갖는 서버 블록이 있어서 이것이 충돌을 일으키는 것이었습니다. Nginx는 클라이언트의 요청을 처리할 때, 특정 서버 블록과 연관된 설정을 기반으로 동작합니다. 동일한 서버 이름을 가진 여러 서버 블록이 존재하면, 어느 서버 블록을 사용할지 결정하는 과정에서 혼란이 발생할 수 있습니다.

 

따라서 80포트에 대한 서버블록을 하나 지워줘서 문제를 해결했습니다.

server {
    listen 80;
    server_name api.yanabada.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl ipv6only=on;
    server_name api.yanabada.com;

    ssl_certificate /etc/letsencrypt/live/api.yanabada.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.yanabada.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass http://127.0.0.1:8081;
        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;
    }

    location /ws-stomp {
        proxy_pass http://127.0.0.1:8081/ws-stomp;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

 

결과

서버 블록 충돌에 대한 경고는 완벽하게 해결되었지만, 아직도 요청이 스프링 서버에 오고 있지 않았습니다.

 

🚀 트러블 슈팅 2

앞서서 CORS 를 공부하였을 때 CORS 동작 방식 중 인증된 요청 (Credentialed Request) 방식이 있었습니다. JWT를 이용하여 쿠키로 자격 인증을 하는 경우 액세스 토큰을 요청 헤더의 Authorization 필드에 설정합니다. Authorization 헤더를 포함하기 때문에, 단순 요청(simple request)이 아니며 프리플라이트 요청이 발생합니다.

https://programmer-may.tistory.com/184

Network - CORS 에러 개념과 해결법 (Spring MVC, Spring Security)

 

해결

따라서 요청을 처리하기 위해서는 Authorization 헤더가 필요한데, 이는 엔진엑스 설정파일에서도 헤더를 명시해주어야 했습니다.

리버스 프록시로 동작하는 Nginx는 클라이언트와 백엔드 서버 사이에 위치하여 요청을 중계합니다. 기본적으로 Nginx는 프록시 요청을 전달할 때, HTTP 요청과 응답을 최적화하기 위해 필요 없는 헤더를 제거하거나 변경할 수 있습니다. 헤더를 명시적으로 설정하지 않으면, Nginx가 이를 전달하지 않거나 무시할 수 있습니다.

proxy_pass http://127.0.0.1:8081;
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;
proxy_set_header Authorization $http_authorization; #Authorization 헤더 추가

 

결과

헤더를 명시하고 나선, 드디어 스프링 부터 서버와 통신이 가능해졌습니다. 하지만, WSS 사용하는 실시간 통신은 작동되고 있지 않은 걸 확인하였습니다.

 

🚀 트러블 슈팅 3

WSS 사용하는 실시간 통신은 작동되지 않은 것도 트러블 슈팅 2와 같은 이유였습니다.

바로 필요한 헤더가 누락됐기 때문입니다.

앞서서 웹소켓 프로토콜을 공부했을 때, 웹소켓 프로토콜로 통신하기 위해선 HTTP/HTTPS 요청을 통해 시작한다고 학습했습니다. 클라이언트는 서버에 HTTP 요청을 보내고, 이 요청은 Upgrade 헤더를 포함하여 웹소켓 프로토콜로의 업그레이드를 요청합니다.

https://programmer-may.tistory.com/191

기업 연계 프로젝트 - 채팅도메인 : 실시간 채팅

 

Upgrade 헤더: 이 헤더는 클라이언트가 HTTP 연결을 WebSocket으로 업그레이드하려고 한다는 신호를 보냅니다. Connection 헤더: 이 헤더는 업그레이드 요청이 있음을 나타냅니다.

Upgrade: websocket

Connection: Upgrade

 

해결

location /ws-stomp {
        proxy_pass http://127.0.0.1:8081/ws-stomp;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade; #Upgrade 헤더 추가
        proxy_set_header Connection "Upgrade"; #Connection 헤더 추가
        proxy_buffering off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

 

따라서 Upgrade 헤더와 Connection 헤더를 추가하여 문제를 해결하였습니다. 추가적으로 proxy_buffering off; 설정을 하여 Nginx는 백엔드 서버로부터 받은 응답을 버퍼링하지 않고, 곧바로 클라이언트에 전달하게 해주었습니다.

기본적으로, Nginx는 백엔드 서버로부터 응답을 받을 때 이를 메모리와 디스크에 버퍼링한 후 클라이언트에 전달합니다. 버퍼링을 통해 Nginx는 클라이언트와 백엔드 서버 간의 속도 차이를 완화하고, 네트워크 대역폭을 효율적으로 사용하며, 백엔드 서버에 가해지는 부하를 줄일 수 있습니다.

proxy_buffering off; 설정을 사용하면 Nginx는 백엔드 서버로부터 받은 응답을 버퍼링하지 않고, 즉시 클라이언트에 전달합니다. 이는 실시간으로 데이터 스트리밍이 필요한 경우에 유용합니다. 예를 들어, WebSocket 연결, 실시간 데이터 피드, 서버 센트 이벤트(Server-Sent Events) 등에서는 버퍼링을 끄는 것이 바람직합니다.

 

결과

단순 API 요청 뿐아니라 이젠 실시간 채팅까지 잘 동작하는 걸 확인할 수 있었습니다. 이로써 엔진엑스 설정파일에 대한 모든 트러블에 대해서 해결을 완료했습니다.

 

마무리하며

아파치 서버와 엔진엑스를 비교 공부하면서 평소 CS를 배워야하는 이유가 있구나 생각했습니다. 프로세스를 활용한 설계와 기능 제공면에서 차이가 있기 때문에 OS 를 공부했던 것이 많이 도움이 됐습니다. 왜 프로세스 컨텍스트 스위칭 비용이 높은지, 왜 많은 프로세스는 많은 주소 공간을 차지하게 되는지, CPU 병렬성 등 평소 배운 내용들을 접목시키고 이해할 수 있어서 뿌듯했습니다.

 

리버스 프록시 서버를 구축하여 Nginx 설정 파일에 대한 트러블슈팅을 진행하는 과정에서 많은 것을 배우고 경험했습니다. 먼저, Nginx의 다양한 설정 옵션과 그 역할을 깊이 이해하게 되었습니다. 예를 들어, Authorization  헤더와  WebSocket 같은 특수한 요구사항을 처리하기 위해 추가적인 헤더 설정이 필요하다는 것을 깨달았습니다.

트러블슈팅 과정에서 가장 크게 느낀 점은 Nginx 설정의 작은 오류나 누락된 설정이 큰 문제를 일으킬 수 있다는 것입니다. 특히, 동일한 서버 이름을 가진 서버 블록이 중복되어 발생하는 충돌 문제나, 특정 헤더가 제대로 전달되지 않아 발생하는 API 요청 누락을 해결하는 데 많은 시간을 투자했습니다.

부족한 부분으로는, 복잡한 설정 파일을 관리하고 유지보수하는 데 있어서 체계적인 접근 방법이 필요하다는 것을 깨달았습니다. 또한, 실시간 문제 해결을 위해 로그 파일을 효과적으로 분석하는 능력이 중요하다는 것을 느꼈습니다.