もういくつ寝るとお正月ございます（適当な挨拶）。
ユニファのインフラ見ているすずきです。
ユニファのアドベントカレンダーの２０日目となります。
re:Inventの時差ボケも治り快調です。
そして昨日Reproさんでre:Invent報告会で話してきました。
その後半でAWS Lambda Provisioned Concurrencyを検証した結果を話したのですが、 そのことについてブログにしようと思います。
AWS Lambda Provisioned Concurrency ってなんぞや
re:Invent期間中に発表されたサービスです。
もともとAWS Lambdaはデプロイされたタイミングや、長時間実行されていないときに動かそうとするとレイテンシがわるくなるのですが、あらかじめ決めた数のLambdaコンテナを起動しておきコールドスタートが起きない状態が準備できる機能になります。
発表中はCloudWatchメトリクスで実際に消費された数がみえるので、オートスケールできそうですねと話したのですが、上の記事みたらできるって書いてありましたね…
AWS Lambda のコールドスタート
AWS Lambaのコールドスタートは先程記載したレイテンシが悪くなる原因です。
これはLambdaの初回起動時や、更新した際、停止したコンテナにアクセスした際などに発生します。
詳細や補足などは以下を見ると良いかもしれません。 AWS Lambda 実行コンテキスト
コールドスタート対策
弊社では利用していないので参考記事を見つけましたので確認いただけたらと思います。（去年のアドベントカレンダーだ…！！)
Provisioned Concurrencyがでたからこの対応が無意味かというとまた違うかなと思います。 Provisioned Concurrencyは常時コンテナを起動し続けることになるのでランニングコストが通常の運用よりかかってきます。なので、ワークロードにあわせ必要な機能を取捨選択してもらったらいいのかと思います。
現実的に使えるかは謎ですが、
例えば日中帯はProvisioned Concurrencyを利用するが、夜間は定期的アクセスとか？
AWS Lambda Provisioned Concurrencyを有効にして動きを確認してみる
実際に動きを確認しようと思いますが以下の方法で動作確認しようと思います。
API Gateway + Lambda環境を作成する
いい感じの環境を持っていなかったので以下のサンプルを使ってAPI Gateway + Lambda環境を作りました 「チュートリアル: Lambda プロキシ統合による Hello World API の構築」に乗っ取りサンプル環境構
別途VPCも準備してVPC Lambdaの検証もします。 (re:InventのアップデートでRDS Proxyの発表もありそれを利用するにはVPCが必要となりますしね。)
動作確認方法
HTTPアクセスをしたいので、やはり我らがサイヤ人の王子、ベジータ様の出番です。
ベジータ様に連続エネルギー弾で秒間100発を10秒間やっていただきます。 (秒間100リクエストを10秒間行います)
確認パターン
- Lambda
- Lambda + Provisioned Concurrency
- VPC Lambda
- VPC Lambda + Provisioned Concurrency
動作結果
| VPC(有/無) | Provisioned Concurrency(有/無) | 0-200ms(件数) | 400ms 未満(件数) | 400ms以上(件数) |
|---|---|---|---|---|
| 無 | 無 | 962 | 35 | 3 |
| 無 | 有 | 980 | 19 | 1 |
| 有 | 無 | 952 | 22 | 26 |
| 有 | 有 | 983 | 17 | 1 |
ちょっと見づらいですが、VPCのほうが少しレイテンシが悪目ですが、Provisioned Concurrencyを有効にした方はレイテンシの改善が見られます。
ためしにですが、上記リクエストを投げた直後にもう一度同じリクエストを投げてみました。これによってコールドスタートが起きていない場合の結果が得られるはずです。
| VPC(有/無) | Provisioned Concurrency(有/無) | 0-200ms(件数) | 400ms 未満(件数) | 400ms以上(件数) |
|---|---|---|---|---|
| 無 | 無 | 993 | 7 | 0 |
| 無 | 有 | 994 | 6 | 0 |
| 有 | 無 | 986 | 14 | 0 |
| 有 | 有 | 995 | 5 | 0 |
どのパターンでもレイテンシが改善していてコールドスタートが無いことが見れますね。Provisioned Concurrencyを利用していても改善するレイテンシはあるみたいです。
雑記
今回 Provisioned Concurrencyは950にしてみました。（lambdaのデフォルトの上限が1000だからか、950までしか設定できませんでした)
Provisioned Concurrencyはエイリアスかバージョンを作成しないと利用できません。 なので、利用している場合はデプロイするたびにProvisioned Concurrencyの設定を作り直さないとだめかもしれないです。（実際に運用する際は調べてみます…）
プロビジョニングはゆっくりされるので、有効にしたらすぐ使えるというものでもないです。950でも5分もかからないです。
Lambdaの同時実行数を制限すると、プロビジョニングできる数も制限されます。
Provisioned Concurrencyを有効にしているLambdaにアクセスした際、以下のメトリクスが増加しました。
プロビジョニングしているLambdaのなかでいくつ利用したかがみえますね、定期的にこの値を見直して、オートスケールの幅などを検討するとよいのかと思います。
950プロビジョニングしても秒間100リクエストくらいだと50くらいしか使わないですね…。
まとめ
Provisioned Concurrencyを利用することでVPC有無関係なくレイテンシーの改善が見られることがわかりました。
しかし通常のLambdaと違い常時コストが発生するのでApplication AutoScalingを利用するなど、運用は検討したほうが良いと思います。今の所弊社で利用用途は思いついてません…。
RDS PoroxyもできたのでLambda活躍の幅もふえてきたので、それによっては利用用途が見つかるかもしれませんし、今後のアップデートにより見えてくるものもあるかもしれないので引き続きサーバレス関連のキャッチアップは進めようと思います。
以上で本ブログは終わりです。
明日のアドベントカレンダーはえっとだれだっけ…楽しみにしておいてください！
すずき
