DevOps22일차 - 프록시와 로드밸런서

문한성·2023년 4월 7일
0

부트캠프

목록 보기
37/123

프록시(Proxy) 란?

프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다.

프록시(Proxy)란 '대리' 라는 의미를 갖고 있으며, 서버와 서버사이의 중계기 역할을 한다고 보면 된다.

프록시를 쓰는 이유는 보안상의 이유로 직접 통신할 수 없는 두 점사이에서 대리로 통신을 수행하여 보안성, 성능, 안정성을 향상 시키기 위해서 이다.

보통 웹은 클라이언트에서 서버로, 서버에서 클라이언트로 통신하며 데이터를 전달한다.
이때 필연적으로 중복되는 데이터를 반복하여 전달하는 상황이 발생하는데, 이렇게 동일한 요청을 매번 처리하는 것은 곧 리소스 낭비 와 서버의 부하 로 이어지게 된다.

때문에 본 서버에 도달하기 전에 새로운 서버(proxy server)를 미리 배치하여 중복 요청에 대해 (연산이 필요없는) 동일한 응답을 할 수 있다면, 클라이언트에겐 빠른 속도의 서비스를, 서버에게는 불필요한 부하를 줄이는 효과를 낼 수 있게 된다.

프록시의 두 종류

프록시 서버는 네트워크 상 어디에 위치하느냐, 혹은 어느 방향으로 데이터를 제공하느냐에 따라 Forward ProxyReverse Proxy 로 나뉘게 된다.

리버스 프록시 서버를 설명하기 전에 포워드 프록시 서버에 대해 먼저 이해하면 리버스 프록시 서버를 이해하는데 도움 된다. 이 2가지의 차이점을 알아보자.

포워드 프록시 (Forward Proxy)

프록시 서버는 아래 그림처럼 클라이언트 바로 뒤에 놓여 있다.

같은 내부망에 존재하는 클라이언트의 요청을 받아 인터넷을 통해 외부 서버에서 데이터를 가져와 클라이언트에게 응답해준다.​

즉, 클라이언트가 서버에 접근하고자 할때, 클라이언트는 타겟 서버의 주소를 포워드 프록시에 전달하여, 포워드 프록시가 인터넷으로 요청된 내용을 가져오는 방식이다.

예를 들어 우리가 naver.com 을 요청하면 포워드 프록시 서버가 naver.com 리소스를 대신 받아와 클라이언트에게 내밀어준다(forward)고 생각하면 된다.

Tip
우리가 흔히 말하는 ‘프록시 서버’란 바로 포워드 포록시 서버를 의미하는 것이다.

포워드 프록시 사용 이점

클라이언트 보안 (Security)

보통 정부, 학교, 기업 등과 같은 기관은 해당 기관에 속한 사람들의 제한적인 인터넷 사용을 위해 방화벽을 사용한다.
포워드 프록시 서버는 방화벽과 같은 개념으로 제한을 위해 사용 된다고 보면 된다.
즉, 해당 기관에 속한 사람들이 그들이 방문하고자 하는 웹사이트에 직접적으로(directly) 방문하는 것을 방지할 수 있다. 예를 들어, 포워드 프록시 서버에 룰을 추가해서 특정 사이트에 접속하는 것을 막을 수 있다.

캐싱 (Caching)

우리가 어떤 웹 페이지에 접근하면 프록시 서버는 해당 페이지 서버의 정보를 캐싱(임시보관)해둔다.
그래서 똑같이 해당 페이지에 접근하거나, 다른 클라이언트가 해당 페이지를 요청할 때 , 캐시된 정보(페이지)를 그대로 반환할 수 있고, 이는 서버의 부하를 줄이는 효과도 낼 수 있다.

위의 그림에서 만일 4명의 클라이언트가 naver.com에 접근할때 본래는 각각 따로 인터넷을 경유해서 네이버 페이지를 받겠지만, 포워드 프록시를 이용하면 프록시내 캐싱 된 네이버 페이지를 불러오기 때문에 훨씬 빠르게 조회할수 있는 원리이다.

암호화 (Encryption)

클라이언트의 요청은 포워드 프록시 서버를 통과할 때 암호화된다.
암호화된 요청은 다른 서버를 통과할 때 필요한 최소한의 정보만 갖게 되는데, 이는 클라이언트의 ip 를 (보안을 위해) 감춰주는 보안 효과를 내준다.
따라서 본 서버에서 IP 주소를 역추적해도 포워드 프록시 서버를 사용하면 정체를 파악하기 어렵게 된다.
왜냐면 IP 추적해도 포워드 프록시 서버 IP만 보이기 때문이다.

리버스 프록시 (Reverse Proxy)

리버스 프록시는 아래 그림 처럼 웹서버/WAS 앞에 놓여 있는 것을 말한다.

클라이언트는 웹서비스에 접근할때 웹서버에 요청하는 것이 아닌, 프록시로 요청하게 되고, 프록시가 배후(reverse)의 서버로부터 데이터를 가져오는 방식이다.

클라이언트쪽으로 데이터(response)를 밀어주는게 포워드라면, 그 반대편인 서버 쪽으로 데이터(request)를 밀어주는 것이 리버스 프록시 라고 보면 된다.

Tip
여기서 Reverse 의 뜻은 "역전, 꺼꾸로"의 뜻이 아닌 "배후, 뒷쪽"의 뜻이다.

Tip
여기서 Reverse 의 뜻은 "역전, 꺼꾸로"의 뜻이 아닌 "배후, 뒷쪽"의 뜻이다.
즉, 배후에 있는 서버에 대한 Proxy라고 생각하면 된다.

내부 서버가 직접 서비스를 제공해도 되지만 이렇게 구성하는 이유는 보안 때문이다.
보통 기업의 네트워크환경에서는 DMZ라고 부르는 내부네트워크/외부네트워크 사이에 위치하는 구간이 존재한다. (내부네트워크/외부네트워크에 둘다 접근할 수 있는 공간)
이 구간에는 보통 메일 서버, 웹 서버, FTP 서버 등 외부 서비스를 제공하는 서버가 위치하게 된다.

WAS를 DMZ에 놓고 서비스해도 되지만 보안상문제가 있기 때문에 그렇게 하진 않는다.

WAS는 DB서버와 연결되어 있으므로, WAS가 해킹당할 경우 DB서버까지 해킹당할 수 있는 문제가 발생할 수 있기 때문이다.
따라서 리버스 프록시 서버를 DMZ에 두고 실제 서비스 서버는 내부망에 위치시킨 후 서비스 하는 것이 일반적이다.

Info
우리가 구성하는 일반적인 WEB(Apache, nginx) - WAS(Tomcat) 분리 형태를 Reverse 프록시라고 보면 된다.
여기서 WEB(Apache, nginx)가 reverse proxy가 된다.
물론 아파치 톰캣 같이 물리적인 한서버에 web, was가 존재한다면 reverse proxy라고 볼 수 없다.

리버스 프록시 사용 이점

로드 밸런싱 (Load Balancing)

유명한 웹 사이트는 하루에도 수백만명이 방문한다.
그리고 그러한 대량의 트래픽을 하나의 싱글 서버로 감당해 내기란 어렵다.
하지만 리버스 프록시 서버를 여러개의 본 서버들 앞에 두면 특정 서버가 과부화 되지 않게 로드밸런싱이 가능하다.

서버 보안 (Security)

리버스 프록시를 사용하면 서버 측 보안에 좋다.
리버스 프록시를 사용하면 본래 서버의 IP 주소를 노출시키지 않을 수 있다. 따라서 해커들의 DDoS 공격과 같은 공격을 막는데 유용하다.

위의 그림 에서 보면, 클라이언트는 인터넷을 통해 리버스 프록시 서버 url에게 요청을 한다. 그리고 리버스 프록시는 본서버에게 요청을 경유해서 보내게 된다.
이렇게 되면 클라이언트는 본 서버의 url을 모른채 리버스 프록시 url을 통해 서비스를 이용하게 되고, 이는 즉 본서버의 정보를 숨기는 효과가 된다.

캐싱 (Caching)

만약 어떤 한국에 있는 유저가 미국에 웹서버를 두고 있는 사이트에 접속할때, 리버스 프록시 서버가 한국에 있다고 해보자.
그러면 한국에 있는 유저는 한국에 있는 리버스 프록시 서버와 통신해서 리버스 프록시 서버에 캐싱되어 있는 데이터를 사용할 경우에는 더 빠른 성능을 보여줄수 있다.
포워드 프록시의 캐싱과 비슷한 기능을 한다고 보면 된다. (정확히 프록시의 본래 기능)

암호화 (Encryption)

마지막으로 SSL 암호화에도 좋다.
본래 서버가 클라이언트들과 통신을 할때 SSL(or TSL)로 암호화, 복호화를 할 경우 비용이 많이 들게 된다.
그러나 리버스 프록시를 사용하면 들어오는 요청을 모두 복호화하고 나가는 응답을 암호화해주므로 클라이언트와 안전한 통신을 할수 있으며 본래 서버의 부담을 줄여줄 수 있다.

로드밸런서(Load Balancer)

서비스 규모가 커지면 서버 한 대로는 모든 서비스를 수용할 수 없게 됩니다. 서버 한 대로 서비스를 제공할 수 있는 용량이 충분하더라도 서비스를 단일 서버로 구성하면 해당 서버의 애플리케이션, 운영체제, 하드웨어에 장애가 발생했을 때, 정상적인 서비스를 제공할 수 없습니다.

서비스 가용성(availability)를 높이기 위해서 하나의 서비스는 보통 두 대 이상의 서버로 구성하는데 각 서버 IP주소가 다르므로 사용자가 서비스를 호출할 때는 어떤 IP로 서비스를 요청할지 결정해야 합니다. 사용자에 따라 호출하는 서버의 IP가 다르면, 특정 서버에 장애가 발생했을 때, 전체 사용자에게 영향을 미치지 않아 장애 범위는 줄어들겠지만 여전히 부분적으로 서비스 장애가 발생합니다. 이러한 문제점을 해결하기 위해서 로드 밸런서(Load Balancer)를 사용합니다.

로드 밸런서에는 동일한 서비스를 하는 다수의 서버가 등록되고 사용자로부터 서비스 요청이 오면 로드 밸런서가 받아 사용자별로 다수의 서버에 요청을 분산시켜 부하를 분산합니다.

로드 밸런서에는 서비스를 위한 가상 IP를 하나 제공하고, 사용자는 각 서버의 개별 IP 주소가 아닌 동일한 가상 IP를 통해 각 서버로 접근 합니다. 이 외에도 로드 밸런서는 각 서버의 서비스 상태를 체크해 서비스가 가능한 서버로만 사용자의 요청을 분산하므로 서버에서 장애가 발생하더라도 기존 요청을 분산하여 다른 서버에서 서비스를 제공할 수 있습니다.

profile
기록하고 공유하려고 노력하는 DevOps 엔지니어

0개의 댓글