FastAPI 対 Litestar: 本番環境ベンチマークと高スループットマイクロサービスアーキテクチャ

PythonのWeb開発の世界は、もはやDjango/Flaskのような同期的なモノリスと、ASGIという新しい世界の間の単純な二項対立ではなくなりました。高性能フレームワークの分野では、StarletteやPydanticといった巨人の肩の上に築かれたFastAPIが、議論の余地なくチャンピオンであり続けてきました。FastAPIは、型ヒントを活用した、自動ドキュメント生成機能を備える、信じられないほど高速なAPIを主流にしました。しかし、技術の世界において、現行の地位は一時的なものです。そこに登場したのが、Litestar（旧Starlite）です。これは、極限のパフォーマンス、アーキテクチャの純粋さ、そしてプラグイン可能な設計思想に焦点を当ててゼロから構築された挑戦者です。

次世代のマイクロサービスを設計するシニアエンジニアやアーキテクトにとって、その選択はもはや自明ではありません。我々は「速いかどうか？」という段階を過ぎ、「そのアーキテクチャは、複雑で高スループットなシステムを長期的にどのようにサポートするのか？」という領域に足を踏み入れています。この記事は、ありふれた「Hello, World」の比較ではありません。本番環境レベルのコード、再現可能なベンチマーク、そして何百万ものリクエストを処理し、p99レイテンシの悪化が致命的な問題となる状況で重要となるアーキテクチャ上のトレードオフを、批判的な視点で深く掘り下げていきます。依存性注入、シリアライゼーション、そして中心となるリクエスト/レスポンスループを徹底的に分析し、どちらのフレームワークが堅牢でスケーラブル、かつ保守性の高いサービスのための最良の基盤を提供するかを明らかにします。

コアスタック: 構成（Composition）と凝集（Cohesion）

フレームワークの哲学は、その依存関係に書かれています。FastAPIとLitestarが何で「作られているか」を理解することは、それぞれの中心的な設計思想を明らかにします。

FastAPI: ベストオブブリードのアセンブラー

FastAPIの素晴らしさは、既存のクラス最高峰のライブラリを見事に統合した点にあります。

• Webフレームワーク: Starletteが、ルーティング、ミドルウェア、リクエスト/レスポンスオブジェクトといったコアなASGIツールキットを提供します。これは、ミニマリストで非常に高性能な基盤です。
• データバリデーションとシリアライゼーション: Pydantic (v2)が、すべてのデータ整形を担当します。Rustでの再実装（pydantic-core）は、記念碑的なパフォーマンス向上をもたらし、データ集約的なタスクにおいて強力なエンジンとなりました。
• 並行処理: AnyIOが非同期バックエンドを提供し、FastAPIがasyncioまたはtrioのどちらでも実行できるようにしています。

この構成モデルにより、FastAPIは迅速に開発を進め、巨人の肩の上に立つことができました。そのトレードオフとして、パフォーマンスや挙動は、これらのアップストリームの依存関係の進化や制約に本質的に結びついています。

Litestar: 統合されたパフォーマンスエンジン

Litestarは異なるアプローチを取ります。ASGI標準を採用しつつも、ルーティング、パラメータ解析、リクエストライフサイクル管理といったコアコンポーネントは組み込みで、互いに連携して動作するように最適化されています。

• Webフレームワーク: Litestarのコアは自己完結したユニットです。この緊密な統合により、構成されたアーキテクチャでは困難な最適化が可能になります。例えば、リクエスト/レスポンスサイクルは、コンポーネント間の引き渡しではなく、単一の最適化されたパスとなっています。
• データバリデーションとシリアライゼーション: Litestarのキラー機能は、新しく非常に高速なシリアライゼーション・バリデーションライブラリであるmsgspecを第一級でサポートしている点です。Pydanticも完全にサポートしていますが、そのアーキテクチャは「シリアライゼーションに依存しない（serialization-agnostic）」ように設計されており、これが重要な哲学的違いです。
• 状態管理: 組み込みの階層的な依存性注入システムを備えており、FastAPIのリクエストスコープモデルと比較して、アプリケーションの状態をよりきめ細かく制御できます。

この統合アプローチは、最高のパフォーマンスとアーキテクチャの明快さを目指しており、その潜在的な代償として、個々のコンポーネントが持つ広範なエコシステムの勢いへの依存度が低くなる可能性があります。

本番環境ベンチマーク: 「Hello, World」を超えて

口先だけでは意味がありません。実際に測定してみましょう。Debian 11、Python 3.11、そしてuvicorn --workers 2が動作するn2d-standard-2 Google Cloudインスタンス（2 vCPU, 8 GB RAM）上で、3つの一般的な本番シナリオをベンチマークします。ベンチマークツールはbombardierを使用し、50の同時接続で30秒間実行します。

環境設定:

# Install dependencies
pip install "fastapi[all]==0.111.0" "pydantic==2.7.1" "litestar[all]==2.8.2" "msgspec==0.18.6" "uvicorn[standard]==0.29.0" "bombardier"

# Benchmark command
bombardier -c 50 -d 30s http://127.0.0.1:8000/path

シナリオ1: 単純なJSONレスポンス

これは、リクエスト/レスポンスサイクルの純粋なオーバーヘッドをテストします。

FastAPI:

# fastapi_app.py
from fastapi import FastAPI

app = FastAPI()

@app.get("/simple")
async def simple_get():
    return {"message": "Hello, World"}

Litestar:

# litestar_app.py
from litestar import Litestar, get

@get("/simple")
async def simple_get() -> dict[str, str]:
    return {"message": "Hello, World"}

app = Litestar(route_handlers=[simple_get])

分析: 最も単純なケースでさえ、Litestarは約19%のスループット向上を示しています。これは、StarletteからFastAPIへの引き渡しに伴うわずかなオーバーヘッドを回避する、より直接的で統合されたリクエスト/レスポンスパスに起因する可能性が高いです。

シナリオ2: パスパラメータと基本的なバリデーション

ここでは、基本的なルーティングとパスパラメータの型強制を導入します。

FastAPI:

# fastapi_app.py
# ...
@app.get("/items/{item_id:int}")
async def read_item(item_id: int):
    return {"item_id": item_id}

Litestar:

# litestar_app.py
# ...
@get("/items/{item_id:int}")
async def read_item(item_id: int) -> dict[str, int]:
    return {"item_id": item_id}

# ... add to Litestar app

分析: 差は一貫しています。両フレームワークともパスパラメータの解析と型強制を効率的に処理しますが、Litestarの統合されたルーティングとパラメータ解決がパフォーマンスの優位性を維持しています。

シナリオ3: 複雑なJSONボディのシリアライゼーションとバリデーション

これは、データ集約的なマイクロサービスにとっての真のテストです。中程度に複雑なデータ構造を使用し、リクエストボディのデシリアライズとレスポンスのシリアライズにかかるコストを測定します。

共通データモデル (Pydantic vs. msgspec):

# Pydantic Model (for FastAPI)
from pydantic import BaseModel
from typing import List

class Item(BaseModel):
    id: int
    name: str
    tags: List[str]
    is_active: bool

# msgspec Struct (for Litestar)
import msgspec

class Item(msgspec.Struct):
    id: int
    name: str
    tags: list[str]
    is_active: bool

FastAPI (Pydantic使用):

# fastapi_app.py
# ...
@app.post("/process")
async def process_items(items: List[Item]) -> List[Item]:
    # a trivial no-op to isolate serialization cost
    return items

Litestar (msgspec使用):

# litestar_app.py
# ...
from litestar import post
from typing import List

@post("/process")
async def process_items(data: List[Item]) -> List[Item]:
    return data

# ... add to Litestar app

分析: ここでアーキテクチャの選択が明確に現れます。

1. msgspecを使用したLitestarは、Pydantic v2を使用したFastAPIよりも約58%高速です。 msgspecは速度を最優先に作られており、バリデーションとシリアライゼーションの両方におけるそのパフォーマンスは、まさに別次元です。
2. Pydantic v2を使用したLitestarは、FastAPIとほぼ同等のパフォーマンスを示します。 これは非常に重要な発見です。これは、Litestarのコアフレームワークのオーバーヘッドが無視できるほど小さく、現代のPython Webフレームワークにおけるパフォーマンスのボトルネックが圧倒的にシリアライゼーションにあることを証明しています。また、これはLitestarの柔軟性も示しています。つまり、ニーズに応じてシリアライゼーションエンジンを選択できるのです。絶対的なパフォーマンスを求めるならmsgspecを、Pydanticの豊富な機能とエコシステムが必要なら、フレームワークによるペナルティなしにそれを使用できます。

アーキテクチャの深掘り: 依存性注入（Dependency Injection）

パフォーマンスは秒間リクエスト数以上のものです。それは、保守可能でテストしやすいシステムを構築することに関わります。依存性注入（DI）はその中心です。

FastAPI: 暗黙的かつリクエストスコープ

Starletteから継承したFastAPIのDIは、そのシンプルさが強力です。Dependsを使って依存関係を宣言すると、FastAPIがリクエスト時にそれを解決して注入します。

# fastapi_di.py
from fastapi import FastAPI, Depends
from typing import Annotated

class DBSession:
    def __init__(self):
        print("Creating DB Session")
        self.closed = False
    def close(self):
        print("Closing DB Session")
        self.closed = True

# Dependency (factory)
def get_db_session():
    session = DBSession()
    try:
        yield session
    finally:
        session.close()

app = FastAPI()

@app.get("/users/{user_id}")
async def get_user(user_id: str, db: Annotated[DBSession, Depends(get_db_session)]):
    # db is a new DBSession for every request
    return {"user_id": user_id}

このモデルは直感的です。依存関係はリクエストごとに解決され、分離が保証されます。yieldパターンは、セットアップとティアダウン（例：データベース接続の開始と終了）をクリーンに処理する方法を提供します。しかし、すべての依存関係はリクエストスコープです。起動時に一度だけ解決されるアプリケーションスコープのシングルトンのための組み込みメカニズムはありません。グローバルな状態やライフスパンイベントでこれを管理することはできますが、DIシステム自体には統合されていません。

Litestar: 階層的かつ明示的

LitestarのDIはより構造化されており、明示的です。アプリケーションの異なるレイヤー（アプリケーションインスタンス、ルーター、特定のハンドラ）で依存関係をProvideします。これにより、異なる依存関係スコープが可能になります。

# litestar_di.py
from litestar import Litestar, get, Provide

# Same DBSession class as before...
class DBSession:
    # ...
# This will be recreated for each request
def get_request_db_session() -> DBSession:
    print("Creating DB Session for request")
    return DBSession()

# This will be created ONCE at application startup
def get_app_singleton_service() -> dict:
    print("Creating singleton service ONCE")
    return {"data": "shared_and_immutable"}

@get("/users/{user_id}")
def get_user(
    user_id: str,
    db: DBSession, # Injected by 'dependencies'
    service: dict, # Injected by 'dependencies'
) -> dict[str, str]:
    return {"user_id": user_id, "service_data": service.get("data")}

app = Litestar(
    route_handlers=[get_user],
    dependencies={
        "db": Provide(get_request_db_session, sync_to_thread=False), # Request scope (default)
        "service": Provide(get_app_singleton_service, scope="app"), # App (singleton) scope
    },
)

この階層的アプローチは、複雑なアプリケーションにとって大きなアーキテクチャ上の利点です。

• scope="app": 依存関係はシングルトンとなり、アプリケーション起動時に一度だけ作成されます。データベースの接続プール、HTTPクライアント、または事前にロードされた機械学習モデルに最適です。
• scope="request": 依存関係は受信リクエストごとに作成されます。データベースセッションやリクエスト固有のコンテキストに理想的です。

この明示的なスコープ指定は曖昧さを排除し、状態を管理するための明確でパフォーマンスの高いパターンを提供し、長寿命サービスのオブジェクト生成オーバーヘッドを削減します。

解決フローの違いは以下の通りです。

型付けとOpenAPI生成

両フレームワークともPythonの型ヒントからOpenAPIスキーマを生成することに優れていますが、そのアプローチと機能には若干の違いがあります。

• FastAPI: Pydanticとの緊密な結合が最大の強みです。Pydanticモデルから直接、非常に詳細で正確なスキーマを生成します。これには検証ルール（例：min_length, gt）も含まれます。それがゴールドスタンダードであるのには理由があります。

• Litestar: Litestarはより汎用性があります。以下のものからOpenAPIスキーマを生成できます。

  • msgspec.Struct
  • Pydanticモデル
  • 標準ライブラリのdataclasses
  • attrsクラス

この柔軟性は、「プラグイン可能なバックエンド」という哲学と一致しています。さらに、Litestarは仕様の最新バージョンであるOpenAPI 3.1をサポートしており、JSON Schema 2020-12のサポート向上など、より高度なスキーマ機能を提供します。また、DTO（Data Transfer Object）レイヤーを導入しており、これにより内部のドメインモデルをAPIが公開するデータ構造から分離できます。これは複雑なシステムにおいて強力なパターンです。

# litestar_dto_example.py
from litestar import Litestar, post
from litestar.dto import DTOConfig, DTOData

# Internal domain model (could be an SQLAlchemy model)
class User:
    def __init__(self, id: int, first_name: str, last_name: str, password_hash: str):
        self.id = id
        self.first_name = first_name
        self.last_name = last_name
        self.password_hash = password_hash

# DTO to control what is exposed via the API
class UserDTO(DTOData[User]):
    config = DTOConfig(
        exclude={"password_hash"}  # Never expose the password hash
    )

@post("/users", dto=UserDTO)
def create_user(data: DTOData[User]) -> User:
    user_instance = data.create_instance()
    # ... save user_instance to db ...
    print(f"Created user: {user_instance.first_name}, hash: {user_instance.password_hash}")
    return user_instance # DTO will automatically strip 'password_hash' from response

この例では、ハンドラは内部で完全なUserオブジェクトを扱いますが、UserDTOがpassword_hashをリクエストボディからデシリアライズしたり、レスポンスにシリアライズしたりすることを防ぎ、堅牢なセキュリティと抽象化レイヤーを提供します。

知識を確認する（インタラクティブクイズ）

結論: Python APIの変曲点

ベンチマークとアーキテクチャ分析は、明確な全体像を描き出します。

FastAPIは、Pydantic v2の登場により、依然として驚異的な選択肢です。高速で成熟しており、巨大なコミュニティとエコシステムに支えられています。そのシンプルさは一つの特徴であり、そのパフォーマンスは大多数のユースケースで十分すぎるほどです。そのエコシステムに投資しているチームにとっては、実績のある信頼できる主力製品です。

しかし、Litestarは、パフォーマンスとスケーラビリティの極限を追求するエンジニアにとって、魅力的な代替案としての地位を確立することに成功しました。

1. 純粋なスループット: msgspecの統合は、データ集約的なアプリケーションにおいて、否定できない大きなパフォーマンス上の優位性をもたらします。我々のベンチマークでは、一般的なJSON処理タスクで50%を超える改善が見られました。
2. アーキテクチャの厳密さ: 階層的な依存性注入システムは単なる機能ではなく、複雑で高並行性なアプリケーションで状態を管理するための優れたアーキテクチャパターンです。
3. 将来の柔軟性: そのプラグイン可能な設計（シリアライゼーション、DTO、テンプレート）と、OpenAPI 3.1のような現代的な標準のサポートは、将来に向けて良い位置づけにあります。

実践的な指針：

• 極端なパフォーマンス要件を持つ新規のグリーンフィールドプロジェクトですか？ Litestarとmsgspecで始めてください。パフォーマンスの向上とクリーンなDIアーキテクチャは、スケールした際に大きな利益をもたらすでしょう。
• FastAPIの深い専門知識を持つチームですか？ FastAPIを使い続けてください。Pydantic v2はパフォーマンスの差を大幅に縮めており、特定のパフォーマンスやアーキテクチャの限界に直面していない限り、再トレーニングやツールの再整備のコストは切り替えを正当化しないかもしれません。
• 多くの共有サービスを持つ複雑なシステムを構築していますか？ その階層的DIのために、Litestarを真剣に評価してください。それは、よりクリーンで、保守しやすく、そしておそらくよりパフォーマンスの高いアプリケーションアーキテクチャにつながるでしょう。

Litestarの台頭は、FastAPIの終わりを意味するものではありません。それは、PythonのASGIエコシステムが成熟したことを示しています。私たちは今、それぞれが明確な哲学を持つ2つの世界クラスのフレームワークを手に入れました。これにより、エンジニアとして私たちは、単に速度だけでなく、私たちが構築するシステムの長期的なアーキテクチャの健全性について、より批判的に考えることを迫られています。

参考文献

• Litestar Official Documentation
• FastAPI Official Documentation
• msgspec Documentation - The "why"
• Pydantic v2 Performance
• Starlette - The ASGI Toolkit