Forward Proxy, Reverse Proxy, Load Balancer

Proxy

• 대리
• 남을 대신하여 일을 처리

 

 
Spring Proxy
 
Proxy 패턴
 
Network Proxy
 
여러가지 의미로 쓰인다. ! 
 
tmi)

• 제가 프록시를 접했던 것은 스프링에서 AOP 기능을 사용하여 공통의 작업을 따로 빼서 전 후로 작업을 수행하려고 할 때였습니다!. (영한님)
• 로깅 or method의 실행 시간 같은 것을 기록해놓을 때. AOP 기능을 쓸 수 있습니다.!
• 이때 의존관계 주입에서 진짜 클래스가 아닌 프록시 객체를 등록해놓고 요청이 오면 프록시 객체가 중간에 가로채서 작업을 수행하고(전) 진짜 클래스의 메서드가 실행된 후 또 작업을 실행하는(후) 과정에서 나온 개념이였습니다.

 

지금은 Network Proxy!

• 대신 처리하는 서버(간단하게 말하면)
• 프록시 서버(Proxy Server)는 클라이언트(사용자 또는 사용자의 컴퓨터)와 인터넷 사이에서 중계 역할을 하는 서버
• 캐시, 보안, 트래픽 분산 등 여러 장점을 가질 수 있습니다.

 

Proxy의 종류

Forward Proxy

• 일반적으로 말하는 Proxy는 Forward Proxy라고 볼 수 있습니다.
• Proxy서버 설정을 한다.
  • 인터넷 속도를 향상시키기 위해서 윈도우 같은 데서 Proxy 서버 설정을 해줘라.
  • 외국에서 접속하는 것처럼 테스트하기 위해 Proxy 설정
  • 개인정보를 빼돌린 해커 A씨는 IP추적을 방지하기 위해 Proxy 설정을 ...
• Forward Proxy는 Clients와 Internet 사이에 있습니다.

• Forward Proxy가 사이에서 흐름을 대신 처리하고 있습니다.

 

특징

• 캐싱
  • 클라이언트가 요청한 내용을 캐싱하여, 응답 속도를 빠르게 할 수 있습니다.!
  • 예시
    • 클라이언트 [요청] : 오늘 날씨 어때?
    • 서버 [응답] : 오늘 날씨 비 옵니다. 
    • Forward Proxy [가로채기] : 위의 요청, 응답 Forward Proxy에 저장해놔야지.
      
      • [요청] : 오늘 날씨 어때?
      • [응답] : 오늘 날씨 비 옵니다.
    • 시간이 흐른 후..
    • 클라이언트 [요청] : 오늘 날씨 어때?
    • 서버 까지 가지 않습니다.
    • Forward Proxy에서 어? 나 그 요청에 대한 응답 알아.~
    • Forward Proxy [응답] : 오늘 날씨 비 옵니다.
  • 뒷 단을 통하지 않기 때문에 전송 시간이 절약됩니다.
  • 불필요한 외부 전송을 하지 않아도 되고
  • 외부 요청이 감소됨으로써 네트워크 병목 현상을 방지할 수 있다.!

 

• 익명성
  • 클라이언트가 보낸 요청을 감춘다.
  • 클라이언트가 서버로 직접 호출할 때는 ~
    • "우리가 요청을 해" 라는 정보를 서버에게 그대로 전달해줍니다.
    • IP같은 것을 받을 수도 있고, 장비 정보 OS정보를 받을 수 있습니다. (서버가)
    • 가운데 Forward Proxy를 넣게 되면?
    • 우리(Clients)가 요청 했지만 Forward Proxy가 요청을 한 것처럼 서버에게 정보를 전달할 수 있게 됩니다.
  • 우리 컴퓨터의 정보를 넘겨주지 않게 되는 것입니다.!
  • 예
    • 서버가 받은 요청 프록시는 프록시 IP가 되는 것

 

 
 

Reverse Proxy

• Forward Proxy와 매우 유사
• Forward Proxt와 다르게 인터넷과 서버들 사이에 위치를 하고 있습니다.

 
특징

• 캐싱
• 보안
  • 서버 정보를 클라이언트로부터 숨길 수 있습니다.
    • 클라이언트 [요청] : 나는 저 서버(IP)에서 정보를 받아올꺼야 ㅎㅎ -> 실제로는 Proxy에 요청을 전달
    • 서버 [응답] : 나는 Reverse Proxy에게 응답을 해줘야지~
    • 리버스 프록시 [실제 응답] : 내가 응답은 담당한다.~ 대신 전달해줌.ㅎㅎㅎ
    • 클라이언트는 Reverse Proxy에 요청을 보냈던 것!
    • 실제 서버의 IP가 클라이언트로부터 안전하게 보호됩니다.
• 로드밸런싱(Load Balancing)
  • 하는 경우도 있고 하지 않는 경우도 있습니다.
  • 부하 분산 처리
  • 해야할 작업을 나눠서 서버의 부하를 분산시키는 것
  • 관련해서는 많은 자료가 있습니다.
    
    • 예
      • 내가 만든 서비스를 서버 한대에 올려서 서비스를 하고 있었는데~
      • 소비자의 니즈가 충족되었는지 사람들이 몰리기 시작합니다.
      • 트래픽이 폭발 합니다.!! 서버 한대로는 요청을 받기 힘들어 집니다.
      • 또한 리팩토링하여 반영하려고 할 때 서버를 껐다 켜야 합니다. (1~2초 안에 끝난다고 하더라도 그 시간에 서비스를 이용하려던 유저들은 에러가 발생했다고 생각합니다.)
      • 어떻게 해야할까요?
        • 서버의 스펙을 올리는 방법
        • 하드웨어의 성능을 향상시키는 방법인 Scale Up 방법이 있습니다.
        • 그러나 서버의 스펙을 올리는 것은 한계가 있기 마련이죠.
        • 무한정으로 메모리를 추가할 수 없으니까요.
      • 이렇게 해볼까?
        • 여러 대의 서버에 내 애플리케이션을 올리고 (당연하지만 DB는 하나만 바라보게~)
        • Load Balancer를 중간에 넣어주어 분산으로 여러 대의 서버에 요청이 갈 수 있도록 설정해주면 됩니다.
        • 여기서 분산 처리에 관련된 알고리즘은 찾아보면 많이 나옵니다. (RR 등등)

 

제가 제일 헷갈렸던 거

L2 / L3 / L4 / L7 로드밸런서 ????? 이게 뭐지

• L2 로드밸런서
  • 데이터링크 계층 - Mac주소로 분산처리
• L3 로드밸런서
  • 네트워크 계층 - IP주소로 분산처리
• L4 로드밸런서
  • IP / Port 레벨에서 분산처리
  • 예시
    • https://cow.oopy.io/
    • 저의 자기 소개 URL입니다. ㅎㅎ
    • 당연히 뒤에 80포트로 접근하게 되고, 이를 여러 대의 서버에 요청을 나눠서 주는 것이라고 보면 됩니다.
    • TCP/IP 계층에서 이를 담당한다고 보면 됩니다.

• 너무 성의가 없나요. 흑 이런 구조입니다.

 

• L7 로드 밸런서
  • 애플리케이션 레벨에서 분산처리
  • https://cow.oopy.io/category
  • https://cow.oopy.io/blog
  • 이런식으로 요청 두개가 날라오면 
  • 뒤의 category, blog 차이점을 인식하고 이를 1번 서버에게 보내주고, 2번 서버에게 보내주고
  • Query Parameter, Path Variable 등등 다양한 방식으로 분산처리를 할 수 있습니다.

 

• 이분 설명을 적어놓았습니다. 설명 너무 좋습니다. 

https://www.youtube.com/watch?v=YxwYhenZ3BE