개요.
리버스 프록시와 웹서버가 나에겐 비슷하게 들리면서 다르게 사용됨을 느꼈다. 그래서 여러 구조도를 그려보면서 어떨땐 reverse proxy 로 불리는지 또는 web server 로 불리는지 생각해보는 시간을 가지기로 했다.
1. client - web server - was
하나의 서버장비 내에, 웹서버(nginx) 와 애플리케이션 서버가 같이 구동되고 있는 형태이다. 이에 따르면 nginx 는 단순 웹서버의 형태의 역할을 하고 있다. 애플리케이션 프로젝트 레벨에 있는 리소스를 서빙하거나 또는 서버 내의 정적 파일들을 서빙해주고 있을 것이다. 그리고 8081 포트와 8082 포트가 각각 앱서버로 구동 중에 있다.
- product (외부 사용자에게 현재 서비스가 되고있는 환경)
- stage (외부 사용자에게 서비스가 되었던 이전 버전 혹은 외부 사용자에게 서비스 되기 직전의 환경)
nginx 는 http 포트와 https 포트 두 개를 받고 있는데 http 포트로 받으면 443 포트 즉 https 포트로 리디렉션 할 수 있다. 아래의 구문은 서버블록내 작성가능하다.
location / {
return 301 https://{server-host}$request_uri;
}
2. client - reverse proxy - web server - was : multi domain
위의 형태가 리버스 프록시 형태이다. 지금 그림은 가장 앞단에 있는 nginx 에 멀티 도메인 설정을 해놓은 구조이다. 안에 세 개의 서버는 각각 서로 다른 도메인으로 작동하고 있는데 lion, tiger, dog 이런 경우에 해당 서버들은 외부에 노출되지 않은 형태의 내부망에서 동작하고 결과를 반환해준다. 외부 클라이언트와 통신은 항상 152.13.248.12 ip 인 프록시 서버 측에서 모두 처리하고 있다.
추가적으로 멀티 도메인 설정은 외부 아이피 하나로 여러개의 도메인을 가진 웹서비스를 할 수 있음을 생각할 수 있다. 만약에 공인 아이피가 하나가 존재하고 내부에 사설 아이피가 여러 개가 있다면 특정 도메인에 따라서 사설 아이피를 분기 처리해서 req/res 할 수 있는 것이다.
리버스 프록시를 두는 이유는 해당 링크에 설명해두었고, 참고링크에도 설명이 잘되어있다.
nginx 상의 멀티 도메인 설정은 아래와 같이 할 수 있다.
http {
// tiger
server {
listen *:80;
server_name www.tiger.com
location / {
proxy_set_header HOST $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass https://10.35.12.13:23080;
}
}
// lion
server {
listen *:80;
server_name www.lion.com
location / {
proxy_set_header HOST $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass https://10.36.16.13:20080;
}
}
}이제 nginx 를 통해서 로드밸런싱 하는 방법도 있다. 흔히 프록시와 로드밸런서의 표현을 혼용해서 쓰는 경우도 있는데 어느 인터넷 글에서 모든 프록시가 로드밸런서라고 말은 할 수 없지만, 대다수의 프록시는 로드밸런싱 기능을 기본적으로 가지고 있다고 한다. 따라서 유사하게 쓰여도 무방하지 않을까.. 개인적으로 생각해본다.
로드밸런싱은 부하분산 클러스터 작업을 위해 필요한 것인데, 만약에 하나의 서버장비로만 게시판 서비스를 외부에 제공하면 추후에 많은 트래픽 발생 시 감당하기 어려워지게 된다. 이런 상황을 대비해서 부하를 분산시켜주는 작업이 필요한데 이 때 애플리케이션 서버 앞단에 로드밸런서가 있고 해당 장비가 트래픽을 적절히 로드밸런싱하면 서비스는 안정적으로 운영할 수 있게된다.
3. client - reverse proxy - web server - was : load balancing
해당 내용은 쓰지 않으려고 했는데 참고자료의 첫번째 링크의 nginx 로드밸런서를 보다가 문득 아키텍처 구상을 저렇게 하는게 맞지 않나 생각에 작성하게 되었다. nginx 의 upstream 설정을 was 여러대로 둘 수 있다.
- 10.35.12.13:8081
- 10.35.12.13:8082
- 10.35.12.14:8081
- 10.35.12.14:8082
실제 레거시 서비스에서는 저렇게 구성된 경우가 있다고 한다.
그리고 앞단의 프록시에서 로드밸런싱을 수행해주고 있음을 생각할 수 있다. 배포형태는 10.35.12.13 에 선배포이후에 배포한 쪽의 트래픽을 막고 dns 설정으로 직접 13 서버쪽으로 접근해서 결과를 확인한다. 이후에 이상 없을 시, 13 서버 쪽의 트래픽은 허용해주고 14 서버쪽의 트래픽을 막고 배포 이후에 확인을 수행한다. 이 같은 방식은 배포전략에 롤링업데이트에 해당한다.
(처음 배포전략이 카나리라 생각했다. 근데 생각하니 점진적으로 새로운 버전의 배포라고 생각되어 롤링업데이트인 듯하다. 왜냐하면 일부 유저의 유입조차, 즉 새 배포버전에는 트래픽 유입을 허용하지 않은 상태로 사내망에서 자체 확인을 거치고 이후에 외부 트래픽 유입을 허용해주기 때문이다.)
4. client - reverse proxy - web server - was : load balancing
(3) 을 그리고 난 뒤, 앞단에 reverse proxy 가 있고 뒤에 웹서버가 다수가 존재하여 서비스를 제공한다고 생각할 수 있지 않을까 해서 그려본 구조도이다. 부하분산 클러스터와 HA 구성이 되어있는 형태로 되어있다.
그래서,
(1) ~ (4) 을 쭉 생각하면서 그려봤는데, nginx를 어떤 역할로 쓰느냐에 따라서 리버스 프록시라고 할 수 있고 또는 웹서버라고 할 수 있다고 생각이 든다. 리버스 프록시 그 자체로 웹서버 형태로 클라이언트의 요청을 받아 앱서버에 해당 요청을 보내고, 앱서버의 응답을 받아 클라이언트로 응답을 주는 것으로 생각할 수 있고, 또는 리버스 프록시가 앞단에 자리잡고 있고 뒷단에 웹서버를 존재하도록 구조를 잡을 수 있게 할 수도 있다는 생각이 든다.
VIP (Virtual IP)
- 하나의 호스트에 여러 개의 IP 를 할당하는 기술이다.
- HA 또는 부하분산 클러스터를 구축하게 되면 VIP 또한 할당이 필요하다.
- 예를 들어 게시판 서버가 1번서버와 2번서버가 있으면 1번과 2번의 서버는 동일한 VIP 로 구축되어야 한다.
- 해당 기술을 사용하게 되면 하나의 NIC (Network Interface Card) 만 있더라도 여러 개의 IP 를 부여할 수 있다.
- 각각의 게시판 서버들(1번/2번) 은 사설 IP 로 구성되었지만 VIP가 부여되고, 해당 VIP 는 로드밸런서가 공인 네트워크와 사설 네트워크 사이에 위치하면서 가지고 있다.
- 따라서 외부에서 VIP 를 통해 게시판 서버를 접근하려고 한다면 로드밸런서는 적절하게 부하를 1번서버와 2번서버 나눠가질 수 있도록 라운드로빈을 수행한다.
- 추가로, 물리서버 장비를 할당 받으면 내부 IP 가 하나 할당되고, 외부 IP 도 하나 할당할 수 있는데 이 때, 외부 IP 를 해당 서버에 부여하게 된다면 NIC 쪽에 직접 사람이 랜선을 꽂아넣는다. (본체에 랜선 꽂아넣는것과 동일) 이 부분은 VIP 를 할당하는 것과는 또 다른 내용이다.
결론적으로, 하나의 서버가 가질 수 있는 IP 는 사설 IP, 공인 IP, 가상 IP(VIP) 가 될 수 있고 VIP 는 HA 또는 로드밸런싱에 많이 이용되고 있다.
확인사항
- nginx worker
- server resource maximum
- L4 (LB 장비)
참고자료
'네트워크' 카테고리의 다른 글
| 2018-09-22 SSH 란 ? (수정 : 2022-05-21) (0) | 2022.05.21 |
|---|---|
| 20200614 리얼리눅스 세미나 : 브라우저부터 웹서버까지. (1) | 2020.06.14 |
| 20200130 포트(Port) 를 개방한다는 건. (수정 : 2020-09-02) (0) | 2020.01.30 |
| 20190408 IDC 란 (0) | 2019.04.08 |
| 20180917 [cmd] Windows Command (0) | 2018.09.17 |
