Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
劇的改善?? VPC Lambda Before&After
Search
TomoyaIwata
October 26, 2019
Technology
0
3.3k
劇的改善?? VPC Lambda Before&After
2019/10/26に開催されたDevelopers.IO 2019 Fukuokaで発表させて頂いた際の資料です
TomoyaIwata
October 26, 2019
Tweet
Share
More Decks by TomoyaIwata
See All by TomoyaIwata
これでLambdaが不要に?!Step FunctionsのJSONata対応について
iwatatomoya
2
4.2k
Qdrantでベクトルデータベースに入門してみよう
iwatatomoya
0
390
詳解 AWS Lambdaコールドスタート
iwatatomoya
1
2k
真のサーバーレスへ向けたAuroraの進化Aurora Limitless Database
iwatatomoya
1
4.5k
AWS SDKのClientはFactory経由で作ろう
iwatatomoya
1
730
OpentelemetryでアプリケーションのObservabilityを強化しよう
iwatatomoya
0
950
AWS Lambdaは俺が作った
iwatatomoya
2
2.3k
SnapStartの未来についての期待と妄想
iwatatomoya
1
1.3k
実例から学ぶ! AWSを活用したシステム開発の勘所
iwatatomoya
1
3k
Other Decks in Technology
See All in Technology
トラブルシュートを楽しもう (wakamonog meeting 15)
recuraki
3
840
2025年のARグラスの潮流
kotauchisunsun
0
870
[JSAC 2025 LT] Introduction to MITRE ATT&CK utilization tools by multiple LLM agents and RAG
4su_para
1
130
AWS Community Builderのススメ - みんなもCommunity Builderに応募しよう! -
smt7174
0
210
Git scrapingで始める継続的なデータ追跡 / Git Scraping
ohbarye
5
580
【Oracle Cloud ウェビナー】2025年のセキュリティ脅威を読み解く:リスクに備えるためのレジリエンスとデータ保護
oracle4engineer
PRO
1
110
PaaSの歴史と、 アプリケーションプラットフォームのこれから
jacopen
7
1.6k
やっちゃえ誤自宅Nutanix
yukiafronia
0
220
三菱電機で社内コミュニティを立ち上げた話(MAWS-UG)
kurebayashi
1
370
デザインシステムを始めるために取り組んだこと - TechTrain x ゆめみ ここを意識してほしい!リファクタリング勉強会
kajitack
2
250
いま現場PMのあなたが、 経営と向き合うPMになるために 必要なこと、腹をくくること
hiro93n
9
8.4k
コスト削減と精度維持を両立!類似画像検索システムの内製化成功事例
shutotakahashi
0
150
Featured
See All Featured
A designer walks into a library…
pauljervisheath
205
24k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2k
Embracing the Ebb and Flow
colly
84
4.5k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
26
1.9k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
192
16k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.1k
A Tale of Four Properties
chriscoyier
157
23k
Being A Developer After 40
akosma
89
590k
Why Our Code Smells
bkeepers
PRO
335
57k
GitHub's CSS Performance
jonrohan
1030
460k
Statistics for Hackers
jakevdp
797
220k
Transcript
劇的改善︖︖ VPC Lambda Before&After CX事業本部 岩⽥ 智哉
スライドは後で⼊⼿することが出来ますので 発表中の内容をメモする必要はありません。 写真撮影をする場合は フラッシュ・シャッター⾳が出ないようにご配慮ください Attention
3 ⾃⼰紹介 lクラスメソッド株式会社 lサーバーレス開発部 改め CX事業本部 l⼤阪オフィス所属 l好きなAWSサービス: AWS Lambda
岩⽥ 智哉
4 今⽇話したいこと アンチパターンとされていた VPC Lambdaの懸念事項が どのように改善されたのか︖︖
5 想定しているターゲット • AWS Lambdaの基礎的な知識を持っている⼈ • サーバーレスなシステムの開発/運⽤をやってる⼈ • VPC Lambdaの利⽤を検討している⼈
6 アジェンダ • AWS Lambdaのアーキテクチャおさらい 5分 • VPC Lambdaのアーキテクチャ(新) •
VPC Lambdaのアーキテクチャ(旧) • 改善効果について 6分 4分 6分 • どのように考え⽅を変えるべきなのか • まとめ 5分 2分
7 アジェンダ • AWS Lambdaのアーキテクチャおさらい 5分 • VPC Lambdaのアーキテクチャ(新) •
VPC Lambdaのアーキテクチャ(旧) • 改善効果について 6分 4分 6分 • どのように考え⽅を変えるべきなのか • まとめ 5分 2分
8 Lambdaのアーキテクチャについて 無駄なコスト ※Security Overview of AWS Lambda(https://d1.awsstatic.com/whitepapers/Overview-AWS-Lambda-Security.pdf)より引⽤ cgroups namespaces
seccomp iptables chroot
9 Lambdaのアーキテクチャについて(EC2モデル) 無駄なコスト • 1つのMicroVM上に複数のLambda実 ⾏環境を作成 • AWSアカウントをまたいでWorkerは 共有されない ※Security
Overview of AWS Lambda(https://d1.awsstatic.com/whitepapers/Overview-AWS-Lambda-Security.pdf)より引⽤
10 Lambdaのアーキテクチャについて(Firecrackerモデル) • 1つのMicroVM上には1つのLambda実 ⾏環境しか作成しない • AWSアカウントをまたいでWorkerを 共有する ※Security Overview
of AWS Lambda(https://d1.awsstatic.com/whitepapers/Overview-AWS-Lambda-Security.pdf)より引⽤
11 アジェンダ • AWS Lambdaのアーキテクチャおさらい 5分 • VPC Lambdaのアーキテクチャ(新) •
VPC Lambdaのアーキテクチャ(旧) • 改善効果について 6分 4分 6分 • どのように考え⽅を変えるべきなのか • まとめ 5分 2分
12 VPC Lambdaのアーキテクチャ (旧) ENIキャパシティの計算式: Projected peak concurrent executions *
(Memory in GB / 3GB) ※Announcing improved VPC networking for AWS Lambda functions (https://aws.amazon.com/jp/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/)より引⽤
13 VPC Lambdaのアーキテクチャ (旧) ※A Serverless Journey: AWS Lambda Under
the Hood (SRV409-R1) - AWS re:Invent 2018 (https://www.slideshare.net/AmazonWebServices/a-serverless-journey-aws-lambda-under-the-hood-srv409r1-aws-reinvent- 2018?ref=https://dev.classmethod.jp/cloud/aws/reinvent2018-srv409/)より引⽤
14 VPC Lambdaの課題 • ENIの枯渇問題 • ENI作成のRate Limit • IPアドレス枯渇問題
• ENI作成を伴うコールドスタート時の遅延 • インターネットアクセスにNAT Gatewayが必要
15 VPC LambdaからRDB(S)を利⽤する際の課題 • 同時接続数の問題 • コネクションプーリングが使えない • RDBはスケールアウトではなくスケールアップ •
コスト最適化の課題
16 RDB(S)を使う場合のコストと同時接続数の関係 • 最⼤同時接続数を上げるにはインスタンスタイプを変える必要がある • 柔軟にスケールアップできない • コストを最適化できない 処理可能な最⼤同時接続数とコスト 実際の接続数
インスタンスタイプ変更 インスタンスタイプ変更
17 VPC Lambdaは⼀般的に アンチパターンと されていた 旧来の考え⽅
18 アジェンダ • AWS Lambdaのアーキテクチャおさらい 5分 • VPC Lambdaのアーキテクチャ(新) •
VPC Lambdaのアーキテクチャ(旧) • 改善効果について 6分 4分 6分 • どのように考え⽅を変えるべきなのか • まとめ 5分 2分
19 VPC Lambdaのアーキテクチャ (新) ※Announcing improved VPC networking for AWS
Lambda functions (https://aws.amazon.com/jp/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/)より引⽤
20 VPC Lambdaのアーキテクチャ (新) ※A Serverless Journey: AWS Lambda Under
the Hood (SRV409-R1) - AWS re:Invent 2018 (https://www.slideshare.net/AmazonWebServices/a-serverless-journey-aws-lambda-under-the-hood-srv409r1-aws-reinvent- 2018?ref=https://dev.classmethod.jp/cloud/aws/reinvent2018-srv409/)より引⽤
21 Hyperplane • AWS内部で利⽤されているSDNの技術 • S3 Load Balancerがベース • EFS、NLB、Private
Link、Managed NATで利⽤ • デフォルト5Gbit/secの性能Tbitレベルまでスケール • msレベルのレイテンシー
22 新アーキテククチャへの移⾏開始 • 2019/9/3 AWSより新アーキテクチャへの段階移⾏開始の アナウンス • 2019/9/27 オハイオ、フランクフルト、東京への適⽤ 完了のアナウンス
23 • AWS Lambdaのアーキテクチャおさらい 5分 • VPC Lambdaのアーキテクチャ(新) • VPC
Lambdaのアーキテクチャ(旧) • 改善効果について 6分 4分 6分 • どのように考え⽅を変えるべきなのか • まとめ 5分 2分
Public subnet 24 検証1 AWS Cloud VPC • API GatewayのバックにVPC
Lambdaを紐付け • EC2からheyコマンドで並列アクセス
25 2019/5/29時点の実⾏結果 Summary: Total: 13.4614 secs Slowest: 13.0460 secs Fastest:
0.0194 secs Average: 1.2528 secs Requests/sec: 37.1433 Total data: 2500 bytes Size/request: 5 bytes Response time histogram: 0.019 [1] | 1.322 [448] |▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪ 2.625 [1] | 3.927 [0] | 5.230 [0] | 6.533 [0] | 7.835 [0] | 9.138 [0] | 10.441 [4] | 11.743 [9] |▪ 13.046 [37] |▪▪▪
26 2019/10/20時点の実⾏結果 Summary: Total: 1.3694 secs Slowest: 0.5470 secs Fastest:
0.0225 secs Average: 0.0970 secs Requests/sec: 365.1342 Total data: 2500 bytes Size/request: 5 bytes Response time histogram: 0.023 [1] | 0.075 [411] |▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪ 0.127 [25] |▪▪ 0.180 [1] | 0.232 [0] | 0.285 [0] | 0.337 [0] | 0.390 [9] |▪ 0.442 [7] |▪ 0.495 [33] |▪▪▪ 0.547 [13] |▪
27 もうちょっと イジメてみる
28 検証2 ENI1が追加作成されたりしない︖︖ • Lambdaの実⾏がすぐに完了しないように2秒 のSleepを追加 • heyの並列数を500に引き上げ
29 検証2の結果 Summary: Total: 21.8108 secs Slowest: 3.4042 secs Fastest:
2.0223 secs Average: 2.1532 secs Requests/sec: 458.4892 Total data: 50000 bytes Size/request: 5 bytes Response time histogram: 2.022 [1] | 2.160 [8998] |▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪ 2.299 [1] | 2.437 [0] | 2.575 [0] | 2.713 [0] | 2.851 [0] | 2.990 [0] | 3.128 [113] |▪ 3.266 [844] |▪▪▪▪ 3.404 [43] |
30 検証2実⾏後のENIの状況 VPC Lambda⽤のENIは1つのまま変わらず
31 さらにイジメてみる
Public subnet 32 検証3 AWS Cloud VPC master slave
33 検証3 • FargateでLocustのクラスタを作成し、API GW経由で VPC Lambdaに⼤量アクセス • Lambdaは3秒Sleep後にレスポンスを返却 •
Usersは1,100に設定 • Hatch rateは100に設定 • 同時実⾏数の上限に達するようなワークロード
34 検証3 スロットリングが頻発するような状況でも ⼤きな待ちは発⽣せず
35 検証3 実⾏時のLambda同時起動数
36 検証3 実⾏時のスロットリング状況
37 検証結果から.... • Lambdaの同時実⾏数が増えてもENIの追加作成が ⾛ることは無さそう • ⼤量のデータ転送を伴うLambdaだと懸念がある︖︖要検証 • Lambdaのペイロードサイズ上限を考えると⼤丈夫︖︖ •
⾮VPC Lambdaと同等レベルの耐久性がありそう
38 • AWS Lambdaのアーキテクチャおさらい 5分 • VPC Lambdaのアーキテクチャ(新) • VPC
Lambdaのアーキテクチャ(旧) • 改善効果について 6分 4分 6分 • どのように考え⽅を変えるべきなのか • まとめ 5分 2分
39 VPC Lambdaの課題(再掲) • ENIの枯渇問題 • ENI作成のRate Limit • IPアドレス枯渇問題
• ENI作成を伴うコールドスタート時の遅延 • インターネットアクセスにNAT Gatewayが必要
40 VPC LambdaからRDB(S)を利⽤する際の課題(再掲) • 同時接続数の問題 • コネクションプーリングが使えない • RDBはスケールアウトではなくスケールアップ •
コスト最適化の課題
41 新アーキテクチャでの考え⽅ • ENI周りの懸念事項は解消された • 新アーキテクチャでも課題は残る • 何でもかんでもVPC Lambdaを使っても⼤丈夫という訳で はない
• あくまでリスク受容できる範囲が広がっただけ
42 VPC Lambdaを使っても良さそうなユースケース • コールドスタートによる10秒~20秒数100ミリ秒~数秒程度の遅 延が許容できるワークロード • 利⽤予定のVPCリソースが想定される最⼤アクセス数を問題な く処理可能なワークロード 例えば、、、
アクセス数が安定しており、数秒程度のレイテンシが許 容できるB2Bサービスのバックエンドなど
43 その他 考慮しておきたいこと • VPC Lambdaを使う ≒ 何かしらのサービスを利⽤するためのラ イブラリが必要 •
パッケージやLayerが肥⼤化しがち 当然コールドスタートは遅い • アプリケーションフレームワークは使う︖それとも使わない︖ • モノリシックなアプリケーションをVPC Lamdbaに乗せ替えよう としていないか︖︖
44 • AWS Lambdaのアーキテクチャおさらい 5分 • VPC Lambdaのアーキテクチャ(新) • VPC
Lambdaのアーキテクチャ(旧) • 改善効果について 6分 4分 6分 • どのように考え⽅を変えるべきなのか • まとめ 5分 2分
45 まとめ • VPC Lambdaのアーキテクチャは様々な課題を抱えていた • そのうちいくつかの課題は改善された • いくつかの課題は継続して残り続けている •
VPC Lambdaを採⽤しても問題ないケースは増えた
46 適切なアーキテクチャを 選定できるように 常に知識のアップデートを まとめ
47 ご清聴ありがとうございました
None