HTTP를 HTTPS로 변환하는 과정을 진행하다보면 NGinx라는 것을 만나게 되고, NGinx는 리버스 프록시, 로드밸런싱 기능을 포함하고 있는 웹 서버 오픈소스임을 알게 된다. 리버스 프록시? 로드밸런싱? 이런 것들이 다 무엇일까? 이번 포스팅에선 이 내용들에 대해 기록해보려고 한다. 아마 컴퓨터공학과 전공 수업에서 잠깐 만났어서 익숙한 사람들도 꽤 있을 것 같다.
프록시 (Proxy)
흔히 포워딩 프록시(Forwarding Proxy)를 통상적으로 프록시라고 부른다. 프록시의 사전적 정의는 아래와 같다.
프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다. 서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을 가리켜 '프록시', 그 중계 기능을 하는 것을 프록시 서버라고 부른다. -위키백과-
여기서 가장 중요한 의미는 '대리'다. 나의 작업을 바톤터치해서 대리로 해주는 친구. 이 친구를 프록시라고 이해하면 편할 듯하다.
위 그림과 같이 클라이언트들이 요청하는 작업을 대리로 처리해주는 프록시가 존재한다. 따라서, 인터넷(서버)와 직접적으로 통신하는 것은 실제 클라이언트가 아닌, 프록시가 된다.
이렇게 함으로써 어떠한 장점이 존재하는걸까?
1. 캐싱을 통한 성능 향상
프록시를 사용하면 캐싱을 통해 성능을 향상시킬 수 있다.
예시를 살펴보자. 클라이언트 1이 kth990303, 즉 나에 대해 궁금해한다. 클라이언트는 정보를 얻기 위해 구글링을 통해 kth990303에 대한 정보를 아래처럼 얻어낸다. 프록시 서버는 해당 요청과 그에 대한 응답을 저장해놓는다.
이후에, 클라이언트 2 에서도 kth990303에 대해 궁금해져서 해당 요청을 보내는 경우를 가정해보자. 이 경우, 아까 클라이언트 1의 요청과 응답 결과를 프록시에 저장해놓았기 때문에, 클라이언트 2의 요청에 대한 응답으로 Internet (Server)까지 통신할 필요 없이, 프록시 서버에 저장해둔 응답값을 바로 보내주면 된다! 웹서버 트래픽이 감소하여 성능을 향상시킬 수 있고, 네트워크 병목 현상을 막을 수 있는 것이다.
2. 보안 및 우회 가능
이 경우도 예시를 통해 살펴보자.
클라이언트 1, 2, 3이 인터넷과 직접적으로 통신하게 되면 클라이언트 1, 2, 3의 IP가 직접적으로 인터넷에 드러나게 된다. 이는 보안적으로 취약할 수밖에 없다. 중간에 프록시 서버를 둔다면, 인터넷 서버는 프록시 서버와 통신하기 때문에 클라이언트 1, 2, 3의 IP를 알 수 없게 된다! 이는 보안적인 취약점을 커버할 수 있게 되며, 특정 서버를 우회하여 들어갈 수 있도록 허용해주는 역할도 하게 된다.
리버스 프록시 (Reverse Proxy)
간단하다. 포워딩 프록시가 서버 쪽에도 존재한다고 생각하면 된다. 응답을 보내주는 측 역시, 어떠한 요청에 대한 응답을 보내줄 때 캐싱과 보안 취약점 제거를 위해 리버스 프록시를 사용한다. 클라이언트 입장에서는 서버 측의 실제 IP가 아닌, 리버스 프록시의 IP만 알 수 있기 때문에 보안상 취약점을 커버할 수 있게 된다.
로드 밸런싱 (Load Balancing)
요청에 대한 응답을 처리할 때, 서버에서 일을 부하분산시키는 작업을 의미한다. 실제로 NGinx를 로드 밸런서로 사용하여 부담하는 부하를 줄여주는 작업을 많이들 진행하고 있다.
위와 같이 일에 대한 부하가 9 정도 되는 것을, 로드밸런싱 작업으로 각 서버에서 3씩 처리할 수 있게 해 일의 부하를 최소화시켜주는 작업을 로드밸런싱이라 한다. 위와 같이 서버를 추가로 증설하여 일의 부하를 분산시키는 방법을 Scale-out이라 하며, 서버 증설이 아닌 기존 서버 성능 자체를 확장시켜 업그레이드하는 것을 Scale-up이라 한다.
만약, 로드 밸런싱 알고리즘이 이상하게 짜여져서 동일 성능의 3대 서버에 각각 7, 1, 1 씩 부담하게 된다면 응답 처리속도가 더 느려지게 될 것이다. 이처럼 로드밸런싱 알고리즘은 매우 중요하다. 만약 이러한 알고리즘을 경험해보고 싶다면 아래 문제를 풀어보는 것도 재밌을 것 같다. 요청이 최대 10만 개나 되고, 해당 요청들을 모두 처리하는 데 걸리는 최소 시간을 O(NlogN) 이하의 시간으로 해결하는 문제이다.
https://www.acmicpc.net/problem/12016
12016번: 라운드 로빈 스케줄러
첫째 줄에 작업의 개수 N (1 ≤ N ≤ 100,000)이 주어진다. 둘째에는 각 작업을 수행해야하는 시간이 공백으로 구분되어 주어진다. 각 작업을 수행해야하는 시간은 1보다 크거나 같고, 1,000,000,000보다
www.acmicpc.net
위 문제에서 알 수 있듯이, 로드 밸런싱 기법에는 요청을 순서대로 돌아가며 배정하는 라운드로빈 기법, 가중치를 추가로 한 가중 라운드로빈 기법, IP를 해싱하여 각 서버에 매핑하는 방식인 IP 해싱 기법 등등 다양한 기법들이 존재한다.
L4 로드밸런싱과 L7 로드밸런싱
로드 밸런싱 중에서 가장 활용이 많이 되고 있는 L4 로드밸런싱과 L7 로드밸런싱에 대해 알아보자. 여기서 L4, L7은 OSI 7 Layers의 계층을 의미한다. 눈치빠른 사람이라면 L4는 Transport layer, L7은 Application layer의 헤더를 부하 분산에 이용하겠다는 걸 알아챘을 수도 있겠다.
L4 로드밸런서는 IP, TCP/UDP, port 번호, MAC 주소 등을 바탕으로 부하를 분산한다. 위에서 설명한 IP 해싱 기법이 L4 로드밸런서의 알고리즘 중 하나라고 볼 수 있다. L4 로드밸런서는 탁월한 성능을 자랑한다.
L7 로드밸런서는 URL, payload, cookie, HTTP 헤더 등을 통해 부하를 분산한다. L4 로드밸런서와 달리, 데이터를 분석해서 부하를 분산하기 때문에 비정상적인 트래픽을 필터링할 수 있어 DDos 공격을 예방할 수 있다는 장점이 있다. 대신, 그만큼 자원적인 소모가 커서 L4 로드밸런서에 비해 성능은 느리다는 단점이 존재한다. L7 로드밸런서는 가장 기본적인 로드밸런서로 널리 통용되고 있다.
HTTPS 변환을 위한 인프라 쪽을 공부하다보니 NGinx에서 사용되고 있는 네트워크, 리눅스 공부들의 필요성을 확실히 느끼게 되는 것 같다. 앞으로도 많은 경험을 하면서 cs의 필요성을 느껴보고 공부해보고 싶다.
참고
1. https://youtu.be/YxwYhenZ3BE
2. https://tecoble.techcourse.co.kr/post/2021-11-07-load-balancing/
3.https://www.lesstif.com/system-admin/forward-proxy-reverse-proxy-21430345.html
'CS > Http, Network' 카테고리의 다른 글
| [매트 스터디] 5주차 HTTP 헤더2 - 캐시와 조건부 요청 (0) | 2022.06.01 |
|---|---|
| [매트 스터디] 4주차 HTTP 헤더 1 - 일반 헤더 (0) | 2022.05.22 |
| [매트 스터디] 3주차 HTTP 메서드 활용 & HTTP 상태코드 (2) | 2022.05.15 |
| [매트 스터디] 2주차 HTTP 기본 & HTTP 메서드 (0) | 2022.05.09 |
| [매트 스터디] 1주차 인터넷 네트워크 & URI와 웹 브라우저 요청 흐름 (2) | 2022.04.30 |