コールドスタート¶
サーバーレス構成では、一定時間リクエストがないとLambdaのインスタンスが破棄され、次のリクエスト時に再起動（コールドスタート）が発生します。 このページでは、magic-pocketでデプロイしたDjangoアプリケーションのコールドスタート時間を実測データとともに紹介します。
| コンポーネント | コールドスタート | 条件 |
|---|---|---|
| Lambda (TiDB構成) | 約 4.5 秒 | 512 MB / x86_64 / コンテナイメージ |
| Lambda (Neon構成) | 約 5.1 秒 | 512 MB / x86_64 / コンテナイメージ |
| TiDB Serverless | 約 1 秒 | ap-northeast-1 |
| Neon Serverless | 約 0.1 秒 | ap-southeast-1（Lambda は ap-northeast-1） |
TiDB Serverless 構成¶
計測環境¶
| 項目 | 値 |
|---|---|
| Lambda メモリ | 512 MB |
| Lambda アーキテクチャ | x86_64 |
| パッケージタイプ | コンテナイメージ |
| Python | 3.12 |
| Django | 5.x |
| データベース | TiDB Serverless |
| リージョン | ap-northeast-1（Lambda・TiDB 同一リージョン） |
計測結果¶
Lambda が完全にコールドな状態から、ログアウト → ログイン → ログアウト → ログイン を連続実行し、CloudWatch Logs の REPORT 行から計測しました。
リクエスト一覧¶
| # | Duration | Init Duration | 操作 |
|---|---|---|---|
| 1 | 1,169 ms | 4,488 ms | 1回目ログアウト (POST) |
| 2 | 370 ms | — | リダイレクト |
| 3 | 10 ms | — | favicon.ico (404) |
| 4 | 24 ms | — | ログインページ表示 |
| 5 | 2,413 ms | — | 1回目ログイン (POST) |
| 6 | 265 ms | — | リダイレクト |
| 7 | 130 ms | — | 2回目ログアウト (POST) |
| 8 | 207 ms | — | リダイレクト |
| 9 | 4 ms | — | favicon.ico |
| 10 | 2,397 ms | — | 2回目ログイン (POST) |
| 11 | 262 ms | — | リダイレクト |
Init Duration（Lambda コールドスタート）: 約 4.5 秒¶
Init Duration 4,488 ms はLambda自体の初期化時間です。以下が含まれます:
- Pythonランタイムの起動
- モジュールの import（Django、magic-pocket 等）
- SSM Parameter Store からのシークレット取得
- Django アプリケーションの初期化
TiDB Serverless コールドスタートの推定: 約 1 秒¶
同じ「ログアウト POST」操作の Duration を比較すると:
| Duration | 状態 | |
|---|---|---|
| 1回目ログアウト | 1,169 ms | Lambda初回 + TiDB初回接続 |
| 2回目ログアウト | 130 ms | すべてウォーム |
| 差分 | 約 1,039 ms |
この約 1 秒の差が、TiDB Serverless のウェイクアップおよび初回の TCP コネクション確立・TLS ハンドシェイクのコストと推定されます。
Neon Serverless 構成¶
計測環境¶
| 項目 | 値 |
|---|---|
| Lambda メモリ | 512 MB |
| Lambda アーキテクチャ | x86_64 |
| パッケージタイプ | コンテナイメージ |
| Python | 3.12 |
| Django | 6.x |
| データベース | Neon Serverless (PostgreSQL 15) |
| Lambda リージョン | ap-northeast-1（東京） |
| Neon リージョン | ap-southeast-1（シンガポール） |
クロスリージョン構成
この計測では Lambda（東京）と Neon（シンガポール）が異なるリージョンにあります。同一リージョンの場合、DB 接続のレイテンシはさらに低くなることが期待されます。
計測結果¶
デプロイ後の WSGI 関数に対するリクエストを CloudWatch Logs の REPORT 行から計測しました。
リクエスト一覧¶
| # | Duration | Init Duration | 操作 |
|---|---|---|---|
| 1 | 51 ms | 5,112 ms | トップページ表示（コールドスタート） |
| 2 | 145 ms | — | トップページ表示（初回 DB クエリ） |
| 3 | 5 ms | — | トップページ表示（ウォーム） |
| 4 | 3 ms | — | トップページ表示（ウォーム） |
Init Duration（Lambda コールドスタート）: 約 5.1 秒¶
Init Duration 5,112 ms はLambda自体の初期化時間です。TiDB 構成（4,488 ms）より約 600 ms 長いのは、psycopg（PostgreSQL ドライバ）と mysqlclient の初期化コストの違いによるものと考えられます。
Neon Serverless 接続コストの推定: 約 0.1 秒¶
| Duration | 状態 | |
|---|---|---|
| 1回目（コールドスタート直後） | 51 ms | Lambda 初回 + Neon 初回接続 |
| 2回目 | 145 ms | 初回 DB クエリ（コネクションプール確立） |
| 3回目以降 | 3-5 ms | すべてウォーム |
コールドスタート直後の最初のリクエスト（51 ms）自体が高速で、Neon Serverless のウェイクアップコストは非常に小さいことがわかります。TiDB（約 1 秒）と比較して大幅に短縮されています。ただし、クロスリージョン構成であるにもかかわらずこの結果であるため、Neon の接続プロトコル（HTTP ベースの serverless driver）の効率性が寄与していると考えられます。
まとめ¶
| コンポーネント | TiDB 構成 | Neon 構成 |
|---|---|---|
| Lambda (Init Duration) | 約 4.5 秒 | 約 5.1 秒 |
| DB 初回接続 | 約 1 秒 | 約 0.1 秒 |
| 合計（初回リクエスト） | 約 5.7 秒 | 約 5.2 秒 |
| ウォーム時 | 130 ms | 3-5 ms |
ログイン POST が常に約 2.4 秒かかる理由（TiDB 構成での計測）
これはコールドスタートとは無関係です。Django のパスワード認証で使用される PBKDF2 ハッシュ検証の計算コストによるものです。Lambda のメモリ（= CPU）を増やすことで短縮できます。
コールドスタートを軽減するには
- Lambda メモリを増やす: メモリに比例して CPU も割り当てられるため、Init Duration が短縮されます
- Provisioned Concurrency: 常にウォームなインスタンスを維持できます（追加コストあり）
- 定期的なウォームアップ: EventBridge で定期的にリクエストを送ることで、インスタンスを維持できます
- DB を同一リージョンに配置: クロスリージョンのレイテンシを排除できます