xDev Asia

数百万の電子メール送信の問題を分析します: 実際の使用例 (マーケティングキャンペーン、トランザクション電子メール、システムアラート)。機能要件と非機能要件。封筒裏の見積もり。通知チャネルを比較します。

数百万の電子メールを送信する通知システムを設計する

パート 1: 基礎 — 大規模な通知問題を理解する

xdev.asia

はじめに

あなたが 1,000 万人のユーザーを抱える e コマース会社のエンジニアであると想像してください。マーケティングチームは毎月、ユーザーベース全体にニュースレターを送信したいと考えています。フラッシュセールが開催されるたびに、数時間以内に何百万通ものメールを送信する必要があります。このボリュームを処理するにはシステムをどのように設計しますか?

このレッスンは、設計を開始する前に問題を理解するのに役立ちます。

1. 電子メール通知が依然として重要なのはなぜですか?

電子メールは最大のコミュニケーションチャネルです

メトリクス	電子メール	プッシュ	SMS
グローバルユーザー	45億	35億	50億
平均開封率	20-25%	5-8%	95%
メッセージあたりのコスト	$0.0001-0.001	無料	$0.01-0.05
豊富なコンテンツ	✅ HTML、画像	❌限定	❌ テキストのみ
アプリは必要ありません	✅	❌	✅

実際の使用例

トランザクション電子メール (リアルタイム、重要):

注文確認メール
OTP/パスワードのリセット
請求書/領収書

マーケティングメール (バッチ、大量):

週刊ニュースレター
フラッシュセールのお知らせ
製品の推奨事項
再エンゲージメントキャンペーン

システム通知:

DevOps チームへのアラート
スケジュールされたレポート
コンプライアンスの通知

2. 要件を分析する

機能要件

FR-1: Hệ thống phải gửi được email đến danh sách recipients
FR-2: Hỗ trợ email templates với dynamic content (personalization)
FR-3: Scheduling: gửi ngay hoặc đặt lịch gửi
FR-4: Tracking: open rate, click rate, bounce rate
FR-5: Unsubscribe management (CAN-SPAM compliance)
FR-6: Multi-provider support (failover giữa các ESP)
FR-7: Priority levels: critical > high > normal > low

非機能要件

NFR-1: Throughput: gửi 10 triệu email trong 4 giờ (~700 emails/giây)
NFR-2: Latency: transactional email < 30 giây từ trigger đến delivery
NFR-3: Availability: 99.95% uptime
NFR-4: Durability: không mất email đã queued
NFR-5: Scalability: horizontal scaling khi load tăng
NFR-6: Deliverability: inbox placement rate > 95%

3. 封筒裏の見積もり

スループットの計算

Target: 10 triệu emails trong 4 giờ
= 10,000,000 / (4 × 3,600)
= 10,000,000 / 14,400
≈ 694 emails/giây

Peak (2x): ~1,400 emails/giây
With headroom (3x): ~2,100 emails/giây

ストレージの見積もり

Email metadata per record: ~1 KB
  - recipient, subject, status, timestamps, tracking IDs

10 triệu emails × 1 KB = 10 GB metadata/campaign
Giữ 90 ngày history: 10 GB × 30 campaigns = 300 GB

Template storage: ~100 KB/template × 1000 templates = 100 MB
Total: ~300 GB database storage

帯域幅の推定

Average email size (rendered HTML): ~50 KB
10 triệu × 50 KB = 500 GB outbound/campaign
Throughput: 500 GB / 4 hours = 125 GB/h ≈ 280 Mbps

4. 大規模な電子メールを送信する際の課題

技術的な課題

ESP からのレート制限: Amazon SES は 200 メール/秒 (デフォルト)、SendGrid 10,000 メール/秒に制限します
IP レピュテーション: 送信が速すぎる → スパムとしてマークされる
バウンス処理: ハードバウンスはリストから直ちに削除する必要があります。
接続管理: パフォーマンスのための SMTP 接続プーリング
メモリプレッシャー: 数百万のレコードをメモリにロードする

ビジネス上の課題

配信性: 電子メールはスパムフォルダーではなく、受信トレイに到達する必要があります。
コンプライアンス: CAN-SPAM、GDPR、CCPA
コスト: 数百万の電子メールを送信する際のコストを最適化します。
タイミング: 正しいタイムゾーンで最適な時間に送信します。
パーソナライゼーション: 受信者ごとに異なるコンテンツ

5. アーキテクチャの比較: ナイーブと本番環境

❌ 素朴なアプローチ

for each recipient in 10_million_list:
    render_template(recipient)
    send_email_via_smtp(recipient)
    save_to_database(status)

問題:

連続 → 1,000 万の損失 × 0.5 秒 = ~58 日 😱
単一障害点
失敗しても再試行しない
リスト全体をロードするとメモリオーバーフローが発生する

✅ 制作アプローチ (プレビュー)

API Request → Notification Service → Message Queue
    → Worker Pool (N workers) → Email Providers (multi-provider)
    → Webhook callbacks → Status tracking → Analytics

次の記事では、このアーキテクチャについて詳しく説明します。

6. 通知システムの状況

有名な通知システム

システム	スケール	技術スタック
Gmail/Google	1 日あたり 3,000 億メール	カスタムインフラストラクチャ
アマゾンSES	100 億以上/日	AWS ネイティブ
SendGrid (Twilio)	1,000 億以上/月	カフカ、Go、Redis
Mailchimp (Intuit)	6億/日	カスタム、マンドリル

オープンソースの代替案

郵便 - メール配信プラットフォーム (Ruby)
Mailtrain - 自己ホスト型ニュースレター (Node.js)
Listmonk - ニュースレターとメーリングリスト (Go)
Novu - 通知インフラストラクチャ (TypeScript)

概要

この記事では、次のことを学びました。

何百万もの電子メールを送信するという問題はなぜ単純ではないのでしょうか?
機能要件と非機能要件
封筒裏の見積もり
課題を解決する必要がある
実稼働アーキテクチャのプレビュー

次の記事: システム全体の上位設計アーキテクチャを設計します。

レッスン 1: 通知システムの概要 — 何百万もの電子メールの送信の問題