Amazon SQS をイベントソースとした AWS Lambda 関数のより高速なポーリングスケールアップの紹介

この投稿は、プリンシパルソリューションアーキテクトの Anton Aleksandrov とシニアプロダクトマネージャーの Tarun Rai Madan の投稿を翻訳したものです。

本日、AWS Lambda は、Amazon Simple Queue Service（Amazon SQS）をイベントソースとして構成したスパイクのある Lambda ワークロードのポーリングスケールアップ率を最大 5 倍高速化したことを発表しました。

この機能により、Lambda と SQS を使用してイベント駆動型アプリケーションを構築し、SQS キュー内のメッセージのバースト時に応答性の高いスケーリングを実現します。また、より高速なメッセージ処理を実現するために Lambda 関数または SQS キューを複製する必要性を減らします。

概要

AWS Lambda で最新のイベント駆動型およびメッセージングアプリケーションを構築するお客様は、分離されたアーキテクチャを作成するための基本的なビルディングブロックとして Amazon SQS を使用します。Amazon SQS は、マイクロサービス、分散システム、サーバーレスアプリケーション向けのフルマネージドなメッセージキューイングサービスです。Lambda 関数がイベントソースとして SQS キューをサブスクライブすると、Lambda はキューをポーリングし、メッセージを取得し、取得したメッセージをバッチで関数ハンドラに送信して処理します。メッセージを効率的に消費するために、Lambda はキューの深さの増加を検出し、キューに入れられたメッセージを処理するためのポーラープロセスの数を増やします。

今日まで、Lambda は SQS キューを購読した Lambda 関数に対して 1 分間に最大 60 回の同時実行を追加し、約 20 分で最大 1,250 の同時実行にスケールアップしていました。しかし、お客様の声では、Lambda と SQS を使用して構築する最新のイベント駆動型アプリケーションのいくつかは、メッセージの突然の急増に敏感であり、エンドユーザーのメッセージの処理に顕著な遅延を引き起こす可能性があるとのことでした。SQS キューでメッセージのバーストがあるアプリケーションに Lambda のパワーを活用するために、これらのお客様はより速くスケールアップするための Lambda メッセージポーリングが必要でした。

今日の発表により、SQS キューを購読する Lambda の機能は、メッセージバックログが急増するキューに対して最大 5 倍速くスケールし、1 分間に最大 300 の同時実行を追加し、最大 1,250 の同時実行数にスケールアップできます。このスケーリングの改善は、Lambda と SQS の統合のシンプルさを使用して、特にリアルタイムシステム向けに、受信メッセージの急増時により高速に拡張できるイベント駆動型アプリケーションを構築するのに役立ちます。また、SQS キューでのメッセージの急増時に処理を高速化する利点を提供する一方で、SQS イベントソースごとに最大同時 Lambda 呼び出しを制限する柔軟性を提供し続けます。

SQS による最大同時 Lambda 呼び出しの制御

新しく改善されたスケーリングレートは、イベントソースとして Lambda と SQS を使用するすべての AWS アカウントに自動的に適用されます。取らなければならない明示的なアクションはなく、追加費用もありません。このスケーリングの改善は、お客様がより高速な SQS ポーリングスケールアップを必要とする、より高性能な Lambda アプリケーションを構築するのに役立ちます。関連するダウンストリームが高負荷になる可能性を低減するために、Lambda は関数レベルで予約済み同時実行数（Reserved concurrency）、イベントソースレベルで最大同時実行数（Maximum concurrency）を設定できます。

次の図は、SQS イベントソースの流量を制御するために使用できる設定を示しています。予約済み同時実行数（Reserved concurrency）を使用して関数レベルのスケーリングを制御し、最大同時実行数（Maximum concurrency）を使用してイベントソースのスケーリングを制御します。

予約済み同時実行数（Reserved concurrency）は、関数に割り当てる最大同時実行数です。関数に割り当てられた予約済み同時実行数がある場合、他の関数はその同時実行数を使用できません。

関数にスケールアップするのに十分な同時実行数を確保したい場合は、予約済み同時実行数を使用することを推奨します。SQS イベントソースが Lambda の同時実行をスケールアップしようとしているが、関数がすでに予約済み同時実行数によって定義されたしきい値に達している場合、Lambda サービスはさらなる関数呼び出しを制限します。

これにより、SQS イベントソースがスケールダウンを試み、同時に処理されるメッセージの数が減少する可能性があります。キューの設定に応じて、制限されたメッセージは再試行のためにキューに返されるか、保持ポリシーに基づいて期限切れになるか、デッドレターキュー (DLQ) または失敗の宛先 (on-failure destination) に送信されます。

最大同時実行数（Maximum concurrency）設定を使用すると、イベントソースレベルで同時実行数を制御できます。これにより、イベントソースが Lambda 関数に送信しようとする同時呼び出しの最大数を定義できます。1つの関数に複数の SQS イベントソースが構成されているシナリオでは、各イベントソースの最大同時実行数を個別に定義することで、よりきめ細やかな制御が可能です。SQS イベントソースにレート制御を追加しようとする場合は、より高い柔軟性を提供するために、まず初めに最大同時実行数の設定を評価することを推奨します。

予約同時実行と最大同時実行は補完的な機能であり、併用することができます。最大同時実行数は、ダウンストリームシステムが高負荷になるのを防ぐために呼び出しをスロットルするのに役立ちます。予約同時実行数は、関数が利用可能な同時実行数を確保するのに役立ちます。

シナリオ例

あなたのビジネスはストレージから大量の文書を処理する必要があると考えてください。数時間ごとに、ビジネスパートナーは大量のドキュメントをアカウントの S3 バケットにアップロードします。

回復力（レジリエンシー）のために、アップロードされた各ドキュメントの SQS キューにメッセージを送信するようにアプリケーションを設計したので、誤ってスキップすることなく効率的に処理できます。ドキュメントは、単一のドキュメントを処理するのに約 2 秒かかる Lambda 関数を使用して処理されます。

これらのドキュメントの処理は CPU 使用率の高い操作であるため、1 つの呼び出しごとに 1 つのドキュメントを処理することにしました。Lambda のパワーを使用して、できるだけ多くの同時実行環境に並列処理をファンアウトしたいと考えています。Lambda 関数は、これらのドキュメントを可能な限り迅速にスケールアップし、コストを節約するためにすべてのドキュメントが処理されたらゼロにスケールダウンします。

ビジネスパートナーが 20万件の文書をアップロードすると、20万件のメッセージが SQS キューに送信されます。Lambda 関数は SQS イベントソースで構成され、キューからのメッセージを消費し始めます。

この図は、SQS イベントソースのスケーリング改善の前にテストシナリオを実行した結果を示しています。予想通り、同時実行数は 1 分間に 60 増加することがわかります。900 の同時実行数に徐々にスケールアップし、キュー内のすべてのメッセージを処理するには、約 16 分かかります。

次の図は、SQS イベントソースのスケーリングの改善後に同じテストシナリオを実行した結果を示しています。両方のチャートに使用される時間枠は同じですが、2 番目のチャートのパフォーマンスは優れています。同時実行数は毎分 300 増加します。1,250 の同時実行数にスケールアップするのに 4 分しかかからず、キュー内のすべてのメッセージは約 8 分で処理されます。

この例をデプロイする

サンプルプロジェクトを使用して、自分の AWS アカウントでこのパフォーマンステストを複製します。AWS Cloud Development Kit (CDK) を使用して AWS アカウントのサンプルプロジェクトをプロビジョニングするには、README.md の指示に従ってください。

このサンプルプロジェクトは、20万件のメッセージを処理する大規模なワークロードを実証するように構成されています。アカウントでこのサンプルプロジェクトを実行すると、料金が発生する場合があります。AWS Lambda の料金と Amazon SQS の料金を参照してください。

デプロイしたら、“sqs-cannon” ディレクトリの下にあるアプリケーションを使用して、20万件のメッセージを SQS キューに送信します(もしくは他の数値を設定します)。SQS キューにメッセージを入力するのには数分かかります。すべてのメッセージが送信されたら、README.md で説明されているように SQS イベントソースを有効にし、プロビジョニングされた CloudWatch ダッシュボードのチャートをモニタリングします。

新しい AWS アカウントのデフォルトの同時実行数クォータは 1000 です。このクォータの増加をリクエストしていない場合、同時実行数はこの数に制限されます。サービスクォータを使用するか、アカウントチームに連絡して同時実行数の増加をリクエストしてください。

セキュリティのベストプラクティス

Lambda 関数に SQS キューへのアクセスを許可するときは、常に最も特権の低い権限を使用してください。これは、特定の機能のみが特定のキューに対して特定のアクションを実行する権限を持つようにすることで、潜在的な攻撃面を減らします。たとえば、関数がキューからのみポーリングする場合は、メッセージを読む権限を付与しますが、新しいメッセージを送信する権限は付与しません。関数実行ロールは、関数が他のリソースで実行できるアクションを定義します。キューアクセスポリシーは、このキューにアクセスできるプリンシパルと、許可されるアクションを定義します。

サーバーサイド暗号化(SSE)を使用して、暗号化された SQS キューに機密データを保存します。SSE では、メッセージは常に暗号化された形式で保存され、SQS は許可された消費者に送信するためにのみ復号化します。SSE は、SQS が管理する暗号化キー (SSE-SQS) または AWS Key Management Service で管理されるキー (SSE-KMS) を使用して、キュー内のメッセージの内容を保護します。

まとめ

改善された Lambda の SQS イベントソースポーリングスケールアップ機能は、SQS キューを使用したスパイクのあるイベント駆動型ワークロードのスケールアップパフォーマンスを追加料金なしで最大 5 倍高速化できます。この改善は、SQS キューのメッセージの急増時に処理を高速化するメリットを顧客に提供しますが、イベントソースとして SQS による最大同時実行数を制限する柔軟性を提供し続けます。

より多くのサーバーレス学習リソースについては、Serverless Land をご覧ください。

翻訳はソリューションアーキテクトの淡路が担当しました。原文はこちらです。