NGINX, Proxy, Load Balance

이번 글에서는 NGINX가 무엇인지, 왜 만들어졌는지 다뤄보고 또 어떻게 사용되는지 실제 사례를 통해 알아보겠습니다.

 

초창기 웹이 간단하고 사용자가 적었을 시절에 웹의 간단한 사용 예시를 살펴보자면, 먼저 브라우저가 어떤 웹 서버에 웹 페이지를 요청합니다. 이 '웹 서버'는 서버 기계에 설치된 소프트웨어로, 웹 페이지를 조립한 후 브라우저로 전송하는 역할을 했습니다. 브라우저 요청에 응답할 수 있는 소프트웨어를 서버에 실행시키는 것입니다. 그 웹 서버 소프트웨어가 바로 NGINX였습니다.

 

그러나 웹이 대중화되고 점점 발전하면서 한 웹사이트에 수천, 수백만 개의 요청이 몰리게 되었습니다. 하나의 서버가 이런 수백만 개의 요청을 처리하는 것은 불가능하기에, 여러 대의 서버를 추가해야 합니다. 하지만 서버가 여러 대인 경우에는 브라우저에서 들어오는 요청을 어떻게 각각의 서버로 분배할지 결정하는 단계가 필요해집니다. 이에 따라 로드 밸런싱(load balancing)이라는 개념이 등장하게 됩니다. 만약 10대의 NGINX 서버를 추가했다면, 역시 동일한 NGINX 웹 서버가 로드 밸런서로서 작동하며, 브라우저 요청을 10대의 서버 중 하나로 보냅니다(프록시 처리). 프록시(Proxy)란 누군가를 대신해서 무언가를 한다는 의미입니다. 즉, NGINX는 브라우저 요청을 웹 서버를 대신해 받아들이고 이를 각 서버에 분배하는 역할을 합니다.

 

로드 밸런싱(load balancing) 방식은 설정된 알고리즘에 따라 다릅니다. 예를 들어, 가장 덜 바쁜 서버(least-connected)가 요청을 받거나, 또는 라운드 로빈(round robin)이라는 알고리즘을 사용하여 요청을 순차적으로 순환하며 균등하게 분배할 수 있습니다. 또는 IP 해시를 통해 다음 요청을 처리할 서버를 결정합니다. 이는 동일한 클라이언트의 요청이 항상 동일한 서버로 전달되도록 보장합니다. 이렇게 세 가지 방식이 NGINX가 지원하는 로드 밸런싱 메서드입니다.

 

이렇듯 NGINX는 웹 서버 소프트웨어와 프록시 역할을 겸하고 있으며, 로드 밸런싱은 NGINX Proxy의 여러 기능 중 하나에 불과합니다. 또 다른 NGINX의 기능을 예시와 함께 살펴보도록 하겠습니다. 뉴욕타임스에서 새로운 기사가 발표되고 수백만 명의 사용자가 브라우저로 기사를 열었다고 생각해 봅시다. 각 요청이 웹 서버로 들어와서 이미지, 데이터베이스, 텍스트, 링크를 매번 새로 조합한 뒤 사용자에게 반환해야 한다면 매우 비효율적일 것입니다. 대신, 이 데이터를 한 번만 조합하고 이를 캐시(cache)로 저장해 뒀다가 요청이 올 때마다 동일한 파일을 반환하도록 하면 훨씬 더 효율적일 것입니다. 이 캐싱 기능이 NGINX의 또 다른 주요 기능입니다.

 

또 다른 기능을 다른 예시와 살펴봅시다. 온라인 뱅킹 앱이나 소셜 네트워크 같은 시스템에 서버 100대가 있다고 할 때, 이 서버들은 해커들에게 아주 매력적인 표적이 될 것입니다. 만약 모든 서버가 공개적으로 접근 가능하다면, 해커들이 그중 하나의 약점을 찾아 시스템 전체를 침투할 가능성이 커집니다. 이렇게 모든 서버를 공개적으로 두는 대신, 단 하나의 프록시 서버만 공개적으로 접근 가능하도록 설정하면, 보안 공격 면적을 대폭 줄일 수 있습니다. 이 프록시 서버는 모든 요청을 받아 내부 웹 서버로 전달하며 방패 또는 보안 계층 역할을 합니다. 보안을 강화하기 위해 프록시 서버는 암호화된 통신(SSL)을 지원합니다. 예를 들어서 프런트엔드는 암호화된 메시지를 프록시에 보내고, 프록시는 이를 해독하거나 그대로 웹 서버로 전달할 수 있습니다. 이렇게 하면 통신이 외부에서 가로채여도 내용을 알 수 없게 됩니다.

 

대용량 콘텐츠 전송 시 NGINX는 압축 기능도 제공합니다. 예를 들어, Netflix 같은 플랫폼이 고화질 비디오를 수백만 사용자에게 전송할 때, NGINX는 파일을 압축해 대역폭을 절약하고 전송 속도를 높일 수 있습니다. 또한 콘텐츠를 한 번에 전송하는 대신 청크(chunk)로 나눠 전송할 수 있습니다.

 

이 모든 기능은 NGINX 설정 파일에서 구성할 수 있습니다. 설정 파일을 통해 NGINX가 웹 서버로 작동할지, 프록시 서버로 작동할지 등이나, 캐싱, SSL, 로드 밸런싱 옵션 등의 세부 설정을 정의할 수 있습니다.

 

NGINX는 설정이 간단하고 유연하며 빠른 성능 덕분에 매우 인기를 얻었으며, Kubernetes의 Ingress Controller로도 널리 사용됩니다. Ingress Controller는 클러스터 내부에서 프록시 및 로드 밸런서 역할을 하며, 외부에서 오는 트래픽을 적절히 분배합니다. 이를 통해 Kubernetes 환경에서도 NGINX는 중요한 역할을 합니다.

 

결론적으로, NGINX는 웹 서버, 프록시 서버, 로드 밸런서, 보안 게이트웨이 등 다양한 용도로 활용되며, 간단한 설정으로 강력한 기능을 제공합니다. NGINX는 Apache 보다 더 가볍고 빠르며 정적 파일 처리와 컨테이너 환경에서 유리하다는 점입니다.

프록시 vs 리버스 프록시 vs 로드 밸런서

대형 웹사이트들이 수백만 명의 사용자를 동시에 처리하면서도 다운되지 않는 이유는 무엇일까요? 수백만명의 사용자에게 데이터를 안전하게 전송하며 적절한 서버로 안내하는 방법은 무엇일까요?

 

프록시(Proxy), 리버스 프록시(Reverse Proxy), 로드 밸런서(Load Balancer)를 포함한 세 가지 중요한 웹 컴포넌트를 간단하게 알아봅시다.

 

레스토랑에 저녁 식사를 예약해야 하는 상황을 가정해 봅시다. 만약 너무 바쁜 상황이라 레스토랑 직원과 직접 소통할 수 없습니다. 만약 개인 비서가 예약을 대신 처리한다면, 레스토랑 직원은 내가 아니라 비서와만 소통할 것입니다. 여기서 ‘나’는 인터넷을 탐색하는 데 사용하는 랩탑이라고 볼 수 있고 나의 비서는 프록시 서버라고 보면 됩니다.

 

프록시 서버는 노트북과 연결된 개인 네트워크와 요청이 나가는 공용 인터넷 사이에서 중개 역할을 합니다. 프록시는 응답을 당신에게 전달하기 전에 트래픽을 필터링하고, 유해한 웹사이트나 스크립트를 차단하여 노트북을 보호합니다.

 

업무 상황에서 프록시는 더 중요해질 수 있습니다. 예를 들어, 직원들이 인터넷에서 무엇을 할지 모르기 때문에, 관리자는 모든 직원의 인터넷 트래픽을 프록시를 통해 라우팅 하도록 설정할 수 있습니다. 이렇게 하면 직원이 악성 웹사이트를 방문해 바이러스에 감염되는 것을 방지할 수 있습니다. 프록시는 요청과 응답을 검사하고, 위험이 있는 콘텐츠를 차단하며, 내부 네트워크를 보호합니다. 또한 캐싱 기능도 있어 대역폭을 절약하고 불필요한 인터넷 트래픽을 줄일 수 있습니다.

 

다시 레스토랑 비유로 돌아가서 나는 비서가 예약한 테이블을 찾기 위해 리셉션에서 체크인합니다. 리셉션 직원이 테이블로 안내하며, 이는 요청을 관리하고 올바르게 분배하는 리버스 프록시(Reverse Proxy)의 역할과 비슷합니다. 리버스 프록시는 서버 쪽에서 클라이언트 요청을 처리하며, 로드 밸런싱 기능을 수행합니다.

 

리버스 프록시는 보안 역할도 수행합니다. 수백 개의 서버가 민감한 데이터에 접근할 수 있다면 이를 모두 인터넷에 노출하는 것은 위험합니다. 리버스 프록시는 요청을 스캔하고 SSL 암호화를 보장하며, 보안 위협을 차단하는 등 다수의 보안 기능을 제공합니다. 대표적인 리버스 프록시로는 Nginx가 있습니다.

 

로드 밸런서와 리버스 프록시는 서로 대체 관계가 아니라 상호 보완적인 관계입니다. 클라우드 로드 밸런서는 외부 트래픽을 내부 네트워크로 전달하는 반면, 리버스 프록시는 내부에서 더 정교한 트래픽 라우팅을 수행합니다. 리버스 프록시는 쿠키나 세션 데이터를 기반으로 더 세밀한 라우팅을 제공하며, 특정 사용자 요청을 동일한 서버로 보낼 수 있습니다.

 

Node.js나 Java 애플리케이션이 자동으로 시작하는 경량 프록시도 존재합니다. 이는 대규모 생산 환경에서 사용하는 Nginx 같은 고성능 리버스 프록시와는 다른 목적을 가집니다. 그러나 이 두 기술은 조합해서 사용할 수 있습니다. 이렇게 프록시와 리버스 프록시, 로드 밸런서를 이해하면 인터넷 작동 방식을 더욱 명확히 알 수 있습니다.