nginx의 개념과 이해
nginx란 무엇인가
nginx는 2004년 Igor Sysoev에 의해 C로 작성되기 시작한 고성능 오픈소스 소프트웨어로, 전세계에서 가장 유명한 HTTP 웹 서버이자 리버스 프록시이면서 동시에 로드밸런서이고 HTTP 캐시 서버입니다. 적은 리소스로 많은 요청을 처리할 수 있기 때문에 모던 웹 어플리케이션에서 널리 사용되고 있습니다.
nginx가 웹 서버로 쓰일 때는 CDN처럼 정적 컨텐츠를 빠르게 서빙하는 용도로 쓰일 수도 있지만, 동적인 웹 컨텐츠 또한 제공할 수 있습니다. 요지는 nginx 서버가 HTTP/S 엔드포인트를 이해하고 웹 컨텐츠를 처리한다는 점입니다.
웹 서버처럼 직접 요청을 처리하는게 아니라 리버스 프록시 서버로도 활용될 수 있습니다. 여기서 리버스 프록시란, 클라이언트와 백엔드 서버 사이에서 중재자 역할을 하는 서버를 뜻합니다. 클라이언트의 요청을 받아 적절한 백엔드 서버로 트래픽을 분산시켜주기도 하고, 자신에게 캐싱된 정적 컨텐츠를 클라이언트에게 바로 반환하기도 합니다. 또한 클라이언트 입장에선 실제 요청을 처리하는 백엔드 서버가 숨겨지기 때문에 보안상의 이점도 취할 수 있게 됩니다.
extra layer의 필요성
가장 단순한 구조를 떠올려보면 요청을 하는 클라이언트와 이를 받는 백엔드 서버만으로도 충분히 웹 서비스가 돌아갈 것만 같습니다. 실제로도 간단한 개인 프로젝트는 이런 구조로도 충분히 돌릴 수 있죠. 하지만 사용자 수가 많은 상용 서비스라면 이야기가 달라집니다. 간단한 예시를 살펴보겠습니다.
여기, 여러분의 방 한구석에 컴퓨터가 있고 3001번 포트에서 클라이언트의 요청을 받는 서버가 구동중이라고 생각해봅시다. 이 서버는 사용자의 정보와 어플리케이션 데이터를 담은 DB와 연결되어있습니다. 클라이언트가 GET 요청을 보내면 이 서버에서 구동되고 있는 코드가 DB에서 데이터를 가져와 JSON 형태의 응답을 반환합니다.
사용자 수가 많아지면서 네트워크 요청이 많아지면 문제점이 생기기 시작합니다. 3001번 포트로는 더이상 모든 요청을 감당할 수 없습니다. 그러면 포트를 계속 추가하기 시작합니다. 3002번 포트, 3003번 포트, 3004번 포트... 문제는 클라이언트가 이 포트 번호들을 알아야하고, 각 엔드포인트마다 HTTPS 인증서가 필요해지기 시작합니다. 서버 상태가 가장 널널한 포트가 무엇인지도 클라이언트 입장에선 알지 못합니다. 설상가상으로 이 컴퓨터가 갑자기 고장나버리면, 모든 서버가 셧다운되고 심각한 서비스 장애로 이어질 것입니다. 그렇다면 또 다른 컴퓨터 한 대를 사서, 또 포트를 추가하고, 또 인증서를 붙이고, 이런 작업을 계속 반복해야할까요?
이 것이 사람들이 extra layer를 고민하게 된 이유입니다. 앞서 nginx의 사용 용도를 설명하면서 로드밸런싱을 언급한 적이 있습니다. nginx를 로드밸런서로 적용한다면 아래와 같은 그림이 될겁니다.
다음과 같은 변화가 생깁니다.
로드 밸런싱 알고리즘을 적용해 트래픽을 여러 서버에 골고루 분산시켜 특정 서버의 과부하를 막을 수 있습니다. 예를 들어, 서버들이 모두 동일한 스펙을 가지고 있고, 서버와의 연결이 오래 지속되지 않는 경우라면 요청을 순서대로 분배하는 라운드 로빈 방식을 생각해볼 수 있겠습니다.
클라이언트 입장에서는 nginx 서버와만 통신하기 때문에 단 하나의 엔드포인트만 존재하는 셈이며, 그렇기 때문에 HTTPS 인증서도 nginx 서버에만 붙여주면 됩니다. 물론, 최종 목적지 서버에 각각 HTTPS 인증서를 또 붙여주는 경우도 있지만요.
중간 단계가 추가된 것이기 때문에 구축 및 운영 비용, 그리고 latency 증가 등의 단점이 뒤따를 수 있습니다. 따라서 nginx 서버를 구축할 땐 최대한 퍼포먼스 중심으로 설계되어야 합니다.
OSI 계층과 nginx
