10個のFastAPIパフォーマンス最適化のヒント：コードからデプロイまでのエンドツーエンドの高速化

FastAPIは、非同期操作のサポート、自動ドキュメント生成、および強力な型検証により、Python API開発で最も推奨されるフレームワークの1つになりました。ただし、同時実行性の高いシナリオでは、最適化されていないサービスは、レイテンシの増加とスループットの低下に苦しむ可能性があります。この記事では、FastAPIのパフォーマンスの可能性を最大限に引き出すために、実装手順と設計原則を含む10個の実用的な最適化ソリューションをまとめています。

1. 非同期の利点を無駄にしないためにasync/awaitを優先する

実装方法: ビュー関数、依存関係、およびデータベース操作に非同期構文を使用し、aiohttp（HTTPリクエスト用）やsqlalchemy.ext.asyncio（データベース用）などの非同期ライブラリと組み合わせます。

from fastapi import FastAPI
import aiohttp

app = FastAPI()

@app.get("/async-data")
async def get_async_data():
    async with aiohttp.ClientSession() as session:
        async with session.get("https://api.example.com/data") as resp:
            return await resp.json()  # イベントループをブロックせずに非同期的に中断

設計原則: FastAPIはASGIプロトコルに基づいており、その中心にはイベントループがあります。同期関数（defで定義）はイベントループスレッドを占有します。たとえば、データベースの応答を待機している間、CPUは完全にアイドル状態ですが、他のリクエストを処理できません。async/awaitを使用すると、I/O操作が中断されたときに、イベントループは他のタスクをスケジュールできるため、CPU使用率が3〜5倍に向上します。

2. 依存関係インスタンスを再利用して再初期化のオーバーヘッドを削減する

実装方法: データベースエンジンや構成オブジェクトなどのステートレスな依存関係については、lru_cacheまたはシングルトンパターンを使用してインスタンスをキャッシュします。

from fastapi import Depends
from functools import lru_cache
from sqlalchemy.ext.asyncio import AsyncSession, create_async_engine

@lru_cache(maxsize=1)  # グローバルに再利用するためにエンジンインスタンスを1つだけ作成する
def get_engine():
    return create_async_engine("postgresql+asyncpg://user:pass@db:5432/db")

async def get_db(engine=Depends(get_engine)):
    async with AsyncSession(engine) as session:
        yield session

設計原則: デフォルトでは、FastAPIはリクエストごとに新しい依存関係インスタンスを作成します。ただし、データベースエンジンやHTTPクライアント（接続プールの確立など）などのコンポーネントの初期化には時間とリソースがかかります。インスタンスをキャッシュすると、初期化のオーバーヘッドを90％以上削減できるだけでなく、接続プールの過剰な作成によって引き起こされる過度のデータベース圧力を防ぐことができます。

3. Pydanticモデルを簡素化して検証コストを削減する

実装方法:

1. APIに必要なフィールドのみを保持する
2. exclude_unsetを使用してシリアル化されたデータを削減する
3. 単純なシナリオではPydanticの代わりにtypingを使用する

from pydantic import BaseModel

class UserResponse(BaseModel):
    id: int
    name: str  # フロントエンドのために「created_at_timestamp」のような未使用のフィールドを削除する

@app.get("/users/{user_id}", response_model=UserResponse)
async def get_user(user_id: int, db=Depends(get_db)):
    user = await db.get(User, user_id)
    return user.dict(exclude_unset=True)  # シリアル化時間を短縮するために非デフォルト値のみを返す

設計原則: Pydanticはリフレクションを通じて型検証を実装します。モデルが持つフィールドが多いほど、ネストが深いほど、リフレクションのオーバーヘッドが大きくなります。同時実行性の高いシナリオでは、複雑なモデルの検証とシリアル化がリクエストのレイテンシの40％を占める可能性があります。モデルを簡素化すると、リフレクション操作が直接削減され、応答速度が20％〜30％向上します。

4. Uvicorn + Gunicornを使用してマルチコアCPUの使用率を最大化する

実装方法: 本番環境では、プロセス管理にGunicornを使用し、CPUコア数と同じ数のUvicornワーカープロセスを開始します。

# 4コアCPUの例：ポート8000にバインドされた4つのUvicornプロセス
gunicorn main:app -w 4 -k uvicorn.workers.UvicornWorker -b 0.0.0.0:8000

設計原則: PythonのGlobal Interpreter Lock（GIL）は、単一のプロセスが複数のコアを利用することを防ぎます。Uvicornは純粋な非同期ASGIサーバーですが、単一のプロセスは1つのコアでのみ実行できます。Gunicornは複数のプロセスを管理し、各Uvicornプロセスが1つのコアを占有できるようにするため、スループットはコア数に応じて直線的に向上します。

5. 高頻度のデータをキャッシュして、繰り返されるクエリ/計算を削減する

実装方法: fastapi-cache2 + Redisを使用して、人気のあるデータ（構成、リーダーボードなど）をキャッシュし、妥当な有効期限を設定します。

from fastapi_cache2 import CacheMiddleware, caches, cache
from fastapi_cache2.backends.redis import CACHE_KEY, RedisCacheBackend

app.add_middleware(CacheMiddleware)
caches.set(CACHE_KEY, RedisCacheBackend("redis://redis:6379/0"))

@app.get("/popular-products")
@cache(expire=300)  # 複雑なSQLの繰り返し実行を避けるために5分間キャッシュする
async def get_popular_products(db=Depends(get_db)):
    return await db.execute("SELECT * FROM products ORDER BY sales DESC LIMIT 10")

設計原則: APIのパフォーマンスボトルネックは、多くの場合「繰り返される時間のかかる操作」（大規模なテーブルのスキャン、複雑なアルゴリズムなど）から発生します。キャッシュは結果を一時的に保存し、後続のリクエストがデータを直接読み取ることができるようにするため、レイテンシが数百ミリ秒からミリ秒に短縮されます。分散キャッシュは、複数のインスタンス間での共有もサポートしているため、クラスターデプロイメントに適しています。

6. データベースの最適化：接続プール+インデックス+ N+1の防止

実装方法:

1. 非同期接続プールを使用して接続数を制御する
2. クエリフィールドにインデックスを作成する
3. select_relatedを使用してN+1クエリを回避する

# 1回のアクセスでユーザーとそれに関連する注文を照会し、「10人のユーザーをクエリ+ 10件の注文をクエリ」というN+1問題を回避する
async def get_user_with_orders(user_id: int, db: AsyncSession = Depends(get_db)):
    return await db.execute(
        select(User).options(select_related(User.orders)).where(User.id == user_id)
    ).scalar_one_or_none()

設計原則: データベースは、ほとんどのAPIのパフォーマンスボトルネックです。

• 接続の確立には時間がかかる（接続プールは接続を再利用します）。
• 全テーブルスキャンは遅い（インデックスはクエリの複雑さをO(n)からO(log n)に軽減します）。
• N+1クエリは複数のI/O操作を引き起こします（単一のクエリでこれを解決します）。これらの3つの最適化により、データベースのレイテンシを60％以上削減できます。

7. 静的ファイルをNginx/CDNに委任する—FastAPIに過負荷をかけない

実装方法: 静的リソースのリバースプロキシとしてNginxを使用し、大規模プロジェクトの場合はCDNと組み合わせます。

server {
    listen 80;
    server_name api.example.com;

    # Nginxは静的ファイルを1日キャッシュで処理する
    location /static/ {
        root /path/to/app;
        expires 1d;
    }

    # APIリクエストをFastAPIに転送する
    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
    }
}

設計原則: FastAPIはアプリケーションサーバーであり、静的ファイルの処理効率はNginxよりも10倍以上低くなっています。Nginxは、静的ファイルの送信に特化して最適化された非同期のノンブロッキングモデルを使用します。CDNは、エッジノードを通じてコンテンツを配信し、ユーザーのレイテンシをさらに短縮します。

8. ミドルウェアを合理化してリクエストのインターセプトのオーバーヘッドを削減する

実装方法: コアミドルウェア（CORS、認証など）のみを保持し、デバッグミドルウェアを削除します。

from fastapi.middleware.cors import CORSMiddleware

# CORSミドルウェアのみを保持し、許可されるオリジンとメソッドを指定する
app.add_middleware(
    CORSMiddleware,
    allow_origins=["https://example.com"],  # セキュリティリスクとパフォーマンスの低下を招くワイルドカード*は避ける
    allow_credentials=True,
    allow_methods=["GET", "POST"],  # 必要なメソッドのみを許可する
)

設計原則: ミドルウェアはすべてのリクエスト/応答をインターセプトします。追加のミドルウェアごとに、リクエストに処理の追加レイヤーが追加されます。ミドルウェアにI/O操作（ロギングなど）が含まれている場合、イベントループをブロックする可能性もあります。ミドルウェアを合理化すると、リクエストチェーンのレイテンシを15％〜20％削減できます。

9. ブロッキングを防ぐために、非同期ビューで同期関数を呼び出すことを避ける

実装方法:

1. 非同期ライブラリを優先する（requestsの代わりにaiohttpを使用する）
2. 同期関数が避けられない場合は、asyncio.to_threadでラップする

import asyncio
import requests  # 同期ライブラリ—非同期ビューで直接呼び出すことはできない

@app.get("/sync-data")
async def get_sync_data():
    # イベントループをブロックせずに、スレッドプールで同期関数を実行する
    resp = await asyncio.to_thread(requests.get, "https://api.example.com/sync-data")
    return resp.json()

設計原則: 同期関数はイベントループスレッドを占有し、他の非同期タスクをキューに入れます。asyncio.to_threadは同期関数をスレッドプールにオフロードし、イベントループが他のリクエストの処理を継続できるようにし、同期ライブラリの使用とパフォーマンスのバランスを取ります。

10. プロファイリングツールを使用してボトルネックを特定する—盲目的な最適化を避ける

実装方法:

1. cProfileを使用して、遅いリクエストを分析する
2. Prometheus + Grafanaをメトリックモニタリングに使用する

import cProfile

@app.get("/profile-me")
async def profile_me():
    pr = cProfile.Profile()
    pr.enable()
    result = await some_expensive_operation()  # 分析対象のビジネスロジック
    pr.disable()
    pr.print_stats(sort="cumulative")  # ボトルネックを特定するために累積時間でソートする
    return result

設計原則: 最適化の前提はボトルネックの特定です—時間のかからない関数にキャッシングを追加することは意味がありません。プロファイリングツールは、時間のかかるポイント（SQLクエリがレイテンシの80％を占めるなど）を正確に特定し、監視ツールはオンラインの問題（ピーク時のレイテンシの急上昇など）を検出し、ターゲットを絞った最適化を保証します。

まとめ

FastAPIのパフォーマンス最適化のコアロジックは、「ブロッキングを減らし、リソースを再利用し、冗長な作業を避ける」ことです。async/awaitや簡素化されたモデルなどのコードレベルの最適化から、サーバーの組み合わせやCDNなどのデプロイメントレベルの改善、キャッシュやデータベースの最適化などのデータレベルの強化まで—これらのヒントをエンドツーエンドで実装することで、FastAPIサービスは高い同時実行下でも低いレイテンシと高いスループットを維持できます。

Leapcell: 最高のサーバーレスWebホスティング

最後に、Pythonサービスをデプロイするための理想的なプラットフォームである**Leapcell**をお勧めします。

🚀 お気に入りの言語で構築する

JavaScript、Python、Go、Rustで簡単に開発できます。

🌍 無制限のプロジェクトを無料でデプロイする

使用した分だけ料金を支払う—リクエストも料金もありません。

⚡ 従量課金制、隠れたコストなし

アイドル料金はかからず、シームレスなスケーラビリティのみです。

📖 ドキュメントをご覧ください

🔹 Twitterでフォローしてください：@LeapcellHQ