[レポート]AWS Lambda非同期処理のベストプラクティス #SVS406 #reinvent

本記事はAWS re:Invent 2019のセッション「Asynchronous-processing best practices with AWS Lambda」のレポートです。

概要

日本語訳

ワークロードが完了するのを待つのは費用がかかり、貴重なシステムを保護するためにトラフィックの流れを制御するのは困難です。 AWS Lambdaイベント呼び出しは、イベント駆動型のコンピューティングソリューションと非同期トラフィックドライバーの両方を提供しますが、「非同期の大規模な」部分はそれ自体が特質です。このセッションでは、Lambdaが非同期処理を行う方法と、Lambdaの使用に関するベストプラクティスを学びます。また、その非同期トラフィックをより適切に監視および制御できるように、主要な機能についても詳しく説明します。

原文

Waiting around for your workload to finish is expensive, and controlling the flow of traffic to protect your precious system is hard. AWS Lambda event invocations provide both an event-driven compute solution as well as an asynchronous traffic driver—but the "asynchronous at scale" part is its own particular beast. In this session, learn how Lambda does asynchronous processing and best practices around using it. We also dive into key features to help you better monitor and control that asynchronous traffic.Waiting around for your workload to finish is expensive, and controlling the flow of traffic to protect your precious system is hard. AWS Lambda event invocations provide both an event-driven compute solution as well as an asynchronous traffic driver—but the "asynchronous at scale" part is its own particular beast. In this session, learn how Lambda does asynchronous processing and best practices around using it. We also dive into key features to help you better monitor and control that asynchronous traffic.

スピーカー

• Cecilia Deng - Software Engineering Manager, Amazon Web Services

レポート

アジェンダ

• 非同期を使用する理由
• AWS Lambdaを使用して非同期を管理する
  • Amazon SQSイベントソース
  • ストリームイベントソース
  • 非同期呼び出し
• AWS Lambda非同期呼び出し：内部

非同期を使用する理由

なぜ非同期なのか

• レイテンシーの緩和
  • 呼び出し元は処理結果を待つ必要がない
  • 呼び出し元は他の処理を行うことができる
• Resiliency(復元力)
  • リクエストを処理する時間の違いを吸収できる
    • エラー処理
    • スロットル処理

なぜバッファリングするのか？

非同期の理由を考えるときはバッファリングする理由を考えることも重要

• バッファがないということは、ドロップ（処理が失われる）する可能性がある
  • 常に何らかの遅延が発生し補う方法がない
  • システム全体に伝播され回復力がさらに低下
• バッファは損失を回避するために重要
• トラフィックの急増、エラー処理に対する回復力のためにバッファが必要

トレードオフ

非同期について考えている場合のトレードオフは何ですか？

• サービスがどれだけの着信トラフィックを処理できるか
• 待ち時間、タイムアウトはどの程度か？
• 未処理の扱いが重要

AWS Lambdaを使用して非同期を管理する

非同期トラフィックをLambdaに送る方法

• Amazon SQSイベントソース
• ストリームイベントソース
• 非同期呼び出し

非同期がつかいこなせると

• トラフィックの急増に対処できる
• エラー処理にかかる時間を吸収できる
• スロットルなどでリトライできる
• 処理の優先順位付（遅らせる、捨てる）
• 処理率を上げるためには..
  • より頻繁な処理
  • 並列処理

Amazon SQSイベントソース

• バッファーを管理し、SQSにキューイングできる
• DLQの設定、再試行回数、最大受信回数などコントロールできる
• 問題が発生したリクエストはDLQへ
  • メインストリームから分離できメイントラフィックに影響を与えない
  • リクエストは適切なレートで処理される
• 新機能（ 最大イベント経過時間と最大再試行回数）を利用すると、TTL等の設定が可能
• 既存のイベントソースマッピング APIから設定

ストリームイベントソース

• メインストリームから分離して処理することが可能
• キネシスストリームを自分で管理
  • ストリーム内の各シャードを独自のFIFOキューと考えることができる

非同期呼び出し

• リクエストを行うだけ
• 単なる呼び出しであり、タイプはイベント

より強力な処理

• 内部な動作：Lambdaは、着信トラフィックに応じて処理能力（並列スレッドの数）を自動スケーリング
• ストリームイベントソースのカスタムバッチウィンドウを設定して、関数を呼び出す前に最大300秒待機してバッチを構築
  • AWS Lambda が Kinesis および DynamoDB イベントソースのカスタムバッチウィンドウをサポート開始

新機能：並列処理（Parallel processing）

• ストリームイベントソースの並列化係数により、単一のシャードがパーティションキーの順序を保証しながら同時に起動できるLambdaの数を設定できる

AWS Lambda非同期呼び出し：内部

未処理の分離

• キューを共有すると干渉が発生する可能性がある
• シャッフルシャーディングは影響範囲を縮小

可視性

• 通知
  • OnSuccessを使用すると、非同期の結果がリアルタイム通知
  • 呼び出しの結果は、失敗も含めて宛先に送信できる
• 滞留時間
  • ペイロードのイベント時間から滞留時間を計算可
  • イベントが生成されてから実際に実行されるまで
• AWS X-Ray
  • 単一の呼び出しの滞留時間と試行回数をトレースできる

Learn more

関連して以下のセッションがオススメのようです。

• SVS317 Serverless stream processing pipeline best practices
• API304 Scalable serverless event-driven applications using Amazon SQS & Lambda
• SVS405 A serverless journey: AWS Lambda under the hood
• SVS407 Architecting and operating resilient serverless systems at scale

さいごに

「Asynchronous-processing best practices with AWS Lambda」のセッション概要でした。既に動画も公開されていますので、詳しく知りたい方は直接確認してみてください！

• AWS re:Invent 2019: Asynchronous-processing best practices with AWS Lambda