はじめに

こんにちは、ウォンテッドリーのEnablingチームでバックエンドエンジニアをしている冨永(@kou_tominaga)です。Enablingチームでは技術的な取り組みを社外にも発信すべく、週替わりで技術ブログをリレー形式で執筆する事となりました。この技術ブログは第1回目の投稿です。

採用管理システムのWantedly Hireにメール受信機能を実装しました。メール受信は一見単純そうに見えますが、信頼性や安全性を考慮すると様々な検討事項があります。

この記事を通して、メール受信機能を実装する際の設計判断や考慮点について理解を深めていただければ幸いです。特に、AWSのSES（Simple Email Service）やSQS（Simple Queue Service）を使ったシステム設計に興味がある方に参考になる内容となっています。

背景

Wantedly Hireは採用活動を効率化するためのシステムで、候補者と採用担当者のコミュニケーションを円滑にする機能を提供しています。

これまで、システムから候補者へのメール送信機能はありましたが、候補者からの返信メールはメールクライアントで確認する必要がありました。「候補者とのやり取りを一箇所で完結させたい」という要望を寄せられていました。そこで、候補者が送信したメールを以下画像のようにWeb画面上で確認できる機能を追加することになりました。

課題

メール受信機能を実装するにあたり、以下のような課題がありました。

1. セキュリティ: 外部からのメールを安全に受け取る方法
2. 信頼性: メールの紛失を防ぎ、確実に処理する方法
3. 監視: メール処理の失敗を検知する方法

また、実装方法についても以下の検討が必要でした。

• SNSからの直接Webhook vs SQSポーリング
• メッセージの重複排除
• 監視設計

やったこと（取り組み・改善内容）

システム設計

メール受信機能の実装にあたり、以下のAWSサービスを組み合わせたアーキテクチャを採用しました。以下フローはとなります。

1. SMTPクライアントからのメールをAmazon SESで受信
2. メールデータをS3に保存
3. メール受信通知をSNSに送信
4. SNSからの通知をSQSにキューイング
5. アプリケーションがSQSをポーリングして通知を取得
6. 通知に含まれるS3のキーを使ってメールデータを取得

シーケンス図にすると以下になります。

設計上の意思決定

実装にあたり、いくつかの重要な意思決定がありました。

1. メールサービスプロバイダーからの直接Webhook vs SQSポーリング

• • 当初はメールサービスプロバイダー(SendGridなど)から直接HTTPエンドポイントを叩く方法も検討しましたが、以下、セキュリティと信頼性の観点からSQSを経由する方法を選択しました
  • セキュリティ面：WebhookのURLが漏洩した場合、認証や署名の検証などの対策がないと悪用されるリスクがあるため。SNSのWebhookは署名付きのメッセージを検証する設計だがSQSを使えばURL自体の露出を避けられ、不要なアクセスリスクを最小化できます
  • 信頼性面：アプリケーションのダウンタイム中にSNSからのWebhookが失敗してメッセージが破棄されるリスクを避けるため

2. メールサービスプロバイダー（SendGridなど） vs AWS SES （Simple Email Service）

• • 前述の通りSQS を経由する構成を採用したため、AWS SES を使うことでメールの受信データを S3 に保存できる点や SNS・SQS との親和性の高さを活かすことができました。
  • これによりメールの受信処理においても、信頼性の高い構成を実現しています。

3. メッセージの重複排除

• • SQSのvisibility timeoutでは厳密に重複の排除ができないので、アプリケーションでの対応が必要でした
  • SNSから直接受け取る場合もSQSを使う場合も同様の課題があるため、アーキテクチャ選択に大きな影響はありませんでした

4. 監視設計

メール処理の失敗を検知するため以下の監視を実装しました。

• • DLQ（Dead Letter Queue）へのメッセージ流入の監視
  • キュー内の最も古いメッセージの経過時間（ApproximateAgeOfOldestMessage）の監視
  • 閾値は運用を通じて調整することとし初期値として10分を設定

ロングポーリングの実装

SQSからメッセージを受け取るために、ロングポーリングを実装しました。ロングポーリングは専用のワーカープロセスで実行され以下の特徴があります。

• 専用のワーカーからロングポーリングを実行
• 最大10秒間のロングポーリングでSQSからメッセージを受信
• 受信したメッセージをエンキュー
• エラーハンドリングとエラー通知サービスへの通知

メッセージの重複排除

SQSはat-least-once配信を保証するため、同じメッセージが複数回配信される可能性があります。これに対処するためメールのメッセージIDを保存して、処理時に確認する方法で冪等性を確保しました。

監視設計

メール受信機能の監視として以下設定をしました。

1. SQSキューの監視

• • キューの深さ（未処理メッセージ数）
  • 処理の遅延時間
  • 古いメッセージの検出

2. デッドレターキュー（DLQ）の監視

• • DLQへのメッセージ流入の検知
  • アラート設定

3. ロングポーリングプロセスの監視

• • プロセスの生存確認
  • リソース使用状況（CPU、メモリ）

結果

メール受信機能の実装により以下のような成果が得られました。

1. ユーザー体験の向上

• • 採用担当者がWantedly HireのWeb画面上で候補者からのメールを確認できるようになった
  • メールのやり取りが一箇所で完結するようになり業務効率が向上

2. システムの信頼性

• • SQSを利用することで、一時的なシステム障害時もメールを失うことなく処理できる
  • 監視体制の整備により問題の早期発見・対応が可能に

3. セキュリティの確保

• • 外部からのメールを安全に受け取る仕組みを構築
  • SESとSQSの組み合わせにより、外部からの直接アクセスを制限

まとめ

メール受信機能の実装は一見シンプルに思えますが、信頼性・セキュリティ・監視など、さまざまな観点から設計を検討する必要があります。本記事が、同様の機能を検討・実装される際の参考になれば幸いです。