WSGI와 ASGI

WSGI와 ASGI

WSGI는 웬 서버 게이트웨이 인터페이스 - 오래전부터 파이썬 웹 애플리케이션이 웹 서버와 통신할때 WSGI 표준을 따랐다. 기본적으로 동기 동작을 전제하고 있으므로 비동기의 성능이나 효율성이 떨어진다. 이 말인 즉슨 WSGI가 웹소켓과 같은 고급 프로토콜을 효과적으로 처리하지 못한다는 것을 의미한다.

 

ASGI는 비동기 서버 게이트웨이 인터페이스 - 이 또한 WSGI와 마찬가지로 파이썬 웹 애플리케이션과 웹 서버 간의 공통적인 인터페이스를 기술한다. WSGI와 다른 점은 애플리케이션당 여러 개의 비동기 이벤트를 허용한다는 점이다. 또한 ASGI는 동기 앱과 비동기 앱을 모두 지원하며 ASGI를 사용해 새로운 비동기 웹 앱을 구축하는 것 뿐만 아니라 오래된 동기 WSGI 웹 앱을 ASGI로 마이그레이션(:데이터나 소프트웨어를 한 시스템에서 다른 시스템으로 이동하는 것) 할 수도 있다.

---

WSGI의 작동방식

WSGI는 보통 application 또는 app이라는 이름의  파이썬 함수를 웹 서버에 드러낸다. 이 함수는 다음의 두 매개변수를 받는다.

environ : 웹 서버가 제공한 환경 변수와 현재 요청에 대한 정보가 포함된 사전

start_response : 클라이언트로 HTTP 응답을 보내는 작업을 시작하는데 사용하는 함수

함수가 반환하는 데이터가 응답 본문을 구성하며 간단한 application 함수는 다음과 같은 형태다.

def application(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/plain')])
    return [b'Greetings universe']

원문보기:
https://www.itworld.co.kr/news/245062#csidx925413f75093b75974f1ca9a639049e

플라스크와 같은 WSGI 호환 웹 프레임워크를 사용하는 경우 프레임워크 자체가 application 함수를 제공하며 이 함수의 모든 구성요소가 자동으로 연결된다.

 

WSGI의 단점은 2가지다. 첫째, 한번에 하나의 요청과 응답만 처리하며 응답이 즉시 반환된다고 전제한다. 웹소켓 또는 롱 폴링 HTTP 연결과 같이 장시간 지속되는 연결을 처리할 방법이 없다. 둘째, WSGI는 동기 전용이다. 멀티스레드 연결 풀을 사용하더라도 응답이 반환될 때까지 각 연결이 차단된다. 많은 WSGI 설정에 스레드와 프로세스 풀을 처리할 수 있는 기능이 있지만 WSGI 인터페이스 자체가 동기적이라는 점에 의해 제한된다.

 

ASGI의 작동 방식

ASGI도 application 함수 객체를 정의한다. 다른 점은 async 함수이며 매개변수가 2개가 아닌 3개라는 것이다.

scope : 현재 요청에 대한 정보가 포함된 사전으로, WSGI의 environ과 비슷하지만 세부적인 명명 규칙이 약간 다르다.

send : 애플리케이션이 클라이언트로부터 메시지를 수신할 수 있게 해주는 async callable이다.

간단한 application 함수는 다음과 같은 형태다.

async def application(scope, receive, send):
    await send({
        'type': 'http.response.start',
        'status': 200,
        'headers': [
            [b'content-type', b'text/plain'],
        ],
    })

    await send({
        'type': 'http.response.body',
        'body': b'Hello, world!',
    })

원문보기:
https://www.itworld.co.kr/news/245062#csidxe36b745890b6e2a84a64fcc06c1851a

 

WSGI 웹 프레임워크와 마찬가지로 ASGI 웹 프레임워크는 자체 application() 함수를 만들어 필요에 따라 연결한다.

ASGI의 가장 큰 특징은 함수 전반에서 비동기 메타포를 사용한다는 것이다. 함수 자체는 async이며 HTTP 헤더와 응답 본문을 별도의 두 가지 await send() 명령으로 보낸다. 따라서 함수 자체와 이 함수의 send 명령은 아무것도 차단하지 않는다. 즉, 다른 많은 연결의 application 및 send 호출과 동시에 교차가 가능하다.

 

앞선 예제에서는 receive를 사용하지 않지만 이것도 async 함수다. 다른 작업을 차단하지 않고도 요청 본문을 받을 수 있다. 이 방법으로 요청과 응답을 증분적으로 서버에서 송수신할 수 있다. WSGI에서는 매끄럽게 하기 어렵거나 아예 불가능 했다.

 

ASGI를 지원하는 웹 프레임워크

스탈렛(Starlette)과 패스트API(FastAPI) : 패스트 API가 스탈렛을 기반으로 하며 둘 다 비동기 우선이므로 ASGI를 지원한다.

쿼트(Quart) : 대표적인 파이썬 웹 프레임워크 플라스크도 ASGI를 지원하지만 플라스크는 처음부터 철저히 비동기 메타포를 활용하도록 설계된 것은 아니다. 깃랩(GitLab)의 쿼트는 플라스크의 구문과 메타포를 사용하지만 비동기 루트 핸들러를 허용한다.

장고(Django) 3.0 이상 : 장고 웹 프레임워크는 버전 3.0부터 ASGI를 지원한다. 단순히 ASGI 핸들러에 장고를 마운트할 수 있는 기능이 아닌, 장고 애플리케이션 내의 비동기 코드에 대한 지원은 장고 3.1에 추가됐다. 실행 속도 측면에서 아쉬움이 있는 프레임워크임을 감안하면 비동기의 존재만으로 이 프레임워크를 선택하면 더 높은 성능을 얻을 수 있다.

 

 

참고 : https://www.itworld.co.kr/news/245062