サーバーレス機能とコールドスタート

1）コールドスタートとは何ですか？

1.中程度の割り当て（コンテナ/マイクロVM、ランタイムローディング）。

2.VPC/ENIプライミング、秘密、ファイル、設定。

3.コードの初期化（モジュールのインポート、データベースへの接続、モデルのロード）。

4.ハンドラの実行。

ウォームスタート（再利用）ステップ1-3をスキップします。コールドスタートの確率は、ダウンタイム後のピーク時に増加し、並列性が向上し、コード/構成の更新が増加します。

2）測定方法と目標（SLO）

メトリクス：'init_duration'（初期化）、'duration_total'、 "share of cold start'、 p95/p99 latency、ダウンタイム後に依存関係に接続するエラー。
テレメトリー除去：プラットフォームログ+独自のラベル（例えば、'contextがある場合は'cold=true/false'）。isColdStart'または静的クロージャ内の独自のフラグ）。
SLO目標（例）：API「ログイン」p95 ≤ 200ミリ秒、コールドシェア≤ 3％；バックグラウンドジョブ-p95 ≤ 1 s。「お金」ルートの場合-分離、より厳格。

3）コールドスタート低減のメインレバー

3.1 Concarrency制御および暖房

Provisioned Concurrency/Min Instances： N暖かい環境を保持します。クリティカルグリップに使用します。
ウォーマー/ウォームアップ：労働者を暖かく保つためのスケジュールされたコール（cron/scheduler）。それを賢明に行う（地域、時間、負荷）。
バーストバッファ：予想されるピーク前に、事前に並行限度を引き上げます。

3.2パッケージと依存関係

Small deploy-artifact： tree-shaking、 '--only prod' dependencies、 layers （AWS Layers） for large libs。
Lazy-init：最初のアクセス時にハンドラ内の重いモジュールをインポートします。ゆっくりと接続を開きます。
ウォームリソース：グローバルスコープのSDK/connectionクライアントをキャッシュして、ウォームスタート時に再利用します。

3.3ネットワークとVPC

プライバシーを必要としない機能のためのVPCなし（そうでなければENI-attachは数百ミリ秒に数十を追加します）。
VPCが必要な場合は、プロバイダのVPCエコノミーモード（ENIプール/最適化）、データベースへのプロキシ（RDS Proxy/Cloud SQL Auth Proxy）、および接続プールを使用します。

3.4言語とランタイム

ノード。js/Go start fastest；Python-通常は高速ですが、大きな輸入に敏感です。Java/。NETは、GraalVM/AOTとプロファイリングなしで重くなります。
JVMについては、SnapStart/CRaC/Graal Nativeを考慮してください。のために。NET-トリムされた自己完結型。

3.5初期化と状態

初期化フック（initフェーズ）に高価な初期化を入れ、リクエストパスには入れません。
ローカル・キャッシュ（TTL）でconfigs/secretsのオンデマンド・ロードを使用します。
ユーザー状態をメモリに保存しないでください。キャッシュ信号/コネクタのみです。

4）コールドスタートの影響を軽減する建築パターン

4.1 Asynchronとキュー

リクエスト→検証→キュー/バス（SQS/PubSub/Queue Storage）→202/Acceptedに応答→バックグラウンドで処理します。
非対話的な操作（支払、レポート、重い計算）のために適した。

4.2プリコンピュート/プリキャッシュ

KV/cache/edgeのトリガー（CRON/events）とストレージによるアクセス/ディレクトリ/フィーチャーフラグの生成。

4.3ファンアウト/ファンイン

長い操作をいくつかの短い関数（Map/Reduce-like）に分割します。

4.4エッジオフロード

最も簡単なチェック（JWT/HMAC、ジオリダイレクト、アンチブート）は、RTTを保存してオリジンをアンロードするためにエッジ（Workers/Functions@Edge）で実行されます。

5）練習： 構成および技術

5.1 AWS Lambda（プロビジョニング+RDSプロキシ）

hcl
Terraform sketch: enable provisioned concurrency on the sales version of the resource "aws_lambda_provisioned_concurrency_config" "api" {
function_name = aws_lambda_function. api. function_name qualifier   = aws_lambda_alias. prod. name provisioned_concurrent_executions = 20
}

RDS Proxy for connection pool "aws_db_proxy" "rds_proxy" {
name          = "pg-proxy"
engine_family     = "POSTGRESQL"
idle_client_timeout  = 1800 require_tls      = true
}

js let pgClient ;//reuse between warm runs let cold = true;

exports. handler = async (event, ctx) => {
const isCold = cold; cold = false;
if (!pgClient) {
const { Client } = await import('pg');     // lazy import pgClient = new Client({ host: process. env. PG_PROXY, ssl: true });
await pgClient. connect();
}
const t0 = Date. now();
const data = await pgClient. query('select 1');
return {
statusCode: 200,
headers: { 'x-cold-start': String(isCold), 'x-elapsed-ms': String(Date. now()-t0) },
body: JSON. stringify({ ok: true })
};
};

5.2 GCPクラウド実行/クラウド機能（最小インスタンス）

yaml
Cloud Run service. yaml apiVersion: serving. knative. dev/v1 kind: Service metadata: { name: api }
spec:
template:
metadata:
annotations:
autoscaling. knative. dev/minScale: "5" # keep warm run containers. googleapis. com/cpu-throttling: "false"
spec:
containerConcurrency: 80 containers:
- image: gcr. io/proj/api:latest env:
- { name: DB_HOST, value: "10. 0. 0. 5" }

5.3 Azure関数（AlwaysOn/PreWarm）

AlwaysOnのプレミアム/弾性プラン;予熱されたインスタンス≥予測p95並行性。

6）タイムアウト、リトリート、締め切り

ヘッダー（'x-deadline-ms'/' grpc-timeout'）に一般的な締め切り（クライアント側）を渡し、関数内の'per-hop timeout'を短縮します。
idempotent操作のみを繰り返します。Idempotency-Keyと重複除外を使用します。
フロントAPI-長距離依存のためのヘッジング（p90以降の重複要求）とサーキットブレーカ。

7）データベース/キャッシュ/シークレットの操作

数千の短い接続の代わりにプール/プロキシ（RDS Proxy/Cloud SQL Proxy/pgBouncer）。
バックグラウンドアップデートでメモリキャッシュ内の短いTTLシークレット+。
キャッシュ（Redis/Memcached/KV）： initに「heavy」ディレクトリをロードしますが、時間制限があります。

8）コード組織とアセンブリ

狭いユースケースのための別のハンドラ；1 「thick」 bundle=long init。
ESBuild/Rollup：未使用を除外し、重要なもののみを結合します。
Layers/Extensions-大きなlibs （OpenSSLモデル、SDK）の場合、プロバイダのキャッシュを再利用します。

9）ピークテストとシミュレーション

「冷たい」の合成が始まります：強制的に最小インスタンスをオフにし、ステップで並列トラフィックを駆動します。
A/B：コールド、p95、接続エラーのシェアをDB/シークレット、コストと比較します。
GameDay：ピーク負荷× 2すべての時間の高さから、ウォームアップオフ。

10）コスト（FinOps）

最小インスタンス/プロビジョニングされた同時通貨コスト-ホットルートのみ有効。
ランタイムの削減：キャッシュ、短いタイムアウト、不要なSDKの回避。
egress（外部APIへの呼び出し）とlogging（ログの量はコールドピークで急速に増加する）を考慮してください。

11） Antipatterns

数十メガバイトの依存関係を持つ1つのモノリシック・ハンドラ。
各コールのデータベースへの必須接続（再利用/プロキシなし）。
すべての関数のためのVPC「念のために」。
長いタイムアウトとブラインドリトリート→「尾」と幻の書き込みオフ。
時計の周りに「すべてが連続して」ウォーミングアップ。
リクエストパスのシークレット初期化（lentice init> 100ms-init/cacheへの転送）。

12） iGaming/Financeの詳細

マネーパス（入金/出金）：プロビジョニング/最小インスタンス、個別のSLO、タイムアウトと繰り返しの厳格な制限（idempotencyは必須です）を保持します。
KYC/PSP：不安定な外部API-キュー+ワーカーでラップ、フロントで-202/ポーリング/webhook。
規制と監査：不変ログ（WORM）、着信イベントログ、'Idempotency-Key'、相関'trace_id'。
データ常駐：地域のアカウント/プロジェクトにPIIを処理する機能を展開します。PIIによるエッジキャッシュはありません。

13） Prod Readinessチェックリスト

• SLI/SLO定義：p95/p99、冷たい分数、ルートターゲット。
• 重要な関数のProvisioned/minインスタンスが有効になります。concarrency予測。
• バンドルを最小限に抑えました。重い面は層に実行されます。lazy-import/initialization。
• SDK/DBクライアントを再利用する。RDS/SQLプロキシが設定されています。接続プール。
• 必要な場合にのみVPC；ENI/プロキシを最適化。マネージャー+ローカルTTLキャッシュによる秘密。
• タイムアウト/締め切り/リトリート：バックオフ+ジッタ；唯一のidempotentリピート。
• 総合的な「冷たい」+負荷テスト；寒さとp99のシェアの成長のためのアラート。
• Runbooks：プロビジョニングを増やす方法、minScaleを変更する方法、劣化を含める方法。
• iGamingの場合：別々のSLO/ダッシュボード「お金の方法」、Idempotency-Key、 WORM監査。

14） TL；DR（ドクター）

コールドスタートは避けられませんが、管理可能です。問題のある暖かいインスタンスを保ち、バンドルを減らし、怠惰なinitを適用して接続を再利用し、不要なVPCを避け、ライン/ワーカーで重い操作を取り出し、簡単なルールにエッジを使用します。重要な財務経路については、SLO、 idempotency、厳格なタイムアウトを分離します。寒さの割合を測定し、それが支払うところだけ温暖化をオンにします。