「非同期なら速い」と信じる哀れな子羊たちへ：SQLAlchemy 2.0 + FastAPIの地獄の歩き方

「`async def`さえ書けば、俺たちのAPIは爆速になる」。
そう信じて疑わないお前らに、一つだけ教えてやる。そのコード、本番環境で何人のユーザーを路頭に迷わせる気だ？

俺はかつて、新機能のリリース直後に調子に乗って非同期化を全導入し、コネクションプールを瞬時に枯渇させ、深夜の監視アラートの嵐の中で冷や汗を流しながらロールバックした経験がある。あの時、DBのログに流れた無数の「`ConnectionTimeout`」の文字は、今でも悪夢に出てくる。

非同期は魔法じゃない。ただのIO多重化という「諸刃の剣」だ。正しく扱えないなら、今すぐそのキーボードを置いて同期処理に戻れ。

---

1. 依存関係（DI）という名の「時限爆弾」

FastAPIの`Depends`でセッションを管理するのは定石だが、多くの奴は「なぜ`AsyncSessionLocal`を使うのか」を理解していない。

# database.py
from sqlalchemy.ext.asyncio import create_async_engine, async_sessionmaker, AsyncSession

# pool_sizeを適当に決めるな。DBのmax_connectionsと相談しろ
engine = create_async_engine(
    DATABASE_URL, 
    pool_size=20, 
    max_overflow=10,
    pool_pre_ping=True  # これを入れないと、DB再起動時に死ぬ
)

AsyncSessionLocal = async_sessionmaker(
    engine, 
    expire_on_commit=False, # これをTrueにすると、コミット後に属性アクセスした瞬間に再クエリが走り、地獄を見る
    class_=AsyncSession
)

async def get_db():
    async with AsyncSessionLocal() as session:
        try:
            yield session
            await session.commit()
        except Exception:
            await session.rollback()
            raise
        finally:
            await session.close()

`expire_on_commit=False`を忘れると何が起きるか？ SQLAlchemyはコミット後にオブジェクトを「期限切れ」と見なす。その状態で別の関数で属性に触れた瞬間、裏で勝手にSELECT文が発行される。非同期コンテキストの外でそれが走れば、即座に`MissingGreenlet`エラーでアプリがクラッシュする。お前が寝ている間に、ユーザーには500エラーが降り注ぐわけだ。

---

2. Repositoryパターンという「過剰な墓標」

「クリーンアーキテクチャのためにRepository層を作る」？ 悪いことは言わない、やめておけ。

SQLAlchemyのORMは、`Identity Map`（同じオブジェクトは一意に管理する）という強力な機能を備えている。Repository層で無意味にラップし、セッションをあちこちで使い回すと、この恩恵が殺される。結果として、メモリ効率は落ち、デバッグ難易度は跳ね上がる。

個人のプロジェクトなら、「Repoは薄く、かつ直接的」が正義だ。

class UserRepository:
    def __init__(self, db: AsyncSession):
        self.db = db

    async def get_user_with_posts(self, user_id: int):
        # 必要なデータは「明示的」にロードしろ
        stmt = select(User).where(User.id == user_id).options(selectinload(User.posts))
        result = await self.db.execute(stmt)
        return result.scalar_one_or_none()

抽象化することに快感を覚えるな。複雑なビジネスロジックがないなら、Repositoryは単なる「クエリの置き場」で十分だ。

---

3. なぜN+1問題が「非同期」だと致命的なのか

同期処理ならN+1が起きても「まあ少し遅いな」で済む。だが非同期でこれをやると、ループ回数分だけDBへのIO待ちが重なり、コネクションプールを即座に食いつぶす。

`selectinload`を忘れた時の地獄のログを見てみろ：

[DEBUG] SELECT ... FROM user WHERE id = 1;
[DEBUG] SELECT ... FROM posts WHERE user_id = 1;  <-- N回ループの末路
[DEBUG] SELECT ... FROM posts WHERE user_id = 2;
[DEBUG] SELECT ... FROM posts WHERE user_id = 3;
...
[ERROR] sqlalchemy.exc.TimeoutError: QueuePool limit of size 20 overflow 10 reached

この「不可解なクエリの洪水」を止めるには、ORMの遅延ロードを信じず、`selectinload`や`joinedload`で「何をロードするか」をコードに刻み込むしかない。

---

4. プロファイラなしで「速くなった」と語るな

俺がローカルコンテナ環境（Docker + PostgreSQL）で計測した結果を叩きつけてやる。`cProfile`と`pyinstrument`で計測した、100リクエストの平均処理時間だ。

結論は明白だ。「IO待ちが支配的な処理」以外で非同期を使っても、オーバーヘッドが嵩むだけだ。 CPUをぶん回す計算処理が混ざっているなら、非同期化はむしろ害悪になる。

自分のアプリがどこで詰まっているのか、`pyinstrument`を回してボトルネックを可視化しろ。勘でコードを書くのはプロの仕事じゃない。

---

最後に

非同期処理は、お前のコードを一段上のレベルへ引き上げるツールだが、同時に「不注意なエンジニアを殺す刃物」でもある。

• `get_db`のライフサイクルを理解しろ。
• `expire_on_commit`の罠を忘れるな。
• データのロード戦略（`selectinload`）をサボるな。

これができないなら、同期処理で堅実に作れ。それがお前のユーザーを守る唯一の道だ。現場からは以上だ。

---