# Lambda マネージドインスタンスのスケーリング
Lambda マネージドインスタンスは、呼び出しの到着時はスケーリングされず、コールドスタートをサポートしません。代わりに、リソース消費シグナルを使用して非同期的にスケーリングします。マネージドインスタンスは現在、CPU リソースの使用率と同時実行数の飽和度に基づいてスケーリングされます。
**主な相違点:**
+ **Lambda (デフォルト):** 着信呼び出しを処理する空き実行環境がない場合にスケーリングする (コールドスタート)
+ **Lambda マネージドインスタンス:** CPU リソース使用率と実行環境の同時実行数の飽和に基づいて非同期的にスケーリングする
トラフィックが 5 分以内に 2 倍を超えると、Lambda が需要に合わせてインスタンスと実行環境をスケールアップするため、スロットリングが表示される場合があります。
## スケーリングライフサイクル
Lambda マネージドインスタンスは、分散アーキテクチャを使用してスケーリングを管理します。
**コンポーネント:**
+ **マネージドインスタンス** – 指定したサブネットのアカウントで実行されます
+ **ルーターおよびスケーラー** – 呼び出しをルーティングし、スケーリングを管理する共有 Lambda コンポーネント
+ **Lambda エージェント** – 各マネージドインスタンスで実行され、実行環境のライフサイクルを管理し、リソースの消費量をモニタリングします
**仕組み:**
1. キャパシティープロバイダーで関数バージョンを発行すると、Lambda はユーザーのアカウントでマネージドインスタンスを起動します。AZ の回復性のためにデフォルトで 3 つ起動され、実行環境が 3 つ開始されると関数バージョンが「ACTIVE」にマークされます。
1. 各マネージドインスタンスは、同じキャパシティープロバイダーにマッピングされた複数の関数の実行環境を実行できます。
1. トラフィックがアプリケーションに流れると、実行環境はリソースを消費します。Lambda エージェントはスケーラーに通知し、新しい実行環境とマネージドインスタンスのどちらをスケーリングするかを決定します。
1. ルーターがリソース消費量の多い実行環境に呼び出しを送信しようとすると、そのインスタンスの Lambda エージェントが別のインスタンスで再試行するよう通知します。
1. トラフィックが減少すると、Lambda エージェントはスケーラーに通知し、実行環境のスケールダウンとマネージドインスタンスのスケールインを決定します。
## スケーリング動作の調整
マネージドインスタンスのスケーリング動作は、次の 5 つのコントロールでカスタマイズできます。
### 関数レベルのコントロール
#### 1. 関数メモリと vCPU
関数のメモリサイズと vCPU 割り当てを選択します。サポートされる関数の最小サイズは 2GB と 1vCPU です。
**考慮事項**:
+ 関数の複数同時実行をサポートするメモリと vCPU 設定を選択してください
+ マネージドインスタンスで実行される関数は複数同時ワークロードをサポートしている必要があるため、1 vCPU 未満の関数を設定することはできません
+ 2GB 未満を選択することはできません。これは、c インスタンスのメモリと vCPU のメモリ比率 (2 対 1) と一致するためであり、c インスタンスの比率は最も低くなっています
+ Python アプリケーションの場合、Python は複数同時実行を処理するため、メモリと vCPU の比率は 4 対 1 または 8 対 1 などの高比率を選択する必要がある場合があります。
+ CPU 負荷が高いオペレーションを実行している場合、またはほとんど IO を実行していない場合は、複数の vCPU を選択する必要があります。
#### 2. 最大同時実行数
実行環境あたりの最大同時実行数を設定します。
**デフォルトの動作:** Lambda では、さまざまなアプリケーションで動作するリソースの消費とスループットとのバランスをとる適切なデフォルトが選択されます。
**調整ガイドライン:**
+ **同時実行数を増やす:** 関数呼び出しで使用する CPU が非常に少ない場合は、vCPU あたり最大 64 まで同時実行数を増やすことができます
+ **同時実行数を減らす:** アプリケーションが大量のメモリを消費し、CPU が非常に少ない場合は、最大同時実行数を減らすことができます
**重要:** Lambda マネージドインスタンスは複数同時実行アプリケーションを対象としているため、同時実行が非常に低い実行環境では、スケーリング時にスロットリングが発生する場合があります。同時実行数の制限に達した実行環境に呼び出しが到着すると、Lambda はそれらの呼び出しを他の場所にルーティングし、負荷を処理するために新しい実行環境をスケールアウトします。スロットルの原因となっているリソース制約を特定するには、「[Lambda 関数のメトリクスのタイプ](monitoring-metrics-types.md)」で説明されているスロットル理由メトリクス (`ConcurrencyThrottles`、`CPUThrottles`、`MemoryThrottles`、`DiskThrottles`) をモニタリングします。
#### 3. 関数あたりの実行環境
関数の実行環境の最小数と最大数を設定します。
**デフォルトの動作:** デフォルトの最小実行環境はアベイラビリティーゾーン全体で 3 つです。デフォルトの最大実行環境はありません。関数の作成後に両方の値を上書きできます。
**調整ガイドライン:**
+ **最小設定:** ベースライントラフィックのキャパシティをプロビジョニングし、突然のバースト時にスロットリングを減らします。値が 3 を下回ると、アベイラビリティーゾーンの冗長性が低下します。
+ **最大値を設定する:** スケールアウトを制御し、複数の関数がキャパシティプロバイダーを共有するときにノイズの多いネイバーの問題を防ぐため、実行環境の数を制限します。
+ **関数を非アクティブ化する:** 最小と最大の両方を 0 に設定して、関数を削除せずに非アクティブ化します。
**例:**
```
aws lambda put-function-scaling-config \
--function-name my-lmi-function \
--qualifier '$LATEST.PUBLISHED' \
--function-scaling-config MinExecutionEnvironments=5,MaxExecutionEnvironments=20 \
--region us-east-1
```
**重要な注意事項:**
+ **修飾スコープ:** これらの設定は、修飾された ARN ごとに関数レベルに適用されます。`$LATEST.PUBLISHED` に設定すると、設定は将来の `$LATEST.PUBLISHED` バージョンに反映されます。特定のバージョンに設定すると、新しく公開されたバージョンはデフォルト値に戻ります。
+ **ペア設定:** 最小値と最大値の両方を一緒に設定する必要があります。指定されていない設定はデフォルト値に戻ります。`MinExecutionEnvironments` と `MaxExecutionEnvironments` の両方の有効な値は 0～15000 です。最小値 0 は、最大値も 0 の場合にのみ有効となります。
+ **コストへの影響:** 関数の非アクティブ化は、関数バージョンレベルで有効になります。アクティブな実行環境がない場合、Lambda は基盤となる EC2 インスタンスを終了し、インスタンスの料金は終了が完了するまで (通常は数分以内に) 継続します。
### キャパシティープロバイダーレベルのコントロール
#### 4. ターゲットのリソース使用率
CPU 使用率消費の独自のターゲットを選択します。
**デフォルトの動作:** Lambda では、スロットリングなしで 5 分以内にトラフィックを倍増させるのに十分なヘッドルームが。保持されます。
**最適化オプション:**
+ ワークロードが非常に安定している場合、またはアプリケーションがスロットリングの影響を受けにくい場合は、ターゲットを高レベルに設定して使用率を高め、コストを削減できます
+ トラフィックのバーストに備えてヘッドルームを維持する場合は、リソースターゲットを低レベルに設定できますが、より多くの容量が必要です
#### 5. インスタンスタイプの選択
許可または除外されたインスタンスタイプを設定します。
**デフォルトの動作:** Lambda ではワークロードに最適なインスタンスタイプが選択されます。利用可能なインスタンスタイプの数を制限すると可用性が低下する場合があるため、Lambda マネージドインスタンスが選択したインスタンスタイプを使用することをお勧めします。
**カスタム設定:**
+ **特定のハードウェア要件:** 許可されたインスタンスタイプを互換性のあるインスタンスのリストに設定します。たとえば、高いネットワーク帯域幅を必要とするアプリケーションがある場合、複数の n インスタンスタイプを選択できます
+ **コストの最適化:** テスト環境または開発環境では、m7a.large インスタンスタイプなど、より小さなインスタンスタイプを選択できます
## スケジュールに基づくスケーリング
[Amazon EventBridge スケジューラー](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html)を使用して、定期的なスケジュールまたは 1 回限りのスケジュールで関数の最小実行環境と最大実行環境を調整します。これは、ピーク時間前にスケールアップしたり、オフピーク時間中にスケールダウンしたりするなど、予測可能なトラフィックパターンに役立ちます。
**スケジューラーの設定:**
+ EventBridge スケジューラー実行ロールを作成するか、ターゲット関数で `lambda:PutFunctionScalingConfig` を呼び出すアクセス許可を付与する既存のロールを使用します。
+ cron 式または rate 式を使用してスケジュールを作成し、`PutFunctionScalingConfig` API をユニバーサルターゲットとしてターゲットにします。入力ペイロードで新しい `MinExecutionEnvironments` と `MaxExecutionEnvironments` の値を指定します。
**例 1: 計画されたピークトラフィックを処理するようにスケールする**
ピーク時間前にスケールアップし、その後スケールダウンする 2 つのスケジュールを作成します。各スケジュールは、更新された `MinExecutionEnvironments` および `MaxExecutionEnvironments` 値を持つ `PutFunctionScalingConfig` API を対象としています。
UTC 午前 8 時にスケールアップします (最小 = 100、最大 = 1000)。
```
aws scheduler create-schedule \
--name "ScaleUpLambdaManagedInstances" \
--schedule-expression "cron(0 8 * * ? *)" \
--flexible-time-window '{"Mode": "OFF"}' \
--target '{
"Arn": "arn:aws:scheduler:::aws-sdk:lambda:PutFunctionScalingConfig",
"RoleArn": "arn:aws:iam:::role/eventbridge-scheduler-role",
"Input": "{\"FunctionName\": \"my-lmi-function\", \"Qualifier\": \"$LATEST.PUBLISHED\", \"FunctionScalingConfig\": {\"MinExecutionEnvironments\": 100, \"MaxExecutionEnvironments\": 1000}}"
}'
```
UTC 午後 6 時にスケールダウンします (最小 = 5、最大 = 20)。
```
aws scheduler create-schedule \
--name "ScaleDownLambdaManagedInstances" \
--schedule-expression "cron(0 18 * * ? *)" \
--flexible-time-window '{"Mode": "OFF"}' \
--target '{
"Arn": "arn:aws:scheduler:::aws-sdk:lambda:PutFunctionScalingConfig",
"RoleArn": "arn:aws:iam:::role/eventbridge-scheduler-role",
"Input": "{\"FunctionName\": \"my-lmi-function\", \"Qualifier\": \"$LATEST.PUBLISHED\", \"FunctionScalingConfig\": {\"MinExecutionEnvironments\": 5, \"MaxExecutionEnvironments\": 20}}"
}'
```
**例 2: オフピーク時に非アクティブ化し、再度アクティブ化する**
`MinExecutionEnvironments` と `MaxExecutionEnvironments` の両方を 0 に設定すると、関数バージョンは削除されずに非アクティブ化されます。非アクティブ化された関数は、トラフィックで自動的にスケールアップされません。別のスケジュールされたアクションを通じてゼロ以外の値を設定して、明示的に再アクティブ化する必要があります。
UTC 午後 10 時に非アクティブ化します (最小 = 0、最大 = 0)。
```
aws scheduler create-schedule \
--name "DeactivateLambdaManagedInstances" \
--schedule-expression "cron(0 22 * * ? *)" \
--flexible-time-window '{"Mode": "OFF"}' \
--target '{
"Arn": "arn:aws:scheduler:::aws-sdk:lambda:PutFunctionScalingConfig",
"RoleArn": "arn:aws:iam:::role/eventbridge-scheduler-role",
"Input": "{\"FunctionName\": \"my-lmi-function\", \"Qualifier\": \"$LATEST.PUBLISHED\", \"FunctionScalingConfig\": {\"MinExecutionEnvironments\": 0, \"MaxExecutionEnvironments\": 0}}"
}'
```
UTC 午前 7 時に再アクティブ化します (最小 = 10、最大 = 20)。
```
aws scheduler create-schedule \
--name "ReactivateLambdaManagedInstances" \
--schedule-expression "cron(0 7 * * ? *)" \
--flexible-time-window '{"Mode": "OFF"}' \
--target '{
"Arn": "arn:aws:scheduler:::aws-sdk:lambda:PutFunctionScalingConfig",
"RoleArn": "arn:aws:iam:::role/eventbridge-scheduler-role",
"Input": "{\"FunctionName\": \"my-lmi-function\", \"Qualifier\": \"$LATEST.PUBLISHED\", \"FunctionScalingConfig\": {\"MinExecutionEnvironments\": 10, \"MaxExecutionEnvironments\": 20}}"
}'
```
**調整ガイドライン:**
+ 予測可能なピークがあるワークロードの場合、トラフィックパターンに合わせて複数のスケジュールを作成します。1 つはピーク時間前に関数をスケールアップし、もう 1 つはピーク時間後にスケールダウンします。各スケジュールは、更新された `MinExecutionEnvironments` 値と `MaxExecutionEnvironments` 値で同じパターンに従います。
+ スケジュールされたスケーリングは、実行環境のプロビジョニングされた床と上限を調整しますが、最小と最大の間の実際のスケーリングは引き続き CPU 使用率と同時実行飽和に応答します。
+ スケジュールされたスケールアップから 5 分以内にトラフィックが 2 倍以上になった場合でも、キャパシティがプロビジョニングされるとスロットリングが発生する可能性があります。
+ ゼロにスケーリングして関数を非アクティブ化する場合、再アクティブ化にはゼロ以外の値を持つ明示的な `PutFunctionScalingConfig` 呼び出しが必要であることに注意してください。
## 次のステップ
+ 「[Lambda マネージドインスタンスのキャパシティプロバイダー](lambda-managed-instances-capacity-providers.md)」について説明する
+ 複数同時実行を処理するためのランタイム固有のガイドを確認する
+ [キャパシティープロバイダーの VPC 接続](lambda-managed-instances-networking.md)を設定する
+ スケーリングメトリクスをモニタリングしてスケーリング動作を最適化する