django를 다시 복습해야될 때가 온 것 같다.

무거워서 별로다, 잡다하다, 요즘은 flask나 fastapi 같은 마이크로서비스를 위한 프레임워크가 잘나간다 등등의 얘기를 들어서 여기 기웃 저기 기웃 하고 있는 중이긴 한데.. 실상 django가 제일 편한 이유는 내가 굳이 별로 건드릴 것이 없다는 것이다. 제대로 활용하기 위해서는 여러가지 배워야할 것들이 좀 있는데 CBV나 FBV의 차이와 같은 기능을 하지만 어떨 때에 활용해야 좋을지 등등 몇시간 배워서 확 써먹을 수 있기는 어렵다는 것이다. 물론 조금 배우면 금세 할 수 있다. 크게 어렵지는 않다. 문제는 주어진 도구들을 커스텀할때이다.. 덕분에 내부 코드를 뜯어보면서 내 살이 되고 피가 되었지만 무언가를 배운다는 것은 그만큼 나를 혹사시킨다는 것과 같은 의미이다.

이번에는 간단한 API를 위한 것도 같이 개발해야 되는 일이 있어서 몇가지 조사한 것들을 정리하고자 한다.

CGI(Common Gateway Interface)

한마디로 말해서 어플리케이션 서버와 웹 서버간 통신을 위한 미들웨어라고 할 수 있다. 프로그래밍 언어를 모르는 웹 서버(정적 파일 제공을 위한 http 통신)와 소통하기 위한 일종의 파파고(?) 라고 할까나. 클라이언트의 요청마다 프로세스를 생성 및 삭제하는 작업을 하기 때문에 요청이 많아지면 성능이 저하된다.

FastCGI

말 그대로 빠르게 응답하는 CGI다. CGI의 개선물. Tomcat이 웹 서버 + FastCGI를 활용한다고 한다.

WSGI(Web Server Gateway Interface)

python으로 작성된 web application server인 gunicorn, uvicorn과 web server가 통신할 수 있게 해주는 미들웨어. 동기식 코드만 지원하기 때문에 오래 걸리는 작업이나 비동기화가 필요한 작업들을 못함. 비동기화가 지원이 안되서 느리다는 것은 함정.

ASGI(Asynchronous Server Gateway Interface)

비동기화를 지원하는 방식. request와 response 방식이 아니라(이건 WSGI 방식) send와 receive 방식으로 되어 있어 여러 송수신이 가능한 것이 장점. django 3의 Channel에서 사용 가능하다고 한다(아직 안써봄).

지금 서비스 중인 웹 어플리케이션은 사용자가 그리 많지 않아서 WSGI 방식으로 구동되어도 만족하면서 사용 중이다. 더 빨라졌으면 좋겠다는 요청도 없다. 사용자 입장에서는 이정도면 좋다고 생각하는 모양이다. 물론 최신의 개선된 기술들을 사용하면 좋겠지만, 새로 배워야 한다는 부담이 있다. 기존 서비스가 잘 돌아가기만 하면 되는데 굳이? 라는 인식도 있어서 섣불리 개선 작업을 시작하기도 어렵다. 이래서 처음부터 서비스할때 잘 선택해야한다고 하는 것 같다. 장고를 조금 더 배우고 더 성숙하게 능숙하게 다루게 되면 ASGI 방식을 사용해보고 싶다. 실상 되냐 안되냐 관점에서 보면 그닥 개선이 없어보일 수 있겠지만, 개인적인 발전을 위해서라도 추후 도입될 서비스를 위해서라도 공부를 해야될 것 같다.

쿠버네티스 위에 돌릴 마이크로서비스를 위한 것은 FastAPI를 도입해서 사용해보고 비지니스 로직을 위한 무거운 컨테이너들은 django를 활용해서 개발을 해볼까 싶다. 우선은 FastAPI를 사용해보고 ASGI에 익숙해 진 후의 django의 개발에 착수해야겠다.