ユニファ開発者ブログ

ユニファ株式会社システム開発部メンバーによるブログです。

AWS Lambda Provisioned Concurrencyをゆるく検証

もういくつ寝るとお正月ございます(適当な挨拶)。

ユニファのインフラ見ているすずきです。

ユニファのアドベントカレンダーの20日目となります。

re:Inventの時差ボケも治り快調です。

そして昨日Reproさんでre:Invent報告会で話してきました。

repro-tech.connpass.com

その後半でAWS Lambda Provisioned Concurrencyを検証した結果を話したのですが、 そのことについてブログにしようと思います。

AWS Lambda Provisioned Concurrency ってなんぞや

aws.amazon.com

re:Invent期間中に発表されたサービスです。

もともとAWS Lambdaはデプロイされたタイミングや、長時間実行されていないときに動かそうとするとレイテンシがわるくなるのですが、あらかじめ決めた数のLambdaコンテナを起動しておきコールドスタートが起きない状態が準備できる機能になります。

発表中はCloudWatchメトリクスで実際に消費された数がみえるので、オートスケールできそうですねと話したのですが、上の記事みたらできるって書いてありましたね…

AWS Lambda のコールドスタート

AWS Lambaのコールドスタートは先程記載したレイテンシが悪くなる原因です。

これはLambdaの初回起動時や、更新した際、停止したコンテナにアクセスした際などに発生します。

詳細や補足などは以下を見ると良いかもしれません。 AWS Lambda 実行コンテキスト

コールドスタート対策

弊社では利用していないので参考記事を見つけましたので確認いただけたらと思います。(去年のアドベントカレンダーだ…!!)

qiita.com

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アクセスをしたいので、やはり我らがサイヤ人の王子、ベジータ様の出番です。

github.com

ベジータ様に連続エネルギー弾で秒間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までしか設定できませんでした)

f:id:mominosin:20191219180108p:plain

Provisioned Concurrencyはエイリアスかバージョンを作成しないと利用できません。 なので、利用している場合はデプロイするたびにProvisioned Concurrencyの設定を作り直さないとだめかもしれないです。(実際に運用する際は調べてみます…)

プロビジョニングはゆっくりされるので、有効にしたらすぐ使えるというものでもないです。950でも5分もかからないです。 f:id:mominosin:20191219180643p:plain

Lambdaの同時実行数を制限すると、プロビジョニングできる数も制限されます。 f:id:mominosin:20191219180848p:plain f:id:mominosin:20191219181002p:plain

Provisioned Concurrencyを有効にしているLambdaにアクセスした際、以下のメトリクスが増加しました。 f:id:mominosin:20191219181304p:plain

プロビジョニングしているLambdaのなかでいくつ利用したかがみえますね、定期的にこの値を見直して、オートスケールの幅などを検討するとよいのかと思います。

950プロビジョニングしても秒間100リクエストくらいだと50くらいしか使わないですね…。

まとめ

Provisioned Concurrencyを利用することでVPC有無関係なくレイテンシーの改善が見られることがわかりました。

しかし通常のLambdaと違い常時コストが発生するのでApplication AutoScalingを利用するなど、運用は検討したほうが良いと思います。今の所弊社で利用用途は思いついてません…。

RDS PoroxyもできたのでLambda活躍の幅もふえてきたので、それによっては利用用途が見つかるかもしれませんし、今後のアップデートにより見えてくるものもあるかもしれないので引き続きサーバレス関連のキャッチアップは進めようと思います。

以上で本ブログは終わりです。

明日のアドベントカレンダーはえっとだれだっけ…楽しみにしておいてください!

すずき