Fast API 사용 이유 - 100-hours-a-week/5-yeosa-wiki GitHub Wiki

1. 개요

  • ai 서버로 fast api를 선정한 이유에 대해 설명한다.
  • 근본인 Django나 이용이 간편한 Flask보다 Fast API가 우리 서비스에 적합함을 설명한다.

2. WSGI vs ASGI

a. WSGI (Web Server Gateway Interface)

  • 요청을 처리하는 동안 다른 요청은 blocking 처리되기 때문에 여러 요청이 오면 병목 발생

    [Client Request] → [WSGI Server (Gunicorn)] → [Flask 앱]
                         |
                       (block)

b. ASGI (Asynchronous Server Gateway Interface)

  • Nonblocking 방식으로 여러 요청을 병목 처리하기 때문에 여러 요청을 동시 처리하는데 강하다

  • I/O 작업은 하나의 작업을 처리하는데 발생하는 지연시간이 길다.

    • 그동안 cpu 사용률은 낮기 때문에 I/O 작업을 기다리기보다 다른 요청을 처리하고 있음으로써 cpu를 유휴 상태로 냅두지 않는다
    [Client Request] → [ASGI Server (Uvicorn)] → [FastAPI 앱]
                         |
              async def → 병렬 처리 가능 (Non-blocking)

3. Django, Flask, Fast API 비교

Django Flask Fast API
특징 전체 서비스 서빙에 적합한 백엔드 프레임워크 입문하기 좋은 쉽고 간편한 프레임워크 비동기 처리가 많은 api 요청 처리에 적합한 프레임 워크
장점 - 세션 유지 기능 제공(로그인 상태, 장바구니)
  • 인증/보안 기능 제공
  • ORM을 통해 sql 없이 DB 이용 가능 (안정적인 DB 이용)
  • 관리페이지 자동 생성
  • HTML 렌더링 기능 | - 최소한의 기능으로 구성되어 있어 배우기 쉽다
  • 간단한 테스트나 학습용으로 적합하다 | - 비동기 처리에 강하다
  • async def, await을 이용한 고성능 API 서버 구현에 적합
  • Swagger/OpenAPI 문서 자동 생성
  • APIRouter, Depends등올 모듈화/계층 구조화에 유리
  • pydantic을 이용한 요청, 응답 검증 | | 단점 | - 비동기 처리에 약하다
  • 코드가 무겁다 | - 비동기 처리에 약하다
  • ORM, 인증, 세션, html 렌더링, 관리페이지 자동 생성 등의 기능을 이용하려면 외부 모듈을 이용해야 한다 | - ORM, 인증 등이 제공되지 않음
  • 로그인, 세션, 관리 기능은 직접 구현하거나 외부 라이브러리에 의존 |

4. 결론: 우리 서비스에는 FastAPI가 가장 적합한 프레임워크

a. 서비스 흐름

요청 (최대 100장 이미지)
  ↓
GCS or S3 이미지 다운로드
  ↓
임베딩 (Batch 처리)
  ↓
사진 처리
  ↓
JSON 결과 응답

b. 서비스 특징

  • 이미지 병렬 다운로드
  • 고속 임베딩 연산
  • 태깅 및 분류 결과 생성
  • 메시지 큐 기반 요청 관리
  • 고성능 API 응답

c. FastAPI가 적합한 이유

  • async def로 병령 다운로드 가능
  • 대량 요청 처리 Uvicorn + ASGI 기반으로 동시 요청 처리에 강함
  • 라우터 모듈화: 기능별로 분리 가능
  • 서버 응답 속도 빠름

d. Flask가 적합하지 않은 이유

  • 이미지 다운로드를 동기 처리해서 느리다
  • 임베딩 연산이 완료될 때까지 한 요청이 블로킹함

e. Django가 적합하지 않은 이유

  • API 서버만 필요한데 ORM/Template/Forms까지 불필요하게 포함됨
  • 고성능 비동기 구조 구현에 불편함