AWSからの通知で仕様変更を知る（2021/8）
通知内容の趣旨
概要
→Lambdaの予約済み同時実行数に “0” が設定されている場合の動作に変更が発生するという内容。
※今回の変更は、予約済みの同時実行が設定されていない、またはゼロ以外の値に設定されている関数には影響しない。
※今回の変更は、すべてのAWSリージョンに適用される。
- これまで：最大6時間再試行されていた
- 変更後：すぐにデッドレターキュー(DLQ) またはon-failure イベントに送られる(どちらも設定されていない場合はイベントは即ドロップされる)
期限（変更日）
→2021/8/30 から変更が有効となる。
※ちなみに今回の通知はリマインド通知で、以前にも同様の通知を受け取っていた模様。
（以前の変更予定日は 2021/8/16 だった）
通知メールのタイトル
AWS Lambda: Updated date for change in behavior of asynchronously invoked Lambda functions with zero reserved concurrency set to 0 [AWS Account: 123456789012]
ToDo（やるべきこと）
影響度の確認と対策
→条件の一致する設定を行っているLambda関数が無いか、確認する必要がある。
→場合によっては、対策（設定変更?）を行う必要がある。
(そのまえに) Lambda関数の「同時実行数」について理解を深める
→恥ずかしながら『同時実行数って・・・』『よ、予約？・・・』という知識レベルだったので、お話についていくために前提知識の遅れを取り戻す必要がある。
→この部分で、今回は学びが多かった◎
と、いうことで
今回のレポートは
調査ついでに調べた内容に学びが多かったので整理してみました、という内容となっております。
どなたかの参考になるかは不明ですが、気になる部分だけでも読んでいっていただけると幸いです。
では、さっそく！
確認した結果（影響度）
いきなりですが、まずは調査結果から。
私の管理するAWSアカウントでは、今回の変更による『影響は無い』ということがわかりました。
そもそも
「予約済み同時実行数に”0” をセットする」運用って無いよな〜と思いつつ、
特に対策を講じる必要も無かったので一安心?といったところです。
確認した内容（やったこと）
同時実行数の上限値を確認する
「Service Quotas」コンソール画面にて、Lambdaのクォータから同時実行数「Concurrent executions」の状態を確認します。
→デフォルトの「1000」が表示されておりました。
Lambda関数の設定内容を確認する
Lambda関数の「設定」タブから「同時実行」を選択し、設定内容を確認します。
→いずれの関数も、『予約されていないアカウントの同時実行の使用』が選択されており、『同時実行の予約』は行っていない状態でした。
ちなみに、
『予約されていないアカウントの同時実行(の残数)』には「1000」が表示されていたので、リージョン内の他の関数においても同時実行の予約（値が1以上）は行われていないことがわかります。
ただし、
今回の仕様変更の対象となるのは、予約済み同時実行数 ”0” で予約している場合」なので、一応、リージョン内の全ての関数を確認しました。
各リージョンのLambda関数の設定内容も確認する
同時実行数の値は、アカウント内のリージョン内で共有されるので、全てのリージョンにて確認を行う必要があります。（一部デフォルトでは有効になっていないリージョンもあるので、そこは確認不要）
→私の環境では、東京リージョン以外ではLambda関数を作成しておりませんでしたので、関数自体が無い、という結果でした。
同時実行数とは？
（開発者ガイドからの抜粋）
同時実行数とは、ある時点で関数が処理しているリクエストの数を指します。
関数が呼び出されると、Lambda はその関数のインスタンスを割り当ててイベントを処理します。
関数コードの実行が完了すると、別のリクエストを処理できます。
リクエストの処理中に関数が再度呼び出されると、別のインスタンスが割り当てられるため、関数の同時実行数が増えます。
同時実行数は、リージョン内のすべての関数で共有されるリージョンのクォータの影響を受けます。
文字通り、ある時点でLambda関数が同時に処理しているリクエスト数、ということですね。
当然、複数のLambda関数が同時に呼び出されると同時実行数は増えますが、その上限（クォータ）はリージョン内で共有されるという仕組みになっています。
２種類ある同時実行のコントロール方法
リザーブド同時実行（←今回の通知に関係するのはコチラ）
（開発者ガイドからの抜粋）
リザーブド同時実行は、関数の同時インスタンスの最大数を保証します。
ある関数が予約された同時実行数を使用している場合、他の関数はその同時実行数を使用できません。
関数に対して予約された同時実行を設定する場合には料金はかかりません。
Reserved concurrency：「同時実行の予約」のお話です。
仮に”5” という値で予約設定を行うと、その同時実行数は対象のLambda関数のために確保（保証）されます。
加えて対象Lambda関数の同時実行の最大値は”5″ となり、この数を超えて同時実行を行うことが出来なくなります。
また、この”5″ の同時実行数が予約されることにより、他のLambda関数が利用できる同時実行数は”5″ 減ることとなります。
プロビジョニングされた同時実行
（開発者ガイドからの抜粋）
プロビジョニングされた同時実行は、リクエストされた数だけの実行環境を初期化して、関数の呼び出しに即座に応答する準備を行います。
プロビジョニングされた同時実行を設定すると、AWS アカウントに課金が発生することに注意してください。
Provisioned concurrency：事前のプロビジョニング設定のお話です。
今回これについては深堀りしませんが、
事前プロビジョニングの設定によりウォームスタートの状態を準備して、コールドスタートを防ぐという方法になります。
利用には別途料金がかかるので注意が必要です。
同時実行を予約したらどうなるの？
ここで改めて、リザーブド同時実行（予約）を行った場合の動作について整理していきます。
同時実行数を専有できる・リージョン内の上限数から差し引かれる
任意のLambda関数で同時実行の予約を行うことにより、同時実行数を専有する状態になると考えていただいて差し支えないでしょう。
また、専有されることによって、リージョン内で共有している上限数（デフォルト 1,000）からは差し引かれることとなります。
つまり、予約を行っていないLambda関数の同時実行数は 減る ということです。
そのLambda関数の同時実行上限が決まる
同時実行の予約を行った場合、その予約の値が そのLambda関数の同時実行上限となります。
前述の通り、仮に”5” という値で予約設定を行うと、対象のLambda関数の同時実行の最大は”5″ ということです。
上限数を超えるとスロットリングエラーとなる
上限数を超えてリクエスト(イベント) が発生した場合、スロットリングエラーとなります。
同時実行数のクォータ（上限）
デフォルトの上限値
同時実行数のデフォルトは 1,000 となっており、申請により上限の引き上げは可能となっております。
現状の上限値を確認する
（「確認した内容」の部分で既に紹介しましたが、）
「Service Quotas」コンソール画面にて、Lambdaのクォータから同時実行数「Concurrent executions」の状態を確認することができます。
上限緩和申請をする
上限緩和申請を行う場合は、同じく「Service Quotas」コンソール画面から申請に進むことができます。
・開発者ガイド｜Lambda のクォータ
予約済み同時実行数の使いどころ
今回調査を進めるなかで、同時実行の予約をどのように活用するのか、という部分が少し見えてきた（ような気がするだけ）ので、ここでご紹介です。
（Operator Guide からの抜粋）
You can also use reserved capacity to throttle the rate of requests processed by your workload. For Lambda functions that are invoked asynchronously or using an internal poller, such as for S3, SQS, or DynamoDB integrations, reserved capacity limits how many requests are processed simultaneously. In this case, events are stored durably in internal queues until the Lambda function is available. This can help create a smoothing effect for handling spiky levels of traffic.
（DeepL 様に頼った結果）
予約済み容量を使用して、ワークロードで処理されるリクエストの速度をスロットルすることもできます。S3、SQS、DynamoDBの統合など、非同期に呼び出されるLambda関数や内部ポーラーを使用するLambda関数では、予約済み容量により、同時に処理されるリクエストの数が制限されます。この場合、Lambda関数が利用可能になるまで、イベントは内部キューに永続的に保存されます。これにより、急峻なレベルのトラフィックを処理するためのスムージング効果を生み出すことができます。
つまり、
同時実行の予約により上限数を指定し、最終的にDBへの書き込みトラフィックを制御につなげることが可能、ということです。（たぶん）
SQSと併せて利用することで溢れたイベントもキューに保存できるとのことで、今後の参考にしたいと思います。
（イメージ：参考ページより）
まとめ
かなり地味な内容でしたが、個人的には学びが多く楽しい調査となりました。
Lambda関数を使っていたものの、同時実行数の予約についてはあまり意識する機会がなかったので、
Lambda関数の新たな一面?を知ることができてよかったです。
最後まで読んでいただきありがとうございました。
