내가 필요해서 정리- Proxy vs Gateway에 대해

이상훈·2023년 1월 31일
1

공부정리

목록 보기
1/1

누군가의 제안으로 쓰는 3줄 요약

  1. 프록시 서버는 프론트와 리버스로 나뉘어 진다.
  2. 현재 리버스 프록시와 api 게이트웨이는 동일한 의미로 쓰이나 논쟁점이 있다.
  3. 그 이유가 프록시 서버의 발달과 api 게이트웨이 경량화 때문이다.
    였는데 계속 확인중이다.

1. Proxy server vs api gateway

이번 뻘짓의 시작은 여기서 부터였다. 모든 문제는 어설프게 알고 있는것으로부터 시작된다.

가. 사전에 어설프게 알고 있던 내용 -proxy sever

프록시 서버는 자신의 정보를 숨기기 위해 작동하는 서버다.
-> 이렇게 알고 있었던 까닭은? 성인사이트에 접근하기 위해서 프록시 서버를 작동시켜 본 사람이 대한민국에 정말 많을 것이다. 나 역시 그렇기에 저렇게 알고 있었고, 지금까지 공부하면서 그냥 넘어갔었다.

나. 의문의 본격화 - 프록시 서버의 정의

그리고 프록시 서버에 대한 정확한 정보를 인터넷에서 검색해 본 결과 다음과 같은 결과를 얻었다.

프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다. 서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을 가리켜 '프록시', 그 중계 기능을 하는 것을 프록시 서버라고 부른다
https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9D%EC%8B%9C_%EC%84%9C%EB%B2%84

다. 그리고 갑자기 든 오한.. 그럼 이놈은 뭐지? -> api Gateway

게이트웨이의 정의는 다음과 같다.

게이트웨이(gateway, 문화어: 망관문)는 컴퓨터 네트워크에서 서로 다른 통신망, 프로토콜을 사용하는 네트워크 간의 통신을 가능하게 하는 컴퓨터나 소프트웨어를 두루 일컫는 용어, 즉 다른 네트워크로 들어가는 입구 역할을 하는 네트워크 포인트이다. 넓은 의미로는 종류가 다른 네트워크 간의 통로의 역할을 하는 장치이다
https://ko.wikipedia.org/wiki/%EA%B2%8C%EC%9D%B4%ED%8A%B8%EC%9B%A8%EC%9D%B4

하지만 그렇다고 게이트웨이를 프록시에 일종으로 보기에는 분명 지금까지 NCP와 SAA, 그리고 SAP 자격 시험을 볼때 그 단어에서 무언가, 차이가 있었다.

그래서 해당 부분(gateway vs proxy)을 검색해 보았다. 그랬더니 수 많은 논쟁이 있었고, 조금씩 다른 이야기로 설명하였다. 일단 해당 부분에서 잘못된 부분과 명확한 부분을 가져오겠다.

라. 잘못된 설명과 반례-프록시는 동일한 프로토콜을 이용하고 gateway는 프로토콜을 다른것을 사용한다.

어떤 사이트에서는 프록시와 게이트웨이의 차이점을 다음과 같이 설명하였다.

"proxies connect two or more applications that speak the same protocol, while gateways hook up two or more parties that speak different protocol"
https://serverfault.com/questions/994319/what-is-the-difference-between-a-proxy-server-and-a-gateway-server

즉 프록시는 동일한 프로토콜을 사용하는데, gateway는 프로토콜이 다르다는 것이다. 하지만 예전 클라우드 실습때 일부 웹 프록시는 http와 https의 상호 다른 프로토콜로 리다이렉팅이 가능했다. 즉 위의 내용만으로는 차이를 분명하게 나타낼 수는 없었다.

마. 올바른 설명(명료한 설명)

오히려 위의 글의 하단 답변에 조금 더 명확한 설명이 있었다.

In other words:
a proxy is an intermediary whose intermediary nature is known to the client;
a gateway (also known as reverse proxy) is an intermediary whose intermediary nature is not known to the client.
https://serverfault.com/questions/994319/what-is-the-difference-between-a-proxy-server-and-a-gateway-server

즉 게이트웨이와 프록시 모두 서버와 클라이어트의 사이를 중재하는 리로스지만, 게이트웨이는 중재자로서 클라이언트를 숨기지만, 프록시는 클라언트를 숨기지 않는다는 것이었다.라는 것이 맞는 설명인줄 알았다.

2. 그리고 한번 더 맞은 단어 reverse proxy

가. reverse proxy??????reverse proxy????? 잠시만 처음 듣는 단어인데?

그 동안 AWS에서 사용하는 프록시의 역활과 내가 성인사이트에 접속하기 위한 프록시의 역활을 동일시에서 보고 있었던 것이었다. 하지만 그 역활은 명확하게 다른 역활이었다. 그 부분에 대해서 알기 위해서 프록시 서버의 역활에 대해서 검색해 보았다.

이미지 가)고객의 입장에서 사용하는 프록시 서버(forward proxy)

이미지 나)서버의 입장에서 사용하는 프록시 서버(reverse proxy)

이미지 출처 : https://losskatsu.github.io/it-infra/reverse-proxy/#1-%ED%94%84%EB%A1%9D%EC%8B%9Cproxy-%EC%84%9C%EB%B2%84%EB%9E%80

즉 프록시는 두개의 프록시 서버를 하나로 본 것이다. 절때 정보의 방향성으로 보면 안된다. 프록시 서버의 위치가 인터넷과 비교했을때 앞단(front)에 있는지 뒷단(reverse)에 있는지가 주요 포인트인 것이다. 그리고 백엔드 프록시는 일종의 게이트웨이며 클라이언트(주/ 사용자의 입장에서 보면 클라이언트, 일반적으로 웹 페이지와 같은 서버)를 보조하는 역활을 하구........

3. 그래서 아 reverse proxy = Gateway의 역활을 하구나 하고 끝낼려고 했다.

그래서 아 reverse proxy = Gateway의 역활을 하구나 하고 끝낼려고 했다. 다시 한번 검색해 본 결과는 참 어려웠다

가. revers proxy vs api gateway

On the other hand API proxy is basically a lightweight API gateway. It includes some basic security and monitoring capabilities. So, if you already have an API and your needs are simple, an API proxy will work fine.

이런 내용이 검색되었다. 경량화된 api gateway가 Proxy이야기 하였다. 하지만 우리는 알 수 있다. 저 안에 있는 gateway의 많은 기능들을 우리는 proxy에서도 할 수 있다. 또한 프론트 프록시가 단순히 중개에 역활만 한다면, 우리는 프록시 서버를 통해 성인사이트에 들어가는 것이 쉽지 않을 것이다. 그렇기에 다시 한번 검색을 해 보았다.

나. 그럼 차이가 뭐야? 다시 천천히 보기

그래서 다시 한번 proxy와 api gateway의 개념부터 다시 봤다. 그리고 이 논쟁이 왜 어려운지 추측할 수 있었다.

1)프록시 서버

프록시 서버가 설치된 처음 목적은 웹 서핑을 비롯한 인터넷 속도의 향상이었다. 1990년대 후반까지만 해도 이런 목적으로 사용되었다. 현재 이 역할은 CDN이 하고 있다. 그리고 내부정보 보안이 필요한 다수의 기업에서 프록시서버를 이용해서 외부망에 접속한다.
https://namu.wiki/w/%ED%94%84%EB%A1%9D%EC%8B%9C%20%EC%84%9C%EB%B2%84

즉 프록시 서버에 대한 역사와 설명을 다시 확인하였을때 내가 1번에 가졌던 잘못된 생각의 이유와 프록시 서버의 발전에 대해서 알 수 있었고, 프록시 위에 프록시 서버의 사용 영역이 왜 한정되어 있는지 알 수 있었다. 즉 기존의 프록시 서버는 주로 현재의 CDN의 역활을 하고 있었는데, 현재는 그 역활을 전문적으로 CDN이 대신하기 시작하였고, 현재는 프록시는 CDN보다는 조금 더 광범위한 기능을 제공하고 있는 것이다.

2)api 게이트웨이

API 게이트웨이는 API서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화하여 묶어주고 API에 대한 인증과 인가 기능에서 부터 메세지에 따라서 여러 서버로 라우팅 하는 고급기능 까지 많은 기능을 담당할 수 있다.
https://bcho.tistory.com/1005

즉 api gateway는 태생부터가 통합적인 API관리를 위해 만들어진 도구로 API를 gateway가 통합하여 나타내서 처리해 주기에 클라리언트의 정보가 제공되지 않는 것이었다.

다. 그렇다면 결론은

결론은 간단하다 자신이 이야기는 자신의 정체성이 매우 중요하다고 생각한다. 예를 들어 Nginx는 자신들이 제공하는 서비스를 프록시라고 한다. 하지만

1번에서 프록시 Vs 게이트웨이의 정의인
즉 게이트웨이와 프록시 모두 서버와 클라이어트의 사이를 중재하는 리로스지만, 게이트웨이는 중재자로서 클라이언트를 숨기지만, 프록시는 클라언트를 숨기지 않는다는 것이었다.

이걸 그대로 적용해버리면, nginx가 프록시를 사용하면, 사용자는 nginx에 접속할때 그 하단에 있는 클라이언트 정보를 볼 수 있어야 한다. 그러나 우리는 그렇지 않다. 즉 nginx에서 제공하는 프록시는 정의로만 보자면 게이트웨이이 가깝다. 하지만 nignx는 자신들이 제공하는 서비스를 프록시 서버라고 한다.

그리고 CAHT GPT가 명확하게 해당 내역을 알려주었다.
API Gateway와 Reverse Proxy의 개념은 비슷하지만, 완전히 같은 것은 아닙니다.

API Gateway는 일반적으로 서비스 게이트웨이처럼 작동하지만, 주로 애플리케이션 프로그래밍 인터페이스(API) 트래픽을 제어하는 데 사용됩니다. API Gateway는 주로 보안, 모니터링, 로깅, 라우팅, 트랜잭션 관리 등의 기능을 제공합니다.

Reverse Proxy는 반대로 클라이언트 요청을 다른 서버에 전달하는 것이 주 목적이며, 일반적으로 보안, 로드 밸런싱, 캐싱 등의 기능을 제공합니다.

따라서 API Gateway와 Reverse Proxy는 비슷한 기능을 제공할 수 있지만, 정확하게는 다릅니다.

다시 내 생각을 정리하면
프록시 서버와 게이트웨이 모두 중재자의 역활을 하고 있고, 프록시 서버 기술의 발달로 기존에 게이트웨이가 하고 있던 역활을 프록시 서버가 많이 대체하고 있다. 그렇기에 현재에 상황에서는 각 프로램들이 제공하는 서비스 이름에 따라 프록시인지 게이트웨이인지 평가하면 된다고 생각된다.

profile
34살 조금은 늦은 나이에 클라우드 엔지니어를 꿈꾸는 청년

1개의 댓글

comment-user-thumbnail
2일 전

좋은 글 감사합니다. 정말 진득하게 공부하신거 같네요. 그런데 역활 -> 역할 로 오타만 수정하면 좋을거 같습니다!

답글 달기