Amazon SES によるメール送信ログを保存する
はじめに
システム運用を行う上で、何らかの理由でシステムからメールが送信されたかどうかを確認したい場面がしばしばあります。もしメール送信に Postfix を使用している場合、その送信ログは通常 /var/log/maillog に保存されるため、このログを確認することでメール送信の有無を把握できます。一方で、プログラムから Amazon SES を利用して API 経由でメールを送信する場合には、AWS 上には「どの時間帯に何通のメールを送信したか」という情報のみが保存されるため、詳細なログは自動的には残りません。 Amazon SES は CloudWatch Logs と直接連携する機能を標準で提供しておらず、メール送信の詳細を CloudTrail で追跡することもできません。そのため、後からメール送信の詳細を参照できるように、適切なログ保存の仕組みを自身で構築する必要があります。
この記事では、Amazon SES のメール送信ログを効果的に保存する方法について詳しく説明します。
Amazon SES 設定セットの利用
Amazon SES を使用してメールを送信する際には、送信用のIDを設定します。このIDには、デフォルトで設定セット(Configuration Sets)を関連付けることが可能です。設定セットは、メール送信時の特定のルールや挙動を管理するための機能であり、この機能を用いることで、メール送信に関する詳細なイベントログを追跡し、データを他の AWS サービスへ送信することができます。
API を使用してメールを送信する際には、特定の設定セットを指定することも可能ですが、指定がなければデフォルトの設定セットが利用されます。このため、デフォルト設定としてログの送信を記録する設定セットをあらかじめ関連付けておくことで、メール送信時のログが自動的に保存されるようになります。
システム実装の具体例
設定セットの送信先としてCloudWatchが利用可能ですが、こちらは主にメトリクスレベルでのデータ連携となります。そのため、CloudWatchへイベントを送信しても、そのイベントの詳細を後から確認することはできません。 そこで、この制限を回避するためにイベントをSNSに通知し、それに基づいてLambda関数をトリガーするというマイクロシステムを構築しています。このLambda関数は、受け取ったイベントデータをDynamoDBに書き込みます。 Lambdaがトリガーされるイベントは設定セットによってカスタマイズすることができます。
マイクロシステム全体の処理の流れは以下の図中の説明を参照してください。
ユースケースに応じて、このデータ保存先をDynamoDBからCloudWatch Logsに変更することも可能です。 また、DynamoDB や CloudWatch Logs は TTL やデータ保持期間の仕組みを利用することで古いデータを自動的に削除してくれるため、そのような仕組みを有効化することで不要なデータを自動的に削除できます。
また、もし生のメールアドレスをログ上に保持したくない場合、メールアドレスをハッシュ化して保存することで具体的なメールアドレスを保有せずに保存できます。 必要であれば、このような仕組みをLambdaの実装で解決することもできます。
おわりに
当初、Amazon SES を使用したメール送信の際には自動的にログが残ると考えていましたが、実際には適切な設定を行わない限り詳細な送信ログは残りません。このため、具体的な実装例を通じて、実際のログ保存方法を紹介しました。
今回の記事では、メール送信インフラ側のログに焦点を当てて説明しました。通常、アプリケーションからのメール送信はアプリケーションのログに記録されることが一般的です。しかし、アプリケーションにログ出力が実装されていない場合や、バッチ処理中にプログラムがハングするなどしてアプリケーションログが不正確になることもあり得ます。このような状況で、どの程度のメール送信が行われたかを後から調査する必要がある場合、インフラレベルでのログが役立つことがあります。