AWSでメール非同期送信処理をする為のネットワーク設計

1. AWSでメール非
同期処理

2. 前提

3. 1-1.シナリオ
• AWS-VPC構成
• WEBシステムで『ユーザーリクエストを元
にしてメール送信処理』が走る
• 『ユーザーリクエストは即時返答』し、
『メール送信は後回し』
• メールはSESを使う
• リバウンド等のメール送信エラーについ
て、何らかの処理を行う

4. 方針

5. 2-1.AWS-Native構成
EC2-Frontからメール送信
命令が登録される（①）
②-2
②-1
EC2 - Front
SQSをポーリングして、
キューが登録されたら処
理開始（②-1）
EC2 - Worker
デキューされた処理を元
に、SESにメール送信（②2)
SESエラーが発生すると、
SNS Notificationを元にEC2Workerに処理依頼(③-1)
①
③-2
SQS
③-1
SES
EC2-WorkerはSQSに再処理
用のエンキュー(③-2)

6. 2-1.所感
• SQS/SESをそのまま使うので運用は楽
• 開発～本番全てをAWSで完結する必要有
• SQS in/outが遅いため、パフォーマンスが
出しにくい
• SNS Topics⇒SQSにすれば多少は改善…？
• SQSメッセージサイズが小さいため、
キューで処理したい内容は別ストレージ
に保存

7. 2-2.（多分）最速構成
②-1
EC2 - Front
③-2
EC2-Frontからメール送信
命令が登録される（①）
EC2 - Worker
②-2
③-1
①
EC2 - Redis
SES
N-Virginia Region
EC2-Workerが北米⇒日本に
定期的ポーリングでEC2Redisを監視（②-1）
デキューされた処理を元
に、SESにメール送信（②2)
SESエラーが発生すると、
SNS Notificationを元にEC2Workerに処理依頼(③-1)
EC2-WorkerはEC2-Redisに再
処理用のエンキュー(③-2)

8. 2-2.所感
• N.Virginia EC2(Worker)からAsia Pacific
EC2(Redis) はほぼリアルタイム
• N.Virginia EC2 ⇒ SESもほぼリアルタイム
• VPC内のEC2 Redisへアクセスするため、
ELBを使ってNAT変換
• EC2-Redisが単一障害点
• N.VirginiaにEC2が存在するため、そちらの
フォローが必要（運用・監視等）

9. 2-3.妥協構成
②-2
EC2-Workerが定期的ポーリ
ングでElastiCacheを監視
（②-1）
EC2 - Front
EC2 - Worker
①
③-1
デキューされた処理を元
に、SESにメール送信（②2)
②-1
③-2
ElastiCache
EC2-Frontからメール送信
命令が登録される（①）
SES
N-Virginia Region
SESエラーが発生すると、
SNS Notificationを元にEC2Workerに処理依頼(③-1)
EC2-WorkerはElastiCacheに
再処理用のエンキュー(③2)

10. 2-3.所感
• EC2-Workerはなんでもいいので、リソース
があまっているところを探せば同居も可
能
• シンプル
• ElastiCacheはリージョンを超えられない
• EC2-Worker⇒SESの処理が遅い（1通4秒と
か）
• VPC内で完結
• リアルタイム性を求められないならアリ

11. 以上