프록시 서버의 단점 및 한계

• IaaS

#Infra #IaaS #개념 #Proxy

1. 공통적인 단점

  • 추가 지연(Latency)
    • 클라이언트와 서버 사이에 중간 서버가 하나 더 끼기 때문에 요청/응답 과정에서 네트워크 지연이 발생할 수 있다.
    • 특히 암호화(SSL/TLS) 처리나 복잡한 규칙이 많을 경우 성능 저하가 두드러진다.
  • 단일 실패 지점(Single Point of Failure, SPOF)
    • 프록시 서버 자체가 장애가 나면 전체 서비스가 중단될 수 있다.
    • 이를 막기 위해 고가용성(HA) 구성이 필수적이다.
  • 운영/관리 복잡성
    • 규칙, 인증서, 접근 제어 목록 등을 관리해야 하고, 특히 대규모 환경에서는 설정이 복잡해진다.
    • 잘못된 정책 적용 시 서비스 장애로 이어질 수 있다.
  • 보안 리스크
    • 잘못 설정된 프록시는 오픈 프록시(Open Proxy) 가 되어 누구나 경유할 수 있는 보안 위협이 된다.
    • 공격자가 트래픽을 가로채거나 악용할 가능성도 있다.

2. 포워드 프록시(Forward Proxy)의 단점

  • 투명성 부족
    • 클라이언트는 프록시 설정을 직접 해야 하는 경우가 많다. (브라우저나 OS 네트워크 설정)
    • 잘못된 설정 시 인터넷 접속 자체가 안 되거나 제한된다.
  • 익명성의 한계
    • 일부 웹사이트나 서비스는 포워드 프록시를 탐지하고 차단한다. (예: 특정 국가 차단 우회 시도)
    • 고급 추적 기술(IP 지문, TLS Fingerprint)을 사용하면 실제 클라이언트 추적이 가능하다.
  • 캐싱 문제
    • 캐싱된 콘텐츠가 오래되어 최신 데이터를 반영하지 못할 수 있다.
    • 실시간성이 중요한 서비스(주식 거래, 실시간 알림 등)에는 적합하지 않다.

3. 리버스 프록시(Reverse Proxy)의 단점

  • 초기 설정 복잡성
    • 로드 밸런싱, SSL 인증서 관리, 리다이렉션, 캐싱 정책 등을 세밀하게 설정해야 한다.
    • 운영 경험이 부족하면 오히려 장애를 유발할 수 있다.
  • 추가 인프라 비용
    • 리버스 프록시 서버를 위한 하드웨어/클라우드 비용이 추가된다.
    • 특히 SSL 종료를 많이 처리하는 환경은 CPU 사용량이 높아 별도 장비(F5, 전용 SSL 오프로딩 장치)가 필요하기도 하다.
  • 병목 지점(Bottleneck)
    • 모든 외부 요청이 리버스 프록시를 거치기 때문에 성능 한계치에 도달하면 병목 현상이 발생한다.
    • 이를 해결하려면 Scale-out 구성이 필수적이다.
  • 보안 관리 부담
    • SSL/TLS 인증서를 모두 리버스 프록시에서 관리해야 한다.
    • 여러 도메인과 마이크로서비스가 섞이면 인증서 관리가 까다로워진다.

프록시 서버 단점에 따른 대표 시나리오

1. 공통 시나리오

(1) 단일 장애 지점(SPOF, Single Point of Failure)

  • 상황: 한 회사가 리버스 프록시(Nginx)를 웹 서비스 앞단에 단일 서버로 배치했다.
  • 문제: Nginx 프로세스가 다운되자 모든 웹 서버가 정상이어도 외부 사용자는 접속할 수 없었다.
  • 원인: 리버스 프록시가 모든 요청을 받아야 하는 구조라 병목이자 SPOF가 되었음.
  • 교훈: 리버스 프록시/로드밸런서는 반드시 이중화(HA 구성)해야 한다.

(2) 성능 저하 및 레이턴시 증가

  • 상황: 기업이 프록시 서버에서 SSL 종료(SSL Termination)와 로깅, 인증까지 동시에 처리했다.
  • 문제: 피크 타임에 CPU 사용률이 100%에 도달하면서 요청 응답 속도가 수 초까지 늘어났다.
  • 원인: 암호화/복호화 연산이 몰리면서 병목 발생.
  • 교훈: SSL 오프로딩 장비나 전용 하드웨어, 또는 Scale-out 구조가 필요하다.

2. 포워드 프록시 시나리오

(1) 캐싱 불일치(Inconsistent Caching)

  • 상황: 회사 내부망에서 Squid 프록시를 사용해 대역폭 절약을 노렸다.
  • 문제: 어떤 직원은 최신 공지사항이 보이는데, 다른 직원은 구버전 페이지가 계속 보였다.
  • 원인: Squid가 오래된 캐시를 계속 제공했기 때문.
  • 교훈: 실시간성이 중요한 서비스에는 캐싱 정책을 조정하거나 특정 URL 캐싱 제외 필요.

(2) 특정 서비스 차단 및 접속 불가

  • 상황: 학생들이 학교에서 유튜브 접속을 시도했는데 “접속 불가” 메시지가 표시됨.
  • 문제: 포워드 프록시 정책에서 스트리밍 서비스 도메인을 차단해 놓음.
  • 원인: 정책 적용은 했지만, 학생들에게 사전 고지가 없어 혼란 발생.
  • 교훈: 접근 제어 정책은 사용자 교육과 함께 투명하게 운영해야 한다.

3. 리버스 프록시 시나리오

(1) 인증서 만료 사고

  • 상황: 한 스타트업이 리버스 프록시(Nginx)에 SSL 인증서를 설치해 HTTPS를 운영했다.
  • 문제: 인증서 갱신을 깜빡해 웹사이트 전체가 “보안 경고(만료된 인증서)”를 띄우며 접속 불가 상태 발생.
  • 원인: 인증서 관리 자동화 미비.
  • 교훈: 인증서 자동 갱신(Let’s Encrypt + certbot 등) 반드시 도입.

(2) 로드 밸런싱 설정 오류

  • 상황: 리버스 프록시에서 라운드 로빈 방식으로 3대의 웹 서버에 분산 설정.
  • 문제: 서버 한 대가 다운됐는데도 헬스체크가 비활성화되어 계속 죽은 서버로 트래픽이 전달됨.
  • 결과: 사용자 3분의 1이 접속 장애 경험.
  • 교훈: 리버스 프록시에는 반드시 헬스 체크(Health Check) 설정이 필요하다.

(3) 보안 설정 누락

  • 상황: 리버스 프록시 뒤에 있는 내부 API 서버가 원래는 외부에서 직접 접근 불가능해야 했다.
  • 문제: 방화벽 규칙 미비로 외부 사용자가 프록시를 우회해 내부 API 서버에 직접 접근 가능.
  • 교훈: 리버스 프록시는 보안 게이트웨이 역할을 하지만, 네트워크 ACL·방화벽과 함께 종합적으로 관리해야 한다.

Comments

💬 Sign in with GitHub to leave a comment. Comments are public and stored in GitHub Discussions.