준수의_개발정리노트

1. Upstream Block Upstream은 서버들의 묶음이다. upstream backend {     server 111.111.111:8000 weight=5;     server 111.111.112:8000;     server 111.111.113:8000; } 위의 예시에서는 3개의 서버간에 load balancing이 되며 weight를 명시하게 되면 해당 서버에 더 많은 load를 배분할 수 있다. 위의 예시에서는 111.111.111서버가 다른 2서버에 비해 5배 많은 load를 할당받는다. configuration 파일에서 server블럭에서는 ip주소로 호출하는 것이 아니라 upstream의 이름으로 호출한다. (예시에서 backend) 2. Server Block Server Block은 하나의 가상 서버를 나타낸다. 따라서 여러개의 server block을 생성하게 되면 하나의 머신에서 여러개의 어플리케이션을 호스팅할 수 있다. Nginx가 라우팅을 할때는 최우선 적으로 listen 옵션을 본다. listen 옵션은     - address:port 숫자     - ip주소 (포트80만 처리)     - port 숫자 (해당 포트로 들어오는 모든 인터페이스)     - unix socket 경로 Nginx는 오직 같은수준으로 명시된 listen이 여러개 있을 때만 server_name을 사용하여 비교한다. server { listen 192.168.1.10; . . . } server { listen 80; server_name example.com; . . . } 위의 예시에서 만약 example.com이 192.168.1.10의 80번 포트에 호스팅 되어 있다면, 항상 첫번째 블럭이 호출된다(Nginx는 불완전한 ip주소를 자동으로...

Ningx 는 request가 가장 먼저 도착하는 곳이다.  Web application으로 보내져야만 하는 request들만을 보낸다.(필터링같은 느낌) Gunicorn 은 request를 웹 프레임워크가 이해하고 처리할 수 있는 형식으로 변환시켜 보낸다. Nginx Nginx는 Web server이자 Reverse Proxy이다. 아래는 Nginx가 잘하는 기능들 예시이다:     - domain name routing     - 정적 파일 보내기     - 한번에 들어오는 많은 양의 request를 처리하기     - 느린 client들 처리하기     - 동적처리가 필요한 request들을 Gunicorn으로 보내기     - SSL 끝내기 Nginx는 다음과 같은 일들은 할 수 없다:     - Python web application 실행하기     - request를 WSGI로 변역하기 Gunicorn Gunicorn은 다음과 같은 일들에 특화되어 있다:     - worker processes/threads 풀을 사용하여 코드 실행     - Nginx가 보낸 request를 WSGI에 맞게 변환     - 어플리케이션에서 보낸 WSGI response를 http response로 변환     - request가 들어오면 실제로 파이썬 코드 실행하기     - Gunicorn은 다양한 웹서버와 통신할 수 있음 다음과 같은 일은 할 수 없다:     - 최전방에 나설 수 없다: DOS에 취약하다     - SSL을 끝낼 수 없다(no https handling)

웹서버의 기본적인 역할은 정적(static)인 파일을 그대로 보내주는 것 입니다. 그 말인즉슨, 뭔가 별도의 처리를 거치지 않고 존재하는 파일을 그대로 보내주는 역할을 합니다. CGI(Common Gateway Interface) 웹서버에서 어플리케이션을 작동시키기 위한 인터페이스로서, 정적인 웹서버를 동적으로 기능하게 하기 위해서 등장 하였습니다. 기존에는 외부프로그램이 필요한 리퀘스트가 들어오면 CGI를 통해 따로 프로세스를 fork하고 외부프로그램을 실행시켜 처리하였지만, 요즘에는 웹서버에 인터프리터를 내장시켜 내부적으로 처리한다. CGI Programming이란, Perl, C/C++를 사용하여 웹서버가 실행할 수 있는 프로그램을 작성하는 것이다. WAS(Web Application Server) 웹서버가 동적으로 기능하면 WAS이다. 즉, Web Server + CGI가 WAS이다. WSGI Server(middleware) Web server와 WSGI를 지원하는 Web Application사이에서 동작하며 아래와 같은 일을 한다     - 환경변수가 바뀌면 타겟 URL에 따라서 리퀘스트 경로를 지정해줌     - 같은 프로세스에서 여러 어플리케이션과 프레임워크가 실행됨 WSGI vs CGI CGI는 리퀘스트가 들어오면 CGI 프로토콜에 따라서 스크립트를 실행시킵니다. 서브프로세스를 fork하여 서브프로세스가 response를 작성하고 이를 웹서버로 보내면 웹서버가 이 response를 브라우저로 보냅니다. 대부분 CGI는 모든 리퀘스트마다 서브프로세스를 fork합니다. WSGI는CGI 디자인 패턴에 기반한 인터페이스입니다. 가장 큰 차이점은 WSGI는 모든 리퀘스트마다 fork를 통해 서브프로세스를 띄우지 않으므로 느리지 않습니다. https://brownbears.tistory.com/350 왜 WSGI가 중요한가? 전통적인 Web Server는 파이썬 어플리케이션들을 이해하...

Apache Apache는 MPM(Multi Processing Module)이라는 방식으로 처리를 하는데 대표적인 방식으로 Prefork와 Worker방식이 있다. - Prefork MPM : 실행중인 프로세스를 복제하여 처리한다. 각 프로세스는 한번에 한 연결만 처리하고 요청량이 많아질수록 프로세스는 증가한다. 하지만 프로세스를 복제하는 것이므로 메모리영역까지 복제되어 동작하기 때문에 메모리 공유가 없어 안정적이다. - Worker MPM : Prefork방식이 1개의 프로세스가 1개의 스레드로 처리가 되었다면 Worker 동작방식은 1개의 프로세스가 각각 여러 쓰레드를 사용하게 된다. 쓰레드간의 메모리를 공유하며 PreFork방식보다 메모리를 덜 사용하는 장점이 있다. Apache vs Nginx Nginx의 가장 유명한 특징이라면 Event Driven방식이다. 따라서 어떠한 요청이 들어오면 어떤 동작을 해야하는지만 알려주고 다른 요청을 처리한다. 그러다보니 프로세스를 fork하거나 쓰레드를 사용하는 Apache와는 달리 CPU에 관계없이 모든 I/O를 전부 Event Listener로 미루기 때문에 흐름이 끊기지 않고 응답이 빠르게 진행되어 1개의 프로세스로 더 빠른 작업이 가능하게 될 수 있다. 이때문에 메모리측면에서 Nginx가 System Resource를 적게 처리한다는 장점이 있다고 한다. https://taetaetae.github.io/2018/06/27/apache-vs-nginx/ Nginx는 Webserver이자 Reverse Proxy이다. Proxy: client가 요청한 정보를 여러개의 서버로부터 받은 뒤 client에 반환한다. Forward Proxy:  client를 위한 proxy로써 아무 server와 통신할 수 있도록 해준다. Reverse Proxy:  server를 위한 proxy로써 서버 어플리케이션의 취약점들을 보완해줌으로써 아무 client와 통신할...