Lambda プロビジョニング済み同時実行数の管理 - AWS Lambda

Lambda プロビジョニング済み同時実行数の管理

ご利用いただける同時実行コントロールには、次の 2 種類があります。

  • 予約同時実行 – 予約同時実行は、関数の同時インスタンスの最大数を保証します。ある関数が予約済同時実行数を使用している場合、他の関数はその同時実行数を使用できません。関数に対して予約された同時実行を設定する場合には料金はかかりません。

  • プロビジョニング済み同時実行 – プロビジョニング済み同時実行は、リクエストされた数の実行環境を初期化して、関数の呼び出しに即座に応答する準備をします。プロビジョニングされた同時実行を設定すると、AWS アカウントに課金が発生することに注意してください。

このトピックでは、予約およびプロビジョニングされた同時実行数を管理および設定する方法について説明します。予約された同時実行数を設定する場合は、「Lambda の予約済み同時実行数の管理」を参照してください。

Lambda が関数のインスタンスを割り当てると、ランタイムは関数のコードをロードし、ハンドラの外部で定義された初期化コードを実行します。コードと依存関係が大きい場合、または初期化中に SDK クライアントを作成する場合、このプロセスには時間がかかることがあります。関数がしばらく使用されていない場合、スケールアップする必要がある場合、または更新する場合、Lambda は新しい実行環境を作成します。これにより、新しいインスタンスによって処理されるリクエストの部分は、残りの部分よりもレイテンシーが長くなります。これはコールドスタートと呼ばれています。

呼び出しの増加前にプロビジョニングされた同時実行数を割り当てることにより、すべてのリクエストが、短いレイテンシーで、初期化されたインスタンスによって処理されるようにできます。プロビジョニングされた同時実行で設定された Lambda 関数は、一貫性のあるスタートアップレイテンシーで実行されるため、インタラクティブなモバイルまたはウェブバックエンド、レイテンシーの影響を受けやすいマイクロサービス、同期的に呼び出される API の構築に最適です。

注記

プロビジョニングされた同時実行数は、関数の予約済み同時実行数とリージョンのクォータにカウントされます。関数のバージョンとエイリアスに割り当てたプロビジョニングされた同時実行数が、関数の予約済同時実行数に達すると、すべての呼び出しはプロビジョニングされた同時実行数を使用して実行されます。この設定には、非公開バージョンの関数 ($LATEST) をスロットリングする効果もあるため、その関数は実行されません。関数に対し、予約済同時実行数よりも多くのプロビジョニングされた同時実行を割り当てることはできません。

Lambda は Application Auto Scaling と統合するので、スケジュールに従って、または使用率に基づいて、プロビジョニングされた同時実行数を管理できます。

プロビジョニングされた同時実行数の設定

バージョンまたはエイリアスのプロビジョニング済み同時実行の設定を管理するには、Lambda コンソールを使用します。プロビジョニングされた同時実行数は関数のバージョンまたはエイリアスに割り当てることができます。

関数の各バージョンには、プロビジョニングされた同時実行数の設定を 1 つのみ割り当てることができます。この設定は、バージョン自体に直接割り当てることも、バージョンを参照するエイリアスに割り当てることもできます。2 つのエイリアスに、同じバージョンのプロビジョニングされた同時実行数を割り当てることはできません。

エイリアスが示すバージョンを変更すると、Lambda はプロビジョニングされた同時実行数の古いバージョンから割り当てを解除し、新しいバージョンに割り当てます。プロビジョニングされた同時実行数を割り当てたエイリアスにルーティング設定を追加できます。詳細については、「Lambda 関数エイリアス」を参照してください。ルーティング設定が有効になっている間は、エイリアスのプロビジョニングされた同時実行設定を管理できないことに注意してください。

注記

プロビジョニング済み同時実行数は、関数の未公開バージョン ($LATEST) ではサポートされていません。プロビジョニングされた同時実行を構成する前に、クライアントアプリケーションが $LATEST を示していないことを確認してください。

プロビジョニングされた同時実行数をエイリアスまたはバージョンに割り当てるには

  1. Lambda コンソールの [Functions] (関数) ページを開きます。

  2. 関数を選択します。

  3. [設定]、[同時実行] の順にクリックします。

  4. [プロビジョニングされた同時実行設定] で、[追加] をクリックします。

  5. エイリアスまたはバージョンを選択します。

  6. 割り当てるプロビジョニングされた同時実行数を入力します。

  7. [Save] を選択します。

以下のオペレーションで Lambda API を使用してプロビジョニングされた同時実行を設定することもできます。

プロビジョニングされた同時実行数を関数に割り当てるには、put-provisioned-concurrency-config を使用します。以下のコマンドは、BLUE という名前の関数の my-function エイリアスに 100 の同時実行数を割り当てます。

aws lambda put-provisioned-concurrency-config --function-name my-function \ --qualifier BLUE --provisioned-concurrent-executions 100

次のような出力が表示されます。

{ "Requested ProvisionedConcurrentExecutions": 100, "Allocated ProvisionedConcurrentExecutions": 0, "Status": "IN_PROGRESS", "LastModified": "2019-11-21T19:32:12+0000" }

リージョンのアカウントの同時実行数クォータを表示するには、get-account-settings を使用します。

aws lambda get-account-settings

次のような出力が表示されます。

{ "AccountLimit": { "TotalCodeSize": 80530636800, "CodeSizeUnzipped": 262144000, "CodeSizeZipped": 52428800, "ConcurrentExecutions": 1000, "UnreservedConcurrentExecutions": 900 }, "AccountUsage": { "TotalCodeSize": 174913095, "FunctionCount": 52 } }

関数の設定ページから、すべてのエイリアスとバージョンのプロビジョニングされた同時実行数を管理できます。プロビジョニングされた同時実行数の設定のリストには、各設定の割り当ての進捗状況が表示されます。プロビジョニングされた同時実行数の設定は、各バージョンおよびエイリアスの設定ページでも利用できます。

Lambda から、プロビジョニング済み同時実行について以下のメトリクスが出力されます。

プロビジョニングされた同時実行数のメトリクス

  • ProvisionedConcurrentExecutions – プロビジョニング済み同時実行数によりイベントを処理している関数インスタンスの数。プロビジョニングされた同時実行数を割り当てたエイリアスまたはバージョンの呼び出しごとに、Lambda は現在のカウントを出力します。

  • ProvisionedConcurrencyInvocations – プロビジョニング済み同時実行数により関数コードが実行される回数。

  • ProvisionedConcurrencySpilloverInvocations - プロビジョニングされたすべての同時実行が使用されているときに、標準同時実行で関数コードが実行される回数。

  • ProvisionedConcurrencyUtilization - バージョンまたはエイリアスの場合、ProvisionedConcurrentExecutions の値を、割り当て済みのプロビジョニングされた同時実行の合計量で割った値。たとえば、5 は、割り当て済みのプロビジョニングされた同時実行数の 50% が使用中であることを示します。

詳細については、「Lambda 関数のメトリクスの使用」をご参照ください。

プロビジョニングされた同時実行数でのレイテンシの最適化

プロビジョニング済み同時実行は、設定後すぐにはオンラインになりません。Lambda は、1~2 分の準備後に、プロビジョニング済み同時実行の割り当てをスタートします。関数の負荷時のスケーリング方法と同様に、リージョンに応じて、関数の最大 3000 インスタンスを一度に初期化できます。最初のバーストの後、リクエストが受理されるまで、インスタンスは 1 分あたり 500 という一定のレートで割り当てられます。同じリージョン内の複数の関数または関数のバージョンに対してプロビジョニングされた同時実行数をリクエストするとき、スケーリングクォータはすべてのリクエストに適用されます。


      プロビジョニングされた同時実行数によるスケーリング。

凡例

  • 関数のインスタンス数

  • 未処理のリクエスト数

  • プロビジョニング済み同時実行

  • 標準の同時実行数

プロビジョニングされた同時実行が使用される関数で、その初期化動作をカスタマイズすることで、レイテンシーを最適化できます。初期化コードは割り当てが行われる際に実行されます。したがって、このコードをプロビジョニングされた同時実行インスタンスで実行しても、レイテンシーには影響を与えません。ただし、オンデマンドインスタンスでは、その最初の呼び出しの際に、初期化コードがレイテンシーに直接的な影響を与えます。オンデマンドインスタンスの場合には、特定の機能のための初期化処理を、関数がその機能を必要とするまで延期することができます。

初期化のタイプを決定するには、AWS_LAMBDA_INITIALIZATION_TYPE の値をチェックします。Lambda はこの環境変数を provisioned-concurrency または on-demand に設定します。AWS_LAMBDA_INITIALIZATION_TYPE の値は不変であり、実行環境のライフタイムにわたって変更されません。

.NET 3.1 ランタイムをご使用の場合には、環境変数 AWS_LAMBDA_DOTNET_PREJIT の設定により、プロビジョニングされた同時実行を使用する関数の、レイテンシーを向上させることができます。.NET ランタイムでは、コードが使用する各ライブラリのコンパイルと初期化が、そのライブラリに対する最初の呼び出しまで延期されます。その結果、Lambda 関数に対する最初の呼び出しが、その後の呼び出しよりも長くかかる場合があります。AWS_LAMBDA_DOTNET_PREJIT を ProvisionedConcurrency に設定した場合、Lambda は、システムの一般的な依存関係のための事前 JIT コンパイルを実行します。Lambda は、プロビジョニング済み同時実行インスタンスに対してのみ、この初期化の最適化を実行します。これにより、最初の呼び出し時のパフォーマンスが高速化されます。この環境変数を Always に設定した場合、Lambda は初期化のたびに事前 JIT コンパイルを実行します。この環境変数を Never に設定した場合には、事前の JIT コンパイルは無効になります。AWS_LAMBDA_DOTNET_PREJIT のデフォルト値は ProvisionedConcurrency です。

プロビジョニングされた同時実行をご使用の場合、関数の実行インスタンスがリサイクルされるため、関数の初期化コードは、割り当て時とその後の数時間ごとに実行されるようになります。インスタンスでリクエストが処理された後、ログとトレースで初期化時間を確認できます。ただし、インスタンスでリクエストが処理されない場合でも、初期化の料金は発生します。関数はプロビジョニングされた同時実行数で継続的に実行され、初期化および呼び出しのコストとは別に料金が発生します。詳細については、「AWS Lambda 料金表」を参照してください。

プロビジョニングされた同時実行を使用した関数の最適化の詳細については、Lambda オペレータガイドを参照してください。

Application Auto Scaling でのプロビジョニングされた同時実行数の管理

Application Auto Scaling を使用すると、スケジュールに従って、または使用率に基づいて、プロビジョニングされた同時実行を管理できます。関数で指定された使用率を維持したい場合は、ターゲット追跡スケーリングポリシーを使用し、ピークトラフィックを見越してスケジュールされたスケーリングを使用して、プロビジョニングされた同時実行数を増やします。

ターゲット追跡

ターゲット追跡では、アプリケーション Auto Scaling がスケーリングポリシーをトリガーする CloudWatch アラームを作成および管理し、ユーザーが定義するメトリクスとターゲット値に基づいてスケーリング調整値を計算します。これは、トラフィックが増加するスケジュールされた時間を持たず、特定のトラフィックパターンを持つアプリケーションに最適です。

必要に応じてプロビジョニングされた同時実行数を自動的に増やすには、RegisterScalableTargetおよびPutScalingPolicyアプリケーション Auto Scaling API のオペレーションを使用してターゲットを登録し、スケーリングポリシーを作成します。

  1. 関数のエイリアスをスケーリングターゲットとして登録します。次の例では、my-function という名前の関数の BLUE エイリアスを登録します。

    aws application-autoscaling register-scalable-target --service-namespace lambda \ --resource-id function:my-function:BLUE --min-capacity 1 --max-capacity 100 \ --scalable-dimension lambda:function:ProvisionedConcurrency
  2. スケーリングポリシーをターゲットに適用します。次の例では、エイリアスのプロビジョニング済み同時実行数の設定を調整して使用率が 70% 近くを維持するように Application Auto Scaling を設定します。

    aws application-autoscaling put-scaling-policy --service-namespace lambda \ --scalable-dimension lambda:function:ProvisionedConcurrency --resource-id function:my-function:BLUE \ --policy-name my-policy --policy-type TargetTrackingScaling \ --target-tracking-scaling-policy-configuration '{ "TargetValue": 0.7, "PredefinedMetricSpecification": { "PredefinedMetricType": "LambdaProvisionedConcurrencyUtilization" }}'

    次のような出力が表示されます。

    { "PolicyARN": "arn:aws:autoscaling:us-east-2:123456789012:scalingPolicy:12266dbb-1524-xmpl-a64e-9a0a34b996fa:resource/lambda/function:my-function:BLUE:policyName/my-policy", "Alarms": [ { "AlarmName": "TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7", "AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7" }, { "AlarmName": "TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66", "AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66" } ] }

Application Auto Scaling は CloudWatch に 2 つのアラームを作成します。最初のアラームは、プロビジョニング済み同時実行の使用率が一貫して 70% を超えたときにトリガーされます。この場合、Application Auto Scaling はプロビジョニング済み同時実行の割り当て数を増やして、使用率を下げます。2 番目のアラームは、使用率が一貫して 63% (70% ターゲットの 90%) を下回った場合にトリガーされます。これにより、Application Auto Scaling はエイリアスのプロビジョニング済み同時実行を減らします。

次の例では、関数は使用率に基づいて、プロビジョニングされた同時実行数の最小値と最大値の間でスケーリングします。オープンリクエストの数が増加すると、Application Auto Scaling は、設定された最大値に達するまで、プロビジョニングされた同時実行数を大規模なステップで増加させます。この関数は、使用率が低下し始めるまで、標準の同時実行数に基づいてスケーリングを継続します。使用率が一貫して低い場合、Application Auto Scaling は、より小さな定期的ステップで、プロビジョニングされた同時実行数を減少させます。


      Application Auto Scaling ターゲット追跡でプロビジョニングされた同時実行数をオートスケーリングします。

凡例

  • 関数のインスタンス数

  • 未処理のリクエスト数

  • プロビジョニング済み同時実行

  • 標準の同時実行数

これらのアラームはどちらも、デフォルトの平均統計を使用します。クイックバーストのトラフィックパターンを持つ関数は、プロビジョニングされた同時実行をトリガーしてスケールアップしない可能性があります。たとえば、Lambda 関数がすばやく (20~100 ミリ秒) 実行され、トラフィックパターンがクイックバーストになると、バースト中に着信リクエストが、割り当て済みのプロビジョニングされた同時実行を超える可能性がありますが、バーストが 3 分間継続しない場合、Auto Scaling はトリガーされません。さらに、CloudWatch がターゲット平均をヒットする 3 つのデータポイントを取得しない場合、Auto Scaling ポリシーはトリガーされません。

スケーリングポリシーがトリガーされず、プロビジョニングされた同時実行がスケーリングされない場合は、アラームがトリガーされたことをチェックします。トリガーされていない場合は、カスタムの CloudWatch アラームセットで関数をデプロイし、最大統計を使用します。

ターゲット追跡スケーリングポリシーの詳細については、アプリケーション Auto Scaling のターゲット追跡スケーリングポリシーを参照してください。

スケジュールされたスケーリング

スケジュールに基づいたスケーリングにより、予想可能な負荷の変化に従って独自のスケーリングスケジュールを設定できます。詳細と例については、Scheduling AWS Lambda Provisioned Concurrency for recurring peak usage を参照してください。