Home 論文解説: Serverless Cold Starts and Where to Find Them
投稿
キャンセル

📄 論文解説: Serverless Cold Starts and Where to Find Them

投稿日 31/05/2026
投稿者 0h-n0
32 分読了時間

論文概要

本記事は Serverless Cold Starts and Where to Find Them (arXiv:2410.06145) の解説記事です。本記事は引用・解説であり、筆者自身による実験は行っていません。

Joosen らは、Huawei の本番サーバーレスプラットフォーム（YuanRong）から収集した31日間・5データセンターリージョンにわたる85億リクエストと1190万コールドスタートイベントを分析し、コールドスタートの発生要因と持続時間を体系的に明らかにした。コールドスタート時間を4つの構成要素に分解し、リージョン間の差異やランタイム言語による影響を定量的に示したうえで、クロスリージョンスケジューリングを含む5つの最適化戦略を提案している。

関連するZenn記事: Gemini 2.5 Flash x Cloud Runでマルチモーダル推論APIを構築しコールドスタートを削減する

情報源

項目内容
タイトルServerless Cold Starts and Where to Find Them
arXiv ID2410.06145
著者Artjom Joosen, Ahmed Hassan, Martin Asenov, Rajkarn Singh, Luke Darlow, Jianfeng Wang, Qiwen Deng, Adam Barker
発表年2024年
会議EuroSys 2025 (ACM European Conference on Computer Systems)
分野cs.DC (Distributed, Parallel, and Cluster Computing), cs.OS, cs.PF
ライセンスCC BY 4.0
データ・コード公開済み

背景と動機

サーバーレスコンピューティングでは、ユーザーリクエストに応じて実行環境（コンテナやマイクロVM）が動的に起動される。しかし、新しい環境の初期化にかかる「コールドスタート」は、レイテンシの増大やユーザー体験の劣化を引き起こす根本的な課題である。

従来のコールドスタート研究は、外部からのベンチマーク測定（Wang et al., 2018）やAzureの関数呼び出しトレース分析（Shahrad et al., 2020）が中心であり、プラットフォーム内部でコールドスタート時間を構成要素レベルまで分解した大規模分析は行われていなかった。著者らは、Huawei YuanRongプラットフォームの内部データに直接アクセスし、コールドスタートの「何が」「なぜ」遅いのかを解明することを目的としている。本研究の特徴は、5リージョン・20クラスターという地理的多様性と、31日間（祝日期間を含む）という時間的多様性を兼ね備えた実データに基づく点にある。

主要な貢献

著者らは以下の貢献を報告している。

  • コールドスタートの4要素分解: Pod割り当て時間、コードデプロイ時間、依存関係デプロイ時間、スケジューリングオーバーヘッドの4構成要素を定義し、各要素の寄与をリージョン・ランタイム別に定量化
  • Pod Utility Ratio（新指標）の提案: Podの有用な稼働時間とコールドスタート時間の比率を測る指標を導入し、コールドスタートの実質的コストを評価
  • リージョン間の特性差異の発見: 同一プラットフォームでもリージョンによってコールドスタートのボトルネックが異なることを実証
  • 5つの最適化戦略の提案: データ分析に基づく具体的なコールドスタート削減手法を提案
  • データセット・コードの公開: 再現性と後続研究への貢献

技術的詳細

コールドスタートの分解モデル

著者らはコールドスタート時間 $T_{\text{cold}}$ を以下の4要素に分解している（論文Section 3より）。

\[T_{\text{cold}} = T_{\text{pod\_alloc}} + T_{\text{code\_deploy}} + T_{\text{dep\_deploy}} + T_{\text{sched}}\]

ここで各項は次のとおりである。

  • $T_{\text{pod_alloc}}$: リソースプールからPodを選択または新規作成する時間
  • $T_{\text{code_deploy}}$: 関数コードのダウンロード・展開・デプロイにかかる時間
  • $T_{\text{dep_deploy}}$: 依存関係（ライブラリ等）の取得・ロードにかかる時間
  • $T_{\text{sched}}$: ネットワークルーティング、スケジューリングに伴うオーバーヘッド

分布特性

著者らは、全リージョンを横断したコールドスタート時間が対数正規分布（LogNormal分布）に従うことを報告している（論文Section 4より）。

\[\ln(T_{\text{cold}}) \sim \mathcal{N}(\mu, \sigma^2)\]

フィッティング結果として、平均 $\mu = 3.24$、標準偏差 $\sigma = 7.10$ が報告されている。また、コールドスタート間の到着間隔はWeibull分布に従い、平均1.25、標準偏差3.66と報告されている。

Pod Utility Ratio

著者らが新たに導入したPod Utility Ratio $R_{\text{util}}$ は、以下のように定義されている（論文Section 5より）。

\[R_{\text{util}} = \frac{T_{\text{pod\_life}} - T_{\text{keep\_alive}}}{T_{\text{cold}}}\]

ここで $T_{\text{pod_life}}$ はPodの総生存時間、$T_{\text{keep_alive}}$ はkeep-alive時間（本プラットフォームでは1分）である。$R_{\text{util}} \leq 1$ の場合、Podがコールドスタートに費やした時間以下しか有用な処理を行っていないことを意味する。著者らは、全Podの約20%がこの条件に該当すると報告している。

Spearman相関分析

著者らはSpearman順位相関係数を用いて、コールドスタートの各構成要素間の関係を分析している（論文Figure 12より）。主な知見は次のとおりである。

  • コールドスタート時間とコールドスタート発生回数には正の相関がある（ただし相関の強さはリージョンにより異なる）
  • スケジューリング時間とPod割り当て時間は、コールドスタート回数と正の相関を示す（特にRegion 1, 3, 4で顕著）
  • スケジューリング時間と依存関係デプロイ時間の間に、特定リージョンでの局所的な強い相関が存在する

実装のポイント

データ収集アーキテクチャ

著者らの計測基盤は、3つの独立したデータストリームで構成されている。

  1. リクエストレベルストリーム: 各ユーザーリクエストの到着時刻、応答時間、コールドスタート有無を記録
  2. Podレベルストリーム: Pod の生成・破棄タイムスタンプ、リソース使用量、keep-alive 期間を追跡
  3. 関数レベルストリーム: 関数ごとのメタデータ（ランタイム、トリガータイプ、同期/非同期、リソース割り当て）を管理

この3ストリーム設計により、コールドスタートの原因を「インフラ層」「アプリケーション層」「ユーザー行動」の各視点から横断的に分析できる。5リージョン・20クラスターにわたるデータをJoin可能にすることで、リージョン間比較を実現している。

コールドスタート分解の計装

4要素への分解は、YuanRongプラットフォームの各コンポーネントにタイムスタンプ計装を埋め込むことで実現している。特に、スケジューリングオーバーヘッドは他の3要素の合計をコールドスタート総時間から差し引くことで算出される間接的な計測値であり、ネットワーク遅延やキュー待機時間を含む包括的な指標となっている。

Production Deployment Guide

本論文の知見をクラウドサービスでのコールドスタート対策に応用する方法を、規模別に整理する。以下は論文の分析結果に基づく指針であり、具体的な構成例はAWSおよびGCPの公式ドキュメントに準拠している。

規模別構成パターン

論文の知見から、コールドスタート対策は「関数の呼び出し頻度」「レイテンシ要件」「コスト許容度」に応じて段階的に適用すべきである。

構成想定規模月間リクエストレイテンシ要件主な対策月額コスト目安
Small個人・PoC~100万許容的（~5s）ランタイム最適化 + パッケージ軽量化$5-20
Mediumスタートアップ100万-1億中程度（~1s）Provisioned Concurrency（部分適用）+ SnapStart$50-300
Largeエンタープライズ1億超厳格（<200ms）コンテナ基盤（EKS/Cloud Run）+ min instances + クロスリージョン$500-5,000+

Small構成: AWS Lambda基本設定

論文では、ランタイム選択がコールドスタート時間に大きく影響することが報告されている（論文Section 4.4より、カスタムランタイムでmedian >10秒、Python3は比較的短い）。Small構成では、コスト追加なしで実施できる最適化を中心に行う。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# Terraform: Small構成 - Lambda基本設定
resource "aws_lambda_function" "api_handler" {
  function_name = "api-handler"
  runtime       = "python3.12"  # 論文の知見: ランタイム選択が重要
  handler       = "main.handler"
  memory_size   = 256  # 論文の知見: 大きなPodほどコールドスタートが長い
  timeout       = 30
  architectures = ["arm64"]  # Graviton2: コスト20%削減

  filename         = data.archive_file.lambda_zip.output_path
  source_code_hash = data.archive_file.lambda_zip.output_base64sha256

  environment {
    variables = {
      POWERTOOLS_SERVICE_NAME = "api-handler"
    }
  }
}
# API GatewayはHTTP API (aws_apigatewayv2_api) でLambda統合

Small構成でのコスト試算（月間100万リクエスト、平均実行時間200ms、256MB）:

  • Lambda実行料金: 約$0.83
  • API Gateway: 約$1.00
  • 合計: 約$2/月（無料枠適用前）

Medium構成: Provisioned Concurrency + SnapStart

論文のPod Utility Ratio分析から、呼び出し頻度の高い関数にリソースを集中させることが効率的であると示唆されている。Medium構成では、レイテンシが重要な関数にのみProvisioned Concurrencyを適用する。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

# Terraform: Medium構成 - Provisioned Concurrency
resource "aws_lambda_function" "api_critical" {
  function_name = "api-critical-path"
  runtime       = "python3.12"
  handler       = "main.handler"
  memory_size   = 512
  timeout       = 30
  architectures = ["arm64"]
  publish       = true  # Provisioned Concurrencyにはバージョン発行が必要

  filename         = data.archive_file.lambda_zip.output_path
  source_code_hash = data.archive_file.lambda_zip.output_base64sha256

  snap_start {
    apply_on = "PublishedVersions"  # SnapStart有効化
  }
}

resource "aws_lambda_alias" "live" {
  name             = "live"
  function_name    = aws_lambda_function.api_critical.function_name
  function_version = aws_lambda_function.api_critical.version
}

# レイテンシ重要パスにのみProvisioned Concurrencyを適用
resource "aws_lambda_provisioned_concurrency_config" "critical" {
  function_name                  = aws_lambda_alias.live.function_name
  qualifier                      = aws_lambda_alias.live.name
  provisioned_concurrent_executions = 5  # 論文の知見: 多くの関数はconcurrency limit未満で稼働
}

# Auto Scaling（論文のピーク対トラフ比の知見を反映）
resource "aws_appautoscaling_target" "lambda" {
  max_capacity       = 50
  min_capacity       = 5
  resource_id        = "function:${aws_lambda_alias.live.function_name}:${aws_lambda_alias.live.name}"
  scalable_dimension = "lambda:function:ProvisionedConcurrency"
  service_namespace  = "lambda"
}

resource "aws_appautoscaling_policy" "lambda" {
  name               = "lambda-concurrency-scaling"
  policy_type        = "TargetTrackingScaling"
  resource_id        = aws_appautoscaling_target.lambda.resource_id
  scalable_dimension = aws_appautoscaling_target.lambda.scalable_dimension
  service_namespace  = aws_appautoscaling_target.lambda.service_namespace

  target_tracking_scaling_policy_configuration {
    target_value = 0.7  # 使用率70%でスケールアウト

    predefined_metric_specification {
      predefined_metric_type = "LambdaProvisionedConcurrencyUtilization"
    }
  }
}

Medium構成でのコスト試算（月間5000万リクエスト、Provisioned Concurrency 5インスタンス、512MB）:

  • Lambda実行料金: 約$42
  • Provisioned Concurrency（5 x 512MB x 730h）: 約$27
  • API Gateway: 約$50
  • 合計: 約$120/月

Large構成: コンテナ基盤（Cloud Run / EKS）

論文のクロスリージョンスケジューリング分析では、データセンター間レイテンシ（数十〜数百ms）がコールドスタート時間（100ms〜7秒）に比べて十分小さいことが報告されている。Large構成では、コンテナ基盤によるmin instances設定とマルチリージョン展開を組み合わせる。

Cloud Run構成（GCP）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

# Terraform: Large構成 - Cloud Run（マルチリージョン）
resource "google_cloud_run_v2_service" "api" {
  name     = "inference-api"
  location = "asia-northeast1"

  template {
    scaling {
      min_instance_count = 2  # コールドスタート回避
      max_instance_count = 100
    }

    containers {
      image = "asia-northeast1-docker.pkg.dev/my-project/repo/api:latest"

      resources {
        limits = {
          cpu    = "2"
          memory = "2Gi"
        }
        cpu_idle          = true   # アイドル時CPU割り当て削減
        startup_cpu_boost = true   # 起動時のCPUブースト
      }

      startup_probe {
        http_get {
          path = "/healthz"
        }
        initial_delay_seconds = 0
        period_seconds        = 5
        failure_threshold     = 3
      }
    }

    max_instance_request_concurrency = 80  # 論文の知見: 同時実行数調整
  }

  traffic {
    type    = "TRAFFIC_TARGET_ALLOCATION_TYPE_LATEST"
    percent = 100
  }
}

# セカンダリリージョン（同一構成、min_instance_count = 1）
# google_cloud_run_v2_service "api_secondary" を us-central1 等に展開

マルチリージョン構成では、同一のサービス定義をセカンダリリージョンにも展開し、Cloud Load Balancingで振り分ける。EKS + KEDA構成の場合は、terraform-aws-modules/eks/awsモジュールでクラスターを構築し、KEDAのHelmチャートでイベント駆動スケーリングを実現する。

Large構成でのコスト試算:

  • Cloud Run（2 min instances, asia-northeast1, 2vCPU/2GiB）:
    • アイドル時: 約$30/月（CPU idle有効時、アクティブ料金の10%）
    • アクティブ時（月間1億リクエスト、平均200ms）: 約$200-400/月
  • EKS（3ノード m7g.xlarge）: 約$300/月（EC2） + $73/月（EKSコントロールプレーン）

運用・監視設定

論文の分析手法に倣い、コールドスタートの4要素を継続的に監視する体制を構築する。

監視項目

  • CloudWatch Metric Math: カスタムメトリクスColdStartとInvocationsの比率でコールドスタート率を算出し、10%超過時にSNSアラーム発報
  • X-Ray Active Tracing: Lambda関数のtracing_config.mode = "Active"を設定し、コールドスタート時間の内訳（INIT phase）をトレースで可視化
  • Cloud Run: Cloud Monitoring でrun.googleapis.com/container/startup_latenciesメトリクスを監視

コスト最適化チェックリスト

論文の知見を踏まえた、定期的に確認すべき項目を以下に示す。

  • Pod Utility Ratio相当の監視: Provisioned Concurrency使用率が常に30%未満の関数がないか確認（AWS Cost ExplorerのProvisionedConcurrencyUtilizationメトリクス）
  • ランタイム・パッケージサイズの定期監査: デプロイパッケージが50MBを超える関数を特定し、Layer分離やdependency削減を検討
  • ピーク/トラフ比の分析: 論文では関数ごとに2倍から1000倍超の変動が報告されている。Auto Scalingのmin_capacityとmax_capacityが実際のトラフィックパターンに適合しているか確認
  • タイマー関数のプリウォーミング: 論文ではタイマートリガーが全コールドスタートの42%を占めると報告されている。定期実行関数のスケジュールを分析し、実行直前のウォームアップイベントを設定
  • クロスリージョンフェイルオーバーの検証: 単一リージョン障害時にコールドスタートが集中しないよう、マルチリージョンのmin instancesを確認
  • 月次コストレビュー: AWS Cost Explorer / GCP Billing でProvisioned Concurrency・min instancesの費用対効果を検証

実験結果

リージョン間比較

著者らは5リージョンのコールドスタート特性に顕著な差異があることを報告している（論文Section 4.2, Table 2より）。

  • Region 1: コールドスタート時間の中央値が最も長く、最大約7秒に達する。依存関係デプロイ時間とスケジューリングオーバーヘッドが支配的である
  • Region 2: 最大約3秒で、Pod割り当て時間が支配的である
  • Region 3: 比較的短いコールドスタート時間を示す

リージョン間で中央値の呼び出し率に最大50倍、関数実行時間に最大25倍、CPU使用率に最大3倍の差があることが報告されている。この差異は、各リージョンのワークロード特性（デプロイされる関数の種類、依存関係の複雑さ、インフラ構成）に起因すると著者らは分析している。

Pod Utility Ratio分布

著者らの分析によると、全Podの約20%がPod Utility Ratio 1:1未満（コールドスタート時間よりも有用な稼働時間が短い）であり、中央値は約4:1と報告されている。特にNodeJSランタイムでは、約40%のPodがRatio 1未満を示しており、短寿命のPodが多い傾向が確認されている。一方、コールドスタート時間が長いPodほど、有用な稼働時間も長い傾向が見られ、単純にコールドスタート時間だけでは効率性を評価できないことが示されている。

実運用への応用

Cloud Runとの関連性

本論文の知見は、Google Cloud Runをはじめとするコンテナベースのサーバーレスプラットフォームに直接関連する。

min instances設定の根拠: 論文のPod Utility Ratio分析は、Cloud Runのmin_instance_countパラメータの適切な値を決定する際の定量的根拠となる。Ratio 1未満のインスタンスが20%存在するという知見は、min instancesを設定しないまま運用した場合に、全リクエストの相当割合がコールドスタートの影響を受けることを示唆している。

Startup CPU Boost: 論文でPod割り当て時間がボトルネックとなるリージョンが報告されているように、コンテナの初期化フェーズにCPUリソースを集中させるCloud RunのStartup CPU Boost機能は、$T_{\text{pod_alloc}}$ と $T_{\text{code_deploy}}$ の短縮に寄与すると考えられる。

マルチリージョン展開: 論文が示すリージョン間のピーク時間差と、データセンター間レイテンシがコールドスタート時間に比べて十分小さいという知見は、Cloud Runのマルチリージョンデプロイによる負荷分散の有効性を裏付けている。特に、60-90%のユーザーが単一関数のみをデプロイしているという報告は、リージョン間移行の実現可能性を示している。

関連研究

以下は、本論文で引用・比較されている主要な関連研究である。

  • Shahrad et al. (2020) “Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider” (USENIX ATC ‘20): Azure Functionsのワークロードトレースを公開・分析した先駆的研究。本論文はこれをプラットフォーム内部からの分析で拡張している
  • Li et al. (2022) “Help Rather Than Recycle: Alleviating Cold Startup in Serverless Computing Through Inter-Function Container Sharing” (USENIX ATC ‘22): 関数間でコンテナを共有することでコールドスタートを軽減する手法を提案
  • Agache et al. (2020) “Firecracker: Lightweight Virtualization for Serverless Applications” (NSDI ‘20): AWSが開発した軽量マイクロVMで、Lambda・Fargateの基盤技術
  • Oakes et al. (2018) “SOCK: Rapid Task Provisioning with Serverless-Optimized Containers” (USENIX ATC ‘18): サーバーレス向けに最適化されたコンテナプロビジョニング手法
  • Du et al. (2020) “Catalyzer: Sub-millisecond Startup for Serverless Computing with Initialization-less Booting” (ASPLOS ‘20): サンドボックス復元により起動時間をサブミリ秒に短縮する手法

まとめと今後の展望

本論文は、商用サーバーレスプラットフォームの内部データに基づき、コールドスタートの構成要素を定量的に分析した点で大きな意義がある。Pod Utility Ratioという新指標により、コールドスタートの「実質的コスト」を評価する枠組みが提示された。

著者らは今後の研究方向として、クロスリージョンスケジューリングの実装と評価、時系列予測に基づくプリウォーミング手法の開発、および動的keep-alive時間の最適化を挙げている。2025年にはEuroSysで発表されており、サーバーレスプラットフォームの設計・運用に携わる研究者・エンジニア双方にとって、コールドスタート最適化の定量的根拠を提供する重要な研究である。

参考文献

  1. Joosen, A., Hassan, A., Asenov, M., Singh, R., Darlow, L., Wang, J., Deng, Q., & Barker, A. (2024). Serverless Cold Starts and Where to Find Them. arXiv:2410.06145. https://arxiv.org/abs/2410.06145
  2. Shahrad, M., et al. (2020). Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider. USENIX ATC ‘20.
  3. Li, Z., et al. (2022). Help Rather Than Recycle: Alleviating Cold Startup in Serverless Computing Through Inter-Function Container Sharing. USENIX ATC ‘22.
  4. Agache, A., et al. (2020). Firecracker: Lightweight Virtualization for Serverless Applications. NSDI ‘20.
  5. Oakes, E., et al. (2018). SOCK: Rapid Task Provisioning with Serverless-Optimized Containers. USENIX ATC ‘18.
  6. Du, D., et al. (2020). Catalyzer: Sub-millisecond Startup for Serverless Computing with Initialization-less Booting. ASPLOS ‘20.
  7. Wang, L., et al. (2018). Peeking Behind the Curtains of Serverless Platforms. USENIX ATC ‘18.

本記事はAIによって生成されました。内容の正確性については原論文をご確認ください。

blog paper arxiv
serverless cold-start cloud-run faas distributed-systems
この投稿は CC BY 4.0 でライセンスされています。
最近の更新
目次