AWS Lambda Service Update at AWS re:Invent 2020

AWS Lambda Service Update at AWS re:Invent 2020

Transcript

1. @_kensh AWS Lambda Update!
2. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Serverless re:Cap 2020 Shimokawa Kensuke Serverless Specialist Solutions Architect @_kensh
3. Who am I? Name Kensuke Shimokawa Company Amazon Web Services Japan K.K. Role Serverless Specialist Solutions Architect @_kensh
4. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
5. Container Image Support
6. • コンテナとLambdaベースのアプリケーションに一貫したツールセット を提供 • 最大10GBの大規模なアプリケーションをデプロイ可能に • Example: ML, data analytics, large dependencies • 高可用性、AWSサービスとの統合、使用分の支払い Container Image Support Lambda関数をコンテナイメージとしてパッケージおよびデプロイします
7. Create Function for ZIP functions (これまで、そしてこれからも) Customer Code Invoke Lambda Function Status: ACTIVE Amazon Simple Storage Service (S3) (S3 required if deployment package >50 MB) ZIP archive CreateFunction AWS Lambda Status: PENDING
8. Container Developer Experience CREATE FUNCTION AS CONTAINER IMAGE docker push Amazon Elastic Container Registry container image Upload image to registry Invoke Status: ACTIVE Ready for invoke Lambda Function Container Image 1. Pull image from ECR 2. Optimize image 3. Deploy image to Lambda CreateFunction container image Status: PENDING AWS Lambda
9. コンテナイメージ、レジストリについて Lambda support for container のイメージマニフェスト • Docker Image Manifest V2 Schema 2 • Open Container Initiative (OCI) Spec (v1.0 and up) Lambda における container registriesサポート状況: • AWS Elastic Container Registry (ECR)
10. AWSが配布するLambdaベースイメージ • Lambda provided base images • AWSによるイメージパッチ • dotnetcore2.1, dotnetcore3.1, go1.x, java8, java8.al2, java11, nodejs12.x, nodejs10.x, python3.8, python3.7, python3.6, python2.7, ruby2.5, ruby2.7, provided.al2, provided • Customer provided base image • linux kernels supported
11. AWS Lambda Runtime Interface Clients (RIC) Lambda Runtime APIの実装 AWS provided base images にはインストール済み open source として、カスタムイメージのために公開されている
12. AWS Lambda Runtime Interface Emulator (RIE) • 開発、試験などプロダクション以前の環境で利用可能 • (ie. desktop, ci/cd) • HTTP portでリスニング • リクエストをラップして, 関数にeventとして提供 • オープンソース/download可能
13. コンテナ実装で気をつけること • AWS Lambda Runtime Interface Clientの利用 • Read only file system • 512 MB の writable storage として /tmp を設定 • デフォルト user のみが利用可能 • 実行時には最小限の権限が与えられている
14. Lambda の機能サポート状況 主な機能はサポート済み • Provisioned concurrency, extensions, Elastic File System (EFS), X-Ray, Amazon Virtual Private Cloud (VPC), reserved concurrency, triggers, destinations, etc. ローンチ時点では非対応 • Code Signing • Layers
15. Infrastructure as Code のサポート状況 • Serverless Application Model (SAM) • CloudFormation • Cloud Development Kit (CDK) • Serverless framework • Terraform
16. Lambda API の変更点 – Create Function aws lambda --region <region> create-function \ --function-name <function name> \ --package-type Image \ --image-uri <ECR Image URI> \ --role <function execution role> Note: イメージタグは、関数の作成中にダイジェストへと解決されます。 レジストリのイメージタグを更新しても、関数は更新されません。
17. Lambda container images ( CICD ) Lambda関数 がZIPパッケージに加え 「コンテナイメージ」で作成可能 → 管理⼿段 と CI/CDパイプライン をより適切なものから選択できる Lambda 関数 コーディング ビルドパイプライン ※コンテナイメージには、Lambda関数を前提とし Lambda Runtime Interface Libraryの組込み等が必要 ※ローカルテスト実⾏には、 Lambda Runtime Interface Emulatorの組込みが必要 コード リポジトリ (Lambda ZIP) S3 ZIPパッケージ ECR コンテナイメージ ビルドパイプライン (コンテナイメージ) ビルド & パッケージング 開発者からみた テスト・ビルドパイプラインの様式を コンテナの開発スタイルに統⼀できる 関数として デプロイ → 最⼤250MB → 最⼤10GB 関数作成時に Lambda基盤によって 最適化されてデプロイ Amazon S3: Simple Storage Service Amazon ECR: Elastic Container Registry 開発者 ビルド & パッケージング
18. Lambda Extensions
19. Extensions以前のLambdaの可視性 Time Duration 実⾏環境の起動 実⾏環境の停⽌ Invoke Invoke CloudWatchとX-Ray 関数実⾏中の可視性を向上させるためには開発者 は関数ロジック中にコードを埋め込む必要がある
20. AWS APIの拡張 Extensionとは何か? • Lambdaの実⾏環境を拡張することで開発者にライフサイクル管理を可能にする • Internal – Runtime option / 同じプロセス • External – サイドカープロセス : Extensions API (新規追加） • Lambdaのライフサイクルイベントを取得するためにExtensions APIに登録 • 例︓Runtime API: /runtime/invocation/next • 例︓Extensions API: /extension/register , /extension/event/next どのようなユースケースで利⽤可能? • セキュリティ、モニタリング、観測ツールとLambdaとの統合 • 秘匿情報の管理、トークン更新処理、UDP上のメトリクスを取得するためのデー モンの実⾏、Lambda環境から様々な送信先へのテレメトリの直接転送など
21. AWS Lambda API Extensions 可能な限り簡単なリッチな診断情報の取得 ビジネスロジックから⽣成されるログ、メトリクス、トレース、プロファイルの取得とインフラストラク チャによって⽣成されるプラットフォームレベルの情報 テレメトリを安価で信頼性⾼く複数送信先へ転送 複数送信先への転送 – 直接、安価で、信頼性⾼く、⾮同期に実⾏ セキュリティ、運⽤、統制⽤サードパーティーのエージェントを実⾏可能 例︓UDPポートをリスンするStatsDデーモンを実⾏しペイロードを全てロギング。将来はアウトバウン ドのネットワークリクエストをモニタも可能に。 サーバーレスアプリにサードパーティープラットフォームを活⽤ 既にサーバーレス以外で利⽤しているAWSパートナーのログの集約、モニタリング、統制、セキュリテ ィーのソリューションをExtensionsとしサーバーレスでも利⽤
22. Lambdaの拡張されたライフサイクル Invoke Invoke Time Duration 関数実⾏時に実⾏され、 関数処理時以外には実⾏されない クリーンアップと 終了処理の時間を 提供 初期化処理 実⾏環境の起動 実⾏環境の停⽌
23. • Lambda Layerにより提供 • ライフサイクルイベント Extensions API により登録 • init • invoke • shutdown Lambda Extensions Lambdaライフサイクルイベントを受信して制御 Invoke Invoke Invoke time Extension Init Runtime Init Function Init Extension Shutdown Runtime Shutdown • 主なユースケース: • Monitoring • Configuration • Security
24. Extensionsの動作について ベースライン ExtensionsなしのLambda関数 関数より早くExtensionsが終了 リソースが競合するのでExtensions が関数のパフォーマンスに影響を与 える Extensionsが関数より長く実行 Extensionsが関数を超えて実行され た場合、オーバーヘッドとして記録 されレポートされる Extensionsを含む実⾏時間が課⾦対象となる PostRuntimeExecutionDuration MaxMemoryUsed
25. パッケージング、配置 、ブートストラップ extensionsはどのように配置、実⾏されるか パッケージング / 配置︓ - ExtensionsはLeyersを通じて配置される ブートストラップ: - LambdaはこれまでのLayersライブラリーローディングメカニズムと同様の ファイルパス規約モデルを利⽤してextensionsを検知 - Lambdaは /opt/extensions/ ディレクトリ内のextensionsを実⾏開始する
26. • 自作可能 • Partner integrations: • Datadog • Lumigo • New Relic • Coralogix • Honeycomb • Sumo Logic Logs API Lambda実行環境から直接ログストリームを送信 ※オプションで、IAMパーミッションを介したCloudWatchLogs へのロギングを無効化
27. Lambda (Others)
28. AWS Lambdaの課⾦単位が100msから1msに • AWS Lambdaの課⾦単位がより⾼精度になり、従 来の100msから1msに変更された • これまでは100ms単位で切り上げのルールだったので、実⾏に 120msを要した場合は200ms分の⽀払いが必要だった • 多くのLambda functionでコストが削減されるが、 特に実⾏時間の短いもので効果が顕著 • データストリーミングやインタラクティブなwebの処理は実⾏時 間が短い傾向があり、こういったケースで効果が⼤きい • ユーザ側での変更作業は不要。中国を除く全リー ジョンで2020年12⽉の請求サイクルから適⽤ AWS Lambda Lambda function 0ms 100ms 200ms 関数実⾏ 課⾦対象 0ms 100ms 200ms 関数実⾏ 課⾦対象
29. AWS Lambdaでリソース上限の緩和を発表 • AWS Lambdaのfunctionが利⽤できるリソースの 上限が緩和され、最⼤10GBのメモリを利⽤するよ うに構成できるようになった • Lambdaはメモリ容量に応じてCPUリソースが割 り当てられる。今回のアップデートで最⼤6vCPU が利⽤可能になり、より⾼い演算能⼒を必要とす る処理でパフォーマンス向上が期待できる • この機能を利⽤するにはコンソールや CLI/SDK/SAMなどを介してLambda functionの メモリ割り当てを再設定すれば良い • 東京をはじめとする各リージョンにて利⽤可能 Lambda function 3x larger Lambda function
30. CloudWatch Lambda Insightsが⼀般利⽤開始に • Lambda Functionのパフォーマンス監視やトラブ ルシュート、最適化を可能にする機能 • Functionに関するメトリクスを⾃動的にダッシュ ボードにとりまとめ、メモリリークや新バージョ ンのデプロイによる性能変化を可視化できる • 名前やタグによるフィルタリング機能により分析 が必要なFunctionを絞り込んだり、個々のリクエ ストの問題を掘り下げて解析することも • CloudWatch Log InsightsやService Lensと連携 することでさらに問題の原因究明が容易になる • メトリクスとログの使⽤分について課⾦される Lambda function Amazon CloudWatch
31. AWS Lambda の SQSバッチウィンドウ • SQS利⽤時にバッチウィンドウをサポート • イベントソースとしてSQSを利⽤している際に、Lambda関数を 起動する前の待ち時間を最⼤5分まで設定可能に • 従来は最⼤10個までのメッセージが蓄積されるまで待つ、とい う制御のみだったものが時間ベースで制御できるようになった • 1回のLambdaの呼び出しで最⼤10,000メッセージまで処理可能 なのでLambdaの実⾏回数を減らしコストの最適化が期待できる Amazon Simple Queue Service Message Message Message Message Message Message Message Message Message Message Message Message Message Message Message Message Lambda function
32. • パフォーマンス向上が期待: • 機械学習の推論 • マルチメディア処理 • HPC • 金融モデル計算 • AVX2拡張命令セット • 利⽤するためには⾃⾝のコードやライブラリ がAVX2命令セットに最適化されている必要 があるため注意 AVX2拡張命令セットのサポート 計算集約型関数のパフォーマンスを向上させる Filter Standard With AVX2 Performance Improvement 1. Bilinear 105 ms 71 ms 32% 2. Bicubic 122 ms 72 ms 40% 3. Lanczos 136 ms 77 ms 43% Source: https://unsplash.com/photos/IMXhx6qhvf0. Photo credit: Daniel Seßler.
33. AWS Lambdaでコード署名による検証が可能に • AWS Lambdaでコード署名が利⽤可能になり、署 名済みで信頼できるコードのみがLambdaで実⾏ されることを保証できるようになった • Lambda関数として実⾏されるコードはセキュアだが、デプロイ パイプランはユーザサイドであり保証ができないため、このリス クに対応するためのアップデート • Lambdaはコードのデプロイ時に署名が信頼され た開発者からのものであること、改ざんが⾏われ ていないことを確認する • AWS Signerというマネージドなコード証明サービ スと連携して動作する • 東京を含む各リージョンで利⽤可能
34. AWS LambdaがイベントソースとしてAmazon MQ for Apache ActiveMQをサポート • Amazon MQ for Apache ActiveMQがイベントソースとして選択可能に • Amazon MQメッセージブローカーからの読み取りとメッセージ処理が 容易に • Lambda関数はメッセージがバッチサイズを超えるか、ペイロードが ６MBを超えたときに呼び出される • Lambdaが認証、認可、スケーリング、モニタリング、障害処理の管理 を実施
35. LambdaイベントソースとしてのAmazon MQ • Lambdaは、Apache ActiveMQのみサポート（現時点ではRabbitMQはサポートさ れない） • LambdaはApaceh ActiveMQのメッセージブローカーからメッセージを取得し、 Lambda関数を同期的に呼び出す • 以下の設定上の制約があるので注意 • 認証：ActiveMQ SimpleAuthenticationPluginのみサポート。 • 接続数の制限：ワイヤーレベルプロトコルごとの最大接続数上限がある。詳細はAmazon MQ Developer Guide のQuotas in Amazon MQを参照 • 接続性：ブローカーはパブリックアクセスとVPC内のいずれも作成可能。プライベートなブローカーにアクセ スするためにはすべてのパブリックサブネットにNAT Gatewayを置くか、LambdaのVPCアクセスとAWS STS 、Secrets ManagerのVPCエンドポイントを有効化する • イベント送信先：キュー送信先のみを指定可能 • ネットワークトポロジー：シングルインスタンス、またはスタンバイブローカーのみサポート • プロトコル：LambdaはOpenWrite/Java Message Service(JMS)プロトコルのTextMessageとBytesMessageをサ ポート、それ以外のプロトコルはサポートされない
36. LambdaイベントソースとしてのAmazon MQ • Lambdaはブローカーから読み取る、同じIDを持つ consumer group を作成 • Lambdaは6MBに達するか、タイムアウトするか、バッチサイズに達するまで メッセージをプルする • メッセージはconsumer groupによってBLOBとして取り出されbase64エンコード されてJSONペイロードとして関数に渡される • 最大の関数実行時間は14分 • イベントソースにMQ brokeを選択し、Batch size、Queue Name、Source access Configuration（Secrets ManagerのSecret）を選択しトリガーを有効にする
37. AWS Cloud9向けのAWS IDE Toolkitを発表 • AWS Cloud9向けのAWS Toolkitがリリースされ、 GUIを介してAWSのサービスに対する操作を容易 に実⾏できるようになった • リソースエクスプローラは、LambdaやAPI Gateway、Amazon S3などのリソースを探索し操作可能にする。対応サービスは今 後拡充される予定 • AWS Lambda functionのサポートが強化され、functionを呼び 出したりインポート、デプロイ、削除が容易に。Serverless Application Modelと統合され、IDEから作成・デプロイが可能 に • 2020年12⽉11⽇以降に作成されたCloud9環境に おいてはToolkitが⾃動的に有効になる。これ以前 の環境では近⽇中に有効化できるようになる
38. AWS Lambdaでストリームデータの解析が容易に • AWS Lambdaを⽤いてAmazon Kinesisと Amazon DynamoDB Streamsのストリームデー タを分析する処理を実現しやすくなった • 論理パーティション毎に最⼤15分の区間が重複しない時間枠(タ ンブリングウィンドウ)を設定し、その範囲における合計、平均、 データ数カウントなどの分析処理を記述することが可能に • POSから注⽂情報がストリーミングされている時に、売り上げ集 計をほぼリアルタイムで実⾏することができるようになった • 前のLambda functionで計算した値などの状態データを転送する ことで、複数回にわたってLambda Functionが実⾏されるケー スでも前の処理の結果を引き渡し、続きを継続できる • 追加料⾦不要で、AWS Lambda、Amazon Kinesis、Amazon DynamoDBが利⽤可能な全 リージョンにてご利⽤可能
39. AWS Lambdaでチェックポイントが利⽤可能に • AWS LambdaでKinesis Data Streamと DynamoDB Streamsのデータをバッチ的に処理 する際に、エラー発⽣時挙動を細かく制御可能に • カスタムチェックポイントを利⽤することで処理 エラーが発⽣したメッセージのシーケンス識別⼦ を返却できる • 右の図（上）で6番のメッセージでエラーが発⽣した場合、 functionは6番で失敗が発⽣した情報を返す。それによって、6 番のメッセージから再試⾏をするように構成できるようになった • 処理済みのデータが再実⾏により再び処理されてしまうことを回 避できる • Lambda、Kinesis、DynamoDBが利⽤可能なリー ジョンにて追加料⾦なしで利⽤可能
40. AWS Lambdaを⼀般のKafkaクラスタから実⾏可能に • セルフマネージドなApache Kafkaクラスタのメッ セージによってAWS Lambda functionを起動でき るようになった • Amazon Managed Streaming for Apache Kafkaに加えて、オ ンプレミスやAWSなど任意のインフラで稼働するKafkaクラスタ からのinvokeに対応 • Lambdaの基盤からKafkaクラスタに対して、パブリックIPアド レスかVPCエンドポイントを介して到達可能であることが必要 • メッセージ数がバッチサイズに到達するか、ペイロードサイズが 6MBに到達したタイミングでLambda functionが起動する • メッセージのバッチサイズは最⼤10,000レコードで、複数の パーティションのメッセージが含まれる可能性がある。パーティ ション無いのメッセージの順番は保持される • 東京をはじめ各リージョンで利⽤可能 Amazon Managed Streaming for Kafka AWS Lambda Self managed Kafka cluster AWS Lambda
41. AWS LambdaがSASL/SCRAM認証をサポート • Amazon Managed Streaming for Apache Kafka (MSK)のトピックから起動されたLambda関数で SASL/SCRAM認証によってAWS Secrets Managerからユーザ名とパスワードを取得可能に • SASL/SCRAMはApache Kafkaでサポートされる ⼀般的な認証メカニズム • Amazon MSKをイベントソースとするLambda functionで認証メカニズムとしてSASL/SCRAMを 選択し、利⽤したいSecrets Managerのクレデン シャルを選択することで利⽤できる • 追加コストなしで利⽤可能 AWS Secrets Manager AWS Lambda Amazon Managed Streaming for Kafka credential invoke
42. Thank you! © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.