Nginx proxy_pass 조심해서 써야하는 이유
안녕하세요. 개발까마귀입니다.
오늘 알려드릴거는 Nginx proxy_pass 입니다.
proxy_pass란?
Nginx가 들어간 서버 아키텍처를 보면 아래와 같습니다.
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://localhost:3000
}
location /test {
proxy_pass http://test.com/test;
}
}여기서 CLIENT가 NGINX를 요청하고 NGINX가 WAS를 요청합니다.
그래서 물리적인 서버안에 같이있기 때문에 `location /` 처럼 proxy_pass를 localhost로 지정하기도합니다.
하지만 proxy_pass 옵션을 꼭 localhost가 MS(Micro Service)로 즉 독립적인 서버로 요청을 보낼수있습니다.
`location /test` `location /test2` 안에 있는 proxy_pass를 MSA 서버 주소라고 생각하시면 됩니다.
즉 /test API 엔드포인트 요청이 들어오면 http://test.com/test MS 로 요청을 보내게 되는겁니다.
이런식으로 API 요청을 다른서버로 보낼수있는거죠 그렇다면 왜 proxy_pass를 조심해야할까요?
proxy_pass 주의해야할 점
위에 말씀드렸다시피 CLIENT -> NGINX -> WAS 식으로 요청흐름이 갑니다.
하지만 MS가 추가가 된다면 아래와 같을겁니다.
위에 NGINX 세팅한거처럼 API 엔드포인트가 `/test` 일 때는 `/test/` proxy_pass에 설정한 MS로 가게됩니다.
그런 다음 MS는 그에 대한 응답을 NGINX 한테 줍니다. 그런 다음 NGINX는 클라이언트 전달하는 거죠
CLIENT -> NGINX -> MS -> NGINX -> CLIENT 순서입니다. 그렇다면 조심해야할 점은 무엇일까요?
바로 MS가 NGINX 서버에 의존되어있다는겁니다. 즉 NGINX 서버가 부하가 있다면 아무리 MS가 빠르고 성능이 좋다하더라도 최종적으로 응답을 보내는 NGINX서버가 클라이언트에 응답을 못보낸다는겁니다.
예를들어 A 은행서비스서버에서 B은행서비스서버에서 공통 서비스인 송금 서비스만 MS로 따로 빼고 각 A,B 은행서비스서버에서는 proxy_pass를 통해서 송금 서비스 MS에 요청갈수있도록 설정을 했습니다. 하지만 A은행서비스에 사람이 너무 몰렸고 송금이 안된다는 CS가 인입됩니다. 하지만 B은행서비스는 송금이 잘됩니다. 여기서 당연히 송금이 안된다고 하니깐 송금서비스 MS에 모니터링 분석을하지만 문제가 없습니다. 결론적으로는 송금서비스 MS는 문제가 없습니다. 문제는 사람이 몰린 A은행서비스가 문제인거죠 송금서비스 MS에 응답이 아무리 빨리 응답이와도 A은행에서비스서버에 NGINX는 worker_connection이 다 차 있기 때문에 다른 요청에 대한 응답처리로인해 빠르게 클라이언트 응답이 안간겁니다. 그에 반해 B은행서비스서버는 사람이 안몰려있기 때문에 송금서비스가 잘됐던겁니다.
즉 proxy_pass를 통해서 의존성이 발생하고 멀쩡한 송금서비스 MS만 계속 모니터링하면서 시간만 날리게되는거죠
그러면 드는 생각은 그냥 송금 서비스는 클라이언트에서 바로 요청하면되는거 아닌가라는 생각이 들겁니다.
그 생각이 맞습니다. 하지만 이러한 구성이 실무에서는 가끔 보입니다. 예를들어 원래는 모놀리식으로 있었던 서비스가 MS로 뺐는데 클라이언트에서는 요청주소를 바꿔서 배포하기가 싫어서 위 구성처럼 서버에서 핸들링하는방법으로 위 구성이 만들어지기도합니다. 아니면 API Gateway를 도입해서 문제를 해결해도되지만요.
해당 문제는 실제로 회사에서 겪었던 문제여서 한번 정리해봤습니다.
감사합니다.
댓글