Django vs Flask vs FastAPI 비교

데이터를 다루는 직종에 있다보면 다양한 IT 서비스와 마주할 수  있게 된다.

 

그 중 가장 근간이 되는 웹에 대해 생각보다 많은 접점이 생기게 된다.

 

바로 웹 크롤링을 하게될 때이다.

(물론 권고하는 내용은 아니다)

 

웹 크롤링을 한번도 해본적이 없는 상태에서 진행을 하게되면 부랴부랴 HTML 부터 찾아보게 된다.

 

나도 그런 사람 중 한명이었고 웹이란 굉장히 먼 이야기처럼 느껴지곤 했다.

 

하지만, 요즘 모델링 결과를 API로 serving 하거나 웹 페이지로 결과물을 보여주는 요구사항이 늘어나고 있는 추세이다.

(추세라고 하기엔 조금 늦은 감이 있지만..)

 

하여 Python 기반 Web Frameworks에 관련된 내용을 정리하고자 하는데 그 중 가장 각광받고 있는 굵직한 3가지를 비교해보고자 한다.

 

[ 전체 요약표 ]

항목	Django	Flask	FastAPI	비고
Framework	Full	Micro	Micro
ORM (Object Relational Mapping)	Django ORM	기본 제공 없음 (SQLAlchemy 등 사용)	기본 제공 없음 (SQLAlchemy 등 사용)	Django는 여러 DBMS를 사용할 때 각 DBMS 간의 차이에 대한 처리 가능
Gateway Interface	WSGI	WSGI	ASGI
관리자 인터페이스	O	X	X
Template Engine	Django Template	Jinja2	Jinja2	파이썬 기반 웹 템플릿 엔진 사용 가능 (Mako, Chameleon 등)
커뮤니티 및 생태계 (하단에 그림1 참조)	제일 오래 됨	Django랑 비슷하거나 조금 낮은 수준	가장 최근에 나와 상대적으로 가장 낮은 수준	FastAPI 가 상대적으로 낮은 수준이기는 하나, 개발에 문제가 되는 수준은 아님
보안	[ 내장 기능 - O ] - XSS   (cross-site scripting)- CSRF   (cross-site request    forgery) - SQL Injection - Clickjacking - ...	[ 내장 기능 - X ] Flask-Security 라이브러리 활용 가능하나, Django 보다 더 많은 셋팅 값을 개발자가 지정해주어야함	[ 내장 기능 - X ] Fastapi-csrf-protect 라이브러리와 같이 특정 보안 시나리오 맞춰 각각 다른 라이브러리를 활용해 셋팅해야 함
API support	[ 내장 기능 - O ] REST Framework (RESTful API 생성 지원)	[ 내장 기능 - X ] Flask-restx 라이브러리 활용 가능	[ 내장 기능 - O ] REST API 생성 가능	FastAPI 는 타 Frame work이랑 다르게 'API 문서 자동 생성' 기능이 제공됨
적합한 프로젝트 규모	Large scale application - 여러가지 제공되는 보안 기능 - ORM 지원 - 관리자 인터페이스 제공 - 쉬운 확장성	small to medium applications - 기본적인 기능만 제공 - 추가 설정이 단순 ( 많이 추가하면 Django에 비해 효율이 떨어짐 ) - 직관적인(짧은) 코드들로 구성	High-performance, ideal for data-heavy APIs - API 서비스 중점적으로 개발 가능 - Pydantic 기반의 Validation - Swagger(OpenAPI) 기반의 자동 문서화 - 비동기식 작동으로 인한 속도 향상

 

* 그림 1 - 각 framework 별 출시 기간 기준 깃헙 stars 수치

스타 수는 깃허브의 좋아요와 같은 의미

 

위는 전체 요약표로 각각 고려할 사항에 맞춰서 비교표를 작성한 것이다.

 

본인이 실질적으로 웹을 최종 산출물로 만들고 싶은 것인지 아니면 단순히 API만 제공을 하고 싶은 것인지에 대해 판단한 후 적합한 Framework을 고르면 될 것 같다.

 

내 기준에서는 모델 serving을 초점을 두고 API 제공을 위한 Framework을 선별하기 위해 이를 위한 추가 척도로 비교를 해보았다.

 

[ Model Serving 측면 비교 ]

항목	Django	Flask	FastAPI	비고
대용량 요청	멀티 프로세스 및 멀티 쓰레드를 통한 대규모 요청 처리 가능, 동기식	Django와 동일	ASGI 기반 비동기식 처리로 대규모 요청 처리 가능
Validation	Django Forms	WTForms (다른 특징과 동일하게 Django 에 비해 기본적으로 제공되는 검증 항목이 적음)	Pydantic	Request Parameter 데이터 타입, 데이터 형식, 최대/최소 입력 필드값 등
API 디자인	REST Framework(DRF)을 사용 Serializer를 통해 모델을 직렬화하고 API를 구성	Flask-RESTful과 같은 확장을 사용하여 RESTful API를 쉽게 구축할 수 있습니다.	Pydantic을 통해 강력하고 직관적인 API 디자인을 제공합니다. 데이터 모델을 선언하고 유효성을 검사하는 과정을 간소화합니다.
단점	*Monolithic 아키텍처를 따르므로 모든 어플리케이션에 적합하지 않을 수 있음. 러닝 커브가 높음.	동기적인 요청 처리 방식으로 인해 고가용성 및 높은 동시성 처리에 한계가 있을 수 있습니다. 복잡한 대규모 애플리케이션을 구축하기에는 Django에 비해 적합하지 않을 수 있습니다.	비동기 프로그래밍에 대한 이해가 필요하므로 초기 러닝커브가 높음.

 

*Monolithic 아키텍처 란?

→ 모놀리스(Monolith) 아키텍처는 하나의 소프트웨어를 구성하는 모든 모듈과 코드를 한 프로젝트에서 관리하는 것을 말한다.

 

[ Web 성능 비교 ]

들어본 사람은 있을 것 같다. 웹 프레임워크에 대한 여러가지 척도를 기준으로 평가해주는 사이트이다.

 

바로 Web Framework Benchmarks 라는 사이트이다.

URL : https://www.techempower.com/benchmarks/#hw=ph&test=fortune§ion=data-r22

TechEmpower Framework Benchmarks

 

해당 페이지는 다양한 언어, 프레임워크를 대상으로 여러 척도로 비교한 사이트이다.

 

대표적인 테스트 척도는 아래와 같다.

 

[ 테스트 척도 ]

1. Composite scores:
→ 이 테스트는 여러 가지 성능 지표를 종합하여 웹 프레임워크의 전반적인 성능을 평가하는데 사용됩니다. 여러 다른 테스트 유형의 결과를 종합하여 하나의 종합 점수를 생성합니다.

 

2. JSON serialization:
→이 테스트는 웹 애플리케이션이 JSON 데이터를 생성하는 데 걸리는 시간을 측정합니다. 이는 대부분의 웹 애플리케이션에서 자주 사용되는 데이터 형식이므로, JSON 직렬화의 성능을 평가하는 데 사용됩니다.

 

3. Single query:
→ 이 테스트는 데이터베이스에서 단일 쿼리를 실행하는 작업의 성능을 측정합니다. 이는 데이터베이스에서 단일 데이터 항목을 가져오는 작업을 평가하는 데 사용됩니다.

 

4. Multiple queries:
→ 이 테스트는 여러 개의 쿼리를 실행하여 데이터베이스에서 여러 데이터 항목을 가져오는 작업의 성능을 측정합니다. 이는 데이터베이스에서 다중 데이터 항목을 가져오는 작업을 평가하는 데 사용됩니다.

 

5. Cached queries:
→ 이 테스트는 캐시된 쿼리를 실행하여 데이터베이스에서 데이터를 가져오는 작업의 성능을 측정합니다. 이는 데이터베이스의 캐싱 메커니즘을 테스트하는 데 사용됩니다.

 

6. Fortunes:
→ 이 테스트는 데이터베이스에서 "Fortune" 데이터를 가져오고 템플릿을 사용하여 렌더링하는 작업의 성능을 측정합니다. 이는 서버 측 템플릿 렌더링의 성능을 평가하는 데 사용됩니다.

 

7. Data updates:
→ 이 테스트는 데이터베이스에 새로운 데이터를 추가하거나 업데이트하는 작업의 성능을 측정합니다. 이는 데이터베이스에 쓰기 작업을 평가하는 데 사용됩니다.

 

8. Plaintext:
→ 이 테스트는 간단한 "Hello World" 메시지를 반환하는 웹 애플리케이션의 성능을 측정합니다. 이는 웹 프레임워크의 초기화 시간 및 기본적인 응답 속도를 측정하는 데 사용됩니다.

 

[ Django / Flask / FastAPI ]

 

[ 결과 ]

전체적으로 고려했을 때 모델의 결과만 단순하게 API로 제공하는 측면에서는 Flask가 내가 생각했을 때 적합하다고 생각했다.

 

이유는 다음과 같다.

- Django를 채택하기에는 불필요한 기능들로 인해 무거워지는 단점이 있음

- FastAPI를 채택하기에는 비동기식으로 진행할만큼 많은 요청들이 들어오는 구조가 아닌 API기 때문

 

주변에는 많은 분석가 분들은 FastAPI를 선호하는 것으로 보여진다.

(분석가가 사용하기에 많은 부분을 고려하지 않아도 되고, 명세서 또한 자동으로 만들어주고 Documentation이 굉장히 친절하게 나와있기 때문인 것 같다.)

 

그래도 한번은 Django로 웹페이지도 구축해보고 FastAPI로 API를 구축해보고 싶다.

 

추후 시간이 된다면 작업 후 정리를 해보겠다.

 

마지막으로 아래 용어 정리는 내가 웹에 대해 지식이 많이 부족한 상태에서 해당 자료 조사를 진행하게 되었기에 위 자료 조사에 대한 이해를 하려면 많은 용어들의 이해가 필요했다.

 

하여, 해당 게시물에 대한 이해를 하기 위해서는 아래의 용어들을 숙지하면 좋을 것 같아 가장 하단에 첨부한다.

 

※ 용어 정리 ※

• 동기식 (Synchronous) - 먼저 시작된 하나의 작업이 끝날 때까지 다른 작업을 시작하지 않고 기다렸다가 다 끝나면 새로운 작업을 시작하는 방식이다.
• 비동기식 (Asynchronous) - 동기식 방식과는 다르게 먼저 시작된 작업의 완료 여부와는 상관없이 새로운 작업을 시작하는 방식이다.
• 정적 콘텐츠(static) - 변화가 없는 콘텐츠를 말합니다.  보통 HTML, CSS, JS와 같이 미리 서버에 저장해두고 서버가 요청을 받으면 그저 응답만 해주면 되는 것들로 구성되어 있습니다. 이것은 곧 어느 사용자에게든지 동일하게 결과값을 보여주게 됩니다.
• 동적 콘텐츠(dynamic)는 누가, 언제, 어떻게 서버에 요청했는지에 따라 결과값을 다르게 보여주는 형식입니다. 즉, 사용자가 맞춤형 콘텐츠를 제공할 수 있게 되는 것이죠. 예를 들면 유투브의 추천 영상이라던지, 이 콘텐츠를 제일 잘 활용하는 웹 서비스는 넷플릭스입니다.
• Web server 란?
  • 하드웨어 - Web 서버가 설치되어 있는 컴퓨터
  • 소프트웨어 - 웹 브라우저 클라이언트로부터 HTTP 요청을 받아 정적인 컨텐츠(.html .jpeg .css 등)를 제공하는 컴퓨터 프로그램
  • 기능 - HTTP 프로토콜을 기반으로 하여 클라이언트(웹 브라우저 또는 웹 크롤러)의 요청을 서비스 하는 기능
    • 정적인 컨텐츠 제공 - WAS를 거치지 않고 바로 자원을 제공한다.
    • 동적인 컨텐츠 제공 - 클라이언트의 요청(Request)을 WAS에 보내고, WAS가 처리한 결과를 클라이언트에게 전달(응답, Response)한다.
      (클라이언트는 일반적으로 웹 브라우저를 의미한다.)
  • 종류 - Apache Server, Nginx, IIS(Windows 전용 Web 서버) 등
• WAS(Web Application Server) 란?
  • DB 조회나 다양한 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위해 만들어진 Application Server.
  • HTTP를 통해 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어(소프트웨어 엔진)이다.
  • “웹 컨테이너(Web Container)” 혹은 “서블릿 컨테이너(Servlet Container)”라고도 불린다.
  • 종류 - Ex) Tomcat, JBoss, Jeus, Web Sphere 등
  • 웹 서비스 아키텍처

• CGI(Common Gateway Interface) 란?
  • 웹 서버와 외부 프로그램 간의 통신을 위한 표준 인터페이스이다.
  • 기존에는 정적 페이지를 하이퍼링크로 연결하면 충분했다. 하지만 점차 동적 페이지에 대한 필요성이 커졌고 이러한 동적 페이지는 페이지에 필요한 데이터를 저장하고, 꺼내는 등의 서버와의 통신이 늘어나 별도의 웹 서버 사이의 정보를 주고받는 규칙으로 정의된 것이 CGI 규격이다.
  • Request 수신 시마다 Apllication 프로세스를 다시 실행하여, 메모리 적재 시간 소요 등의 문제 발생 (다량의 요청이 들어올 시 매우 비효율적)
• WSGI(Web Server Gateway Interface) 란?
• CGI 인터페이스를 기반으로 만들어진 Python 특화 웹 애플리케이션 인터페이스이다.
• 즉, 웹 서버와 Python 애플리케이션 간의 통신을 담당하는 인터페이스인 것이다.
• ( 작동 방식 )
  1. 클라이언트가 웹 서버에 요청을 보낸다.
  2. 웹 서버가 클라이언트 요청을 받으면 WSGI 인터페이스를 구현한 Python 애플리케이션의 함수를 호출하여 요청을 처리한다.
  3. 이때 함수는 요청 객체(request)와 응답 객체(response)를 인자로 받고, 응답 객체를 반환한다.
• ASGI(Asynchronous Server Gateway Interface)
  • ASGI는 WSGI와 비슷한 목적을 가지고 있지만, 비동기 요청-응답 처리를 지원하는 인터페이스이다.
  • ASGI는 비동기 웹 애플리케이션의 개발을 가능하게 하기에 WebSocket과 같은 실시간 통신 기술도 지원한다.
  • 실시간 채팅 애플리케이션이나 비디오 스트리밍 서비스와 같이 높은 동시성을 요구하는 애플리케이션의 경우에 적합하다.