Technology that powers Lambda / AWS Lambda を支える技術

AWS Lambdaはその誕生から10年が経ちますが、このカンファレンスに来られている皆様は普段からご利用になっている方も多いのではないでしょうか？
このセッションでは、Lambdaのスケーラブルでリクエストごとに独立して実行される仕組みを振り返りながら改めて、 Lambdaアーキテクチャデザインを理解していただきスケーラブルなサービス構築に対する知見として役立てていただければ幸いです。

Transcript

1. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS Lambda を⽀える技術 Celebrating the 10th anniversary S E R V E R L E SS DAY S TO K YO 2 0 2 4 Kensuke Shimokawa Serverless Specialist Amazon Web Services Japan G.K.
2. Myself 2 Kensuke Shimokawa Amazon Web Services Serverless Specialist _kensh Slides https://speakerdeck.com/_kensh Qiita https://qiita.com/_kensh
3. AWS Lambda の どこら辺が好きですか︖ 3
4. Introduction 4
5. More than a MILLION customers use Lambda every month More than 10 TRILLION Lambda invocations per month Serverless の現状
6. AWS Lambda: Serverless の歴史 AWS Lambda GA AWS Lambda supports Java AWS Lambda supports Python, 5-minute functions Node.js support Access resources in a VPC AWS SAM Provisioned concurrency Amazon EventBridge AWS Step Functions C# support X-Ray support Lambda raises concurrency limit to 1,000 Lambda@Edge AWS SAM Local Enhanced console experience Doubles memory capacity Go support AWS SAM implementation open source 15-minute functions Amazon SQS as an event source Service-level agreement Lambda destinations Lambda console deployments Amazon SQS FIFO support AWS Lambda participates in Compute Savings Plans Lambda Ready Partners Amazon EFS support CloudWatch Lambda Insights Functions with up to 10 GB of memory 1 ms billing Container image support AWS Lambda Extensions GA Enhanced console experience Functions powered by AWS Graviton2 Event filtering IAM condition keys AWS Step Functions Workflow Studio AWS SAM Accelerate Functions with up to 10GB of ephemeral storage Function URLs Telemetry API SnapStart 2015 2016 2017 2019 2021 2018 2020 2022
7. Lambda とは、、、 7 Security Availability Utilization Performance Scale ⽣産性向上を⽀援するために、Serverless において⼤切にすること
8. AWS の責任共有モデル 8 CUSTOMER DATA PLATFORM, APPLICATIONS, IDENTITY & ACCESS MANAGEMENT OPERATING SYSTEM, NETWORK & FIREWALL CONFIGURATION CLIENT-SIDE DATA ENCRYPTION & DATA INTEGRITY AUTHENTICATION SERVER-SIDE ENCRYPTION (FILE SYSTEM AND/OR DATA) NETWORKING TRAFFIC PROTECTION (ENCRYPTION, INTEGRITY, IDENTITY) SOFTWARE COMPUTE STORAGE DATABASE NETWORKING HARDWARE / AWS GLOBAL INFRASTRUCTURE REGIONS AVAILABILITY ZONES EDGE LOCATIONS CUSTOMER RESPONSIBILITY FOR SECURITY “IN” THE CLOUD AWS RESPONSIBILITY FOR SECURITY “OF” THE CLOUD
9. Lambda の責任共有モデル / よりAWSへシフト 9 CUSTOMER FUNCTION CODE AND LIBRARIES IDENTITY & ACCESS MANAGEMENT SERVER SOFTWARE HARDWARE / AWS GLOBAL INFRASTRUCTURE REGIONS AVAILABILITY ZONES EDGE LOCATIONS CUSTOMER RESPONSIBILITY FOR SECURITY “IN” THE CLOUD AWS RESPONSIBILITY FOR SECURITY “OF” THE CLOUD COMPUTE EXECUTION ENVIRONMENT RUNTIME LANGUAGE NETWORKING INFRASTRUCTURE RESOURCE CONFIGURATION CUSTOMER DATA
10. Isolation 10 Security
11. Lambda はかつて T2 instances を利⽤
12. T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 Lambda はかつて T2 instances を利⽤
13. T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 Routing route Lambda はかつて T2 instances を利⽤
14. T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 Routing route Lambda はかつて T2 instances を利⽤
15. Lambda on Firecracker EC2 m5.metal instance 384GB of RAM Smallest Lambda function 128 MB of RAM
16. サーバーレス コンピューティング のための安全で高速な microVMs
17. Worker Host - EC2 Bare Metal Instance Host OS Host Kernel KVM MicroVM Execution Environment Runtime Function Code Extensions Guest Kernel Firecracker MicroVM Execution Environment Runtime Function Code Extensions Guest Kernel Firecracker Lambda Worker with Firecracker See Agache et al, “Firecracker: Lightweight Virtualization for Serverless Applications”, NSDI’20 https://www.usenix.org/system/files/nsdi20-paper-agache.pdf EC2 Worker Host
18. T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 T2 Lambda on T2
19. Lambda on Firecracker F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F
20. Firecracker 20 • Firecracker プロセスは、vCPU の数の設定やマシンの 起動などの一般的なアクションを可能にする RESTful API を介して制御 • 組み込みのレートリミッターが提供され同じマシン上 の何千もの microVM によって使用されるネットワーク リソースとストレージリソースを細かく制御可能 • バーストまたは特定の帯域幅/操作制限をサポート する柔軟なレート リミッターを設定可能 • Firecracker microVM は、「jailer」と呼ばれる、Linux ユーザー空間セキュリティバリアでさらに分離 https://firecracker-microvm.github.io
21. Utilization 21
22. Worker Utilization 22 Time Maximum capacity Traditional/on-premises Over capacity Under capacity Traffic Time Traffic Maximum capacity Instance-based (EC2) Time Traffic Maximum capacity AWS Serverless
23. Utilization / 23 AWS Lambda Worker (EC2 instance) Worker (EC2 instance) Worker (EC2 instance) Worker (EC2 instance) Worker (EC2 instance) Lambda Service 内部でのワークロードの分散最適化を考える
24. Utilization / 24 AWS Lambda BAD: リソース効率が悪い Execution Environment 30% Worker (EC2 instance) Execution Environment 30% Worker (EC2 instance) Execution Environment 30% Worker (EC2 instance) Execution Environment 30% Worker (EC2 instance) Execution Environment 30% Worker (EC2 instance)
25. Utilization / 25 AWS Lambda Execution Environment Execution Environment Execution Environment 90% Worker (EC2 instance) Execution Environment Execution Environment Execution Environment 90% Worker (EC2 instance) 0% Worker (EC2 instance) 0% Worker (EC2 instance) 0% Worker (EC2 instance) Cache locality Ability to autoscale GOOD: リソース効率が良い
26. Utilization / 26 BAD: 同じタイプのワークロードを同じワーカーに詰め込む AWS Lambda Execution Environment Execution Environment Execution Environment 90% Worker (EC2 instance) Execution Environment Execution Environment Execution Environment 90% Worker (EC2 instance) 1つの関数のCPU使用率が 急上昇すると、他の関数も 同様に急上昇する可能性が 高い
27. Utilization / 27 BETTER: 異なるタイプのワークロードをワーカーに詰め込む (統計的手法) AWS Lambda 統計的多重化を利用して相関 関係のない多数のワークロー ドをパックする Execution Environment Execution Environment Execution Environment 90% Worker (EC2 instance) Execution Environment Execution Environment Execution Environment 90% Worker (EC2 instance)
28. Utilization / 28 BEST: 異なるタイプのワークロードをワーカーに詰め込む (機械学習的手法) AWS Lambda 機械学習を使用して、最適に まとめられるワークロードを 選択 • 競合を最小限に抑える • 使用率を最大化する • パフォーマンスを向上 Execution Environment Execution Environment Execution Environment 90% Worker (EC2 instance) Execution Environment Execution Environment Execution Environment 90% Worker (EC2 instance)
29. Performance 29 Performance
30. The “state” of Lambda 30 Worker Host Firecracker Input Code Running VM Input code.zip Amazon S3 bucket
31. Lambda は、、、 31 • Artifact として、Zip および Container type をサポート • Zip 最大 250 MB • Container Image 最大 10 GB • Java, Go, Node.js, .NET, Python, Ruby を利用可能 • カスタムランタイムを利用し 他の言語も持ち込み可能 • ミリ秒単位の課金 • サーバーのプロビジョニングや管理は不要 • トラフィックに応じてミリ秒単位でスケール
32. The “state” of Lambda 32 Worker Host Firecracker Input Code Running VM Input code.zip Amazon S3 bucket 250 MB
33. The “state” of Lambda 33 Worker Host Firecracker Input Code Running VM Input Amazon S3 bucket 10 GB Container image
34. Container image は巨⼤だが密度が低い 34 From Harter et al, Slacker: Fast Distribution with Lazy Docker Containers, FAST’16 https://www.usenix.org/system/files/conference/fast16/fast16-papers-harter.pdf Opportunity
35. Cache (Read) 35 Dedicated Local Cache Dedicated Local Shared Local Chunk Chunk Chunk Chunk Shared AZ Chunk Chunk Chunk Chunk AWS Key Management Service (AWS KMS) Keys Worker AZ Dedicated Shared Encrypted Plaintext Read/write Read Only Read Only Firecracker microVM
36. Container image 36 FROM public.ecr.aws/lambda/nodejs:20 COPY app.mjs package.json ./ RUN npm install CMD ["app.lambdaHandler"] Dockerfile
37. Container image 37 ef4rzoi94x.tar.gz d139d87el.tar.gz … 44ds9a234.tar.gz Container Layers
38. Container image 38 ef4rzoi94x.tar.gz d139d87el.tar.gz … 44ds9a234.tar.gz / /var/task /var/runtime /opt/ … Container Layers File System
39. Container image 39 ef4rzoi94x.tar.gz d139d87el.tar.gz … 44ds9a234.tar.gz Container Layers File System Block-level Chunks [0-1] Chunk0 [2-3] Chunk1 [4-5] Chunk2 [...-…] Chunk.. [6-7] Chunk3 / /var/task /var/runtime /opt/ …
40. Block-level Chunks / ls File System Container image [0-1] Chunk0 [4-5] Chunk2 [...-…] Chunk.. [6-7] Chunk3 [2-3] Chunk1
41. Block-level Chunks / /var/runtime/node ls open File System Container image [0-1] Chunk0 [4-5] Chunk2 [...-…] Chunk.. [6-7] Chunk3 [2-3] Chunk1 Shared chunk
42. Block-level Chunks / /var/runtime/node /var/task/app.mjs ls open open File System Container image [0-1] Chunk0 [4-5] Chunk2 [...-…] Chunk.. [6-7] Chunk3 [2-3] Chunk1 Shared chunk
43. Block-level Chunks / /var/runtime/node /var/task/app.mjs ls open open File System Container image Unused chunks [0-1] Chunk0 [4-5] Chunk2 [...-…] Chunk.. [6-7] Chunk3 [2-3] Chunk1 Shared chunk
44. Shared chunk [2-3] Chunk1 Shared chunk
45. Shared chunk [2-3] Chunk1 Shared chunk
46. Shared chunk [2-3] Chunk1 Shared chunk
47. Shared chunk 47 Base operating system
48. Shared chunk 48 Base operating system Node runtime
49. Shared chunk 49 Base operating system Node runtime Function code
50. Shared chunk 50 Reason #1: Non-determinism (非決定的)
51. Shared chunk 51 Reason #1: Non-determinism (非決定的)
52. Shared chunk 52 Reason #1: Non-determinism (非決定的) Reason #2: Encryption Key (鍵管理)
53. Convergent encryption (収束暗号化) 53 Chunk 1234
54. Convergent encryption (収束暗号化) 54 Chunk 1234 extra +
55. Convergent encryption (収束暗号化) 55 Chunk 1234 Hash (chunk + extra) extra +
56. Convergent encryption (収束暗号化) 56 Chunk 1234 Hash (chunk + extra) Unique per-chunk key (same for unique chunk-extra pairs) extra +
57. Convergent encryption (収束暗号化) 57 Encrypted chunk 1234 Chunk 1234 Hash (chunk + extra) Unique per-chunk key (same for unique chunk-extra pairs) extra +
58. Convergent encryption (収束暗号化) 58 Encrypted chunk 1234 Chunk 1234 Hash (chunk + extra) Unique per-chunk key (same for unique chunk-extra pairs) Image Manifest chunk1 -> …… …… chunk1234 -> 0xabba extra + AWS Key Management Service (AWS KMS)
59. Convergent encryption (収束暗号化) 59 Chunk 1234 extra + K347 Hash( )
60. Convergent encryption (収束暗号化) 60 Chunk 1234 extra + K347 Hash( ) Chunk 1234 extra + K347 Hash( )
61. Convergent encryption (収束暗号化) 61 Hash( ) Chunk 1234 extra + K347 Hash( ) Chunk 1234 extra + K347 Hash( ) Chunk 1234 extra' + K824 Read more about convergent encryption: Storer et al, “Secure Data Deduplication”, StorageSS’08 Douceur et al, “Reclaiming Space from Duplicate Files in a Serverless Distributed File System”, MSR-TR-2002-30
62. The “state” of Lambda 62 Worker Host Firecracker Input Code Running VM Input Container image
63. The “state” of Lambda 63 Worker Host Firecracker Input Code Running VM Input Container image
64. Cache 64 Dedicated Local Cache Dedicated Local Shared Local Chunk Chunk Chunk Chunk Shared AZ Chunk Chunk Chunk Chunk AWS Key Management Service (AWS KMS) Keys Worker AZ Dedicated Shared Encrypted Plaintext Read/write Read Only Read Only Firecracker microVM
65. Cache 効率 • Chunk の不要な重複を防ぎ Cache 効率を上げる § Key の⽣成 (SHA-256) § Convergent encryption (収束暗号化) § Manifest に Key を貼り付けておく ( Key⾃体の管理は KMS ) • Cache 効率をあげて Cold Start を緩和 65
66. Cell-based Architecture 66 Availability Scale
67. よくある Architecture 67 router Service Application Load Balancer Compute Storage
68. Cell-based Architecture 68 Cell router Service Application Load Balancer Compute Storage Cell 0 Application Load Balancer Compute Storage Cell n Application Load Balancer Compute Storage Cell 1 サービスを「Cell」と呼ばれる複数のデプロイメントスタックに分割する設計パターン
69. Cell-based Architecture - 主要な考慮事項 69 • Cell size • Cell-based アーキテクチャパターン – AZ と リージョンをどう組み合わせるか • Cell Router の堅牢性 – 可能な限り薄い層 • パーティションディメンション Cell 0 Cell Router Service Cell 1 Cell n
70. Cell-based Architecture - BLAST RADIUS 70 障害影響範囲: Region Zone b Zone c Zone a Zone b Zone c Zone a 障害影響範囲: Cell 障害影響範囲: Cell 障害影響範囲: Cell
71. Cell-based Architecture - Deployment 71 セルを利用した段階的なデプロイを採用 https://aws.amazon.com/builders-library/cicd-pipeline/ Source Build Prod Stg Dev Pipeline Cell 1 Cell 2 Cell 3 Cell 4 Cell 5 Cell 6 Wave 1 Wave 2 Wave 3 Wave Cell Deploy Bake time Routing Start Routing
72. Cell-based Architecture - Rebalancing 72 Cell To 1. Copy Cell Router Read OK / Write OK Cell From Data Store Data Store Read NO / Write NO
73. Cell-based Architecture - Rebalancing 73 Cell To 1. Copy Cell Router Read OK / Write NO Cell From Data Store Data Store Read NO / Write NO 3. 同期完了を確認 2. Write stop
74. Cell-based Architecture - Rebalancing 75 Cell To Cell Router Read redirect / Write redirect Cell From Data Store Data Store Read OK / Write OK 6. Cell 受付開始 4. Redirect start 5. Router configured
75. Cell-based Architecture - Rebalancing 76 Cell To Cell Router Read redirect / Write redirect Cell From Data Store Data Store Read OK / Write OK 6. Cell 受付開始 4. Redirect start 5. Router configured
76. Cell-based Architecture - Rebalancing 77 Cell To Cell Router Cell From Data Store Data Store Read OK / Write OK 7. Dispose start
77. Shuffle Sharding 78 Availability
78. No Sharding 79 Workers クライアント全体がワークロード全体に対して負荷分散される方式
79. No Sharding + Poison Pill 80 クライアント全体がワークロード全体に対して負荷分散される方式 Poison pill による障害が発生
80. No Sharding + Poison Pill 81 クライアント全体がワークロード全体に対して負荷分散される方式 Poison pill が他の Worker にも流入し全体障害が発生 障害影響範囲 = 100 %
81. Cell-based Sharding 82 Cell Cell Cell Cell クライアントが特定の Cell にアサインされる方式 クライアントはそれぞれのセルに割り当てられる
82. Cell-based Sharding + Poison Pill 83 Cell Cell Cell Cell クライアントが特定の Cell にアサインされる方式 Poison pill による障害が発生
83. Cell-based Sharding + Poison Pill 84 Cell Cell Cell Cell クライアントが特定の Cell にアサインされる方式 Poison pill の影響範囲は Cell に留まる 障害影響範囲 = x 100 = 100/4 = 25 % 1 | Cell 数 |
84. Cell-based Sharding + Poison Pill 85 Cell Cell Cell Cell クライアントが特定の Cell にアサインされる方式 Cell 内の他のクライアント全体が障害影響を受ける
85. Shuffle Sharding 86 クライアントに対して複数の Shard をランダムに割り当てる方式 偏りがなるべくないように、Shard 全体から複数の worker をクライアントに組み合わせる
86. Shuffle Sharding + Poison Pill 87 クライアントに対して複数の Shard をランダムに割り当てる方式 Poison Pill と同じ Shard のクライアントは、一時的に Poison Pill の影響を受けるが、 別の Shard で処理が継続可能
87. Shuffle Sharding + Poison Pill 88 クライアントに対して複数の Shard をランダムに割り当てる方式 障害影響範囲 = x 100 = 100/28 = 3.6 % 1 |組み合わせ数| 8 つのうち 2 つのワーカーを選択する組み合わせは 8C2 = 8!/(2! x 6!) = 28 通り
88. Shard の数と収束の速度 89 Number of processors 1 3 5 8 10 20 50 Processors per tenant (shard size) 1 1 2 3 3 3 3 Number of combinations 1 3 10 56 120 1140 19600 P (2 tenants using same shard) 100% 33% 10% 2% 0.83% 0.0877% 0.00510% P (3 tenants using same shard) 100% 11% 1% 0.0319% 0.0069% 0.0000769% 0.000000260% P (4 tenants using same shard) 100% 4% 0.1% 0.0006% 0.00006% 0.000000067% 0.0000000000133%
89. Shuffle Sharding 90 クライアントに対して複数の Shard をランダムに割り当てる方式 • クライアントからリトライや迅速なフェイルオーバー § 同じことが複数のワーカーで実現できる前提が必要 Shuffle Sharding ユースケース § DNS § セルルーター § ログ収集サービス § レコメンデーション⽤ API サービス § 特定セルの中でさらにレジリエンスを⾼めたい場合
90. Key takeaways 91
91. Lambda とは、、、 92 Security Availability Utilization Performance Scale ⽣産性向上を⽀援するために、Serverless において⼤切にすること 裏側でこれらの技術で支えられているというのを知ることで、 自身のプロダクト/プロジェクト/サービスにも活かせることがある
92. アンケートにご回答ください︕ 93 AWS Icon チョコレート チョコレートでアーキテクチャを作ろう！ コーヒー Thank you!!
93. Thank you! 94 Kensuke Shimokawa Amazon Web Services Serverless Specialist _kensh Slides https://speakerdeck.com/_kensh Qiita https://qiita.com/_kensh アンケートにご回答ください！