HTTP 200 OK

Memento mori & Carpe diem

CS

Nginx Proxy vs API Gateway(Part. 1)

sjoongh 2023. 12. 9. 15:45

웹 개발자들 대부분은 nginx를 사용해 봤거나 한번쯤은 들어보셨을 거라고 생각합니다.

 

요즘은 업무중에 K8S와 함께 사용해보니 nginx-ingress라는 개념도 나오고 api gateway도 함께 적용하고 있어서

기초부터 다잡고 싶은 마음에 nginx와 gateway의 차이점과 개념적인 부분들을 정리하고

정확히 이해하기 위해 글을 작성했습니다.

 

지금부터 nginx와 proxy 그리고 gateway까지 전반적인 개념을 살펴보겠습니다.

 

nginx란?

Nginx는 가벼움과 높은 성능을 목표로 하는 웹 서버 소프트웨어로, 웹 서버, 리버스 프록시 및 메일 프록시 기능을 가진다.
https://ko.wikipedia.org/wiki/Nginx

 

 

Nginx는 정적 파일을 제공(HTML, CSS 등)하는 웹서버의 역할도 하면서 Proxy의 역할도 수행할 수 있군요 하지만 위의 설명만으로 Nginx를 완전히 이해하기에는 부족한 부분이 있습니다.

 

Nginx를 파악하기전에 프록시는 대체 무엇일까요?? 프록시에 대한 정확한 개념부터 살펴보겠습니다.

 

프록시(Proxy)란?

  • 프록시는 “대리”라는 의미로서 내부 네트워크에서 인터넷 접속을 할 때에 빠른 엑세스나 안전한 통신등을 확보하기 위한 중계서버를 의미합니다.
  • 클라이언트와 Web 서버의 중간에 위치하고 있어 대신 통신을 받아주는 것이 프록시 서버입니다.

프록시

 

 

프록시의 주요 기능

 

  1. 익명으로 컴퓨터를 유지(보안 목적)
  2. 캐시를 사용하여 리소스로의 접근을 빠르게 하기 위해
  3. IP추적을 당하지 않고 지역제한을 우회하기 위해
  4. 원하지 않는 사이트를 차단

 

아하!! 크게 본다면 우리가 프록시를 사용하는 경우는 보안상의 문제로 직접 통신을 받을 수 없는 상황이나 리소스로의 접근을 빠르게 하기 위해서라고 생각됩니다. 또한 프록시도 서버의 위치에 따라 종류를 나눌 수 있습니다.

 

프록시의 종류는 2가지가 있는데 바로 포워드 프록시와 리버스 프록시입니다.

 

Forward Proxy

포워드 프록시

  • 포워드 프록시는 일반적인 프록시 서버를 말하며 클라이언트와 웹 서버의 중계역할로
  • 클라이언트가 프록시 서버에 요청한 내용을 프록시 서버에서 캐시로 저장해 두면
  • 나중에 다시 데이터를 요청할 때 캐시된 데이터를 사용하면 되므로 전송 시간을 절약할 수 있습니다.
  • 또한 프록시 서버는 클라이언트가 요청하기 전까지 웹 서버의 주소를 알 수 없습니다.(URL 필터링)
  • 캐싱 기능(엑세스 고속화)을 제공하면서 동시에 특정 사이트는 접근 불가능하도록 제한을 걸 수도 있습니다.
  • 즉 클라이언트가 요청을 전달하면 프록시 서버가 목적 사이트의 내용을 받아와서 전달을 대신해주는 것입니다.

 

Reverse Proxy

리버스 프록시

 

  • 클라이언트와 내부망(Private Network) 서버 사이에 위치하여 제어역할을 합니다.
  • 클라이언트가 바로 서버에 데이터를 요청하여 받아올 수도 있지만,
  • 그렇게 하면 중요한 데이터가 있는 DB가 노출될 수 있다는 위험이 존재합니다.
  • 따라서 중간에 프록시 서버를 두고 내부망을 보호하는 역할을 담당하게 하는 것입니다.
  • 또한 로드밸런싱 기능을 활용해 메모리 사용량을 효율화할 수 있습니다. 포워드 프록시와 마찬가지로 캐시도 저장합니다.
  • 즉 클라이언트가 프록시 서버에 데이터를 요청하면 프록시 서버는 내부망 서버에서 데이터를 받아와 클라이언트에게 전달해 줍니다.

 

 

여기까지 프록시란 무엇인가? 를 살펴봤습니다.

 

 

이제 Nginx에 대해서 알아볼 수 있을 것 같습니다!!

Nginx는 가장 대표적인 웹 서버로서 프록시를 간편하게 만들 수 있습니다.

앞선 개념과 접목시켜 구축하려는 목적에 맞게 사용하시면 되겠습니다.

NGINX

 

Nginx는 프록시 설정 외에도 SSL을 지원하고 데이터 압축, 비동기처리 등 다양한 기능이 존재합니다. Nginx와 다른 제품의 역사를 살펴보는 것도 재밌겠지만 그 영역은 다음에 기회가 된다면 다루어 보겠습니다.

 

그렇다면 당최 API Gateway란 무엇일까요? 필자는 API Gateway라는 단어를 들어보기는 했지만 API 엔드포인트 용도 그 이상으로 생각해 본 적이 없었습니다.

 

Gateway란?

게이트웨이는 컴퓨터 네트워크에서 서로 다른 통신망, 프로토콜을 사용하는 네트워크 간의 통신을 가능하게 하는 컴퓨터나 SW를 일컫는 용어, 즉 다른 네트워크로 들어가는 입구 역할을 하는 네트워크 포인트입니다. 넓은 의미로는 종류가 다른 네트워크 간의 통로 역할을 하는 장치입니다.
https://ko.wikipedia.org/wiki/게이트웨이

API Gateway

  • API 게이트웨이는 API서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화해서 묶어주고 API에 대한 인증과 인가 기능에서부터 메시지에 따라 여러 서버로 라우팅 하는 고급기능까지 많은 기능을 담당할 수 있습니다.
  • 즉 api gateway는 만들어진 목적 자체가 통합적인 API관리를 위해 만들어진 도구입니다.

 

Gateway의 주요 기능

 

  1. 인증/인가 및 토큰 발급
  2. 공통 로직 처리
  3. 로드밸런싱
  4. 메디에이션기능

 

이외에도 다양한 기능이 존재하지만 개념을 학습해보니 MSA환경에서 활용하기에 좋은 방법이라고 보였습니다.

  • MSA는 분산된 서버로 구성되어 있는 만큼 공통으로 인증/인가를 관리하는 것이 좋아 보였고(각각의 서버에 Spring Securiy 의존성을 추가해 기능구현을 하는 것은 생각만 해도 끔찍하네요)
  • 공통적인 로직을 처리하는 일도 MSA에 적합한 용도였습니다.
  • 메디에이션 기능에는 메시지 호출 변화가 있는데 동기/비동기와 같은 API를 호출하는 메시지 패턴을 정의하는 것인데, Gateway를 이용하면 동기 호출을 비동기 호출로 바꿀 수도 있습니다.

 

 

하지만 Gateway의 주요 기능을 살펴보아도 필요성을 느끼지 못했고 익숙한 Nginx proxy를 사용하는 것이 더 편리해 보였습니다. 그 이유는 크게 두가지인데

 

  1. nginx proxy도 충분히 API 엔드포인트에 따라 트래픽을 다르게 설정해 줘서 API Gateway와 유사한 용도로 사용할 수 있는데 왜 Gateway를 사용할까??
  2. Nginx proxy와 GateWay가 제공해주는 기능이 많은 부분 흡사해 보인다는 점이었습니다.

 

여기까지 살펴보았을때 명확한 차이점을 발견하지 못했습니다.

글을 작성하다 보니 생각보다 너무 길어져서 Gateway와 Nginx Proxy의 차이에 대한 결론은

2편에서 마무리하겠습니다.

 

TIP : Proxy vs VPN

 

  • 둘의 공통점은 사용자의 IP주소를 숨기며 대체할 수 있다는 점밖에 없습니다.
  • VPN은 장치의 모든 수, 발신 데이터를 보호하고 암호화하여 해킹 공격을 방지해 보안적인 측면에서 proxy보다 좋습니다.
  • Proxy는 브라우저나 특정 앱만 보호하며 암호화가 되어있지 않지만 가볍고 빠르다는 장점이 있습니다.

 

출처

https://furkangulsen.medium.com/forward-proxy-vs-reverse-proxy-4b2061ef17d6

https://ko.wikipedia.org/wiki/프록시_서버

https://wildeveloperetrain.tistory.com/205