운영중인 앱들의 요청 라우팅 하기 - AWS Route 53, Nginx

문제 상황

지난 달에는 회사에서 SPOF로 작용했 던, 앱 사용자 로그를 수집 및 처리하는 레거시 로그 서버를 AWS 클라우드 환경으로 분리 이전 하는 작업을 진행했다.

 

그러면서 현재 서비스 중인 50종의 앱들에서 이제는 레거시 로그 서버가 아닌 새로운 신규 로그 서버로 로그를 보내주도록 하는 작업이 필요하게 되었다.

 

먼저 생각 해 본 방식은 앱 자체를 업데이트 해서 새로운 리시버 서버로 로그를 보내도록 업데이트 하는 방법이였다. 

이렇게 하려면, 앱에 적용되어있는 로그 리시버 서버 URL을 새로운 URL로 바꾸어 주어야 했는데, 현재 서비스 중인 앱의 종류가 50종이 넘는 상황이여서 그 앱들을 모두를 업데이트 하기 쉽지 않은 상황이였다.

 

또한 앱 자체를 업데이트를 한다고 해도 유저가 스토어에서 앱을 업데이트 하지않고, 이전 버전으로 계속 사용하는 경우도 있을 수 있었기 때문에 문제가 될 수 있었다.

 

뿐만 아니라 서비스 중인 앱 이외에 사내 레거시 운영툴에서 보내는 일부 요청도 기존 로그 서버 URL을 통해 들어오고 있는 상황이여서 사내 레거시 운영툴에서 보내는 요청은 그대로 레거시 로그 서버로 요청을 보내게 놔두고, 50여종의 앱에서 로그를 보내는 수집 요청 만 신규 로그 서버로 보내야 하는 상황이였다.

 

 

시도한 방법

1. AWS Route 53에서 기존 로그 서버 URL의 호스트 변경

먼저 수행한 방법은 50종이 넘는 앱들에 적용되어있는 기존 URL을 신규 URL로 바꾸어 줄 수 없기 때문에, 기존 URL 자체의 라우팅 설정을 바꾸어 주는 방법이였다.

 

기존 로그 서버 URL 라우팅 설정 변경 전

기존 로그 서버 URL 라우팅 설정 변경 후

이렇게 되면 50여종의 앱을 업데이트 할 필요가 없이 기존 로그 서버 URL로 요청을 보내도 신규 로그 서버에 요청이 보내지게 된다.

하지만, 사내 레거시 운영툴에서 보내는 요청도 신규 로그 서버로 함께 들어오는 문제가 있었다. 그래서 사내 레거시 운영 툴에서 보내는 요청은 이전 처럼 계속 기존 IDC 레거시 로그 서버로 보내도록 분리하는 작업을 따로 진행 해 주었다.

 

2. 로그를 수집하는 요청만 신규 로그 서버에서 받도록 요청 분리하기

로그를 수집하는 요청의 경우 예시로 /post 이렇게 요청의 경로가 특정 되어있었기 때문에 해당 경로로 들어오는 요청만 신규 로그 서버로 받고, 나머지 요청은 레거시 로그 서버로 라우팅을 해주어야 했다.

2-1. nginx 에서 redirect 하기

먼저 생각한 방법은 로그 서버의 리버스 프록시 서버인 nginx에서 기존 로그 서버 URL로 들어오는 요청 중 경로가  /post인 요청은 신규 로그 서버 주소로, /post가 아닌 요청은 레거시 로그 서버의 신규 주소로 redirect 해주는 것이였다.(이전에 사용하던 주소는 위의 1단계 에서 라우팅 설정이 변경 되었으므로 신규 주소를 만들어서 사용)

nginx에서 redirect 하기 위한 설정 파일 예시

nginx.conf

server {
	server_name 기존레거시로그서버URL

...
 
	location ~ ^/post(/*)$ {
		return 308 신규로그서버URL/$request_uri;
	}
    
	location / {
		return 308 레거시로그서버의신규URL/$request_uri;
	}
    
}
...

😱 nginx 에서 redirect시 발생한 문제

200, 300대 상태 코드

영구 redirect 상태 코드 302, 308 중 원본 요청의 Method가 변경되지 않는 308 response를 내려주도록 설정 했지 만, nginx access 로그를 살펴보니, 일부 redirect 되어 다시 들어오는 요청이 POST 가 아닌 GET으로 원본 요청의 Method가 바뀌거나, 경로가 바뀌는 문제가 발생하였다.

//nginx access logs

appname:log-receiver-nginx	request:GET / HTTP/1.1	request_method:GET	status:404	
appname:log-receiver-nginx	request:GET /post HTTP/1.1	request_method:GET	status:404

nginx에서 308 리다이렉트 응답을 보낸다고 해도, 요청을 보내는 쪽에서 redirect를 제대로 지원하지 않을 수 있고, 그렇게 되면 다른 요청의 Method나 경로로 리다이렉트 될 수 있다는 것을 알게되었다.

 

2-2. nginx 에서 redirect 대신 proxy_pass로 요청 분기 처리하기

redirect의 경우, 위와 같이 GET 이외의 요청에서 제대로 동작하지 않는 문제가 있을 수 있기 때문에 nginx에서 redirect 대신 upstream을 분리한 후, proxy_pass로 각 upstream에 요청을 분리해 전달하도록 수정했다.

nginx.conf

...
	upstream new-log-server {
		server 신규로그서버호스트:포트;
	}

	upstream regacy-log-server {
		server 레거시로그서버신규주소;
	}
...

    server {    
        location ~ ^/post(/*)$ {
            proxy_pass http://new-log-server;

            proxy_http_version 1.1;

            proxy_set_header Host $host;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';

            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-Host $host;
            proxy_set_header X-Forwarded-Server $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location / {
            proxy_pass http://regacy-log-server;

            proxy_http_version 1.1;

            proxy_set_header Host $host;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';

            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-Host $host;
            proxy_set_header X-Forwarded-Server $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
...

 

결과

최종적으로 아래와 같은 상태가 되었다. 기존 로그 서버의 URL을 그대로 사용하면서 각 요청 별로 처리가 필요한 각각의 upstream 서버로 요청을 라우팅처리 할 수 있게 되었다.

추후 레거시 IDC 서버와 레거시 운영툴 까지 덜어내게 된다면, 아래 그림과 같이 이미 서비스 중인 50여종의 앱에서는 기존 로그 서버의 URL을 그대로 사용하고, 신규 출시 되는 앱의 경우에만 신규 로그 서버 URL을 사용해 로그를 보낼 수 있을 것 같다.

레거시 시스템과 완벽히 분리 된 모습