든든한 ProxyServer

Intro

---

회사를 근무했던 당시 보안과 관련하여 여러 이야기를 듣던 중 AWS 의 각종 자원들이 Public Subnet 에 있게 된다면 손쉽게 외부 네트워크를 통해 접속할 수 있다라는 말을 듣고 황급히 회사내 AWS 설정을 들여다보았는데 역시나...

RDS, EC2, 등등 전체적인 자원들이 전부 Public Subnet 으로 되어있었고 내부 네트워크로 변경할 타이밍을 지켜보고 있었고 적절한 시기에 옮길 수 있었는데

이때 큰 고민이 생겼었다

그럼..외부에서 내부 네트워크를 어떻게 연결하지...?

당연히 외부네트워크에서 Private Subnet 을 직접적으로 연결할 수 없으니

외부 네트워크와 내부네트워크 둘다 갖고 있는 Public Subnet 이 존재할 수 밖에 없었고 외부네트워크에서 받은 트래픽을 내부네트워크로 전달을 해줘야한다
즉, 내부와 외부 둘 사이의 중간다리 역할을 하게 된다.

이를 분배하기 위해 EC2가 필요 했었는데 이를 Proxy Server 라고 생각을 했다.

ProxyServer 란?

가장 앞단에 있는 서버

즉, https://aaa.com 으로 접속을 하면 가장 먼저 맞이하는 서버를 의미한다.

Proxy server 의 장점으로는

1. 다른 서버들의 위치와 주소를 Front 에서 알지 못한다. (보안 상승)
2. 트래픽을 분산할 수 있다.

단점은

1. ProxyServer 가 다운되다면 전체 서비스가 다운된다.

정도가 있다.

장점에 해당하는 부분이 단점을 커버하고도 남는 상황이라 ProxyServer 를 도입하기로 생각을 했다.

Proxy Server 를 구성하기 위해 3가지를 생각하게 되었는데

1. NodeServer 를 띄운다.

2. Nginx 띄운다.

3. AWS LoadBalancer 이용

nodeServer

1번 방법인 Node Server 를 띄울 경우 단순히 Server Redirection 만 하면 되기 때문에 간단했다.

특히나 특정 서버에 중간에 NODE 를 이용하여 캐시작업을 할 수도 있고 DataBase 와 연결하여 다른 서버를 경유하지 않아도 바로 응답할 수 있어서 서버 제어에도 탁월했다.

다만 서버를 증설할 때 문제와 안정성의 문제가 있었다.

nodeServer 특성상 트래픽이 몰리면 서버가 다운 되기도하고 서버를 증설할 떄마다 코드를 수정해서 배포를 해야한다는 점이다.
그리고 또한 각서버를 분배하는 Logic을 따로 구현해야한다는 점이였다.

그래서 2번째 방법이 생각이 났다.

nodeServer - 공통 작업하기 좋음, 안정성 낮음, 알고리즘 직접 구현 필요

Nginx

Nginx 라는 웹서버를 띄움으로서 각 인스턴스에 있었던 Nginx 설정을 한번에 몰아서 처리할 수도 있었고

트래픽 분산 알고리즘도 갖고 있어서 단순히 설정만 하게 된다면 Nginx 에서 알고리즘에 의해 트래픽을 분산해주었다.

그래서 ProxyServer 에는 단순히 Nginx 서버만 띄우고 트래픽을 분배하는 알고리즘을 설정하여 각 서버에서 전달을 하도록 선택을 했다.

nginx - 안정성 좋음, loadBalance 기능 제공, 각 서버별 Nginx 제거 가능

AWS LoadBalancer

이런 부분도 진작 고민한부분인지 AWS 에서는 트래픽을 분배할 수 있는 LoadBalancer 라는 서비스를 제공한다.

이는 ProxyServer 처럼 갑자기 대용량 트래픽이 몰리거나 서버를 증설하여 여러개 서버가 있을 경우 분배해주는 서비스이다.

사실 우리에게 적합한 서비스였다. 다만 당시 개발비용을 추가적으로 들기기 힘들기도 하고 Loadbalancer 에 대한 공부가 부족하여 바로 적용하기에 부담이 좀 되었다.

aws - 비용부담, 추가 공부 필요
그래도 이제와 지금 생각하면 그때 그냥 이걸 하고 올걸 그랬다...

그래서 결국 NGINX 를 이용하여 트래픽 분산을 하기로 했다.

NGINX 에서 트래픽을 분산하는 방법은 LoadBalance 설정을 해주면된다.

Nginx 의 경우 ReverseProxy 를 이용하여 다음과 같이 설정하여 실제 서비스와 연결을 했는데

server {
	proxy_pass http://127.0.0.1:8000; 
}

이를 Nginx 의 LoadBalance 설정을 해주면된다.

우선 upstream 을 통해 서버들을 묶어주고

proxy_pass 옆에 적어주면된다.

upstream serverList { # 우선 upstream 으로 정의
	# 가장 상위에 분배 알고리즘을 작성 
    # 미작성 - round roubin
    # least_conn; - 최소 연결
    # ip_hash; - iP 주소 Hash
    # hash $request_uri consistent; - hash $변수에 따라 hash 로 변환하여 분배
 
    server 10.0.0.1:8000;
    server 10.0.0.1:9000;
    server 10.0.0.1:1212;
    
   
}

server {
	proxy_pass http://serverList; 
}

추가적인 설정을 공식문서를 확인해보자!
https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/

당시엔 채팅방 소켓 연결이 중요하여 least_conn; 알고리즘을 선택하여 진행했다.

그로인해 추가적인 부작용들...

이렇게 설정함으로써 보안과 서버증설에는 정말 유연하게 앞으로 대처를 할 수 있게 되었다.

다만 이제 그에 대한 부작용들이 생겨나기 시작했는데

첫번째로 개발시 불편함이였다.

proxyServer 를 경유하여 접속을 해야하겠기 때문에

이전엔 단순히 SSH 연결을 하나만 하면 DataBase 든, Server 컴퓨터든 접속이 한번에 됬지만 이제는 ProxyIP 또한 알고 있어야만 접속이 되었다

덕분에 보안은 올라감이 체감되었지만 할떄 마다 외부 IP, 내부 IP 둘다 설정하느라 설정을 다시 한 경험이 있다.

두번째는 이후에 다룰 채팅 SOCKET 연결에 대해 문제가 터졌었다.

이 부분은 서버를 증설한 부작용과도 연관이 높은데 ProxyServer 는 단순히 같은 채팅방에 있는 2가지의 트래픽이 같은 서버에 전달해야하는 이유를 모르기때문에

접속할 때 마다 운에 맡겨야만 했다. 그렇기 때문에 실시간 통신이 되질 않았던 부작용들이 있었다.

Outro

---

ProxyServer 를 구성하고 난 후 추후 서버를 트래픽이 몰리며 갑자기 증설할 일이 생겼었는데

증설하고 나서 안전하게 서비스를 유지하는 모습을 보고 미리 준비하길 너무 잘 했다라는 생각이 들었고 서버증설에 대한 대비가 잘 강화 되어 좋았습니다.