2024.10.17この記事は約3分で読めます。AWSにデプロイしたLaravelアプリケーションからメールが送信できない事象が発生しました。調査した点、原因について解説します。発生したことの詳細AWSにデプロイ済みのLaravelアプリケーションからメールが送信できていないことが確認されました。アプリケーションには本番環境とステージング環境がありますが、ステージング環境でのみ発生していました。本番環境ではメールが送信され受信できています。そのため、この問題は以前から認知されていましたが放置されていました。今回、他の機能の改修の動作確認のために必要になったので修正することになりました。・本番用とステージング用のEC2インスタンス、RDSインスタンスが用意されています。・双方がひとつのSESインスタンスを用いてメール送信を行っています。本番用とステージング用のソースコードに差異がないことは確認しています。.envファイルにも、別々に用意したAWSインスタンスに関係しない点に差異はありませんでした。プロジェクトファイルに問題はないということになります。続いて、AWSインスタンスの設定を確認します。VPCなどの設定に問題はなく、各インスタンスが正しく接続されている様子でした。Laravelのソースコードのところどころにログ出力を設定します。送信ボタン押下時にフォーム内容を出力するログは設定されていました。・送信先のアドレスを入力するフォーム画面に遷移したときに確認ログ・送信先の情報を確認する画面に遷移したときにフォーム内容を出力を新たに加えました。すべてのログが正しく出力されています。そこで、より細かくメール送信処理にログ出力を挟みました。→メールを作成し送信処理を非同期処理のキューに追加すると、キューに追加する処理付近に挟んだログのみが出力されていませんでした。ここで本番環境とステージング環境の差異が見つかります。メールの送信処理を行うクラスインスタンスを非同期処理のキューに渡しているのですが、インスタンスのプロセスを確認するとこれを処理するプロセスがステージング環境では動いていませんでした。queue:workが動いていませんでした。試しにコマンドを実行するとすぐに二十数件のメールが送信されました。SESのパフォーマンスに影響するので止めておきます。プロセスが停止していた原因は特定できていません。いかんせん、いつから発生していた問題なのかが分からず、特定するための情報が少ないのです。queue:restartを実行したのでしょう。restartという見かけに反して停止するためのコマンドのため、変更を加えたあとにプロセスを再起動しようとしたのかもしれません。前述則りSESの送信上限やスパム評価などに影響するため、単にプロセスを再度動かすだけでは最善ではありません。直接キューを全削除してからプロセスを再起動するのがよいでしょう。queue:workをデーモン化して実行していたので、再度supervisordを動かすだけで解決しました。原因アプリケーションからメールが送信されなかった原因は、メール送信処理のキューが処理されず溜め込まれていたことでした。キューの処理が止まっていたのかは未だ不明です。