FastAPI ( with gRPC를 곁들인.. )
서론 : Back-end의 본질 ( 주관적 )
필요한 API 구축 , 데이터 서버 로직을 관리하며 데이터베이스를 프레임워크를 통해 조건들을 통합시키는 역할
또한 신뢰도와 확장성을 얼마나 사용자들에게 안정적으로 시스템을 구축할지 고민하는 사람.
✅ FastAPI
- Python 3.6+ 기반의 웹 프레임워크
- 비동기(async/await) 기능을 기본 지원
- 자동 문서화 (Swagger/OpenAPI) 내장
- 경량화된 구조로 빠른 개발과 높은 성능을 제공
Fast api 는 이름에 api가 있는 것처럼 api를 통해 문서를 생성하거나
어떤 사용자가 정의하는 api를 만들기 위한 파이썬 특화 웹 프레임 워크이다.
파이썬 3.6 부터 지원 가능한 최신적이고 꽤 트렌디한 파이썬 웹 프레임 워크이다.
우리가 대중적으로 파이썬 웹 프레임워크에는 Flask와 Django가 있다.
그럼 Flask와 Django랑 다른 어떤 차이점이 있을까?
📌 FastAPI vs Flask vs Django
FastAPI ORM
!pip install sqlalchemy pydantic typing_extension uvicorn
DB 연결을 위해 SQLAlchemy라는 라이브러리와 fastapi 활용을 위해 pydantic과 typing_extension을
수기로 설치함으로써 ORM을 사용한다.
FastAPI vs Flask의 간결성 문제
코드적인 면으로 봤을때도 Flask보다 더 간단하게 구현이 가능한 라우터 문법 예시이다.
** 참고 **
이러한 라우터 방식은 왜 필요할까??
from fastapi import FastAPI, APIRouter
app = FastAPI()
router = APIRouter()
@router.get("/users/")
def read_users():
return [{"username": "Alice"}, {"username": "Bob"}]
@router.get("/users/{user_id}")
def read_user(user_id: int):
return {"user_id": user_id, "username": "Alice" if user_id == 1 else "Bob"}
app.include_router(router)
API를 라우팅하는 방식은 여러 경로들을 그룹화하고 모듈화 하는 방식이다.
@router.get("/users/")
@router.get("/users/{user_id}")
경로를 지정해서 FastAPI에 포함시키는 방식으로 앱에 포함시킨다.
즉, 예를 들어서 user id가 1이면 Alice 아니면 Bob이다.
http://0.0.0.0:3000/users/1로 접근했을 경우
http://0.0.0.0:3000/users/2로 접근했을 경우
마지막 HTTP 예외처리
from fastapi import APIRouter, HTTPException
userrouter = APIRouter()
@userrouter.get("/")
def read_users():
return [{"user_id": 1, "username": "Alice"}, {"user_id": 2, "username": "Bob"}]
@userrouter.get("/{user_id}")
def read_user(user_id: int):
if user_id == 1:
return {"user_id": 1, "username": "Alice"}
elif user_id == 2:
return {"user_id": 2, "username": "Bob"}
else:
raise HTTPException(status_code=404, detail="유저 ID가 존재하지 않습니다.")
만약 라우팅 방식이 없다면 모든 요청을 함수 하나 하나 받아야하며, 모든 시뮬레이션에서 조건문을 만들어야한다.
그래서 특히 TDD 방식을 이용할 때 Test Code를 정말 많이 거쳐야한다는 단점이 있음.
이를 보안하기 위해 라우팅 방식을 사용.
물론 Flask와 Django도 지원하지만 가장 핵심적으로 보여주고 싶은 것은 문법이 간단하는 것 !!
TL;DR 을 따졌을 때 같은 성능을 냈을 때 간결함은 최고의 조건 중에 하나.
(( TL;DR - Too Long;Didn’t Read )) 너무 길어서 읽지 않는다.
그래서 실무에서는 최강이라는 소리를 듣지만 유지 보수 측면에서 보면 힘들 수도 있다.
🤝 공통점
- 모두 Python 기반
- RESTful API 구축 가능
- 외부 라이브러리 확장 가능
- 커뮤니티와 문서 지원 활발
비동기식 처리가 백엔드 개발자에게 중요한 이유?
I/O 작업 중 대기 시간 제거
- 웹 애플리케이션은 종종 데이터베이스 조회, 파일 읽기, 외부 API 호출 등을 수행합니다.
- 동기식(Synchronous) 처리에서는 이 작업이 끝날 때까지 다른 작업이 멈춤.
- 비동기 처리를 사용하면 → I/O 작업 중에도 다른 요청을 동시에 처리 가능.
높은 동시성 (Concurrency)
- async/await를 이용하면 하나의 서버 인스턴스에서도 수많은 요청을 병렬적으로 처리 가능
- 이는 특히 실시간 서비스(예: 채팅, 주식 시세, 게임 서버)에 매우 중요
사용자 경험 향상
- 서버가 빠르게 응답하면 → 프론트엔드 사용자에게도 빠르게 피드백 제공
- 사용자가 느끼는 지연(Latency) 을 줄여줌
비용 절감
- 동일한 하드웨어에서 더 많은 요청을 처리할 수 있기 때문에, 서버 수를 줄이고 운영비 절감 가능
왜 그럼 이 FastAPI를 선택했을까?
AI가 많이 발전되고 있는 현 시점에서 FastAPI는 다른 파이썬 웹 프레임워크보다 뛰어나다.
예를 들면 OpenAI , Pytorch와 같이 AI를 활용한 서버 구조를 만드는 코딩 및 프로젝트가 늘어났다
🚀 FastAPI가 AI 백엔드에 잘 맞는 이유
✅ 1. 비동기(async) 지원
- AI inference는 시간이 걸리는 작업이므로, 비동기 요청 처리가 중요합니다.
- FastAPI는 async/await를 기본 지원 → 대량 요청에도 빠르게 대응 가능
@app.post("/predict")
async def predict(data: InputData):
result = await model.infer(data)
return result
Flask와 Django는 기본적으로 동기(synchronous) → 비동기 처리에 약함 (특히 Django는 ASGI 전환 필요)
ASGI (Asynchronous Server Gateway Interface)는 파이썬 웹 서버, 프레임워크, 애플리케이션 간의 통신 표준 인터페이스
✅ (중요) 2. 자동 문서화 (Swagger / ReDoc) → 실험과 테스트 용이
- AI API는 자주 실험, 테스트 필요
- FastAPI는 /docs, /redoc에서 자동 API 테스트 페이지 제공
Flask/Django는 외부 라이브러리로 Swagger 연동 필요 (예: Flask-RESTX, DRF + drf-yasg 등)
- AI에 보내는 입력 데이터의 타입을 명확하게 정의할 수 있음
- FastAPI는 Pydantic 기반으로 입력 검증, 자동 문서화 제공
from pydantic import BaseModel
class InputData(BaseModel):
text: str
temperature: float
@app.post("/generate")
def generate(data: InputData):
return ai_model.generate(data.text, data.temperature)
✅ 3. ASGI 호환 → WebSocket, Streaming 지원
- AI 응답을 스트리밍하거나, 실시간 피드백이 필요한 경우 WebSocket 사용
- FastAPI는 ASGI 기반 → WebSocket 완전 지원
@app.websocket("/ws/infer")
async def websocket_infer(ws: WebSocket):
await ws.accept()
while True:
data = await ws.receive_text()
result = run_ai(data)
await ws.send_text(result)
Flask는 WebSocket 기본 미지원 (Flask-SocketIO 등 필요)
Django는 Channels 설정 필요 (복잡)
이러한 조건으로 인해 실무에서 실제로 AI를 연결해서 웹 프레임워크를 FastAPI를 사용함.
🤡 간단한 AI모델 FastAPI로 베포하기 ( pytorch )
= 가정 =
학습이 완료된 pytorch 모델
AI 모델의 예측값을 변환할 수 있음.
모델 python 파일
import torch.nn as nn
class SimpleModel(nn.Module):
def __init__(self):
super(SimpleModel, self).__init__()
self.fc = nn.Linear(4, 3) # 입력을 4차원으로 받고 출력을 3 클래스로 분류시키는 과정
def forward(self, x):
return self.fc(x)
스키마 정의 python 파일
from pydantic import BaseModel
from typing import List
class PredictRequest(BaseModel):
input: List[float] # 예: [5.1, 3.5, 1.4, 0.2]
class PredictResponse(BaseModel):
class_idx: int
probabilities: List[float]
스키마 - 데이터베이스의 구조와 제약 조건에 관한 전반적인 명세를 기술한 메타데이터의 집합
메인 python 파일
from fastapi import FastAPI
from model.model import SimpleModel
from schemas import PredictRequest, PredictResponse
import torch
import torch.nn.functional as F
app = FastAPI()
# 모델 로드 부분
model = SimpleModel()
model.load_state_dict(torch.load("model/model.pth", map_location="cpu"))
model.eval()
# app에 post해서 베포하는 비동기식 함수
@app.post("/predict", response_model=PredictResponse)
async def predict(data: PredictRequest):
input_tensor = torch.tensor(data.input).unsqueeze(0) # (1, 4)
with torch.no_grad():
output = model(input_tensor)
probs = F.softmax(output, dim=1).squeeze().tolist()
class_idx = int(torch.argmax(output))
return PredictResponse(class_idx=class_idx, probabilities=probs)
베포
uvicorn main:app --reload
베포 후 테스트
curl -X POST "http://127.0.0.1:8000/predict" -H "Content-Type: application/json" \
-d '{"input": [5.1, 3.5, 1.4, 0.2]}'
👀 심화편 - FastAPI 와 gRPC
- 개인 프로젝트- AWS 서버를 사용해서 특정 웹에서 양방향 스트리밍을 하는 과정에서 gRPC라는 개념을 접하게 됨.
https://bumh07.tistory.com/entry/Trading-View-코인-자동-매매-시스템-1-구상-단계
Trading View 코인 자동 매매 시스템 ( 1 ) / 구상 단계
서론지금 대학생 신분으로 시험을 치는 기간이다. 힘든 시기를 많이 겪고 있지만 최근 6달 동안 나 자신을 돌이켜 보면 많은 성장을 한 것 같다. 공부한 것들을 모두 정리해서 블로그에 올리고
bumh07.tistory.com
gRPC란 무엇일까??
구글에서 개발한 고성능 오픈소스 RPC(Remote Procedure Call) 프레임워크
HTTP/2를 기반으로 하며, 클라이언트와 서버 간의 통신을 위한 인터페이스를 정의하는 데 Protocol Buffers를 사용. gRPC는 분산 애플리케이션 개발을 용이하게 하고, 다양한 환경에서 실행할 수 있도록 설계.
😵FastAPI + gRPC 조합이 적합한 상황
AI 모델 서빙 (ML 모델 API)
- FastAPI: 외부에서 요청을 받고, 입력 검증/문서화 처리
- gRPC: 고성능 AI 모델 서버로 데이터 전달 및 결과 수신 (TensorRT, TorchServe 등)
예시:
- FastAPI가 /generate, /classify 같은 REST API 제공
- 내부적으로 gRPC로 모델 서빙 서버에 빠르게 요청
→ 실시간 inference, 대규모 요청 대응이 필요한 상황에 적합
대규모 마이크로서비스 아키텍처
- 클라이언트 → FastAPI REST API
- 내부 마이크로서비스 간 통신 → gRPC
예시:
- 주문 서비스, 결제 서비스, 사용자 서비스가 각각 분리되어 있고
- FastAPI가 Gateway 역할, 내부는 gRPC로 초고속 통신
→ 성능 최적화 + 확장성 + 유지보수성을 동시에 확보 가능
양방향 스트리밍이 필요한 서비스
- 예: 실시간 채팅, 실시간 번역, 음성 처리, 주식 가격 업데이트 등
- FastAPI는 HTTP 기반으로 사용자와 통신
- gRPC는 실시간 양방향 스트리밍 처리로 서버 간 실시간 데이터 처리
→ FastAPI는 Web UI에 초점, gRPC는 백엔드 실시간 처리용
다양한 언어/플랫폼에서 접근하는 경우
- 클라이언트는 Android(Java), Web(JavaScript), iOS(Swift) 등 다양한 플랫폼
- gRPC는 각 언어별 SDK 지원 → AI/로직 서버와 효율적 통신
- FastAPI는 REST API 통해 브라우저 또는 간단한 클라이언트 앱과 연결
→ Cross-platform 시스템에서 언어 독립적이고 빠른 통신 가능
왜 두 개를 결합해서 사용할까??
첫째 : 추상적 방면
gRPC는 명확하게 정의된 인터페이스와 경량화된 구조 덕분에 복잡한 시스템을 단순하게 만들 수 있다.
다양한 언어를 지원하고, Python처럼 함수형 프로그래밍 스타일도 활용 가능한 언어와의 결합을 통해,
빠르고 유연한 백엔드 구성에 최적화된 방식으로 API를 사용자 중심으로 구현할 수 있다.
둘째 : FastAPI 단점과 gRPC 단점을 서로 보안
FastAPI의 가장 큰 단점은 유지 보수의 측면이다. 이를 보안하기 위해 gRPC는 로직 중복을 줄여주고, 유지보수를 간소화 시켜준다.
gRPC는 장점이자 단점을 꼽는 것이 REST 방식이 아니다. 그렇기에 추상화 수준이 높은 fastapi는 restfulapi 유지만 담당하고 fastapi를 사용한 ai 관리는 gRPC를 사용.
gRPC 특성 중 하나 : HTTP/2기반으로 헤더 압축과 다중 요청 처리의 특성을 가짐.