[ 데이터를 위한 Python : From Scratch to Master. ] 파이썬 웹 백엔드 개발의 필요 요소 : WSGI-guicorn & ASGI-uvicorn

Data-Forge : 데이터로 세상 이해해보기.·2025년 10월 16일

데이터를 위한 Python : From Scratch to Master.

목록 보기

8/8

[ 데이터를 위한 Python : From Scratch to Master. ] 파이썬 웹 백엔드 개발의 필요 요소 : WSGI-guicorn & ASGI-uvicorn

▽ [ 데이터를 위한 Python : From Scratch to Master. ] 파이썬 웹 백엔드 개발의 필요 요소 : WSGI-guicorn & ASGI-uvicorn

목  차

1. 정리하는 계기

2. WSGI란?

3. guicorn이란?

4. ASGI란?

5. uvicorn이란?

1. 정리하는 계기

파이썬으로 데이터를 서빙하는 백엔드 서버를 구성해보고 싶다는 생각에 진행했던
최근 프로젝트인 '자세 교정 웹' 프로젝트에서 파이선 프레임워크를 FastAPI로 선택하면서
웹을 띄우는 과정에서 uvicorn이 사용되었는데, 이걸 좀 더 알아보고 정리하고자 포스팅합니다.

2. WSGI란?

로컬 개발 환경에서의 파이썬-Django,Flask.

로컬에서 장고 서버를 구동하기 위해서는 python manager.py runserver 처럼 장고의 내장 서버를 구동하는 방식을 사용.

장고의 내장서버

장고의 내장 서버는 이번 장에서 설명할 웹 서버와 WSGI 서버의 기능을 모두 포함하고 있다. 다만 내장 서버는 기능이 단순하고 '대량 요청'이나 '동시 요청'을 효율적으로 처리하지 못하므로 운영 환경에는 적합하지 않다.

웹 브라우저.

웹 브라우저(Web Browser)는 사용자가 인터넷상의 웹 페이지와 기타 콘텐츠에 접근하고, 상호 작용하며, 그 내용을 볼 수 있도록 하는 소프트웨어 애플리케이션.

정적 페이지와 동적 페이지로 구성.

정적 페이지.

정적 페이지는 서버에 파일 형태로 저장되어 있으며, 사용자에게 요청될 때마다 동일한 내용을 제공하는 웹 페이지.

정의: 내용이 미리 완성되어 파일 시스템에 저장되어 있음.
사용자의 신원, 시간, 요청 내용과 관계없이 항상 똑같은 HTML, CSS, JavaScript 파일이 전송.
특징:
- 고정된 내용: 파일 내용 자체가 변하지 않습니다.
- 빠른 속도: 서버는 단순히 저장된 파일을 읽어 전송하기 때문에 처리 속도가 매우 빠릅니다.
- 낮은 부하: CPU 연산이나 데이터베이스(DB) 접근이 필요 없어 서버 부하가 낮습니다.
처리 주체: 주로 웹 서버 (예: Nginx, Apache)가 직접 처리.
WSGI와의 관계:
정적 파일 요청은 WSGI 서버로 전달되지 않고 웹 서버가 직접 처리하므로, WSGI는 관여하지 않음.

동적 페이지.

동적 페이지는 사용자의 요청 시점에 서버 측 프로그램(웹 애플리케이션)이 데이터베이스 조회나 비즈니스 로직을 수행하여 내용을 생성한 후 사용자에게 제공하는 웹 페이지.

정의: 요청마다 서버에서 데이터 처리 후 콘텐츠가 실시간으로 만들어지므로,
사용자나 시점에 따라 페이지 내용이 달라집니다.
특징:
- 가변적인 내용
  : 요청 매개변수나 DB 상태에 따라 페이지 내용이 바뀜.
- 높은 유연성
  : 사용자별 맞춤 정보, 검색 결과, 로그인 등 복잡한 기능을 구현할 수 있음.
- 상대적 부하
  : DB 접근, 연산, 템플릿 렌더링 등의 과정이 필요하여 정적 페이지보다 처리 시간이 길고
  서버 부하가 높음.
처리 주체: 웹 애플리케이션 서버(WAS) 또는 웹 프레임워크 (예: Django, Flask)가 담당.
WSGI와의 관계:
웹 서버가 동적 요청을 받으면, 이 요청을 파이썬 웹 애플리케이션으로 전달하기 위해
WSGI 표준을 따르는 WSGI 서버 (예: Gunicorn)를 중개자로 사용합니다. WSGI가 핵심적으로 작동하는 영역.

WSGI 환경에서의 요청 흐름.

WSGI를 사용하는 일반적인 구성(Nginx/Apache + Gunicorn/uWSGI + Django/Flask)에서 요청은 다음과 같이 분리.

클라이언트 요청 수신: 웹 브라우저가 웹 서버(Nginx 등)에 요청을 보냅니다.
요청 종류 판단:
- 정적 요청 (.css, .js, .png 등): 웹 서버가 자신의 저장 공간에서 파일을 찾아 직접 클라이언트에 응답합니다.
- 동적 요청 (/login, /posts/123 등): 웹 서버는 요청을 WSGI 서버 (Gunicorn 등)로 전달(프록시)합니다.
동적 요청 처리: WSGI 서버는 WSGI 규약에 따라 요청을 파이썬 웹 애플리케이션으로 전달하고, 앱이 생성한 동적 콘텐츠를 받아 다시 웹 서버를 통해 클라이언트에게 응답합니다.

이러한 분리 덕분에 웹 서버는 단순하고 빠른 정적 파일 서빙에 집중하고,
WAS는 복잡한 동적 로직 처리에 집중하여 시스템의 효율성을 극대화.

WSGI란?

WSGI는 웹 서버(Web Server) 소프트웨어와 파이썬으로 작성된 웹 애플리케이션 또는 웹 프레임워크 간의 통신을 위한 표준 인터페이스(규약).

이 표준은 2003년 PEP 333으로 처음 제안되었고 이후 PEP 3333으로 개정되며 파이썬 웹 개발의 사실상 표준으로 자리 잡음.

WSGI 정의 및 필요성.

정의.
- Web Server Gateway Interface의 약자로, 파이썬으로 작성된 웹 애플리케이션(예: Django, Flask)이 Apache, Nginx 같은 웹 서버와 통신할 수 있도록 하는 호출 가능한(Callable) 규약을 정의
- WSGI의 역할은 웹 서버가 보낸 HTTP 요청을 파이썬 애플리케이션이 이해할 수 있는 형태로 변환하여 전달하고, 애플리케이션의 응답을 다시 웹 서버가 클라이언트에게 보낼 수 있는 형태로 변환하는 중개자 역할.
주요 목적.

웹 서버와 어플리케이션 사이의 모든 상호작용에 대해 간단하고도 포괄적인 인터페이스를 제공하는 것.

ex) 웹 서버로부터 HTTP 요청을 받은 경우 어플리케이션으로 전달할 때 어떤 형식(dict, str 혹은 bytes 등)으로 전달할지, 또 통신 중 예외 상황이 발생한 경우 어떻게 처리할지 등에 대한 명세를 담고 있음.

덕분에, Django,Flask를 사용하는 어플리케이션 개발자는 WSGI 내부 설계나 배포에 대한 고민 없이 어플리케이션 내부 프레임워크에만 집중 가능해짐.

필요성.
- 호환성 및 이식성 확보:
  - WSGI 표준 덕분에 어떤 파이썬 웹 프레임워크(Django, Flask 등)를 사용하든, WSGI를 지원하는 모든 웹 서버(Gunicorn, uWSGI 등)에서 쉽게 구동 가능.
  - 웹 서버와 웹 애플리케이션이 독립적으로 개발 및 교체될 수 있도록 함.
- 효율성 개선:
  - 기존의 CGI(Common Gateway Interface) 방식이 요청마다 새로운 프로세스를 생성했던 것과 달리, WSGI 서버는 프로세스와 스레드를 재사용하여 리소스 효율성을 높임.

WSGI의 구성 요소.

WSGI 아키텍처는 크게 3가지 핵심 컴포넌트로 구성.

서버/게이트웨이 (Server/Gateway)

역할:
- 클라이언트(웹 브라우저)로부터 HTTP 요청을 받아 WSGI 애플리케이션으로 전달하고, 애플리케이션의 응답을 받아 다시 클라이언트에게 HTTP 응답으로 반환.
예시:
- Gunicorn, uWSGI, Waitress 등이 대표적인 파이썬 WSGI 서버입니다.
  (Apache나 Nginx 같은 웹 서버와 연동하여 사용됨).

애플리케이션/프레임워크 (Application/Framework)

역할:
- WSGI 표준을 준수하며 서버로부터 받은 요청을 처리하고,
  비즈니스 로직을 수행한 후 응답을 생성하여 서버에 반환.
예시:
- Django, Flask, Pyramid 등 파이썬 웹 프레임워크가 WSGI 인터페이스를 통해 서버와 통신.

미들웨어 (Middleware)

역할:
- 서버와 애플리케이션 사이에 위치하여 요청(environ)이나 응답을 가로채고 수정하는 추가 기능을 제공.
- 미들웨어는 WSGI 서버의 입장에서는 WSGI 애플리케이션처럼 작동하고,
  WSGI 애플리케이션의 입장에서는 WSGI 서버처럼 작동하는 특성.
예시:
- 세션 관리, 인증/권한 부여, 로깅, URL 라우팅, 디버깅 페이지 제공 등.

WSGI의 작동 방식(인터페이스 규약)

WSGI는 본질적으로 서버와 애플리케이션 간의 호출 가능한 객체(Callable Object)를 통한 통신 규약.

WSGI 애플리케이션 인터페이스

WSGI 표준을 따르는 파이썬 애플리케이션은 반드시 다음 두 인수를 받는
'호출 가능한 객체'여야 함.

1. environ (환경 변수 딕셔너리):
- 웹 서버로부터 전달된 HTTP 요청 관련 정보(헤더, 경로, 쿼리 스트링 등)를 포함하는 파이썬 딕셔너리.
- REQUEST_METHOD, PATH_INFO, SERVER_NAME 등의 CGI 환경 변수와 wsgi.input, wsgi.errors 등의 WSGI 관련 변수들을 담고 있음.
2. start_response (콜백 함수):
- 응답의 상태 코드(200 OK, 404 Not Found 등)와 HTTP 응답 헤더를 설정하기 위해 WSGI 서버가 제공하는 콜백 함수.
- 애플리케이션은 응답 본문을 반환하기 전에 반드시 이 함수를 한 번 호출해야 함.

요청 및 응답 처리 흐름

1. 요청 수신
: 웹 서버(예: Nginx)가 클라이언트의 HTTP 요청을 수신.
2. WSGI 서버 호출
: 웹 서버는 요청을 WSGI 서버(예: Gunicorn)로 프록시(전달).
3. 애플리케이션 호출
: WSGI 서버는 HTTP 요청 정보를 파싱하여 environ 딕셔너리를 만들고,
자신의 콜백 함수인 start_response와 함께
WSGI 애플리케이션의 호출 가능한 객체를 실행.

      # WSGI 애플리케이션의 기본 형태
      def application(environ, start_response):
         # 1. 응답 상태 및 헤더 설정
         status = '200 OK'
         headers = [('Content-type', 'text/plain')]
         start_response(status, headers)

        # 2. 응답 본문 반환 (반드시 이터러블한 바이트열(byte string)이어야 함)
         return [b"Hello, WSGI World!"]

4. 응답 생성
: 애플리케이션은 environ을 기반으로 로직을 처리하고,
start_response를 호출하여 상태/헤더를 설정한 후,
응답 본문(바이트열의 이터러블 객체)을 반환.
5. 응답 전송.
: WSGI 서버는 start_response로 받은 상태/헤더와 애플리케이션이 반환한
응답 본문을 조합하여 완전한 HTTP 응답을 만든 후,
웹 서버를 통해 최종적으로 클라이언트에게 전송.

흐름 정리.

Application 방면.

어플리케이션 객체는 두 변수를 입력받는 callable 객체 형태여야함.
- 즉, 파이썬에서 함수 형태거나 혹은 call 메소드가 정의된 클래스 객체를 이용하여 어플리케이션 작성이 가능.
- 서버 및 게이트웨이로부터 요청이 반복되어 들어올 수 있으므로 반복 호출이 가능해야 함.

# main.py
def wsgi_app(environ, start_response):
    status = "200 OK"
    headers = [("Content-type", "text/plain")]
    start_response(status, headers)
    return [b"It Works!"]

Server 방면

웹서버는 HTTP 클라이언트로부터 요청이 들어올 때마다
어플리케이션 측에서 제공하는 callable 객체를 한 번씩 호출.

상세 스펙.

어플리케이션은 반드시 callable 객체이어야 하며 다음 두 변수 environ, start_response를 입력받음.

다만, 어플리케이션 호출 시 위치 인자(positional arguments)로 입력받기 때문에
변수명을 동일하게 가질 필요는 없음.

environ.
- environ은 CGI 정보를 포함한 dict 객체.
- 반드시 다른 파이썬 mapping 객체를 상속받은 객체가 아닌 파이썬 builtin dict 객체 형태.
- 어플리케이션에서는 해당 dictionary 객체를 원하는 대로 가공 가능.
- 아래의 정보는 필수.

start_response
- start_response는 두 인자 status, response_headers와
  선택적으로 exc_info를 입력받는 callable 객체.
  - 입력값으로 받는 status는 “200 OK”, “404 Not Found”와 같이 상태를 나타내는 스트링.
  - response_headers는 HTTP 응답 헤더의 (header_name, header_value) 튜플 쌍을 담은 list 객체
    - 헤더는 파이썬 list 타입이어야 하고, 필요에 따라 서버 측에서 해당 리스트 내용을 가공가능.
    - 헤더의 header_name 값에는 구두점이나 세미콜론이 포함되어서는 안 되며
      모든 스트링에 \n, \r과 같은 개행 문자가 들어가서는 안 됨.
      (이는 추후 설명할 서버의 검증 단계에서 복잡성을 줄이기 위해서)
- 호출 시 HTTP 응답 처리를 시작하며,
  리턴값으로 write(body_data) callable 객체를 반환.

WSGI 순서도.

3. guicorn이란?

WSGI의 Guicorn은 파이썬 웹 환경을 배포할 때 가장 널리 사용되는 핵심 도구 중 하나.

Gunicorm 은 Green Unicorn의 약자로,
파이썬 웹 애플리케이션을 구동하기 위한 WSGI HTTP 서버의 일종.

Gunicorn의 개요.

정의
: Python WSGI HTTP 서버 (Python Web Server Gateway Interface HTTP Server)
역할
: 웹 서버(예: Nginx)와 파이썬 웹 애플리케이션(예: Django, Flask) 사이에서
WSGI 표준을 준수하며 요청을 처리하고 응답을 관리하는 게이트웨이 역할.
특징
: 구현이 심플하고, 서버 리소스 사용이 적으며, 비교적 빠른 속도로 동작하여 프로덕션(실제 서비스) 환경에 적합.
기반
: Ruby의 Unicorn 프로젝트에서 영감을 받아 이식된 Pre-fork(프리-포크) 워커 모델을 사용

Gunicorn은 왜 쓰이는걸까.

(참고 : Django의 runserver 역시 똑같은 역할을 수행하지만 보안적으로나 성능적으로 검증이 되지 않았기 때문에 production 환경에서는 사용할 수 없다.) - 개발용으로는 유용

하지만 WSGI는 멀티 쓰레드를 만들 수 있기 때문에 Request가 많아지더라도 효율적으로 처리할 수 있음.
즉, production(제품) 환경에 적합

Gunicorn의 핵심 역할(WSGI 서버로서)

Gunicorn은 WSGI 아키텍처에서 WSGI 서버/게이트웨이 역할을 수행.

1. 웹 서버와의 통신 중개:

외부 웹 서버(Nginx, Apache)로부터 HTTP 요청을 받음.
WSGI 규약에 맞게 이 요청 데이터를 environ 딕셔너리 형태로 파이썬 애플리케이션에 전달.
애플리케이션이 생성한 응답 본문과 start_response 콜백 함수로 받은 헤더를 다시 HTTP 응답 형태로 변환하여 웹 서버로 돌려보냄.

2. 프로덕션 환경 구동:

앞서 말했듯이, Django나 Flask의 내장 서버(runserver 등)는 개발 용도로만 적합하고 동시 요청 처리 및 보안에 취약.
Gunicorn은 멀티 프로세스/멀티 스레드 환경에서 동작하며 높은 동시성과 안정성을 제공하여 실제 서비스 환경(Production)에서 애플리케이션을 구동하는 데 사용.

Gunicorn의 아키텍처 및 작동 방식.

Gunicorn은 'Master-Worker(마스터-워커)' 구조로 동작하여, 효율적으로 요청을 처리.

1. 마스터 프로세스(Master Process)

Gunicorn이 실행될 때 가장 먼저 생성되는 메인 프로세스.
'워커 프로세스'를 관리하고 모니터링하는 역할을 수행.
워커 프로세스가 비정상적으로 종료되면,
자동으로 새로운 워커를 생성하여 서버의 안정성을 유지.

2. 워커 프로세스(Worker Process)

마스터 프로세스가 복제(fork)하여 생성하는 실제 요청 처리 담당 프로세스
각 워커는 요청을 독립적으로 처리하며, 워커 수만큼 동시 요청을 처리 가능
Gunicorn은 기본적으로 '동기(Sync)'워커를 사용하지만,
'비동기(Async)워커'도 지원.
- Sync(동기)
  - 특징 : 한 번에 하나의 요청을 처리하며, 요청이 블로킹되면 다른 요청을 처리 가능
    - 가장 간단하고 안정적.
  - 적합한 상황 : Cpu 연산이 많은 작업
- Async(비동기)
  - 특징 : I/O작업(DB 접근, 외부 API 호출 등)시 작업을 양보하여
    해당 시간에 다른 요청을 처리(비동기적 동시성)
  - 적합한 상황 : I/O 작업이 많은 작업

3. 워커 개수 설정.

Gunicorn의 성능을 좌우하는 중요한 설정. 일반적으로 권장되는 워커 수는 다음과 같음.

CPU 자원을 최대한 활용하면서도 여분의 워커를 두어 안정성을 확보.

WSGI 서버로서의 Gunicorn 사용 예시.

Gunicorn은 명령 한 줄로 파이썬 애플리케이션을 WSGI 서버로 구동 가능.

4. ASGI란?

최근 파이썬 웹 개발 환경에서는 WSGI의 후속으로 ASGI(Asynchronous Server Gateway Interface)가 등장.

WSGI의 특징:
- 동기(Synchronous) 방식을 기반.
- 하나의 요청이 완전히 처리될 때까지 다른 요청을 차단(Blocking)하는 구조.
- HTTP 1.0/1.1 같은 '동기식 요청 처리'에 적합.

ASGI (Asynchronous Server Gateway Interface)는 파이썬 웹 서버와 비동기(Asynchronous)를 지원하는 파이썬 웹 애플리케이션 및 프레임워크 간의 통신을 위한 표준 인터페이스이자 WSGI의 정신적 후계자.

WSGI의 한계 & ASGI의 등장 배경

WSGI는 웹소켓(WebSocket)이나 롱 폴링(Long Polling)과 같이 지속적 연결이나 비동기 통신이 필요한 현대적인 웹 환경을 효율적으로 처리하기 어렵기에 이를 해결하기 위해 등장.

WSGI가 동기적(Synchronous) 요청 처리에만 초점을 맞췄던 한계를 극복하고,
비동기 통신(Async)과 지속적인 연결을 지원하기 위해 설계.

ASGI의 특징

비동기(Asynchronous) 방식을 지원
- 하나의 프로세스/스레드 내에서 여러 요청을 동시에 처리(Concurrency)가능.
웹소켓, HTTP/2 등 비동기 및 동시성이 필요한 서비스에 적합
Uvicorn, Daphne, Hypercorn 등이 대표적인 ASGI 서버이며, FastAPI와 같은 최신 프레임워크가 이를 기반.

ASGI의 핵심 역할 및 필요성.

ASGI의 핵심은 파이썬의 async/await 기능을 웹 서버와 애플리케이션 간의 통신에 통합하여 높은 동시성과 새로운 웹 프로토콜을 지원하는 것.

WSGI의 한계 극복.

기존의 WSGI는 요청-응답(Request-Response)의 단일 동기 호출 방식에 고정되어 있어서
다음과 같은 현대 웹 기술을 효율적으로 지원하기 어려웠음.
- 웹소켓(WebSocket)
  : 클라이언트와 서버 간에 지속적인 양방향 통신 채널을 유지하는 프로토콜.
  - (WSGI는 단발성 HTTP 요청에만 적합)
- HTTP/2
  : 하나의 연결로 여러 요청을 병렬 처리하는 동시성(Concurrency) 기능.
- 롱 폴링/서버 센트 이벤트(SSE)
  : 서버가 클라이언트에게 실시간 데이터를 보내는 기술.

ASGI의 해결책.

ASGI는 이러한 문제들을 해결하기 위해 비동기 이벤트 기반의 인터페이스를 제공.
- 하나의 프로세스나 스레드가 여러 네트워크 연결(I/O 작업)을 차단(Blocking)하지 않고 효율적으로 처리가능.

ASGI의 구성 요소 및 인터페이스.

WSGI와 마찬가지로 ASGI도 서버와 애플리케이션 사이의 통신 규약을 정의하지만, 비동기 처리를 위해 인수의 구성이 다름.

ASGI 애플리케이션 인터페이스.

ASGI 애플리케이션은 "호출 가능한 비동기 객체(Asynchronous Callable) 형태여야 하며,
3 가지 인수를 받음.

1. scope (연결 범위):

현재 연결(Connection)에 대한 상세 정보가 담긴 딕셔너리.
연결 유형(http, websocket, lifespan 등), Http경로, 쿼리 문자열 등을 포함.
이 scape는 연결 수명 동안 불변.

2. receive (수신 함수):

ASGI 서버로부터 비동기 이벤트 메시지를 '수신'하는 await 가능한 함수.
- ex) HTTP 요청 본문 청크, 웹소켓 메시지 등등...

3. send (전송 함수):

ASGI 애플리케이션이 ASGI 서버로 비동기 이벤트 메시지를 '전송'하는 await 가능한 함수.
- ex) HTTP 응답 상태/헤더, 웹소켓 메시지 등등...

ASGI 서버 및 프레임워크.

ASGI 서버

ASGI 표준에 따라서, 클라이언트의 요청을 받아 애플리케이션을 호출하고
결과를 전송하는 서버.
- ex) Uvicorn, Daphne, Hypercorn

ASGI 프레임워크

ASGI 인터페이스를 기반으로 구축되어, 비동기 기능을 기본으로 제공하는 프레임워크.
- (예: FastAPI, Starlette, Django Channels (Django 3.0+부터는 코어 Django도 ASGI 지원))

WSGI와 ASGI의 주요 차이점 비교.

ASGI는 WSGI가 사용되던 역할을 대체하거나 확장하는 관계.!

ASGI는 I/O 바운드 작업(네트워크 통신, DB접근 등)이 많아 동시성이 중요한 애플리케이션,
- 특히, {실시간 채팅, 게임 서버 API, 스트리밍 서비스} 등에서 탁월한 성능을 발휘.

5. uvicorn이란?

Uvicorn은 파이썬으로 작성된 '초고속 ASGI(Asynchronous Server Gateway Interface) 서버 구현체.

Gunicorn이 WSGI 표준을 구현하여
동기 웹 애플리케이션(Django, Flask 등)을 구동하는 역할을 한다면,
Uvicorn은 ASGI 표준을 구현하여 비동기 웹 애플리케이션
(FastAPI, Starlette, 비동기 모드로 실행되는 Django 등)을 구동하는 역할을 수행.

Uvicorn의 역할 및 특징.

Uvicorn은 현대적인 비동기 파이썬 웹 서비스 환경에서 필수적인 역할을 수행하며, 특히 그 성능과 간결함으로 유명.

ASGI 서버로서의 역할.

인터페이스 구현

클라이언트의 HTTP 요청을 받아 ASGI 표준에 맞는 {scope, receive, send 구조}로
변환하여 애플리케이션에 전달 후,
반대로, 애플리케이션의 응답을 HTTP 응답 형태로 변환하여 클라이언트에게 전달.

비동기 구동.

async/await로 작성된 파이썬 애플리케이션을 구동하여
I/O 바운드 작업에서 높은 동시성(Concurrency)을 확보.

고성능의 비결.

Uvicorn의 놀라운 속도는 다음 두 가지 핵심 라이브러리를 활용하기 때문.

uvloop

파이썬의 기본 이벤트 루프인 asyncio를 대체하는 C 기반의 이벤트 루프 구현체.
OS와의 효율적인 상호작용을 통해 매우 빠른 비동기 처리 속도를 제공.

httptools

HTTP 프로토콜 파싱 및 직렬화를 담당하는 라이브러리로, C로 구현되어 빠른 속도를 보장.

Uvicorn과 Gunicorn의 일반적인 결합 구조.

실제 프로덕션 환경에서는 Uvicorn을 단독으로 사용하기보다는 Gunicorn과 결합하여 사용하는 것이 일반적.

구조: 클라이언트 ➡️ (Nginx) ➡️ Gunicorn (마스터) ➡️ Uvicorn (워커) ➡️ FastAPI/Starlette

Data-Forge : 데이터로 세상 이해해보기.

Roll with the punches

이전 포스트

[ 데이터를 위한 Python : From Scratch to Master. ] 파이썬 웹 백엔드 개발의 필요 요소 : WSGI-guicorn & ASGI-uvicorn

데이터를 위한 Python : From Scratch to Master.

[ 데이터를 위한 Python : From Scratch to Master. ] 파이썬 웹 백엔드 개발의 필요 요소 : WSGI-guicorn & ASGI-uvicorn

▽ [ 데이터를 위한 Python : From Scratch to Master. ] 파이썬 웹 백엔드 개발의 필요 요소 : WSGI-guicorn & ASGI-uvicorn

1. 정리하는 계기

2. WSGI란?

로컬 개발 환경에서의 파이썬-Django,Flask.

웹 브라우저.

정적 페이지.

동적 페이지.

WSGI 환경에서의 요청 흐름.

WSGI란?

WSGI 정의 및 필요성.

WSGI의 구성 요소.

서버/게이트웨이 (Server/Gateway)

애플리케이션/프레임워크 (Application/Framework)

미들웨어 (Middleware)

WSGI의 작동 방식(인터페이스 규약)

WSGI 애플리케이션 인터페이스

요청 및 응답 처리 흐름

흐름 정리.

Application 방면.

Server 방면

상세 스펙.

WSGI 순서도.

3. guicorn이란?

Gunicorn의 개요.

Gunicorn은 왜 쓰이는걸까.

Gunicorn의 핵심 역할(WSGI 서버로서)

1. 웹 서버와의 통신 중개:

2. 프로덕션 환경 구동:

Gunicorn의 아키텍처 및 작동 방식.

1. 마스터 프로세스(Master Process)

2. 워커 프로세스(Worker Process)

3. 워커 개수 설정.

WSGI 서버로서의 Gunicorn 사용 예시.

4. ASGI란?

WSGI의 한계 & ASGI의 등장 배경

ASGI의 특징

ASGI의 핵심 역할 및 필요성.

WSGI의 한계 극복.

ASGI의 해결책.

ASGI의 구성 요소 및 인터페이스.

ASGI 애플리케이션 인터페이스.

1. scope (연결 범위):

2. receive (수신 함수):

3. send (전송 함수):

ASGI 서버 및 프레임워크.

ASGI 서버

ASGI 프레임워크

WSGI와 ASGI의 주요 차이점 비교.

5. uvicorn이란?

Uvicorn의 역할 및 특징.

ASGI 서버로서의 역할.

인터페이스 구현

비동기 구동.

고성능의 비결.

uvloop

httptools

Uvicorn과 Gunicorn의 일반적인 결합 구조.

[데이터를 위한 Python : From Scratch to Master.] 연휴동안 인프런 강의 녹이기 : "실리콘밸리 엔지니어가 가르치는 파이썬 기초부터 고급까지"._03.

0개의 댓글