エントリーの編集
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
Amazon SQSワーカーのアーキテクチャーをLambdaイベントソース/EventBridge Pipes/独自の3パターンで比較してみた | DevelopersIO
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
Amazon SQSワーカーのアーキテクチャーをLambdaイベントソース/EventBridge Pipes/独自の3パターンで比較してみた | DevelopersIO
各実装方式の詳細は以下のとおりです 1. Lambdaイベントソース型 Lambdaのイベントソースマッピングを利... 各実装方式の詳細は以下のとおりです 1. Lambdaイベントソース型 Lambdaのイベントソースマッピングを利用すると、SQS・Kinesis Data Streamなど様々なソースにポーリングを行い、Lambdaを呼び出せます。 イベントソースが暗黙にポーリングやSQSメッセージの受信・削除をするため、Lambdaアプリケーションは受け取ったメッセージの処理ロジックだけを記述します。 def lambda_handler(event, context): for message in event['Records']: print(message['body']) 覚えることが少なくて済み、管理も楽なため、SQSコンシューマーの初手としておすすめできる一方で、最大の問題点はLambdaの制約に縛れることです。 メッセージ処理が15分を超えたり、10GBを超える潤沢なメモリが必要だった