리버스 프록시와 로드 밸런서
1. Topology 관점에서 리버스 프록시란 클라이언트보다는 서버 쪽에 가까운 프록시로 정의할 수 있을 것 같다. Web framework의 interceptor와 유사하게 요청을 필터링하는 기능도 있으며 두드러지는 특징으로
인터넷으로부터 서버를 은닉화한다.
인터넷으로부터 서버를 보호한다.
Concurrent한 요청으로부터 효율적인 퍼포먼스를 기대할 수 있다.
가 있다.등을 소개할 수 있을 것 같다.
Nginx와 Apache 서버의 차이
1.요청마다 프로세스/쓰레드를 생성하는 Apache 서버는 높은 트래픽 환경에서의 메모리 문제(C10K)를 갖는다. 이벤트 기반 방식을 취한 Nginx는 효율을 목표로 경량화된 HTTP 특화 웹 서버/proxy라고 할 수 있을 것 같다.
2. 이벤트 기반 방식도 마스터 프로세스/워커 프로세스 방식으로 나눌 수 있다고 하는데, 전자의 경우에는 마스터 프로세스 자체가 병목 지점이 될 가능성이 있다고 한다. Nginx의 경우에는 후자를 따른다.
3. (Nginx를 운용하는 데 있어)설정을 읽고 유효성 검증 정도를 수행하는 마스터 프로세스의 CPU 사용량은 높지 않아서 특정 코어를 점유할 필요가 없다고 한다. 따라서 8코어 서버 기준, 1 마스터/ 8워커 프로세스가 존재하는 걸 확인할 수 있다.
Nginx와 HAProxy의 차이
1. 조금 비약해서 Nginx는 ‘로드 밸런싱이 가능한 HTTP 웹 서버/proxy’로, HAProxy는 ‘로드 밸런싱에 특화된 프록시’로 분류할 수 있을 것 같다.
2. 둘 중에 HAProxy를 프록시 서버로 써야 할 이유를 정리하자면
HAProxy의 로드 밸런싱이 성능이 더 좋다.
무료로 모니터링 툴을 위한 metric을 제공한다.
Nginx에서는 포트 기반 헬스 체크만 가능하고 URL 기반 헬스 체크는 제한된다. (Telnet과 SSH를 통한 통신 체크 방법이 생각나는 대목이다.)
Nginx
1. 초기 핸드셰이크를 포함하는 과정이 HTTP/HTTPS 통신에서 리소스 소모가 심한 단계라고 한다. 때문에 두 가지 방식이 발전되는데, SSL termination가 persistent connection이 그것이다.
2. SSL Offloading(Termination)
서버에서 매 번 SSL/TLS encrypt/decrypt를 진행하기에는 부담이 있으므로, 프록시 서버에서 HTTPS를 HTTP로 변환한 뒤에 서버에는 HTTP 평문을 전달하게 된다.
3. Persistent Connection
Connection은 기본적으로 소켓을 사용하고 이는 리눅스 기준으로 파일 시스템을 사용한다고 볼 수 있을 것이다. 클라이언트의 HTTP/HTTPS 요청은 결국 서버와의 TCP connection으로 이어지므로 이를 효율적으로 사용하는 것이 중요하다.
HTTP 1.0에서는 keep-alive 옵션이 선택적이었으나, HTTP 1.1부터는 기본적으로 persistent connection을 제공한다고 한다. 아직 성숙한 기능은 아니기 때문에 max connection이나 timeout과 같은 옵션이 중요하다고 한다.
추가적으로 확인한 HTTP 1.1 -> 2.0 발전 방향은 메세지 단위를 직렬 처리하는데 있어서 발생하는 blocking 문제를 frame/message/stream 단위로 병렬 처리하는 데 주된 목적을 두는 것으로 확인할 수 있었다.
HAProxy
1. 사실 Nginx를 웹 서버로 두고 HAProxy는 리버스 프록시 - 로드 밸런서로 역할하는 것도 가능하다. http/tcp 모드 중 http 모드를 기대했으나 Nginx에서 HAProxy 포트로 보낸 트래픽을 tcp 모드로 받을 수도 있는 부분이 흥미로웠다.
2. HAProxy에서 multi process → multi thread로의 발전
1) 분명 multi process가 성능면에서는 우위를 가지나, 1.8 버전을 기준으로 multi thread 기능을 도입했는데 이는 편의성을 목적으로 한다.
2) 한편 multi process가 HAProxy에서 제한을 갖는 점은 다음과 같다.
- HAProxy에서 세션 지속성을 목적으로 세션 정보를 공유하고자 stick table을 관리하는데, 이는 프로세스간 공유될 필요가 있다. 프로세스 독립적인 환경에서는 이 동기화가 오버헤드로 작용한다고 한다.
- 헬스체크가 프로세스 마다 진행되므로 내용이 글로벌하게 공유된다고 보기 어렵다. (이 부분은 참된 의미가 와닿지 않는다...)
멀티 쓰레드를 구현할 때 (여러 쓰레드가 하나의 스케줄러를 공유하는 게 아니라) 하나의 쓰레드 내에 하나의 스케줄러를 포함시켰다고 한다. 결과적으로 멀티 프로세스와 유사하게 동작하되, 위에 설명한 제한되는 부분을 해결하려고 시도했다고 한다.
더 자세하게는 (stick table을 참고해서) 특정 세션에 관련되는 작업 모음을 특정 쓰레드가 처리하도록 해서 해당 세선이 serialized 될 수 있었고, 결과적으로 lock을 줄이고 세션 지속성을 달성했다고 한다.
3) 현재는 multi thread가 디폴트라고는 하나, 코어 당 1 쓰레드 이상은 추천하지는 않는다. (자세한 이유는 확인하기 어려웠다.) nbthread config는 보통 설치 시 자동 설정되는 것으로 보이는데 코어 당 1 쓰레드만 넘지 않으면 되는 것 같다.
참고
https://brainbackdoor.tistory.com/28
https://www.haproxy.com/blog/how-to-get-ssl-with-haproxy-getting-rid-of-stunnel-stud-nginx-or-pound?ref=log.cyconet.org
https://etloveguitar.tistory.com/137
https://www.haproxy.com/blog/http-keep-alive-pipelining-multiplexing-and-connection-pooling
https://www.haproxy.com/blog/layer-4-and-layer-7-proxy-mode
https://www.haproxy.com/blog/multithreading-in-haproxy
https://www.haproxy.com/blog/haproxy-1-9-has-arrived#improved-threading
https://discourse.haproxy.org/t/multi-process-or-multi-treaded/7409/4
https://blog.naver.com/bumsukoh/222179667781
https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-HTTP-20-%ED%86%B5%EC%8B%A0-%EA%B8%B0%EC%88%A0-%EC%9D%B4%EC%A0%9C%EB%8A%94-%ED%99%95%EC%8B%A4%ED%9E%88-%EC%9D%B4%ED%95%B4%ED%95%98%EC%9E%90
