同時実行のモニタリング - AWS Lambda
一般的な同時実行メトリクスプロビジョニングされた同時実行数のメトリクスClaimedAccountConcurrency メトリクスの処理

同時実行のモニタリング

Lambda は、関数の同時実行のモニタリングに役立つ Amazon CloudWatch メトリクスを出力します。このトピックでは、これらのメトリクスとその解釈方法について説明します。

一般的な同時実行メトリクス

Lambda 関数の同時実行のモニタリングには、以下のメトリクスを使用します。各メトリクスの詳細度は 1 分です。

  • ConcurrentExecutions - 特定時点のアクティブな同時実行呼び出し数。Lambda は、このメトリクスをすべての関数、バージョン、エイリアスに対して出力します。Lambda コンソールのどの関数であっても、Lambda は [モニタリング] タブの [メトリクス] に ConcurrentExecutions のグラフをネイティブに表示します。MAX を使用してこのメトリクスを表示します。

  • UnreservedConcurrentExecutions – 予約されていない同時実行を使用している、アクティブな同時呼び出しの数。Lambda は、リージョン内のすべての関数にこのメトリクスを出力します。MAX を使用してこのメトリクスを表示します。

  • ClaimedAccountConcurrency — オンデマンド呼び出しでは使用できない同時実行の量。ClaimedAccountConcurrency は、UnreservedConcurrentExecutions に割り当てられた同時実行数を加えたものに等しくなります (つまり、予約された同時実行数の合計にプロビジョニングされた同時実行数の合計を加えたもの)。ClaimedAccountConcurrency がアカウントの同時実行数の制限を超える場合は、アカウントの同時実行数の上限を引き上げるようにリクエストできます。MAX を使用してこのメトリクスを表示します。詳細については、「ClaimedAccountConcurrency メトリクスの処理」を参照してください。

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

プロビジョニングされた同時実行を使用する Lambda 関数のモニタリングには、以下のメトリクスを使用します。各メトリクスの詳細度は 1 分です。

  • ProvisionedConcurrentExecutions – プロビジョニングされた同時実行で呼び出しをアクティブに処理している実行環境インスタンスの数。Lambda は、プロビジョニングされた同時実行が設定された関数バージョンとエイリアスごとにこのメトリクスを出力します。MAX を使用してこのメトリクスを表示します。

ProvisionedConcurrentExecutions は、割り当てるプロビジョニングされた同時実行の合計数と同じではありません。例えば、100 ユニットのプロビジョニングされた同時実行を関数バージョンに割り当てるとします。任意の 1 分間で、100 個の実行環境のうち最大 50 個が同時に呼び出しを処理していた場合、MAX (ProvisionedConcurrentExecutions) の値は 50 になります。

  • ProvisionedConcurrencyInvocations – Lambda がプロビジョニングされた同時実行を使用して関数コードを呼び出す回数。Lambda は、プロビジョニングされた同時実行が設定された関数バージョンとエイリアスごとにこのメトリクスを出力します。SUM を使用してこのメトリクスを表示します。

ProvisionedConcurrencyInvocations は呼び出しの総数をカウントしますが、ProvisionedConcurrentExecutions はアクティブな環境の数をカウントするという点で、ProvisionedConcurrencyInvocations は ProvisionedConcurrentExecutions と異なります。この違いを理解するために、次のシナリオを考えてみます。

ProvisionedConcurrencyInvocations と ProvisionedConcurrentExecutions の比較。

この例では、1 分あたり 1 回の呼び出しを受け取り、各呼び出しの完了までに 2 分かかるとします。オレンジ色の横棒はそれぞれ 1 つのリクエストを表します。この関数に 10 ユニットのプロビジョニングされた同時実行を割り当て、各リクエストがプロビジョニングされた同時実行で実行されるとします。

0 分と 1 分の間に Request 1 が入ります。1 分の時点では、それまでの 1 分間でアクティブだった実行環境は最大 1 つなので、MAX (ProvisionedConcurrentExecutions) の値は 1 です。それまでの 1 分間に入った新しいリクエストは 1 件だったため、SUM (ProvisionedConcurrencyInvocations) の値も 1 です。

1 分から 2 分の間に Request 2 が入り、Request 1 は実行し続けます。2 分の時点では、それまでの 1 分間でアクティブだった実行環境は最大 2 つなので、MAX (ProvisionedConcurrentExecutions) の値は 2 です。ただし、それまでの 1 分間に入った新しいリクエストは 1 件のみだったため、SUM (ProvisionedConcurrencyInvocations) の値は 1 です。このメトリクスの動作は、この例の終わりまで継続します。

  • ProvisionedConcurrencySpilloverInvocations – プロビジョニングされた同時実行がすべて使用されているときに、Lambda が標準的な同時実行 (予約された同時実行または予約されていない同時実行) で関数を呼び出す回数。Lambda は、プロビジョニングされた同時実行が設定された関数バージョンとエイリアスごとにこのメトリクスを出力します。SUM を使用してこのメトリクスを表示します。ProvisionedConcurrencyInvocations + ProvisionedConcurrencySpilloverInvocations の値は、関数呼び出しの総数 (Invocations メトリクス) と一致するはずです。

    ProvisionedConcurrencyUtilization - 使用中のプロビジョニングされた同時実行の割合 (ProvisionedConcurrentExecutions をプロビジョニングされた割り当て同時実行の合計量で割った値)。Lambda は、プロビジョニングされた同時実行が設定された関数バージョンとエイリアスごとにこのメトリクスを出力します。MAX を使用してこのメトリクスを表示します。

例えば、100 ユニットのプロビジョニングされた同時実行を関数バージョンにプロビジョニングするとします。任意の 1 分間で、100 個の実行環境のうち最大 60 個が同時に呼び出しを処理していた場合、MAX (ProvisionedConcurrentExecutions) の値は 60 に、MAX (ProvisionedConcurrencyUtilization) の値は 0.6 になります。

ProvisionedConcurrencySpilloverInvocations の値が大きい場合は、関数にプロビジョニングされた同時実行を追加で割り当てる必要があることを示している可能性があります。または、事前定義されたしきい値に基づいてプロビジョニングされた同時実行の自動スケーリングを処理するように Application Auto Scaling を設定することもできます。

逆に、ProvisionedConcurrencyUtilization の値が常に低い場合は、関数にプロビジョニングされた同時実行数を過剰に割り当てている可能性があります。

ClaimedAccountConcurrency メトリクスの処理

Lambda は ClaimedAccountConcurrency メトリックスを使用して、アカウントがオンデマンド呼び出しに使用できる同時実行の量を判断します。Lambda は、以下の式を使用して ClaimedAccountConcurrency を計算します。

ClaimedAccountConcurrency = UnreservedConcurrentExecutions + (allocated concurrency)

UnreservedConcurrentExecutions は、予約されていない同時実行を使用している、アクティブな同時呼び出しの数です。割り当てられた同時実行数は、次の 2 つの部分の合計です (RC は「予約された同時実行」、PC は「プロビジョニングされた同時実行」に置き換えます)。

  • リージョン内のすべての関数の合計 RC。

  • リージョン内で PC を使用しているすべての関数の合計 PC。RC を使用する関数は除きます。

注記

1 つの関数に RC よりも多い PC を割り当てることはできません。したがって、関数の RC は常に、その関数の PC と同数かそれよりも多くなります。Lambda では、PC および RC によるこのような関数に割り当てられた同時実行性への寄与度を算出する際に、この 2 つのうちの最大値である、RC のみを考慮します。

Lambda は ConcurrentExecutions ではなく ClaimedAccountConcurrency メトリックスを使用して、アカウントがオンデマンド呼び出しに使用できる同時実行の量を判断します。ConcurrentExecutions メトリックスはアクティブな同時呼び出しの数を追跡するのに役立ちますが、実際の同時実行の可用性を必ずしも反映しているわけではありません。これは、Lambda では予約された同時実行とプロビジョニングされた同時実行も考慮して可用性を判断するためです。

ClaimedAccountConcurrency の例として、ほとんど使用されなくなっている関数全体で、多くの予約された同時実行とプロビジョニングされた同時実行を設定するシナリオを考えてみましょう。次の例では、アカウントの同時実行数の上限が 1,000 で、アカウントにとの 2 つの主要関数 function-orange、function-blue があるとします。function-orange には 600 単位の予約された同時実行を割り当てます。function-blue には 200 単位のプロビジョニングされた同時実行を割り当てます。時間の経過とともに、追加の関数をデプロイし、以下のトラフィックパターンに注目したとします。

Lambda が ClaimedAccountConcurrency をどのように判断するかを示すグラフ。

前の図では、黒い線は時間の経過に伴う実際の同時実行使用量を示し、赤い線は時間の経過に伴う ClaimedAccountConcurrency 値を示しています。このシナリオでは、関数全体の実際の同時実行使用率は低いものの、ClaimedAccountConcurrency は最低でも 800 です。これは、function-orange と function-blue に合計 800 の同時実行ユニットを割り当てたためです。Lambda の観点からすると、ユーザーがこの同時実行性の使用を「要求」しているため、他の関数に使用できる同時実行ユニットは 200 ユニットしか残っていないことになります。

このシナリオでは、ClaimedAccountConcurrency 計算式で割り当てられる同時実行数は 800 です。これで、ダイアグラム内のさまざまなポイントでの ClaimedAccountConcurrency 値を導き出すことができます。

  • t1 では、ClaimedAccountConcurrency は 800 (800 + 0 UnreservedConcurrentExecutions) です。

  • t2 では、ClaimedAccountConcurrency は 900 (800 + 100 UnreservedConcurrentExecutions) です。

  • t3 でも、ClaimedAccountConcurrency は 900 (800 + 100 UnreservedConcurrentExecutions) です。

CloudWatch での ClaimedAccountConcurrency メトリクスのセットアップ

Lambda は CloudWatch で ClaimedAccountConcurrency メトリクスを出力します。次の式に示すように、このメトリクスを SERVICE_QUOTA(ConcurrentExecutions) の値とともに使用すると、アカウントの同時実行使用率を取得できます。

Utilization = (ClaimedAccountConcurrency/SERVICE_QUOTA(ConcurrentExecutions)) * 100%

次のスクリーンショットは、この数式を CloudWatch でグラフ化する方法を示しています。緑の claim_utilization 線は、このアカウントの同時実行使用率が約 40% であることを表しています。

CloudWatch で ClaimedAccountConcurrency メトリクスを使用する方法を示すスクリーンショット。

前のスクリーンショットには、同時実行使用率が 70% を超えると ALARM 状態になる CloudWatch アラームも含まれています。ClaimedAccountConcurrency メトリックスと類似のアラームを併用することで、アカウントの同時実行制限の引き上げをいつリクエストする必要があるかを事前に判断できます。