はじめに
AWS re:Invent 2025 で発表された Lambda Managed Instances（LMI）を触ってみたの２回目の記事です。
今回は Lambda Managed Instances の大きな特徴の一つ、Multi concurrency について検証してみます。
Parallel processing. Multiple invocations can execute simultaneously within the same execution environment, each handled by a different runtime worker.
従来の Lambda Default では、1 つの実行環境で 1 つのリクエストしか処理できません(単一同時実行)
でしたが、Lambda Managed Instances では 1 つの実行環境で複数のリクエストを同時に処理できる模様です。
(https://youtu.be/7mWa2HpCZfg)
今回はこの Multi concurrency について検証してみます！
やってみた！
実際に確認してみるため、以下のような TypeScript コードでテストしてみました。
グローバル変数で実行環境IDを作成し、その他プロセス、スレッドを ID、実行完了時間等を取得するプログラムです。
また同時実行を確認するため 5 秒の wait を入れています。
import {
APIGatewayProxyEvent,
APIGatewayProxyResult,
Context,
} from "aws-lambda";
import { isMainThread, threadId } from "worker_threads";
import { randomUUID } from "crypto";
import { cpus } from "os";
// 実行環境IDをグローバル変数で管理
let EXECUTION_ENVIRONMENT_ID = null;
if (!EXECUTION_ENVIRONMENT_ID) {
EXECUTION_ENVIRONMENT_ID = randomUUID();
}
export const handler = async (
event: APIGatewayProxyEvent,
context: Context
): Promise<APIGatewayProxyResult> => {
// 現在のプロセスIDとスレッド情報を取得
const processId = process.pid;
const nodeThreadId = threadId;
console.log(
`[${EXECUTION_ENVIRONMENT_ID}] Request ${context.awsRequestId} started on Process ${processId}, Thread ${nodeThreadId}`
);
// 5秒間待機
await new Promise((resolve) => setTimeout(resolve, 5000));
console.log(
`[${EXECUTION_ENVIRONMENT_ID}] Request ${context.awsRequestId} completed`
);
return {
statusCode: 200,
headers: {
"Content-Type": "application/json",
},
body: JSON.stringify({
message: "Hello from Lambda Managed Instances",
executionEnvironmentId: EXECUTION_ENVIRONMENT_ID,
processId: processId,
threadId: nodeThreadId,
isMainThread: isMainThread,
timestamp: Date.now(),
}),
};
};
また、１つの実行環境で動作確認をするため、関数スケーリング設定は最小最大実行環境数ともに1にしておきます。
この状態で、aws lambda invokeを利用し、それぞれ3回を同時・順番に実施してみます。
以下それぞれ、Lambda Default と Lambda Managed Instances の実行結果です。
Lambda Default（順次実行）
| リクエスト | プロセス ID | スレッド ID | 実行環境 ID |
|---|---|---|---|
| 1 | 2 | 0 | 0daa0784-954f-4934-b131-34cd41f8efa9 |
| 1 | 2 | 0 | 0daa0784-954f-4934-b131-34cd41f8efa9 |
| 1 | 2 | 0 | 0daa0784-954f-4934-b131-34cd41f8efa9 |
3回とも同じ結果です。
初回の実行で実行環境がプロビジョニングされた後は、同じ環境が利用されている模様です。
プロセス ID は常に2、スレッド ID は0（メインスレッド）での実行です。
Lambda Default（同時実行）
| リクエスト | プロセス ID | スレッド ID | 実行環境 ID |
|---|---|---|---|
| 1 | 2 | 0 | bad28be9-7de7-42c4-8e4c-dea6179c4cda |
| 2 | 2 | 0 | e05f9678-6d17-4048-aab0-2d00ce353b1b |
| 3 | 2 | 0 | fb34f3a3-6ccf-40cb-bec8-c309938ee570 |
1回の呼び出しに5秒間の Wait が入っているため、それぞれ個別の実行環境がプロビジョニングされています。
1つの実行環境では1つの同時実行しかできないという挙動になっていますね。
プロセス ID とスレッド ID に変化はありません。
続いて、Lambda Managed Instancesです。
Lambda Managed Instances（順次実行）
| リクエスト | プロセス ID | スレッド ID | 実行環境 ID |
|---|---|---|---|
| 1 | 14 | 2 | b15d71be-051f-461f-8525-45c39fba48b5 |
| 2 | 14 | 4 | be155a1e-0bc9-4682-b307-c5a94ada59e1 |
| 3 | 14 | 1 | 36e93ce3-fd7b-4372-81bf-6e7e5e3da204 |
3回とも結果が違いますね。
同一の実行環境で、同じプロセス ID 14で動いているものの、別スレッドで動作している模様です。
Lambda Managed Instances（同時実行）
| リクエスト | プロセス ID | スレッド ID | 実行環境 ID |
|---|---|---|---|
| 1 | 14 | 4 | d4133cd0-7c5d-43a3-a160-1f1dc8d6d4c8 |
| 2 | 14 | 1 | 413a1fba-6bb9-41ba-a020-8650ac3bd355 |
| 3 | 14 | 2 | 819bfbcf-b5c3-4fd5-8f9a-0649bae86fa2 |
こちらも同じ挙動です。
もう少し動作確認をしてみます。
同時に20回ほど実行してみて、どのくらいスレッドが利用されるかを確認してみました。
Lambda Managed Instances（20 回同時実行）
| リクエスト | プロセス ID | スレッド ID | 完了時刻 | 実行環境 ID |
|---|---|---|---|---|
| 1 | 14 | 3 | 09:45:30 | 00d516f3... |
| 2 | 14 | 4 | 09:45:30 | 4fc1adba... |
| 3 | 14 | 6 | 09:45:30 | 753725ac... |
| 4 | 14 | 1 | 09:45:30 | b080d2e8... |
| 5 | 14 | 2 | 09:45:30 | 48af8992... |
| 6 | 14 | 8 | 09:45:30 | 4fc7d903... |
| 7 | 14 | 1 | 09:45:30 | b080d2e8... |
| 8 | 14 | 7 | 09:45:30 | aef24a68... |
| 9 | 14 | 5 | 09:45:30 | 3e662ae5... |
| 10 | 14 | 1 | 09:45:30 | b080d2e8... |
| 11 | 14 | 7 | 09:45:30 | aef24a68... |
| 12 | 14 | 2 | 09:45:30 | 48af8992... |
| 13 | 14 | 7 | 09:45:30 | aef24a68... |
| 14 | 14 | 6 | 09:45:30 | 753725ac... |
| 15 | 14 | 8 | 09:45:30 | 4fc7d903... |
| 16 | 14 | 5 | 09:45:30 | 3e662ae5... |
| 17 | 14 | 3 | 09:45:30 | 00d516f3... |
| 18 | 14 | 2 | 09:45:30 | 48af8992... |
| 19 | 14 | 6 | 09:45:30 | 753725ac... |
| 20 | 14 | 4 | 09:45:30 | 4fc1adba... |
全てプロセス ID は 14 ですが、スレッドは1〜8の 8 種類用意されています。
実行環境 ID は同一スレッド ID の場合、同じIDでした。
かつ、完了時刻は全て同じ時間なので、1つのスレッドでも複数の処理を捌いていそうです。
次にこれまで関数スケーリングの最小最大実行環境を1にしていましたが2に変更して動作確認してみます。
Lambda Managed Instances（20 回同時実行 - 実行環境数２）
| リクエスト | プロセス ID | スレッド ID | 完了時刻 | 実行環境 ID |
|---|---|---|---|---|
| 1 | 14 | 2 | 11:21:48 | 5ecc53af... |
| 2 | 14 | 5 | 11:21:48 | 62a5565a... |
| 3 | 14 | 7 | 11:21:48 | 487618fa... |
| 4 | 14 | 2 | 11:21:48 | 18e8b280... |
| 5 | 14 | 1 | 11:21:48 | 3abcc34d... |
| 6 | 14 | 4 | 11:21:48 | 1a6e8a09... |
| 7 | 14 | 6 | 11:21:48 | 752eea3f... |
| 8 | 14 | 7 | 11:21:48 | 83befca3... |
| 9 | 14 | 8 | 11:21:48 | 83616bad... |
| 10 | 14 | 1 | 11:21:48 | 849978be... |
| 11 | 14 | 5 | 11:21:48 | 7cda3a4a... |
| 12 | 14 | 2 | 11:21:48 | 5ecc53af... |
| 13 | 14 | 5 | 11:21:48 | 62a5565a... |
| 14 | 14 | 8 | 11:21:48 | 2c26a9bb... |
| 15 | 14 | 4 | 11:21:48 | 7d66dd2c... |
| 16 | 14 | 3 | 11:21:48 | 942c4d3d... |
| 17 | 14 | 3 | 11:21:48 | 942c4d3d... |
| 18 | 14 | 4 | 11:21:48 | 1a6e8a09... |
| 19 | 14 | 6 | 11:21:48 | b9853833... |
| 20 | 14 | 3 | 11:21:48 | 5c748236... |
PID は同じものの、スレッド ID が2の実行環境 ID が5ecc53af...と18e8b280...の2種類になりました。
おそらく、別実行環境数分同一 PID、スレッド ID の環境が存在していそうです。
少しドキュメントについて調べてみます。
Node.js 環境の実行環境数については以下に記載があり、デフォルトは vCPU あたり 64 の同時が可能みたいです。
The maximum number of concurrent requests which Lambda sends to each execution environment is controlled by the PerExecutionEnvironmentMaxConcurrency setting in the function configuration. This is an optional setting, and the default value varies depending on the runtime. For Node.js runtimes, the default is 64 concurrent requests per vCPU, or you can configure your own value. Lambda automatically adjusts the number of concurrent requests up to the configured maximum based on the capacity of each execution environment to absorb those requests.
現状の環境は メモリ4096MBのlambda を 4:1 の設定で動作させているので、1vCPU で動いているはず。
確かにコンソール上でも64であることを確認できました。
では、この数を超えて実行しようとした場合の挙動も確認してみます。
実行環境あたりの最大同時実行数(PerExecutionEnvironmentMaxConcurrency)
実行環境あたりの最大同時実行数（PerExecutionEnvironmentMaxConcurrency）を5に設定してみます。
Lambda Managed Instances（20 回同時実行 - 実行環境あたりの最大同時実行数=5）
| リクエスト | プロセス ID | スレッド ID | 実行環境 ID |
|---|---|---|---|
| 4 | 14 | 8 | 621afa14... |
| 8 | 14 | 1 | 37bfcb62... |
| 13 | 14 | 5 | 47b436bb... |
| 16 | 14 | 3 | 1443d299... |
| 17 | 14 | 4 | b1528f68... |
20 リクエスト中 5 個のみ成功し、残り 15 個はTooManyRequestsExceptionでスロットリングしていました。
想定通りの動きですね。
まとめ
ということで、一通り Multi concurrency の挙動を確認できたと思います。
コールドスタートの排除、これまでよりも並列度を高く処理できるのはメリットですね。
その一方、セキュリティ観点では Lambda Default 以上に気をつける必要があります。
以下に記載があります。
capacity providers as trust boundaries.とある通り、セキュリティの境界線がキャパシティープロバイダ単位です。
コストは踏えますが、セキュリティ要件が異なるワークロードはそれぞれ別のキャパシティプロバイダ上で動作させる必要がありそうですね。
誰かのお役に立てると幸いです〜。