[웹 배포] 프록시(Proxy)

프록시의 역사와 배포에서의 역할

웹 개발을 하다 보면 프록시라는 용어를 자주 접하게 됩니다. 하지만 프록시가 정확히 무엇이며, 어떻게 발전해 왔는지, 그리고 배포 환경에서 어떤 역할을 하는지 깊게 생각해 본 적이 있으신가요? 이번 글에서는 프록시의 역사와 함께 배포에서의 프록시 활용에 대해 알아보겠습니다.

프록시의 탄생: 왜 필요했을까?

프록시는 영어로 "대리인"을 뜻합니다. 마치 누군가 대신해서 메시지를 전달해주는 역할을 하는 것이죠. 인터넷 초창기에는 네트워크 속도가 느리고, 보안 이슈도 많았습니다. 이때 프록시는 클라이언트와 서버 사이에서 중간 역할을 수행하며 이러한 문제들을 해결하는 데 도움을 주었습니다.

예를 들어, 학교 도서관에서 특정 웹사이트에 접속하려고 할 때 직접 인터넷에 연결하지 않고 도서관 서버를 통해 접속하는 방식이 바로 프록시의 초기 형태였습니다. 이는 네트워크 트래픽을 효율적으로 관리하고, 보안을 강화하는 데 큰 도움이 되었습니다.

프록시의 발전 과정

시간이 흐르면서 인터넷 사용이 폭발적으로 증가하고 웹 기술이 발전함에 따라 프록시의 역할도 다양해졌습니다.

• 캐싱(Cache): 자주 요청되는 데이터를 프록시에 저장하여 응답 시간을 단축했습니다.
• 콘텐츠 필터링: 기업이나 기관에서 불필요한 웹사이트 접근을 차단하는 데 사용되었습니다.
• 보안 강화: 방화벽과 함께 사용되어 내부 네트워크를 보호했습니다.

프록시란 무엇인가?

간단히 말해, 프록시는 클라이언트의 요청을 받아 대신 서버에 전달하고, 서버의 응답을 다시 클라이언트에게 전달하는 중계자입니다.

비유로 이해하기

프록시를 택배 회사에 비유해 볼까요? 여러분이 온라인 쇼핑몰에서 물건을 주문하면 택배 회사가 그 물건을 판매자로부터 받아 여러분에게 전달합니다. 이때 택배 회사는 물건이 안전하게, 그리고 효율적으로 전달되도록 중간에서 조율합니다. 프록시도 이와 비슷하게 데이터의 전달을 중계하고 관리합니다.

종류별 프록시

• 포워드 프록시(Forward Proxy): 클라이언트 앞에 위치하여 클라이언트의 요청을 대신 전달합니다. 예를 들어, 내부망에서 외부 인터넷에 접근할 때 사용됩니다.

표준 인터넷 통신에서는, 컴퓨터 A가 컴퓨터 C에 직접 연결하고 클라이언트는 원본 서버에 요청을 보내며 원본 서버가 클라이언트에 응답합니다. 정방향 프록시가 설정되면 A가 대신 B에 요청을 보내고 B가 요청을 C로 전달합니다. 그런 다음 C가 B에게 응답을 보내고 B가 응답을 A에게 다시 전달합니다.

 

주 당국 또는 기관의 검색 제한을 피하기 위해 - 일부 정부, 학교, 기타 조직에서는 방화벽을 사용하여 사용자에게 제한된 버전의 인터넷에 대한 액세스 권한을 부여합니다.정방향 프록시를 사용하면 사용자가 방문하는 사이트에 직접 연결하지 않고 프록시에 연결할 수 있으므로 이러한 제한을 피할 수 있습니다.

특정 콘텐츠에 대한 액세스를 차단하려면 - 반대로 사용자 그룹이 특정 사이트에 액세스하는 것을 차단하도록 프록시를 설정할 수도 있습니다.예를 들어 학교 네트워크에서는 콘텐츠 필터링 규칙을 활성화하는 프록시를 통해 웹에 연결하도록 구성되어 Facebook 및 기타 소셜 미디어 사이트의 응답 전달을 거부할 수 있습니다.

 

온라인에서 자신의 신원을 보호하기 위해 - 어떤 경우에는 일반 인터넷 사용자가 단순히 온라인에서 익명성을 원하지만, 다른 경우에는 정부가 반체제 인사에게 심각한 처벌을 가할 수 있는 곳에 인터넷 사용자가 살 수도 있습니다. 웹 포럼이나 소셜 미디어에서 정부를 비판하면 이러한 사용자에게 벌금이나 징역형이 선고될 수 있습니다.이러한 반체제 인사 중 한 명이 정방향 프록시를 사용하여 정치적으로 민감한 댓글을 게시하는 웹 사이트에 연결하는 경우, 댓글 게시에 사용된 IP 주소로 반체제 인사를 추적하는 일이 더 어려워집니다.프록시 서버의 IP 주소만 표시됩니다.

 

• 리버스 프록시(Reverse Proxy): 서버 앞에 위치하여 외부의 요청을 받아 내부 서버로 전달합니다. 로드 밸런싱이나 SSL 종료 등에 사용됩니다.

역방향 프록시는 하나 이상의 웹 서버 앞에 위치하여 클라이언트의 요청을 가로채는 서버입니다. 이것은 프록시가 클라이언트 앞에 위치하는 정방향 프록시와 다릅니다. 역방향 프록시를 사용하면 클라이언트가 웹 사이트의 원본 서버에 요청을 보낼 때 역방향 프록시 서버가 네트워크 에지에서 해당 요청을 가로챕니다. 그런 다음 역방향 프록시 서버가 원본 서버에 요청을 보내고 응답을 받습니다.

 

정방향 프록시와 역방향 프록시의 차이는 미묘하지만, 중요합니다. 요약하면 정방향 프록시는 클라이언트 앞에 위치하며 원본 서버가 해당 특정 클라이언트와 직접 통신하지 못하도록 하는 것입니다. 반면에 역방향 프록시는 원본 서버 앞에 위치하며 어떤 클라이언트도 원본 서버와 직접 통신하지 못 하도록 합니다.

 

다시 한 번 관련된 컴퓨터의 이름을 지정하여 설명하겠습니다.

 

D: 사용자의 가정용 컴퓨터 수
E: 이것은 역방향 프록시 서버입니다
F: 하나 이상의 원본 서버

 

일반적으로 D의 모든 요청은 F로 직접 이동하고, F는 D에게로 직접 응답을 보냅니다. 역방향 프록시를 사용하면 D의 모든 요청이 E로 직접 이동하고, E는 요청을 F에게로 보내며 F로부터 응답을 받습니다. E는 그런 다음 적절한 응답을 D에게 전달합니다.

 

아래에서는 역방향 프록시의 이점을 간략하게 설명합니다.

 

부하 분산 - 매일 수백만 명의 사용자를 확보하는 인기 있는 웹 사이트에서는 단일 원본 서버로 들어오는 모든 사이트 트래픽을 처리하지 못할 수 있습니다.대신, 사이트에서는 동일한 사이트에 대한 요청을 모두 처리하는 서로 다른 서버 풀에 분산될 수 있습니다.이 경우 역방향 프록시는 단일 서버에 과부하가 걸리는 것을 방지하기 위해 들어오는 트래픽을 여러 서버에 고르게 분산하는 부하 분산 솔루션을 제공할 수 있습니다.서버가 완전히 실패하는 경우 다른 서버가 트래픽을 처리하기 위해 나설 수 있습니다.

공격으로부터 보호 - 역방향 프록시를 사용하면 웹 사이트 또는 서비스에서 원본 서버의 IP 주소를 공개할 필요가 없습니다.이로 인해 공격자가 DDoS 공격과 같은 표적 공격을 활용하기가 훨씬 더 어려워집니다.대신 공격자는 Cloudflare의 CDN과 같은 역방향 프록시만 대상으로 지정할 수 있습니다. 이는 사이버 공격을 방어하기 위해 더 엄격한 보안과 더 많은 자원을 갖게 됩니다.

전역 서버 부하 분산 (GSLB) - 이 부하 분산 형식에서 웹 사이트는 전 세계 여러 서버에 분산될 수 있으며 역방향 프록시는 클라이언트를 지리적으로 가장 가까운 서버로 보냅니다.그러면 요청과 응답이 이동해야 하는 거리가 줄어들어 로드 시간이 최소화됩니다.

캐싱 - 역방향 프록시도 콘텐츠를 캐시할 수 있으므로 성능이 향상됩니다.예를 들어, 파리에 있는 사용자가 로스앤젤레스에 있는 웹 서버가 있는 역방향 프록시 웹 사이트를 방문하는 경우, 사용자는 실제로 파리에 있는 로컬 역방향 프록시 서버에 연결할 수 있습니다. 그러면 이 서버는 LA에 있는 원본 서버와 통신해야 합니다. 프록시 서버는 그런 다음 응답 데이터를 캐시(또는 임시 저장)할 수 있습니다.사이트를 탐색하는 파리의 후속 사용자는 파리의 역 프록시 서버에서 로컬로 캐시된 버전을 가져오므로 성능이 훨씬 빨라집니다.

SSL 암호화 - 각 클라이언트에 대한 SSL(또는 TLS) 통신의 암호화 및 암호 해독은 원본 서버의 경우에 계산 비용이 많이 들 수 있습니다.역방향 프록시는 들어오는 모든 요청을 해독하고 나가는 모든 응답을 암호화하여 원본 서버의 귀중한 리소스를 확보하도록 구성할 수 있습니다.

 

클라이언트와 서버 간의 통신의 매개체가 되는 인터넷을 중심으로 Proxy가 어디에 존재하는지에 따라 포워드, 리버스 Proxy로 구분된다고 생각하면 편할 것 입니다.

배포에서의 프록시 역할

배포 환경에서는 프록시가 더욱 중요한 역할을 합니다. 특히 서비스의 안정성과 확장성을 확보하기 위해서는 프록시의 활용이 필수적입니다.

로드 밸런싱

여러분이 인기 있는 음식점을 운영한다고 생각해 보세요. 손님이 몰리면 한 명의 직원으로는 감당하기 어렵습니다. 이때 여러 직원이 손님을 분담하여 응대하면 대기 시간을 줄일 수 있습니다. 마찬가지로, 리버스 프록시는 들어오는 트래픽을 여러 서버로 분산시켜 서버의 부담을 줄이고 서비스의 안정성을 높입니다.

SSL 종료

SSL 암호화 통신은 보안을 위해 필수적이지만 서버에 부하를 줄 수 있습니다. 프록시 서버에서 SSL 처리를 담당하면 내부 서버들은 복잡한 암호화 과정 없이도 안전한 통신을 할 수 있습니다.

마이크로서비스 아키텍처에서의 역할

마이크로서비스 환경에서는 수많은 서비스들이 서로 통신합니다. 이때 프록시는 서비스 간의 통신을 관리하고, 라우팅을 담당하며, 서비스 디스커버리를 지원합니다. 이는 복잡한 도로망에서 네비게이션 시스템이 최적의 경로를 안내하는 것과 비슷합니다.

 

HTTPS와 프록시의 관계

HTTPS와 프록시는 현대 웹 아키텍처에서 중요한 역할을 하며, 특히 보안과 성능 최적화 측면에서 밀접하게 연관되어 있습니다. 이 둘의 관계를 더 자세히 살펴보겠습니다.

 

SSL/TLS 터미네이션

HTTPS 통신에서 프록시의 가장 중요한 역할 중 하나는 SSL/TLS 터미네이션입니다. 이는 마치 국제 공항의 입국 심사대와 비슷합니다. 해외에서 온 승객(HTTPS 요청)이 입국 심사대(프록시)에서 검사를 받고 나면, 국내에서는 자유롭게 이동할 수 있습니다.

프록시 서버는 클라이언트로부터 오는 암호화된 HTTPS 요청을 받아 복호화하고, 내부 네트워크에서는 일반 HTTP로 통신합니다. 이렇게 하면 백엔드 서버의 부하를 줄이고, 내부 네트워크의 트래픽을 모니터링하기 쉬워집니다.

 

보안 강화

프록시는 HTTPS를 통한 보안 강화에도 중요한 역할을 합니다. 예를 들어:

1. HTTPS 리다이렉션: HTTP로 들어오는 요청을 자동으로 HTTPS로 리다이렉트하여 모든 통신을 암호화할 수 있습니다.
2. HSTS (HTTP Strict Transport Security) 적용: 브라우저가 항상 HTTPS를 사용하도록 강제하여 중간자 공격을 방지합니다.

이는 마치 보안 게이트가 있는 아파트 단지와 같습니다. 모든 방문자는 보안 게이트(프록시)를 통과해야 하며, 게이트에서는 방문자의 신원을 확인(HTTPS 인증)하고 보안 규칙(HSTS)을 적용합니다.

 

성능 최적화

HTTPS와 프록시의 조합은 웹 서비스의 성능을 크게 향상시킬 수 있습니다:

1. HTTPS 캐싱: 프록시는 HTTPS 응답을 캐시하여 반복되는 요청에 대해 빠르게 응답할 수 있습니다.
2. HTTP/2 지원: 많은 프록시 서버는 HTTP/2를 지원하여 HTTPS 연결의 성능을 더욱 향상시킵니다.

이는 마치 고속도로의 하이패스 시스템과 같습니다. 한 번 인증된 차량(HTTPS 연결)은 이후에 빠르게 통과할 수 있으며, 여러 차선(HTTP/2의 멀티플렉싱)을 동시에 이용할 수 있습니다.

 

인증서 관리

대규모 시스템에서 SSL/TLS 인증서 관리는 복잡할 수 있습니다. 프록시를 사용하면 인증서 관리를 중앙화할 수 있어, 마치 한 곳에서 모든 열쇠를 관리하는 것과 같습니다. 이렇게 하면 인증서 갱신이나 보안 정책 변경 시 훨씬 효율적으로 관리할 수 있습니다.

 

CDN과의 통합

콘텐츠 전송 네트워크(CDN)는 종종 프록시 서버로 구현되며, HTTPS를 통해 안전하게 콘텐츠를 전달합니다. 이는 마치 전 세계에 분산된 물류 센터 네트워크와 같습니다. 사용자는 가장 가까운 센터(CDN 엣지 서버)에서 안전하게(HTTPS) 콘텐츠를 받아볼 수 있습니다.

 

API 게이트웨이로서의 역할

마이크로서비스 아키텍처에서 프록시는 종종 API 게이트웨이 역할을 합니다. 이 게이트웨이는 HTTPS를 통해 외부 요청을 안전하게 받아들이고, 내부 서비스로 라우팅합니다. 이는 마치 큰 회사의 리셉션 데스크와 같습니다. 모든 방문객은 리셉션(프록시)에서 체크인(HTTPS 인증)을 하고, 적절한 부서(내부 서비스)로 안내받습니다.