[PYTHON] FastAPI 비동기 Worker 모델의 3가지 핵심 처리 방법과 성능 최적화 해결책

FastAPI 비동기 Worker 모델

 

현대 백엔드 개발에서 FastAPI는 가장 주목받는 프레임워크 중 하나입니다. 하지만 많은 개발자가 단순히 async def를 사용하면 모든 것이 해결된다고 오해하곤 합니다. FastAPI가 내부적으로 비동기 요청을 어떻게 관리하는지, 특히 Worker 모델과 AnyIO 기반의 스레드 풀이 어떻게 상호작용하는지를 명확히 이해하는 것은 고성능 애플리케이션 구축의 필수 요건입니다. 본 포스팅에서는 FastAPI의 비동기 처리 메커니즘을 심층 분석하고, 실제 운영 환경에서 발생할 수 있는 병목 현상을 해결하는 구체적인 수치와 방법을 제시합니다.

---

## 1. FastAPI와 ASGI: 비동기 Worker 모델의 근간

FastAPI는 자체적으로 서버 기능을 수행하지 않습니다. 대신 Uvicorn이나 Gunicorn 같은 ASGI(Asynchronous Server Gateway Interface) 서버 위에서 동작합니다. 여기서 'Worker'는 클라이언트의 요청을 받아 처리하는 독립적인 프로세스 단위를 의미합니다.

Uvicorn의 단일 프로세스 모델 vs Gunicorn의 멀티 워커 모델

Uvicorn은 단일 루프에서 수만 개의 동시 연결을 처리할 수 있는 uvloop를 사용합니다. 하지만 CPU 코어가 여러 개인 서버에서는 단일 Uvicorn 프로세스만으로는 자원을 100% 활용할 수 없습니다. 이때 Gunicorn을 프로세스 관리자로 사용하여 여러 개의 Uvicorn Worker를 실행하는 방식을 사용합니다.

---

## 2. 내부 동작의 핵심: Async vs Sync 함수 처리 차이

FastAPI의 가장 독창적인 점은 개발자가 정의한 함수의 형태(async 여부)에 따라 실행 경로를 다르게 가져간다는 것입니다. 이는 성능 최적화의 80%를 결정짓는 핵심 요소입니다.

구분	async def (비동기 함수)	def (일반 동기 함수)
실행 위치	Main Event Loop (이벤트 루프)	External Thread Pool (별도 스레드 풀)
처리 방식	협력적 멀티태스킹 (await 시 제어권 반환)	병렬 처리 (스레드 점유)
적합한 작업	I/O Bound (DB 조회, API 호출)	CPU Bound 또는 레거시 라이브러리 활용
주의사항	Blocking 코드 포함 시 루프 전체가 정지됨	스레드 생성 비용 및 컨텍스트 스위칭 발생

---

## 3. Worker 내부의 스레드 관리와 AnyIO

FastAPI는 일반 동기 함수(def)를 처리하기 위해 AnyIO 라이브러리를 사용합니다. 사용자가 비동기가 아닌 일반 함수로 엔드포인트를 작성하면, FastAPI는 이를 이벤트 루프에서 직접 실행하지 않고 별도의 Bounded Capacity Thread Pool로 넘깁니다.

• 작동 원리: 이벤트 루프는 요청을 스레드 풀에 던지고 즉시 다음 클라이언트 요청을 받으러 돌아갑니다.
• 해결책: 만약 동기 함수가 너무 많아 스레드 풀이 가득 차면, 비동기 서버임에도 불구하고 응답 지연이 발생합니다. 이 경우 워커 수를 늘리거나 RuntimeConfig를 통해 최대 스레드 수를 조절해야 합니다.

---

## 4. 실전 코드 예제 (Sample Example)

비동기 처리와 동기 처리가 내부 워커 모델에서 어떻게 다르게 작동하는지 확인하는 파이썬 코드 예시입니다.

from fastapi import FastAPI
import asyncio
import time

app = FastAPI()

# 1. 비동기 방식: 이벤트 루프를 효율적으로 활용
@app.get("/async-task")
async def async_task():
    # await 키워드가 제어권을 루프에 반환함
    await asyncio.sleep(1) 
    return {"message": "Async task completed using Event Loop"}

# 2. 동기 방식: FastAPI가 내부 스레드 풀에서 실행함
@app.get("/sync-task")
def sync_task():
    # 이 작업은 별도의 스레드에서 돌아가므로 메인 루프를 막지 않음
    time.sleep(1) 
    return {"message": "Sync task completed using Thread Pool"}

---

## 5. 성능 최적화를 위한 3가지 전략

1. Worker 수 설정: 일반적으로 서버의 CPU 코어 수에 2n + 1 공식을 적용하여 Gunicorn 워커를 설정합니다.
2. Blocking I/O 제거: async def 내부에서 requests나 time.sleep 같은 블로킹 함수를 절대 사용하지 마십시오. 대신 httpx나 asyncio.sleep을 사용해야 합니다.
3. Heavy Computation 분리: 데이터 분석이나 이미지 처리 같은 CPU 집중 작업은 FastAPI 워커 내부가 아닌, Celery나 RQ 같은 별도의 Task Queue로 위임하는 것이 최선의 해결 방법입니다.

---

## 6. 결론 및 요약

FastAPI의 Worker 모델은 이벤트 루프의 고속 I/O 처리와 스레드 풀을 통한 안정적인 동기 작업 지원이라는 두 마리 토끼를 모두 잡도록 설계되었습니다. 개발자는 자신이 작성하는 코드가 루프를 점유하는지, 아니면 스레드 풀로 위임되는지를 명확히 인지하고 설계해야만 진정한 고성능 비동기 애플리케이션을 완성할 수 있습니다.

참고 문헌 및 출처

• FastAPI 공식 문서: "Concurrency and async / await" (https://fastapi.tiangolo.com/async/)
• Starlette Documentation: "Threading and Starlette"
• Uvicorn Documentation: "Deployment - Gunicorn"
• AnyIO Documentation: "Working with threads"