ある企業がElastic Beanstalkで受注管理Webアプリケーションを運用しています。注文を受け付けると、PDF領収書の生成（処理時間：約30秒）と外部決済APIへの通知という2つのバックグラウンド処理が必要です。現在はHTTPリクエスト内で同期的に処理しているため、エンドユーザーへのレスポンスが大幅に遅延しています。Elastic Beanstalkのエコシステムを最大限に活用し、最小限のアーキテクチャ変更でこの問題を解決する最善の方法はどれですか？
Elastic Beanstalk Workerティアはバックグラウンドの長時間処理を非同期実行するために設計された専用機能です。Workerティア環境では sqsd（SQS デーモン）が自動的にSQSキューからメッセージを取得し、アプリケーションの指定エンドポイントにHTTP POSTでルーティングします。Webティアは即座にレスポンスを返せるようになり、スケーリングもBeanstalkが管理します。 選択肢AのWebサーバーのインスタンスタイプを上位のものにスケールアップは、コスト増加を招くうえ、30秒の同期処理という根本問題は解決しません。非同期アーキテクチャへの移行が必要です。 選択肢CのAWS Lambda関数を2つ作成は、LambdaのInvocationType=Eventによる非同期呼び出しも技術的には有効ですが、Elastic Beanstalkを使用しているコンテキストでWorkerティアを活用する方がAWSの推奨パターンであり、インフラ管理の複雑さも最小限です。また Lambdaには15分の実行時間制限があります。 選択肢DのWebアプリケーションコードにPythonスレッドを追加は、Webサーバープロセス内でスレッドを使う方法はWebサーバーのメモリとCPUを消費し、スケールアウト時に各インスタンスが独立してキューを持たないため処理の重複や欠落が起きやすく、耐障害性が低下します。