Django는 과연 무거운가?

최근 제가 만들었던 서비스 iidxrank 회고록을 작성하다 보니, 몇가지 의문점들이 생겼습니다. 그중 하나는 “django가 과연 괜찮은 툴인가?” 라는 점입니다.

그래서 이에 대한 정보를 모아 정리해 보았습니다. 직접 경험한 것들이 아니다 보니 잘못된 부분이 있을지도 모르겠습니다.

언어의 순수 성능 측면에서

Node.js는 최근 웹브라우저들에서 쓰이는 V8 엔진을 쓰고 있고, Python은 인터프리터를 사용하고 있습니다. 인터프리터 언어로는 V8의 적수가 안 되죠...

• 물론 Pypy를 이용하면 파이썬 JIT가 가능하긴 합니다. 하지만 공식 파이썬 프로젝트가 아니다 보니, 호환성 문제 등이 있어 사용할 여건이 맞지 않을 수 있습니다.

실제 N-Queen 문제 푸는 테스트 결과에서, 파이썬이 상당히 느린 성능을 보여주고 있습니다.

다만 약간 재미있는 점은 메모리 사용량 측면에서는 거의 비슷한 모습을 보여주었다는 건데, 이건 약간 무리해서 지레짐작 해보면 brute force recursion이 heap이 아니라 stack을 주로 사용했기 때문이 아닐까 싶습니다 ㅎㅎ... 역으로 말하면 메모리 사용량 관련해서는 좋은 코드에서는 큰 차이가 나지 않는다고 말할 수 있을 것 같네요.

그리고 스레딩 측면에서는 GIL 때문에 절망적이다시피한 성능을 보여줍니다. 다만, 이건 문제가 안 될 수도 있는게, 어차피 요즘은 분산시스템에 최적화 된 구성으로 가니까 구성하기 따라서 극복할 수 있는 문제일지도 모릅니다.

그렇다면, 실제 성능 측면에서는?

실제 RPS(Requests per second)를 측정한 테스트 수치에 따르면, python 기반의 django는 상당히 낮은 성능을 보여주고 있습니다.

JIT를 지원하는 Java 및 JS 계열들 언어들에게 완벽하게 밀리는 모습을 보여주고 있습니다 ^^;

앗, 그러면 django는 못쓸 물건인가?!

물론 django의 절대적인 성능 자체는 부족한 편입니다. 하지만 그럼에도 불구하고, 생각해 볼 요소들이 분명 있습니다. 그래서 추가로 더 적어 놓습니다. 결과에만 관심이 있으시다면 더 읽으실 부분은 없어서 그냥 스크롤 내리셔도 될 것 같습니다 ㅎㅎ.

정말 django의 처리 능력이 심각하게 문제일까?

잘 생각해보면 위 결과에서 봤을 때 초당 4000~6000 request를 처리할 수 있을 정도의 능력은 됩니다. 저정도면 순수 리퀘스트 처리능력만으로는 페이지당 0.2ms의 짧은 시간내 처리가 가능한 수준이고, 그마저도 부족할 정도의 리퀘스트가 들어온다면 scale을 늘리면 됩니다. 물론 비용은 다른 언어 대비 더 들겠지만요... ^^;

웹 서비스의 구성요소는 django만이 전부가 아니다

역으로 말하면 속도에 영향을 끼치는 요인은 오히려 django가 적게 차지하는 편이라고 볼 수 있습니다.

일례로 실제 웹 서비스의 아키텍처를 보면 파일서버, DB서버, API 서버 등 다양한 요소들이 있고, 그 중 실제 웹 서빙을 수행하는 django가 들어갈 부분은 조금밖에 차지하지 않습니다.

따라서, 혹시라도 django 때문에 느리니 프레임워크를 바꿔야겠다 라고 생각한다면 다시 한 번 생각해 볼 필요가 있습니다. 서버 스케일 대비 리퀘스트 수가 정말로 많은지, 다른 서비스들에서 병목이 생기고 있지는 않은지, 아키텍처나 사용하고 있는 기술을 잘못 쓰고 있는건 아닌지, 혹은 서비스들 분리가 제대로 안 되어 있는지 등 생각해 볼 필요 있습니다.

• 한 가지 이야기해야 할 점은 코어 서비스(API)가 파이썬에서 돌아가면 분명 느릴 겁니다 ^^;
  장고는 웹 프레임워크니까 그렇게 쓰는 것 자체가 잘못 쓰는 것이기도 하고요.
• 이따금씩 django가 제공하는 ORM이 비효율적인 쿼리를 만들어 느린 경우도 있습니다. 이를 위해 django에서는 Django-debug toolbar나 등의 다양한 기능을 제공하고 있으니, 확인해 볼 필요가 있습니다. 사실 이건 django의 문제라고 볼수도 있지만, 정확히는 여기서 짚고자 하는 python의 문제는 아니니까요.

월등히 낮은 입문 장벽

이거 은근히 큽니다. 프레임워크와 언어에 익숙해지는 것 또한 의외로 무시할 수 없는 비용이거든요. 비용이 크면 사람들이 자연스럽게 기피하게 됩니다.

그리고 python과 django(+ ORM, MVC)는 쉽습니다. 덕분에 많은 사용자를 확보하고 있고 자료 또한 많습니다.

실제 점유율 측면에서

마지막으로, 만약 온라인 서비스를 할 수 없을 정도로 무거운 물건이라면 사람들이 쓰지도 않겠죠?

마침 실제 장고로 서비스되는 사이트들을 정리해 둔 사이트가 있습니다. 보면 상당히 많은 사이트들이 있습니다. 이 사이트에 따르면 인스타그램, 그리고 무려 유튜브도 장고를 쓰고 있다고 합니다!

엄청난 트래픽을 자랑하는 사이트에도 실사용이 가능하다는 게 검증되었다면, 단순히 “성능 때문에 못 쓰겠다” 라는 말은 핑계에 불과할지도 모르겠네요.

결론

근데 요즘은 다들 Node.js 써서 (좀 보수적인 데는 Spring)... ㅎㅎ 기회가 된다면 다음 프로젝트는 Node.js로 다시 해보렵니다 ㅋㅋ.

참고

• Express vs. Django: 10 Indicators to Choose the True Backend King
• Node.js vs Python vs PyPy – A Simple Performance Comparison, Updated
• 베이글 서비스의 아키텍쳐
• Quora: How does node.js compare against Django in terms of memory usage?
  • 이 글에서는 직접적인 django 성능에 대한 답변보다는 django가 성능의 병목점이라고 생각하지 말라는 답변이 있습니다. 위에서 제가 쓴 의견과 일치하는데 읽어볼 만 합니다.
• Django와 ALB의 502 오류 대모험
  • 장고 ORM이 생성한 SQL이  병목 현상을 일으킨 사례입니다. 성능 병목에 있어서 장고 프레임워크 만이 문제 요소가 아님을 알 수 있죠.