Socket.IO 2 : python-socketio 서버 배포와 비동기 옵션 eventlet, node.js 서버에서의 호출

서버 개발이 나의 주된 업무이므로, 서버단 socket.io 설정 위주로 설명함.

socket.io 클라이언트- socket.io 서버 구성

프론트엔드 코드가 무사히 사용자 브라우저에 전달되고

사용자의 브라우저가 호환된다면

js기반의 socket.io로 통신할 준비를 마치게된다.

여기서 서버측은 python-socketio의 패키지를 사용한다 가정.

socket.io 프론트엔드 서버 - 백엔드 서버 구성

이번에는 node.js 서버가 django 백엔드 서버를 호출하고,

django는 동기식 rest api를 사용한다 가정하자.

전체구조를 살펴보면 다음과 같다.

[ Client ] <-Socket.IO-> [ Node.js Server ] <-HTTP-> [ Django REST API ] <-ORM-> [ Database ]

client - node.js 사이에 활성화돼있는 연결이 

django rest api를 호출한 후 응답을 받기까지는 동기식으로 처리된다.

때문에 django rest api - database 라인의 최적화 처리가 되어있지 않으면

node.js 서버가 응답받는 시간이 늘어나고

client 또한 응답을 늦게 받을 수 있다.

어느 서버에 탑재할 것인가? WSGI, ASGI 서버

비동기 통신에 기반하기 때문에

socket.io가 어느 서버 환경에서 실행되는 지 중요하다.

따라서 socket.io 서버 객체를 만들 때

- async_mode

- cors_allowed_origins

- logger

의 옵션 중에 async_mode에 비동기 처리 설정을 해주어야한다.

WSGI 서버 -> Client - Server

ASGI 서버 -> AsyncClient - AsyncServer

gunicorn과 같은 WSGI 서버에서 python-socketio 사용을 위해서는

python2, 3에서 coroutine을 사용한

동시성 네트워킹을 지원하는 eventlet 라이브러리가 설치돼있어야한다.

설치시 gunicorn과 eventlet의 버전을 체크하여 호환성을 검사해야한다.

그 후, socketio 객체의 async_mode로서 'eventlet'을 설정해주어야하며

명시하지 않을 경우에도 default 값으로 eventlet이 설정됨.

Framework 내에 통합 운영하기 vs MSA로 운영하기

DB와 통신하는 WAS 로직 데이터가 필요하지 않다면

MSA로 빌드하는 것이 유지보수 및 확장에서 편하고 서버 선택의 폭이 넓다.

동기 서버 대신 비동기 서버로 배포함으로서 성능상의 이점을 얻어갈 수 있다.

(네트워크 설정, 트래픽 대처, 수평 확장성)

( ex ) 채팅 로그 데이터를 저장하지 않는 간단한 q&a 챗봇 )

 다만, 이와 같은 애플리케이션의 경우,
 클라이언트의 웹 브라우저에서 따로 저장을 하지 않는다면

 페이지를 새로고침 할 때 내역이 사라진다. 

django의 orm객체 데이터가 필요하다면

gunicorn - django - db 구조에서

socketio를 django 프로젝트에 통합하여 운영할 수 있다.

성능을 위해 django python application에서 비동기 통신을 원한다면

gunicorn 대신 ASGI 서버로 daphne나 uvicorn을 선택할 수 있다.

( daphne project는 django project의 멤버에 의해 운영됨. )

소프트웨어 설치 후, asgi.py에 명세한 후 프로젝트를 가동해야한다.

중복 실행으로 인한 포트 충돌 유의

이미 socketio middleware에 eventlet에 대한 처리가 명세됐기 때문에

wsgi.py에서 eventlet 프로세스를 포트로 지정하여 실행할 필요는 없다.

같은 포트로 지정할 시 포트 충돌 에러가 발생하므로 유의.